Lan là một developer ở Thành phố Hồ Chí Minh đang xây một chương trình khách hàng thân thiết bảo vệ quyền riêng tư: thành viên chứng minh họ đã giữ một token sáu tháng mà không tiết lộ họ sở hữu ví nào. Tài liệu đều chỉ về một hướng — arkworks, hệ sinh thái Rust phía sau phần lớn code ZK trong sản xuất. Cô thêm ark-groth16, ark-bn254 và ark-relations vào Cargo.toml rồi nhìn chằm chằm dòng đầu tiên: type Fr = . Fr. Fq. Base field. Scalar field. Embedding degree. G1, G2, GT. Không tutorial nào giải thích vì sao chúng quan trọng — cho đến ngày circuit của cô phải xác minh một bằng chứng bn254 curve zk bên trong một bằng chứng khác, và cả dự án sụp đổ hay không phụ thuộc vào field mà phép tính của cô chạy trên đó.
Bài viết này là lời giải thích mà các tutorial kia bỏ qua: finite field thực sự là gì và vì sao mọi thư viện ZK được xây trên nó, vì sao BN254 trở thành lựa chọn bn254 curve zk mặc định vì Ethereum ship precompiled contract cho nó, vì sao Zcash và Ethereum 2.0 chuyển sang làm việc với bls12 381 zk trên BLS12-381, và cách chọn giữa arkworks và zkcrypto — hai gia đình thư viện Rust ở trung tâm của tất cả. Đến cuối bài bạn sẽ đọc được ark_ff::Fp hay bls12_381::Scalar trong một codebase và biết chính xác tác giả đang trả lời câu hỏi gì.
arkworks và zkcrypto: hai thư viện, hai triết lý
Thế giới ZK trong Rust chia làm hai phe dễ nhầm lẫn vì chúng triển khai cùng một toán học. arkworks là một hệ sinh thái full-stack: một tổ chức, hàng chục crate, và một quan điểm rõ ràng về cách một ứng dụng ZK nên được xây dựng. zkcrypto là triết lý ngược lại: một bộ sưu tập các crate nhỏ, tập trung, mỗi cái làm một việc, theo cách dự án Zcash từng cần.
Cả hai phe cùng xuất phát từ một nhóm người. Các tác giả bài báo ZEXE — Pratyush Mishra, Weikeng Chen và cộng sự — đã xây lớp đại số trở thành arkworks, chuyển thể từ các crate ff, pairing và bellman của zkcrypto do Sean Bowe và nhóm Zcash viết. Hai thư viện không phải là đối thủ; chúng là hai câu trả lời cho cùng một câu hỏi — "hình dạng đúng của code ZK là gì?" arkworks nói: một framework. zkcrypto nói: một hộp công cụ.
Bản đồ crate của arkworks là cách nhanh nhất để thấy sự khác biệt. Lớp đại số là ark-ff (finite fields), ark-ec (curves và pairings), ark-poly (polynomials và FFTs), cộng các crate curve có sẵn như ark-bn254 và ark-bls12-381. Lớp circuit là ark-relations (API hệ ràng buộc) và ark-r1cs-std (các gadget dùng lại — booleans, hashes, so sánh). Lớp bằng chứng là ark-snark (interface) cùng ark-groth16, ark-marlin và ark-gm17. ark-std làm mượt std/no_std, và ark-circom đọc file .r1cs và .zkey của Circom để bạn chứng minh circuit circom từ Rust và đưa bằng chứng vào một verifier Solidity. Một cây dependency, một API nhất quán, một hệ sinh thái.
zkcrypto thì cố tình ngược lại. ff và group định nghĩa hệ từ vựng trait — một phần tử field, một phần tử group — mà gần như mọi thư viện khác giờ dựa lên. bls12_381 là curve BLS12-381, không hơn không kém. pairing định nghĩa interface Engine và giữ curve cụ thể trong một crate riêng. jubjub là một curve chữ ký. bellman xây circuit một cách tổng quát trên bất kỳ scalar field nào bạn đưa vào ("kiểu scalar field được dùng như 'từ' của một circuit"), và halo2 là hệ thống chứng minh kế thừa nó. Không gì trong zkcrypto giả định bạn thậm chí muốn một hệ thống chứng minh; chỉ cần kéo bls12_381 để làm phép pairing cho giao thức của riêng bạn.
Còn một khác biệt nữa đáng biết trước khi bạn cam kết một stack. README của arkworks groth16 nói thẳng: "Đây là bản prototype học thuật chứng minh khái niệm, và đặc biệt chưa được code review kỹ lưỡng. Bản triển khai này KHÔNG sẵn sàng cho sản xuất." README của zkcrypto bls12_381 mang tuyên bố miễn trừ riêng — "Bản triển khai này chưa được review hay audit. Dùng tự chịu rủi ro" — dù thư viện pairing cũ của Zcash mà nó kế thừa đã nhận một bản audit chuyên nghiệp của Kudelski năm 2018 (một vấn đề mức thấp, hai ghi nhận thông tin). Bài học không phải là một trong hai thư viện nguy hiểm; mà là trạng thái audit là thuộc tính của triển khai của bạn, không phải của thư viện bạn chọn. Cả hai stack đều đã thử lửa — Reth, Rust EVM, ship phép toán BN254 của arkworks bên trong các precompile của nó, và Zcash, Ethereum 2.0 và Filecoin chạy trên code hậu duệ của zkcrypto.
Finite fields: nền tảng mọi thư viện ZK xây dựng trên đó
Mọi thứ trong một thư viện ZK nằm trên một khái niệm: finite field. Một finite field là một tập số có cộng, trừ, nhân, chia đều hoạt động như bạn mong đợi, nhưng tập đó hữu hạn — trên thực tế, các số nguyên từ 0 đến p−1 với một số nguyên tố khổng lồ p nào đó, mọi phép toán được rút gọn theo modulo p. Điều này được viết Fp và gọi là prime field. Một elliptic curve "trên Fp" chỉ đơn giản nghĩa là tọa độ của nó là phần tử của Fp, và phương trình y² = x³ + ax + b được tính bằng số học modulo.
Mọi curve dùng trong ZK thực ra kéo theo hai finite field, và đây là ý tưởng quan trọng nhất bài viết. Base field là field mà các phần tử là tọa độ của các điểm trên curve. Scalar field là field mà các phần tử là scalar bạn dùng để nhân điểm — và order của nó chính xác là số điểm trong subgroup chính của curve. Đây là hai số nguyên tố khác nhau. Trong crate ark-bn254 của arkworks, base field gọi là Fq (một số nguyên tố 254-bit) và scalar field gọi là Fr (một số nguyên tố 254-bit khác, không phải cùng một số). Trong tài liệu bls12_381 của zkcrypto, hai khái niệm tương tự được đặt tên Fp (base 381-bit) và Fq (scalar 255-bit). Các ký hiệu không nhất quán giữa hai thư viện cho cùng một cặp khái niệm — một trong những nguồn nhầm lẫn ít được ghi chép nhất cho người mới trong lĩnh vực này, và giờ bạn có thể gọi tên nó.
Vì sao developer circuit nên quan tâm cái nào là cái nào? Vì một hệ thống bằng chứng làm toàn bộ số học trong scalar field, và chỉ scalar field — let x = Fr::from(7) trong một circuit arkworks hoạt động theo modulo số nguyên tố của scalar field. Public inputs phải là phần tử scalar field hợp lệ, và nhầm base với scalar field trong kiểm tra đó là một nguồn lỗi verifier đã được ghi nhận. Nói cách khác, chọn một curve là chọn field mà circuit của bạn được phép tính toán. Bạn không chọn một tham số bảo mật; bạn đang chọn "bo mạch chủ" mà circuit của bạn chạy trên đó.
Cả hai gia đình thư viện triển khai số học field giống nhau bên dưới: các số được lưu dạng Montgomery để phép nhân modulo nhanh, và ark-ff phơi bày điều này như một backend dùng lại (MontBackend) phía sau các trait Field và PrimeField của nó. Với hệ thống dựa pairing, các thư viện cũng xây extension towers — Fp2, Fp6, Fp12 — vì nhóm đích của một pairing nằm trong extension field bậc 12, không phải trong base field. ark-ff ship tất cả dưới dạng mô hình tổng quát; bạn không bao giờ tự viết tower.
Hình 1: Giải phẫu finite field và curve — một curve, hai fields, scalar field là nơi circuit của bạn sống
BN254: curve mà Ethereum precompiles đưa thành chuẩn
Mọi SNARK dựa pairing cần một curve hỗ trợ pairing — một ánh xạ song tuyến e: G1 × G2 → GT với e(aP, bQ) = e(P, Q)^(ab). Tính song tuyến giúp một verifier kiểm tra bằng chứng với một nhúm phép pairing thay vì kiểm tra toàn bộ phép tính. BN254 — cũng viết alt_bn128, bn256 hoặc BN128 — là một curve Barreto-Naehrig có embedding degree 12 được thiết kế chính cho việc này, và nó trở thành lựa chọn bn254 curve zk mặc định vì một lý do tầm thường: Ethereum ship precompiled contract cho nó.
EIP-196 thêm 0x06 (cộng điểm G1) và 0x07 (nhân vô hướng G1); EIP-197 thêm 0x08, một precompile tính phép kiểm tra optimal ate pairing. Đó là tất cả những gì một verifier Groth16 cần, và nó chạy bên trong EVM với giá gas cố định — 6.000 gas cho mỗi phép nhân vô hướng, 34.000 cộng 45.000 cho mỗi pairing. Một phép xác minh Groth16 điển hình trên BN254 rơi vào khoảng 200.000 gas. Vì mọi L2, sidechain và chain tương thích Ethereum đều kế thừa các precompile này, hệ sinh thái — circom, snarkjs, các ứng dụng bảo mật lớp Tornado Cash, rollups, và các verifier Solidity được sinh cho chúng — chuẩn hóa trên BN254. Nếu bạn muốn xác minh bằng chứng giá rẻ trên một chain EVM hôm nay, gần như chắc chắn bạn sẽ xác minh một bằng chứng trên BN254.
Giải phẫu của curve đáng ghi nhớ vì nó lặp lại với mọi curve pairing. G1 là nhóm các điểm trên y² = x³ + 3 trên base field Fp — 64 byte mỗi điểm không nén. G2 là nhóm các điểm trên một twist bậc hai, y² = x³ + 3/(9+u) trên Fp² — 128 byte mỗi điểm. GT là một subgroup của nhóm nhân của extension bậc 12, nơi output của pairing nằm. Một bằng chứng Groth16 là ba điểm: A ∈ G1, B ∈ G2, C ∈ G1, nén còn 128 byte. Verifier tính một tích các pairing với các hằng số verification-key đã tính sẵn — O(1) pairing, O(public inputs) phép nhân G1.
Và đây là điểm trung thực. BN254 được thiết kế khi bảo mật ~128-bit tưởng như đạt được, nhưng tiến bộ của các tấn công Number Field Sieve lên nhóm đích pairing đã bào mòn điều đó. Nguồn arkworks giờ cảnh báo: "Curve này không còn thỏa mãn mức bảo mật 128-bit nữa." Các ước tính độc lập đặt nó quanh 100–110 bit. Không phải là "hỏng" — không ai đi tính discrete log trên nó — nhưng nó thấp hơn biên độ mà hệ thống hiện đại thích, và thấp hơn cả một mức bảo mật so với những gì BLS12-381 được xây để đạt tới.
BLS12-381: con ngựa thồ bảo mật 128-bit
BLS12-381 là curve Sean Bowe thiết kế cho bản nâng cấp Sapling của Zcash năm 2017, và thông số kỹ thuật của nó là một bài học mẫu về cách đặt curve khớp với khối lượng công việc. Nó là một curve BLS (Barreto-Lynn-Scott), lần nữa embedding degree 12, nhưng tham số được chọn cho ba việc cùng lúc: một base field p dài 381 bit (nên điểm G1 nén vừa 48 byte và G2 vừa 96), một scalar field q dài 255 bit với căn nguyên thủy bậc 2³² (nên FFT cơ số 2 — động cơ của công việc đa thức kiểu PLONK/KZG — hiệu quả), và một tham số curve z có trọng lượng Hamming nhỏ (nên pairing nhanh). Ngách bls12 381 zk — các hệ thống ZK muốn biên độ bảo mật lớn hơn BN254 — được xây chính trên những con số này.
Câu chuyện bảo mật là lý do Zcash rời khỏi curve BN của mình. Ghi chú riêng của crate bls12_381 dẫn giải toán: các curve thân thiện pairing tất yếu kém an toàn hơn curve thường vì embedding degree nhỏ cho phép kẻ tấn công ánh xạ bài toán vào nhóm đích; các tấn công NFS tối ưu có thể làm yếu thêm, nhưng ngay cả trong trường hợp bi quan BLS12-381 chỉ suy giảm còn khoảng 117–120 bit — "trái ngược với các curve BN 254-bit thường có dưới 100 bit bảo mật trong cùng tình huống." Đó là cả một mức bảo mật dư địa, và là lý do Sapling kích hoạt trên BLS12-381 tháng 10/2018, vì sao lớp đồng thuận của Ethereum 2.0 dùng nó cho chữ ký BLS, và vì sao Filecoin cùng hầu hết triển khai halo2 đi theo.
Cái giá của biên độ đó là cụ thể. Bằng chứng Groth16 trên BLS12-381 là 192 byte thay vì 128, và số học G2 — điểm 96 byte trong một extension field bậc hai — nặng hơn để tính và đắt hơn để serialize. Không chain EVM nào ship precompile BLS12-381 như nó ship precompile BN254, nên xác minh on-chain cần Solidity tùy chỉnh (chậm hơn, tốn gas hơn) hoặc chuyển off-chain. Các đội chọn BLS12-381 khi biên độ bảo mật và sự thân thiện FFT thắng chi phí on-chain; họ chọn BN254 khi hệ sinh thái precompile là quyết định.
BN254 vs BLS12-381: cách chọn
Đặt hai curve cạnh nhau và quyết định trở nên máy móc. Cả hai có embedding degree 12. BN254 có base field 254-bit và scalar field 254-bit, bảo mật ~100–110 bit, bằng chứng Groth16 128 byte, và hỗ trợ precompile EVM hạng nhất. BLS12-381 có base field 381-bit và scalar field 255-bit, bảo mật ~126 bit, bằng chứng Groth16 192 byte, và không có precompile gốc — nhưng một căn đơn vị 2³² khiến các hệ thống nặng đa thức nhanh hơn. BN254 là câu trả lời tương thích: nếu verifier của bạn là một contract Solidity trên chain EVM, hoặc circuit của bạn đến từ circom (mà toolchain là BN254-native), quyết định được đưa sẵn cho bạn. BLS12-381 là câu trả lời greenfield: khi bạn kiểm soát verifier, quan tâm biên độ bảo mật dài hạn, và đang xây hệ thống nặng FFT, nó là lựa chọn có thể bảo vệ.
Hình 2: BN254 vs BLS12-381 — BN254 cho tương thích EVM, BLS12-381 cho biên độ bảo mật và tốc độ FFT
Có một quy luật sâu hơn đằng sau bảng, một quy luật cứu bạn cả tuần debug. Scalar field của curve là field của circuit — hết chuyện. Mọi ràng buộc, mọi gadget, mọi public input nằm trong nó. Vậy nên khi bạn chọn một curve, bạn không chọn "curve", bạn đang chọn field mà ứng dụng của bạn được phép tính toán. Đó là lý do hai scalar field có 2-adicity khác nhau (kích thước FFT lũy thừa hai lớn nhất mà chúng hỗ trợ): scalar field của BLS12-381 hỗ trợ 2³², của BN254 hỗ trợ 2²⁸. Nếu hệ thống của bạn bị giới hạn bởi FFT, khác biệt đó đo được bằng thời gian prover.
Quy luật tương tự giải thích những bài toán khó nhất trong kỹ thuật ZK. Chứng minh một mệnh đề về phần tử BN254 bên trong một circuit — chẳng hạn xác minh chữ ký BN254, hoặc xác minh đệ quy một bằng chứng Groth16 bên trong một bằng chứng khác — là không thể trực tiếp, vì base field của BN254 không phải là scalar field nơi circuit của bạn sống. Đây gọi là số học field phi bản địa (non-native field arithmetic), và nó đắt. arkworks ship ark-nonnative chính cho việc này, cộng các curve hướng đệ quy (ark-bw6-761, ark-grumpkin) có field được chọn để hai bên của sự lệch khớp thẳng hàng. Các crate này không phải đồ chơi: chúng là bài toán field-mismatch được đóng gói thành code. Biết từ vựng — base field vs scalar field — là điều làm các crate đó dễ hiểu thay vì thần kỳ.
Ghép lại: một dự án thực tế kéo vào những gì
Một dự án Groth16 arkworks tối thiểu trông thế này: ark-ff cho bạn kiểu scalar field, ark-ec bộ máy curve, ark-bls12-381 (hoặc ark-bn254) curve cụ thể, ark-relations hệ ràng buộc, ark-r1cs-std các gadget, ark-snark interface và ark-groth16 hệ thống chứng minh. Một dự án zkcrypto tối thiểu trông khác: bls12_381 cho bạn phần tử field và curve, pairing trait Engine và lời gọi pairing, và bellman (hoặc halo2) lớp circuit — với ff và group làm nền trait mà mọi thứ khác giả định.
Những hình dạng dùng chung quan trọng hơn tên crate. Cả hai stack cho bạn cùng ba kiểu group cho mỗi curve — G1 (điểm base-field), G2 (điểm twist) và GT (output pairing) — và cả hai đại diện cùng hai field. Nếu bạn đọc được tham số curve trong một stack, bạn đọc được trong stack kia; ký hiệu đổi chỗ (Fq/Fr trong arkworks, Fp/Fq trong zkcrypto), toán không đổi. Đó là giá trị thực tiễn của việc hiểu toán thay vì học thuộc API: hai hệ sinh thái trở nên hoán đổi trong đầu bạn.
Hệ sinh thái xốp hơn tên crate gợi ý. Cả hai thư viện triển khai cùng các curve, nên một bằng chứng ark-groth16 trên BN254 xác minh được với một contract do snarkjs sinh, circuit circom chứng minh được từ Rust qua ark-circom, và chính lớp đại số của arkworks là hậu duệ của ff/pairing/bellman từ zkcrypto. Và khi Zcash cần một curve chữ ký hoạt động tự nhiên bên trong circuit Sapling, họ định nghĩa Jubjov trên chính scalar field của BLS12-381 — "việc chọn GF(q) được thực hiện để nó là scalar field của cấu trúc elliptic curve BLS12-381" — nên một bản triển khai field trả tiền cho cả bằng chứng lẫn chữ ký. Đặt một curve lên một field thuận tiện là một pattern thiết kế lặp lại: đó là cách hệ thống ZK chia sẻ số học.
Hình 3: arkworks vs zkcrypto — cùng fields và curves, khác triết lý trust
Stack nào một dự án mới nên với tới? Nếu bạn đang xây phía chứng minh của một ứng dụng trong Rust và muốn một API mạch lạc — hệ ràng buộc, gadget, hệ bằng chứng, serialization, không dependency native — arkworks là con đường ngắn hơn, và đó là con đường Mopro (một toolchain proving di động) chọn cụ thể vì arkworks "tránh dependency thư viện native và chạy ở bất cứ nơi nào Rust chạy". Với một giao thức hoặc hệ thống nghiên cứu muốn bề mặt crypto tối thiểu, các primitive ff/group/bls12_381 của zkcrypto là chuẩn hệ sinh thái. Câu trả lời trung thực ở giữa: nhiều hệ thống sản xuất dùng cả hai — arkworks để chứng minh, bls12_381 của zkcrypto cho chữ ký và phép pairing ở nơi khác.
Điều này có nghĩa gì với developer ZK Việt Nam
Cộng đồng developer Việt Nam đang lớn nhanh, và Rust ngày càng hiện diện tại các meetup địa phương và dự án đại học, nhưng ZK vẫn là một ngách nơi vài trăm developer trên thế giới tạo ra phần lớn tooling. Chính là loại ngách nơi kiến thức nền tảng trả lãi kép: toán field-and-curve trong bài này không bao giờ lỗi thời, trong khi API crate được viết lại mỗi một hai năm.
Lộ trình học thực tiễn: bắt đầu với một hệ thống che đi toán — circom + snarkjs trên BN254, hoặc r1cs-tutorial chính thức của arkworks — và chứng minh thứ gì đó thật, dù nhỏ. Rồi quay lại các câu hỏi của bài viết này. Khi tutorial nói Fr, hãy hỏi "field này là cái nào, và base field của cùng curve là gì?" Khi gặp tranh luận "có nên dùng BLS12-381?" với đội của bạn, hãy hỏi bằng những thuật ngữ này: "verifier của chúng ta có nằm trên chain EVM không, và chúng ta có bị giới hạn bởi FFT không?" Bạn sẽ thấy hầu hết bất đồng ZK thực ra là bất đồng field-và-verifier mang tên khác. Đóng góp open source khi bạn đi — và nhớ lời cảnh báo audit: việc review bảo mật cho triển khai của bạn là trách nhiệm của bạn, không phải của thư viện.
Một điều nữa cho các đội xây trên các use case thị trường Việt Nam — KYC bảo vệ quyền riêng tư, thông tin xác thực kiểm chứng được, danh tính phi tập trung: những ứng dụng đó thường xác minh bằng chứng on-chain, và các chain tương thích Ethereum chỉa mạnh về BN254 vì precompile làm phép xác minh ~200.000 gas thay vì gấp nhiều lần. Nếu ứng dụng bảo mật của bạn phát hành bằng chứng mà một contract xác minh, hãy thiết kế circuit quanh ràng buộc field và precompile của bn254 curve zk từ ngày đầu, và dành bls12 381 zk cho các hệ thống nơi bạn kiểm soát verifier từ đầu đến cuối.
Các câu hỏi thường gặp
Tôi có cần hiểu finite fields để dùng arkworks không?
Không cần để chạy tutorial — nhưng có, ngay khi bạn lệch khỏi chúng. Mỗi circuit là số học trong một scalar field cụ thể; bạn không thể chọn một field khác mà không chọn một curve khác, và không thể debug "constraint mismatch" mà không biết constants của bạn nằm trong field nào. Field là dependency ít thấy nhất trong stack, nên nó đắt nhất khi bị bỏ qua.Khác biệt giữa base field và scalar field là gì?
Base field chứa tọa độ của các điểm trên curve; scalar field chứa các scalar bạn dùng để nhân điểm, và order của nó là số điểm trong subgroup chính. Một hệ thống bằng chứng làm toàn bộ số học circuit chỉ trong scalar field. Với BN254 đây là hai số nguyên tố 254-bit khác nhau; với BLS12-381 là base 381-bit và scalar 255-bit. Nhầm lẫn chúng là một nguồn lỗi verifier đã biết.BN254 còn an toàn để dùng cho ứng dụng zk không?
"An toàn" cần một con số. Ước tính post-special-TNFS đặt BN254 ở khoảng 100–110 bit bảo mật, và nguồn arkworks nói rõ nó không còn thỏa mãn 128 bit. Nó vẫn là lựa chọn thực dụng vì precompile của Ethereum và hệ sinh thái circom, nhưng một mô hình mối đe dọa 128-bit bảo thủ chỉa về BLS12-381.Khi nào tôi nên chọn BLS12-381 thay vì BN254 cho một hệ thống mới?
Khi bạn kiểm soát verifier (không bị ràng buộc precompile EVM), khi khối lượng công việc nặng đa thức/FFT (scalar field của BLS12-381 có căn đơn vị 2³²), và khi biên độ bảo mật dài hạn thắng bằng chứng to hơn và số học G2 chậm hơn. Zcash Sapling, đồng thuận Ethereum 2.0 và Filecoin đều đánh đổi theo cùng hướng.Tôi có thể dùng arkworks và zkcrypto cùng nhau không?
Có, và các dự án sản xuất làm vậy. Các thư viện triển khai cùng các curve, nên một bằng chứng Groth16 từark-groth16 xác minh được với một contract snarkjs, và các đội thường ghép việc chứng minh bằng arkworks với bls12_381 của zkcrypto cho chữ ký hay phép pairing. Từ vựng đủ tương thích rằng chính lớp đại số của arkworks là hậu duệ của các crate ff/pairing của zkcrypto.
Lựa chọn field ảnh hưởng thế nào đến bằng chứng đệ quy?
Đệ quy nghĩa là chứng minh rằng một bằng chứng xác minh được, và phép tính đó chạy bên trong một circuit — nên nó chạy trong scalar field. Một bằng chứng BN254 chứa phần tử base field của BN254, vốn không phải phần tử của scalar field BN254. Bạn cần hoặc số học field phi bản địa (ark-nonnative) hoặc một curve thứ hai (BW6-761, Grumpkin, Pasta) có field thẳng hàng với field của curve đầu. Hiểu base vs scalar field làm tất cả điều này hiển nhiên thay vì khó hiểu.
Kết luận
Ứng dụng khách hàng thân thiết của Lan gần như chắc chắn sẽ ship trên arkworks với bn254 curve zk, vì verifier của cô là một contract Solidity và circuit của cô muốn tương thích circom. Hiểu fields và curves không thay đổi quyết định đó — nó làm quyết định trở nên đọc được. Một hệ thống ZK là một tòa tháp: finite field, elliptic curve, pairing, hệ bằng chứng, ứng dụng. Hai gia đình thư viện trong tiêu đề chỉ là hai cách phổ biến nhất để xây tòa tháp đó trong Rust. Triết lý arkworks là "một hệ sinh thái cho cả tòa tháp"; triết lý zkcrypto là "các primitive nhỏ nhất đã được thử nghiệm kỹ, bạn tự lắp phần còn lại". Cả hai đứng trên cùng hai curve và cùng hai field trên mỗi curve. Học toán mà các thư viện dùng chung, và các API crate trở thành chi tiết bạn có thể tra cứu; chỉ học API, và mỗi lần viết lại thư viện lại bắt đầu cuộc điều tra từ con số không. Base field là nơi các điểm sống. Scalar field là nơi circuit của bạn sống. Chọn curve, và bạn đã chọn cả hai.
Tham chiếu nhanh
arkworks vs zkcrypto
| Thuộc tính | arkworks | zkcrypto |
|---|---|---|
| Triết lý | Hệ sinh thái full-stack, một API nhất quán | Crate nhỏ, tập trung, tự mang lớp của bạn |
| Finite fields | ark-ff (trait Field/PrimeField, backend Montgomery) | ff (traits), bls12_381 (fields của curve cụ thể) |
| Curves & pairings | ark-ec + ark-bn254 / ark-bls12-381 | pairing (Engine) + bls12_381 |
| Hệ ràng buộc | ark-relations + gadget ark-r1cs-std | bellman (word = phần tử scalar field) / halo2 |
| Hệ bằng chứng | ark-groth16, ark-marlin, ark-gm17 | bellman gói Groth16; halo2 |
| Interop | ark-circom (Circom R1CS, ZKey, Solidity) | Không có lớp circom; Zcash-native |
| Trạng thái audit | README groth16: prototype học thuật, chưa sẵn sàng sản xuất | README bls12_381: "chưa review hay audit"; thư viện pairing cũ của Zcash do Kudelski audit (2018) |
| Phù hợp nhất | Full Rust proving stack, circom compat, proving di động | Công việc giao thức/nghiên cứu, bề mặt crypto tối thiểu |
BN254 vs BLS12-381
| Thuộc tính | BN254 (alt_bn128) | BLS12-381 |
|---|---|---|
| Họ curve | Barreto-Naehrig | Barreto-Lynn-Scott |
| Embedding degree | 12 | 12 |
| Base field | 254-bit (Fq trong arkworks) | 381-bit (Fp trong zkcrypto) |
| Scalar field | 254-bit (Fr trong arkworks), 2-adicity 2²⁸ | 255-bit (Fq trong zkcrypto), 2-adicity 2³² |
| Bảo mật (post-TNFS) | ~100–110 bit | ~126 bit (tệ nhất ~117–120) |
| Kích thước điểm G1 / G2 (nén) | 32 B / 64 B | 48 B / 96 B |
| Kích thước bằng chứng Groth16 | 128 byte | 192 byte |
| Precompile EVM | Có: 0x06 ecAdd, 0x07 ecMul, 0x08 ecPairing (EIP-196/197) | Không có precompile gốc |
| Xác minh on-chain | ~200K gas | Solidity tùy chỉnh, tốn gas hơn |
| Người dùng nổi bật | Ứng dụng lớp Tornado Cash, hệ sinh thái circom/snarkjs, rollups | Zcash Sapling, đồng thuận Ethereum 2.0, Filecoin |
| Phù hợp nhất | Xác minh EVM, tương thích circom | Greenfield, biên độ bảo mật, hệ nặng FFT |