TL;DR – Tóm tắt
ZK-SNARK là hệ thống chứng minh mật mã cho phép prove một tính toán đúng mà không tiết lộ input. Proof cực nhỏ (~200 byte), xác minh cực nhanh (~1ms), nhưng đòi hỏi trusted setup một lần duy nhất. Đây là nền tảng của các ZK Rollup lớn như zkSync Era, Polygon zkEVM và ứng dụng privacy như Zcash. Biến thể PLONK đã giải quyết hạn chế circuit-specific của Groth16, cho phép tái sử dụng trusted setup.
IZK-SNARK là gì?
ZK-SNARK là viết tắt của Zero-Knowledge Succinct Non-Interactive Argument of Knowledge — hệ thống chứng minh mật mã cho phép một bên (prover) thuyết phục bên kia (verifier) rằng một lệnh tính toán đã được thực thi đúng, mà không tiết lộ bất kỳ thông tin nào về dữ liệu đầu vào.
Ý tưởng nền tảng xuất phát từ bài báo kinh điển của Goldwasser, Micali và Rackoff năm 1985 về interactive proof system. Nhưng phiên bản "non-interactive" — tức là không cần trao đổi qua lại nhiều vòng — chỉ trở nên thực tiễn vào đầu thập kỷ 2010 nhờ công trình của Groth, Sahai và Boneh về pairing-based cryptography.
Tên gọi SNARK phân rã như sau:
- Zero-Knowledge (ZK): Verifier không học được gì về witness (input bí mật) ngoài việc biết rằng proof hợp lệ.
- Succinct: Proof size là hằng số hoặc rất nhỏ so với kích thước của tính toán gốc — thường chỉ vài trăm byte.
- Non-Interactive: Chỉ cần một thông điệp từ prover đến verifier, không cần nhiều vòng challenge-response.
- ARgument of Knowledge: Đây là "argument" (dựa trên hardness assumption) chứ không phải "proof" toán học tuyệt đối. Prover phải biết witness thực sự — không thể giả mạo.
Trong blockchain, ZK-SNARK giải quyết bài toán scalability cực kỳ quan trọng: thay vì buộc mọi validator phải replay toàn bộ giao dịch, một prover có thể nén hàng nghìn giao dịch thành một proof nhỏ mà bất kỳ ai cũng có thể xác minh nhanh chóng. Đây là cơ chế cốt lõi của ZK Rollup.
IIBa thuộc tính cốt lõi của ZK-SNARK
Mọi hệ thống ZK-SNARK hợp lệ phải thỏa mãn đồng thời ba thuộc tính sau. Đây cũng là các tiêu chí để đánh giá bảo mật của hệ thống:
1. Completeness (Đầy đủ)
Nếu statement đúng và prover thực sự biết witness hợp lệ, thì verifier sẽ chấp nhận proof với xác suất áp đảo. Nói đơn giản: prover trung thực luôn có thể chứng minh thành công. Đây là tính chất cơ bản nhất — một hệ thống thiếu completeness sẽ reject ngay cả các giao dịch hợp lệ.
2. Soundness (Vững chắc)
Nếu statement sai, một prover gian lận không thể tạo proof được verifier chấp nhận — ngoại trừ với xác suất không đáng kể (negligible probability). Trong ngữ cảnh computational soundness của SNARK, điều này dựa trên hardness assumption như Discrete Logarithm hoặc Bilinear Pairing problem — chứ không phải unconditional. Đây là điểm phân biệt "argument" và "proof" toán học thuần túy.
3. Zero-Knowledge
Verifier không học được gì thêm ngoài sự thật rằng statement đúng. Về mặt kỹ thuật, điều này được định nghĩa bằng cách cho rằng mọi thứ verifier có thể tính toán từ proof đều có thể được một simulator tạo ra mà không cần biết witness. Trong nhiều ứng dụng blockchain công khai như ZK Rollup, thuộc tính ZK thực ra không cần thiết — người ta chỉ cần succinct và soundness. Do đó một số hệ thống được gọi đúng hơn là SNARK không có ZK (ví dụ Groth16 trong một số triển khai).
Ngoài ba thuộc tính trên, hệ thống SNARK thực tiễn còn cần Knowledge Soundness — đảm bảo prover không chỉ chứng minh statement đúng mà còn thực sự "biết" witness. Đây là sự khác biệt giữa "argument of knowledge" và "argument" đơn thuần.
IIITrusted Setup & Common Reference String
Hầu hết các hệ thống ZK-SNARK yêu cầu một giai đoạn thiết lập trước (setup phase) để tạo ra Common Reference String (CRS) — bộ tham số công khai mà cả prover lẫn verifier đều dùng. Đây là điểm mấu chốt và cũng là điểm yếu lớn nhất của SNARK.
Toxic Waste — Rủi ro cốt lõi
Trong quá trình tạo CRS, người thực hiện setup phải tính toán với một giá trị bí mật ngẫu nhiên (thường gọi là toxic waste hoặc trapdoor). Sau khi CRS được tạo xong, toxic waste phải bị hủy hoàn toàn. Nếu bất kỳ ai giữ lại toxic waste, họ có thể:
- Tạo proof giả cho bất kỳ statement nào — kể cả statement sai.
- Giả mạo giao dịch không tồn tại trong ZK Rollup.
- Tạo tiền từ không khí (trong trường hợp privacy coin như Zcash).
Powers of Tau — Lễ nghi bảo mật tập thể
Giải pháp thực tiễn là tổ chức Multi-Party Computation (MPC) ceremony — còn gọi là "Powers of Tau". Nhiều bên tham gia lần lượt, mỗi bên thêm vào một lớp ngẫu nhiên riêng của mình. CRS cuối cùng chỉ bị compromise nếu TẤT CẢ người tham gia thông đồng với nhau. Zcash tổ chức ceremony với hàng trăm người tham gia từ nhiều quốc gia khác nhau để đảm bảo tính an toàn.
Đây cũng là lý do PLONK được đón nhận rộng rãi hơn Groth16: PLONK dùng universal trusted setup — chỉ cần setup một lần cho mọi circuit, trong khi Groth16 cần setup riêng cho từng circuit cụ thể.
IVKiến trúc kỹ thuật: Từ computation đến proof
Để hiểu ZK-SNARK hoạt động, cần nắm quy trình chuyển đổi từ một chương trình thông thường sang một proof toán học. Quy trình này gồm nhiều bước trừu tượng hóa liên tiếp.
Bước 1: Arithmetic Circuit
Đầu tiên, chương trình cần chứng minh được biểu diễn dưới dạng arithmetic circuit — một mạng lưới các cổng cộng (+) và nhân (×) trên một trường hữu hạn (finite field). Mỗi wire trong circuit mang một giá trị trường. Ví dụ, phép tính x² + y = z trở thành circuit với cổng nhân (x×x) rồi cổng cộng (+y).
Bước 2: R1CS — Rank-1 Constraint System
Circuit được chuyển sang dạng R1CS — một hệ phương trình ràng buộc dạng (a·w)(b·w) = c·w trong đó w là vector chứa tất cả giá trị wire. Mỗi gate trong circuit tạo ra một constraint. Nếu w thỏa mãn toàn bộ các constraint, thì computation đúng.
Bước 3: QAP — Quadratic Arithmetic Program
R1CS được chuyển tiếp sang QAP thông qua Lagrange interpolation. Các constraint giờ trở thành các đa thức, và việc thỏa mãn R1CS tương đương với việc một đa thức nhất định chia hết cho một đa thức target đã biết trước. Đây là nơi phép toán pairing trên elliptic curve được đưa vào để tạo ra proof súc tích.
Bước 4: Elliptic Curve Pairing
Proof cuối cùng bao gồm vài phần tử trên elliptic curve (thường là BN254 hay BLS12-381). Verifier kiểm tra tính hợp lệ bằng cách tính bilinear pairing — một phép toán đặc biệt trên elliptic curve cho phép xác minh quan hệ giữa các đa thức mà không cần biết đa thức gốc. Đây là lý do proof có thể nhỏ như vậy — tất cả thông tin được "nén" vào vài phần tử curve.
VGroth16 và PLONK — Hai biến thể phổ biến nhất
Trong thực tế, có nhiều hệ thống SNARK với đánh đổi khác nhau. Hai biến thể được dùng rộng rãi nhất trong blockchain là Groth16 và PLONK.
Groth16
Được Jens Groth đề xuất năm 2016, đây là hệ thống SNARK hiệu quả nhất về kích thước proof và tốc độ xác minh:
- Proof size: Chỉ 3 phần tử elliptic curve (~200 byte trên BN254).
- Verification time: ~1ms — đủ nhanh để thực hiện on-chain.
- Nhược điểm: Circuit-specific trusted setup — mỗi circuit cần một ceremony riêng. Không thể cập nhật circuit mà không làm lại từ đầu.
Groth16 được dùng trong Zcash (Sapling protocol), Hermez 1.0 và nhiều ZK Rollup thế hệ đầu. Chi phí verification gas trên Ethereum khoảng 500k–1M gas.
PLONK và họ hàng
PLONK (Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge) ra đời năm 2019 với cải tiến quan trọng: universal & updatable trusted setup.
- Một ceremony duy nhất có thể dùng cho mọi circuit — miễn là circuit không vượt quá giới hạn kích thước đã setup.
- Proof size lớn hơn Groth16 (~1–2 KB) nhưng linh hoạt hơn nhiều.
- Cho phép thêm tính năng mới mà không cần làm lại ceremony.
Từ PLONK, nhiều biến thể mạnh hơn ra đời: TurboPlonk (dùng bởi Aztec), UltraPlonk (hỗ trợ lookup arguments), HyperPlonk. zkSync Era dùng hệ thống PLONK-based tùy chỉnh, Polygon zkEVM cũng tương tự.
HALO2 — Không cần trusted setup
HALO2 (dùng bởi Zcash và zkEVM của Scroll) là hệ thống SNARK-like loại bỏ hoàn toàn trusted setup bằng cách dùng inner product argument (IPA) thay cho pairing. Proof lớn hơn nhưng bảo mật mạnh hơn về mặt giả thuyết.
VIZK-SNARK vs ZK-STARK — So sánh chi tiết
Hai nhánh chính của zero-knowledge proof trong blockchain là SNARK và STARK. Mỗi loại có ưu điểm riêng phù hợp với use case khác nhau.
| Tiêu chí | ZK-SNARK | ZK-STARK |
|---|---|---|
| Trusted setup | Cần (trừ HALO2) | Không cần |
| Proof size | Rất nhỏ (~200B – 2KB) | Lớn hơn (~100KB) |
| Verification time | Rất nhanh (~1ms) | Nhanh hơn proving |
| Proving time | Chậm hơn STARK | Nhanh hơn SNARK |
| Quantum resistance | Không (dựa vào EC) | Có (hash-based) |
| Nền tảng toán học | Elliptic curve pairing | Hash functions, FRI |
| On-chain gas | Thấp hơn | Cao hơn |
Trong thực tế, nhiều dự án kết hợp cả hai: StarkNet dùng STARK để prove execution, sau đó dùng SNARK để "wrap" proof STARK lại cho rẻ hơn khi verify on-chain — đây gọi là recursive proof hay proof aggregation.
VIIỨng dụng thực tế của ZK-SNARK trong blockchain
1. ZK Rollup — Scaling Ethereum
Đây là ứng dụng lớn nhất hiện tại. Trong ZK Rollup, một sequencer xử lý hàng nghìn giao dịch off-chain, sau đó một prover tạo ra SNARK chứng minh tất cả giao dịch đó được thực hiện đúng. Smart contract trên Ethereum (Layer 1) chỉ cần verify proof này — tiết kiệm ~100x gas so với thực thi từng giao dịch riêng lẻ.
- zkSync Era: Dùng Boojum (PLONK-based), hỗ trợ EVM-compatible.
- Polygon zkEVM: Dùng PIL/PLONK tùy chỉnh để prove EVM execution.
- Scroll: Dùng HALO2 để prove EVM bytecode.
- Linea (Consensys): Dùng PLONK-based prover.
2. Privacy Coins — Zcash
Zcash là blockchain đầu tiên triển khai ZK-SNARK vào production (2016). Người dùng có thể gửi giao dịch "shielded" — ẩn hoàn toàn sender, receiver và số tiền — bằng Groth16 SNARK. Chỉ bên có viewing key mới đọc được thông tin giao dịch.
3. Cross-chain Bridge Verification
Thay vì dùng multisig (dễ bị hack như Ronin Bridge), các bridge thế hệ mới như Succinct Labs và Polyhedra dùng SNARK để prove trạng thái của chain nguồn. Bridge smart contract chỉ cần verify proof, không cần tin tưởng bất kỳ committee nào.
4. Identity & Credential Proof
ZK-SNARK cho phép prove "tôi đủ 18 tuổi" mà không tiết lộ ngày sinh, hay "tôi có đủ balance" mà không tiết lộ số dư chính xác. Polygon ID và zkPass là ví dụ ứng dụng trong Web3 identity.
5. Verifiable Computation
Outsourcing tính toán nặng ra cloud, sau đó dùng SNARK để prove kết quả đúng. Đây là nền tảng của nhiều dịch vụ prover-as-a-service đang nổi lên.
VIIIGiới hạn hiện tại và hướng phát triển
Proving time còn chậm
Tạo SNARK proof cho một batch giao dịch trên zkEVM vẫn mất từ vài phút đến hàng giờ, tùy circuit. Đây là bottleneck chính ảnh hưởng đến finality time của ZK Rollup. Giải pháp đang theo đuổi: GPU/FPGA prover acceleration, parallel proving, recursive proof aggregation.
Circuit complexity — zkEVM là bài toán khó
Prove EVM execution là cực kỳ phức tạp vì EVM không được thiết kế với ZK-friendly computation trong đầu. Mỗi opcode EVM cần hàng trăm đến hàng nghìn constraint. Một block Ethereum thông thường có thể tương đương hàng triệu constraint khi prove bằng SNARK.
Quantum threat
Hầu hết SNARK dựa trên elliptic curve pairing sẽ bị phá vỡ nếu máy tính lượng tử đủ mạnh xuất hiện. Đây là lý do STARK (dựa trên hash function) được cho là future-proof hơn. Tuy nhiên, quantum computer đủ mạnh vẫn còn rất xa trong tương lai.
Xu hướng: Recursive SNARK & Proof Aggregation
Recursive proof — một SNARK prove tính đúng đắn của một SNARK khác — cho phép xây dựng chuỗi chứng minh không giới hạn. Mina Protocol dùng recursive SNARK để giữ blockchain size chỉ ~22KB bất kể lịch sử giao dịch. Kỹ thuật này cũng được dùng để aggregate nhiều proof Layer 2 thành một proof duy nhất trước khi post lên Layer 1.
❓Câu Hỏi Thường Gặp
Không nhất thiết. Nhiều ZK Rollup sử dụng SNARK nhưng không kích hoạt tính năng zero-knowledge — tức là dữ liệu giao dịch vẫn public. Họ chỉ dùng tính "succinct" và "soundness" để tiết kiệm chi phí verification. Khi người ta nói "ZK Rollup" thường ám chỉ rollup dùng SNARK/STARK proof, không nhất thiết ẩn dữ liệu giao dịch.
Có, đây là rủi ro nghiêm trọng. Nếu toxic waste từ trusted setup bị lộ và kẻ tấn công khai thác, họ có thể tạo proof giả cho bất kỳ statement nào — bao gồm việc giả mạo giao dịch hoặc tạo tiền ảo không có thật. Đó là lý do các dự án tổ chức MPC ceremony với hàng trăm người tham gia để đảm bảo không ai đơn phương có thể compromise setup.
Đây là đặc tính cơ bản của SNARK: asymmetric computation. Prover phải thực hiện các phép tính đa thức và elliptic curve nặng trên toàn bộ circuit — tốn kém theo kích thước circuit. Verifier chỉ cần kiểm tra vài phép pairing cố định — O(1) complexity. Sự bất đối xứng này chính là "phép màu" cho phép SNARK scale: một prover đắt tiền giúp cho mọi verifier rẻ tiền.
Không có câu trả lời tuyệt đối. SNARK cho proof nhỏ hơn và verification rẻ hơn on-chain — phù hợp khi gas cost là ưu tiên. STARK không cần trusted setup và kháng quantum — phù hợp khi bảo mật dài hạn quan trọng hơn. Nhiều dự án dùng STARK để prove execution rồi wrap bằng SNARK để submit on-chain, tận dụng điểm mạnh của cả hai.
📚Tài liệu tham khảo
- Groth, J. (2016). "On the Size of Pairing-based Non-interactive Arguments." EUROCRYPT 2016.
- Gabizon, A., Williamson, Z. J., & Ciobotaru, O. (2019). "PLONK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge."
- Ben-Sasson, E. et al. (2019). "Scalable transparent arguments and post-quantum." CRYPTO 2019. (ZK-STARK paper)
- Zcash Foundation. "Zcash Protocol Specification" — sapling-crypto section. zips.z.cash
- Ethereum Foundation. "Proof systems." Ethereum.org Developer Docs.
- Boneh, D., & Shoup, V. "A Graduate Course in Applied Cryptography." Chapter 14: Elliptic curves.
- Bowe, S., Gabizon, A., & Green, M. (2018). "A Multi-Party Protocol for Constructing the Public Parameters of the Pinocchio zk-SNARK."