Hãy tưởng tượng một làng Việt Nam vào buổi tối. Hai người canh gác đi tuần tra trên các con đường, mỗi người có một quan điểm khác nhau về an ninh.
Watchman A (SNARK) mang theo một chìa khóa chính – một bí mật duy nhất có thể mở tất cả các cửa trong làng. Anh ta chứng minh rằng anh ta đã kiểm tra từng ngôi nhà bằng cách cho bạn xem một dấu khóa thần kỳ chỉ có chìa khóa của anh ta mới có thể tạo ra. Dấu khóa rất nhỏ, đẹp và được xác minh ngay lập tức. Tuy nhiên, có một điều cần lưu ý: chìa khóa này được làm trong một nghi lễ bí mật nhiều năm trước. Nếu mọi người tham dự nghi lễ đó giữ lại một bản sao, họ có thể tạo ra các dấu khóa cho những ngôi nhà mà họ chưa từng đến.
Watchman B (STARK) không mang theo bất kỳ chìa khóa nào. Thay vào đó, ông đăng các quy tắc tuần tra trên cổng làng để mọi người xem: "Tôi kiểm tra từng cửa vào lúc nửa đêm. Tôi hét lên kết quả. Mọi người có thể kiểm tra bằng cách nghe tiếng vang." Sự chứng minh của ông là một cuốn sách dài ghi các kết quả được hét lên, mỗi cuốn được liên kết với cuốn tiếp theo bằng các chuỗi toán học mà mọi người có thể theo dõi. Không có nghi lễ bí mật. Không có chìa khóa chính. Chỉ có các quy tắc minh bạch và xác minh công khai.
Đây là snark vs stark trong một nốt nhạc – hai phương pháp hoàn toàn khác nhau đối với các bằng chứng không biết (ZKP), sức mạnh bí mật trong mật mã giúp bảo mật cho các đồng tiền, zk-rollups và thế hệ tiếp theo của việc mở rộng blockchain.
Zero-Knowledge Proof là gì? (Bối cảnh làng)
Trước khi so sánh hai người canh giữ của chúng ta, hãy hiểu những gì họ thực sự chứng minh.
Một bằng chứng không có kiến thức cho phép một người chứng minh thuyết phục một người kiểm tra rằng một tuyên bố là đúng – mà không tiết lộ lý do tại sao nó đúng. Trong làng của chúng ta:
- Thông báo: "Tôi biết mật khẩu bí mật để mở kho bạc."
SNARK và STARK đều đạt được điều này. Hai thuật toán này khác nhau ở cách xây dựng chứng minh, những giả định mà chúng yêu cầu và những sự cân bằng mà chúng thực hiện.
SNARK: Người canh gác có chìa khóa chủ
SNARK = Succinct Non-interactive ARgument of Knowledge.
Cách hoạt động của SNARK (bao thư được khóa)
Hãy xem SNARK như một gói bưu phẩm được khóa kín chứa một hàm số – một đối tượng toán học mã hóa toàn bộ quá trình tính toán.
- Trusted Setup (Lễ trao khóa): Trước khi có bất kỳ bằng chứng nào, một nhóm người tham gia thực hiện một lễ hội tính toán đa bên (MPC) – đó là sức mạnh của Tau nổi tiếng. Mỗi người thêm vào một ngẫu nhiên bí mật của họ, sau đó xóa nó đi. Kết quả là một khóa chứng minh và khóa xác minh. Nếu tất cả các người tham gia hợp tác (hoặc một người giữ bí mật của họ), họ có thể tạo ra bằng chứng cho những tuyên bố sai.
- Thử nghiệm: Người thử nghiệm lấy khóa thử nghiệm + các đầu vào riêng (công chứng) + chu trình công khai → tạo ra một bằng chứng. Trong Groth16 (SNARK truyền thống), bằng chứng này chỉ là 3 yếu tố của nhóm (~200 byte).
- Xác minh: Người xác minh sử dụng khóa xác minh + các đầu vào công khai + bằng chứng → kiểm tra một số phương trình kết hợp. Hoàn thành trong vài milisecond.
Các biến thể SNARK bạn sẽ gặp
| Phiên bản | Cài đặt | Kích thước chứng minh | Xác minh | Được sử dụng bởi |
|---|---|---|---|---|
| Groth16 | Cấu hình tin cậy cho từng vòng | ~200 byte | Nhanh nhất (3 cặp) | Zcash, Tornado Cash, các phiên bản zk-rollups sớm |
| PLONK | Cài đặt tin cậy chung | ~1-2 KB | Nhanh | zkSync v1, Aztec, Polygon Hermez |
| Halo2 | Không có cấu hình đáng tin cậy (IPA) | ~5-10 KB | Chậm hơn | Midnight, Penumbra, Electric Coin Co. |
| Plonky2 | Cài đặt tin cậy chung | ~100-200 KB | Rất nhanh (recursive) | Polygon zkEVM, RISC Zero |
Chìa khóa: "Cài đặt chung" có nghĩa là một nghi lễ phục vụ cho nhiều chu trình - nhưng nó vẫn là một cài đặt đáng tin cậy.
STARK: Người canh gác với các quy tắc công khai
STARK = Scalable, Transparent, ARgument of Knowledge.
Cách STARK hoạt động (The Public Shout)
STARK thay thế phong bì được khóa bằng một cây Merkle của các phép tính đa thức – giao thức FRI (Fast Reed-Solomon Interactive Oracle Proof).
- Cấu hình minh bạch: Không có nghi lễ. Không có bí mật. Các tham số công khai = hàm hash (Keccak-256 hoặc Poseidon) + các tham số trường. Bất kỳ ai cũng có thể kiểm tra xem các tham số có đúng hay không.
- Arithmetization: Tính toán trở thành một tập các giới hạn bậc hai trên một trường hữu hạn (thường là trường nguyên tố 64-bit hoặc 256-bit). Mỗi bước thực hiện = một hàng trong một bảng theo dõi thực hiện.
- Tăng độ thấp: Các đa thức theo dấu được mở rộng sang một miền lớn hơn. Nếu phép tính có giá trị, các đa thức này có độ thấp.
- FRI Protocol: Người chứng minh cam kết với hàm đa thức thông qua cây Merkle. Người xác minh thực hiện các câu hỏi về các điểm ngẫu nhiên. Nếu hàm đa thức không có độ cao, các câu hỏi có thể phát hiện nó với xác suất cao. Lặp lại cho tính hợp lý.
- Bằng chứng: Một gốc Merkle + các đường xác thực cho các điểm được truy vấn. Kích thước bằng chứng: 10-100 KB (lớn hơn SNARK, nhưng không có cấu hình đáng tin cậy).
Công ty STARK Properties
| Tài sản | SNARK (Groth16/PLONK) | STARK |
|---|---|---|
| Cài đặt đáng tin cậy | Có (cho mỗi dây hoặc chung) | Không |
| Kích thước chứng minh | ~200 byte - 2 KB | 10-100 KB |
| Thời gian xác minh | ~1-5 ms (cặp nối) | ~10-50 ms (bảo mật dựa trên hash) |
| Thời gian Prover | Nhanh (có nhiều MSM) | Chậm hơn (FFT + FRI) |
| Cường độ chống lại năng lượng lượng tử | Được phá vỡ bởi lượng tử (cặp) | Kháng lại (cấu trúc dựa trên hash) |
| Truyền tiếp | Cần chu kỳ của các đường cong | Độc địa (FRI tự nhiên) |
| Năng lực phát triển công cụ | Cao (Circom, snarkjs, Arkworks) | Nguyên sinh (Cairo, Stone, Winterfell) |
Lễ cài đặt đáng tin cậy: Điều gì thực sự đã xảy ra
Điều được hiểu sai nhất về SNARK. Hãy giải thích.
Lễ trao quyền của Tau (2022, vòng 2)
- 100+ người tham gia từ Ethereum Foundation, Zcash, Filecoin, các nhà khoa học, cá nhân
So sánh: Hãy tưởng tượng 100 người dân trong một làng mỗi người thêm một thành phần bí mật vào một nồi chung, sau đó đốt bỏ công thức nấu của họ. Món nước dùng cuối cùng (là yếu tố quan trọng) là công khai. Để làm độc nó, tất cả 100 người phải giữ bí mật các công thức của họ và phối hợp với nhau.
Kiểm tra thực tế: Đây là một giải pháp an toàn hơn so với một chìa khóa chủ duy nhất, nhưng không an toàn bằng mô hình zero-trust của STARK. Lễ hội là một giả định về lòng tin xã hội, chứ không phải là một giả định toán học.
Cấu hình STARK trong suốt: không cần nghi lễ
Cấu hình của STARK chỉ có thông số công khai:
`rust // STARK public parameters (simplified) struct StarkParams { field: PrimeField, // e.g., 2^64 - 2^32 + 1 (Goldilocks) or 256-bit hash: HashFunction, // Keccak-256 or Poseidon fri_folding_factor: u32, // 2, 4, 8... security_bits: u32, // 96, 128, 192... } `
Mọi người có thể: 1. Đọc các tham số 2. Kiểm tra xem trường đó có phải là số nguyên tố hay không 3. Kiểm tra hàm hash có đúng tiêu chuẩn hay không 4. Tạo ra chính xác chìa khóa chứng minh của riêng mình – không cần nghi lễ, không cần tin tưởng
Đó là lý do tại sao "cấu hình rõ ràng và minh bạch" là một yếu tố phân biệt cơ bản.
Cam kết đa thức: trung tâm của sự khác biệt
Cả hai hệ thống đều cần tiết kiệm một hàm đa thức và xác minh các kết quả tính toán. Đây là nơi mà KZG (SNARK) và FRI (STARK) khác nhau.
KZG Commitment (SNARK) — Bao gói được khóa
Kate-Zaverucha-Goldberg (KZG) sử dụng cặp đường elip (elliptic curve pairings).
` Commitment: C = [p(τ)]₁ (τ = secret from trusted setup) Opening proof: π = [(p(τ) - p(z)) / (τ - z)]₁ Verification: e(C - [p(z)]₁, [1]₂) = e(π, [τ - z]₂) `
- Cam kết: Một phần tử nhóm duy nhất (32 byte trên BLS12-381)
Cam kết FRI (STARK) — Cây Merkle của các đánh giá
FRI (Fast Reed-Solomon IOP) sử dụng cam kết dựa trên hash.
`
- Evaluate polynomial p(x) on large domain D → vector v
- Commit: Merkle root of v
- FRI rounds: Fold v → v' → v'' ... until degree < threshold
- Proof: Merkle paths for queried indices in each round
`
- Cam kết: căn bản Merkle (32 byte)
- Hướng giả định về tin cậy: Không có. Hàm hash là công khai.
Hình 1: Hai người canh đêm — SNARK (chìa khóa chính) vs STARK (quy tắc công khai)
Hình 2: Trusted setup ceremony vs transparent setup
Khi nào nên chọn cái nào? (Cơ chế quyết định)
Chọn SNARK Khi:
- Kích thước chứng minh là quan trọng nhất — Xác minh trên chuỗi (chi phí dữ liệu gọi của Ethereum)
- Tốc độ xác minh rất quan trọng — Các lớp thanh toán có hiệu suất cao
Thực tế: Zcash (txs được bảo vệ), Tornado Cash (bảo mật), zkSync v1, Aztec, Filecoin (WinningPoSt)
Chọn STARK Khi:
- Tối ưu hóa việc giảm thiểu sự tin tưởng là rất quan trọng — Không có nghi lễ, không có chất thải độc hại, mãi mãi
Thực tế: StarkNet (các bản cập nhật hợp lệ), zkSync Era (bằng chứng hợp lệ), RISC Zero (ZK-VM), Polygon Miden, Herodotus (bằng chứng lưu trữ)
Thực tế hỗn hợp: hầu hết các hệ thống sản xuất sử dụng cả hai
Đây là điều các nhà cung cấp không luôn thông báo: hầu hết các bản cập nhật "STARK" được giải quyết bằng SNARKs.
` StarkNet: STARK validity proof → SHARP prover → SNARK (Groth16) verifier on Ethereum zkSync Era: STARK validity proof → SNARK (PLONK) recursive compression → Ethereum RISC Zero: STARK (RISC-V execution) → SNARK (Groth16) for on-chain verification `
Tại sao? Ethereum hỗ trợ các cặp BLS12-381 (kiểm tra SNARK) nhưng không hỗ trợ kiểm tra FRI. Kiểm tra một STARK trong chuỗi tốn khoảng 5 triệu gas; kiểm tra một bằng chứng Groth16 tốn khoảng 200.000 gas.
Kiến trúc: 1. STARK cho việc bằng chứng (mô hình minh bạch, chống lại các mối đe dọa về lượng tử, có khả năng mở rộng cho người cung cấp bằng chứng) 2. SNARK cho việc thanh toán (bằng chứng nhỏ, xác minh nhanh trên chuỗi, đã được precompile)
Đây là cả hai thế giới tốt nhất – và nơi ngành công nghiệp đang hội tụ.
Hình 4: Bảng so sánh thuộc tính SNARK vs STARK
Hình 3: Cam kết đa thức — KZG envelope vs FRI Merkle tree
FAQ: Câu hỏi của bạn được trả lời
Câu hỏi: SNARK có bị "hỏng" do cấu hình tin cậy không?
A: Không. Lễ hội quyền lực của Tau (có hơn 100 người tham gia, tính toán đa bên) làm cho việc hợp tác trở nên rất khó xảy ra. Tuy nhiên, đó là một giả định về lòng tin xã hội. STARK loại bỏ nó theo cách toán học.Câu hỏi: Tại sao các bằng chứng STARK lớn hơn nhiều như vậy?
A: FRI cam kết thực hiện nhiều đánh giá cho đa thức (cây Merkle), trong khi KZG cam kết thực hiện một yếu tố nhóm. STARK trao đổi kích thước chứng minh cho sự minh bạch. Tương tác và nén (ví dụ, STARK → SNARK) giảm thiểu điều này cho việc sử dụng trên chuỗi.Câu hỏi: STARK có thể chạy trên Ethereum hiện nay không?
A: Xác minh một STARK nguyên liệu trên Ethereum tốn khoảng 5 triệu gas (quá đắt). Các rollup STARK sản xuất sử dụng một lớp bao phủ STARK-to-SNARK: chứng minh bằng STARK, nén thành SNARK và xác minh SNARK trên chuỗi.Câu hỏi: Đâu là loại có khả năng chống lại lượng tử tốt hơn?
A: STARK. An ninh của nó được giảm xuống thành khả năng chống xung đột của hàm hash (Keccak-256/Poseidon). An ninh SNARK được giảm xuống thành giả định log riêng lẻ/đôi – bị phá vỡ bởi thuật toán của Shor trên một máy tính lượng tử lớn.Câu hỏi: Tôi có cần học Cairo cho STARK không?
A: Đối với StarkNet - có. Đối với phát triển chung của STARK: Winterfell (Rust), Stone (Rust) hoặc SP1 (RISC-V) cho phép bạn viết bằng Rust/C++. Cairo là dành riêng cho lĩnh vực.Câu hỏi: Về Halo2 / Nova – không có SNARKs được tin cậy?
A: Halo2 sử dụng IPA (Inner Product Argument) thay vì KZG – không có cấu hình đáng tin cậy, nhưng các bằng chứng lớn hơn (~5-10 KB) và xác minh chậm hơn. Nova/IVC cho phép xác minh tính toán theo cách tăng dần – SNARKs quy hồi mà không có chu kỳ đường cong. Những điều này làm mờ đi ranh giới nhưng vẫn là lĩnh vực nhỏ so với Groth16/PLONK/FRI.Tóm tắt: Hai người bảo vệ, một làng
| Người canh gác | Triết học | Tốt nhất cho |
|---|---|---|
| SNARK (chuẩn mật) | "Yêu cầu nghi lễ, tăng hiệu quả" | Xác minh trên chuỗi, ứng dụng bảo mật, công cụ hoàn thiện |
| STARK (Quy định công khai) | "Đừng tin ai, kiểm tra mọi thứ" | Rollups giảm thiểu sự tin cậy, chống lại lượng tử, các phép tính lớn |
Thị trấn cần cả hai. SNARK bảo vệ cổng kho tàng (xác minh trên chuỗi). STARK tuần tra trên các con đường (bằng chứng thực hiện, bảo mật, mở rộng). Cùng nhau, họ bảo vệ thị trấn blockchain – một thị trấn có một chìa khóa chính được tạo ra trong một nghi lễ, một thị trấn có các quy tắc được đăng trên cổng để mọi người xem.
Hiểu được snark vs stark không phải là chọn một người chiến thắng. Đó là biết nên đặt người canh giữ ở đâu – và nhận ra rằng các biện pháp phòng thủ mạnh nhất thường kết hợp cả hai.
Số từ: ~2,800 | Từ khóa chính: "snark vs stark" | Từ khóa phụ: "zk snark stark khác nhau", "stark transparent setup"