a16z: Những suy nghĩ và làm rõ liên quan đến việc hiểu Jolt zkVM
Tuyển chọn TechFlowTuyển chọn TechFlow
a16z: Những suy nghĩ và làm rõ liên quan đến việc hiểu Jolt zkVM
Chi phí của zkVM chủ yếu phụ thuộc vào số chu kỳ, chứ không phải các đặc tính cụ thể của bất kỳ ứng dụng nào, đây thực sự là một điều kỳ diệu nhỏ.
Chuyên sâu báo cáo Web3Tác giả: Justin Thaler, cộng sự nghiên cứu tại a16z
Biên dịch: xiaozou, Jinse Finance
Kể từ bài luận chủ đề mùa hè năm ngoái và việc triển khai Lasso, cho đến việc phát hành Jolt mã nguồn mở hoàn toàn vào tháng trước, chúng tôi đã đạt được tiến triển ổn định trong nghiên cứu và phát triển công nghệ Lasso+Jolt (giải pháp lookup argument hiệu suất cao mới và zkVM của chúng tôi).
So với các công nghệ hiện có, phiên bản này thể hiện tiềm năng tươi sáng của Jolt và thách thức nhiều quan điểm truyền thống trong thiết kế SNARK. Kể từ khi phát hành, chúng tôi liên tục cập nhật, bổ sung hỗ trợ thư viện chuẩn Rust, tích hợp cải tiến từ hơn 10 đóng góp viên, sáp nhập gần 50 yêu cầu kéo (pull request), đồng thời nâng cao tính mô-đun, hiệu suất và khả năng mở rộng của kho mã.
Trong khi tiếp tục cải thiện Jolt, tôi muốn phản hồi những nghi vấn và hiểu lầm từ bên ngoài, làm rõ một số quan điểm sai lệch, đồng thời chia sẻ góc nhìn cá nhân về một số vấn đề then chốt. Trong bài viết này, tôi sẽ thảo luận bốn nội dung chính: (1) mối quan hệ giữa giao thức sum-check và sơ đồ cam kết Binius, (2) vai trò của sum-check và lookups trong Jolt, (3) đường cong elliptic và hàm băm, (4) các tiền biên dịch liên quan đến zkVM.
1. Giao thức Sum-check và Sơ đồ Cam kết Binius
Các sơ đồ cam kết thường được coi là thành phần then chốt của SNARK. Tuy nhiên, cần lưu ý rằng một thành phần khác cũng rất quan trọng, đó là chứng minh đa thức tương tác oracle (polynomial interactive oracle proof - PIOP). Ví dụ, sơ đồ cam kết Binius dựa trên đa thức đa tuyến tính là một bước tiến lớn, nhưng nó phải được ghép nối với một PIOP để đảm bảo dữ liệu đã cam kết thực sự xác minh được tuyên bố của người chứng minh.
Sơ đồ cam kết Binius cực kỳ tương thích với PIOP sử dụng giao thức sum-check. Lý do vừa rõ ràng (sum-check dựa vào đa thức đa tuyến tính chứ không phải đa thức đơn biến; FRI-Binius thậm chí dùng sum-check bên trong), vừa tinh tế (PIOP sum-check hoạt động tự nhiên trên mọi trường đặc trưng, điều này rất quan trọng để tận dụng tối đa hiệu suất mới của Binius). Ngược lại, sơ đồ cam kết Binius không tương thích với các PIOP phổ biến nhất hiện nay – đáng tiếc là những PIOP này lại không dùng sum-check.
Thiết kế một PIOP nhanh đòi hỏi nhiều hiểu biết sâu sắc hơn chỉ là câu nói "áp dụng sum-check". Binius sử dụng giao thức sum-check để thực hiện IOP đa thức hiệu quả. Phần 4 và 5 của bài báo Binius tập trung vào việc thiết kế các PIOP mới, hiệu quả dựa trên sum-check nhằm kết hợp với sơ đồ cam kết.
Sự kết hợp giữa cam kết Binius và Jolt giống như bơ đậu phộng với mứt – vì Jolt hiện là zkVM duy nhất hoàn toàn dựa trên giao thức sum-check. Hiện tại Jolt sử dụng sơ đồ cam kết mã hóa dựa trên đường cong elliptic, nhưng việc tích hợp cam kết Binius vào Jolt là trọng tâm hàng đầu trong công việc của chúng tôi.
2. Sum-check, lookups, hiệu suất và tính súc tích
Điều gì khiến Jolt trở nên khác biệt? Là vì Jolt là zkVM đầu tiên (và hiện vẫn là duy nhất) chuyên dùng IOP đa thức dựa trên sum-check, hay vì Jolt đạt đến điểm kỳ dị lookup (gần như mọi thứ đều được thực hiện thông qua lookups thay vì hệ thống ràng buộc hoặc mạch)? Câu trả lời là cả hai yếu tố này. So với các zkVM trước đây, phần lớn lợi thế súc tích của Jolt bắt nguồn từ lookups, còn lợi thế hiệu suất đến từ việc sử dụng đồng thời lookups và sum-check.
Phương pháp thuần túy dùng lookup phù hợp hơn với một số lệnh (những lệnh không có mạch rất nhỏ), nhưng có thể kém hơn với các lệnh khác vốn có mạch rất nhỏ. Tuy nhiên, tổng thể mà nói, phương pháp thuần lookup chỉ mang lại lợi ích chứ không gây hại cho hiệu suất, ít nhất là khi xử lý trường 256 bit. Hiện nay, bộ chứng minh Jolt dành 20% thời gian cho các lookup "thực thi lệnh", và 40% thời gian để kiểm tra thông tin ràng buộc. Việc thêm ràng buộc để giảm số lượng lookup là vô ích.
Nói một cách khái quát, Jolt sử dụng các lookup để thực hiện phần "lấy" và "thực thi" trong vòng lặp lấy-giải mã-thực thi của CPU. Các lookup này đủ nhanh đến mức phần lớn thời gian của bộ chứng minh được dùng để chứng minh việc thực hiện "giải mã", phần này được xử lý bằng các ràng buộc truyền thống.
Phương pháp thuần lookup cũng thúc đẩy việc triển khai ngắn gọn và dễ kiểm toán hơn. Những lợi ích này khó định lượng và cần thời gian để được thấy và công nhận. Nhưng xét về số dòng mã (kho mã Jolt khoảng 25.000 dòng, ít hơn 2–4 lần so với các zkVM RISC-V trước đó) và thời gian phát triển, Jolt thể hiện vượt trội. Những cải tiến như vậy khó đạt được hơn nhiều so với cải tiến hiệu suất: mặc dù tôi dự đoán bộ chứng minh zkVM trong vài tháng tới sẽ nhanh gấp khoảng trăm lần so với tháng 8/2023, nhưng thật khó hình dung khi nào số dòng mã của một zkVM có thể giảm 10 lần.
3. Đường cong Elliptic
Diễn đàn công cộng đang đánh giá thấp lợi ích của việc sở hữu một zkVM nhanh dành riêng cho đường cong elliptic, một phần do sự nhiệt tình phổ biến đối với các sơ đồ cam kết dựa trên hàm băm (như Binius).
Khi chứng minh các khẳng định liên quan đến mật mã đường cong elliptic, zkVM dựa trên đường cong có thể tránh được các thuật toán trường phi nguyên sinh, vốn làm tăng chi phí thời gian chứng minh lên hàng trăm, hàng ngàn lần. Các ứng dụng này bao gồm chứng minh nhiều chữ ký số (công việc chính liên quan đến máy khách nhẹ blockchain và cầu nối dựa trên SNARK), gộp các chứng minh Plonk/Groth16/Nova/Honk, và chứng minh đường dẫn xác thực cây Verkle.
Tôi lạc quan rằng cộng đồng sẽ chú ý đến sự kết hợp giữa PIOP dựa trên sum-check và sơ đồ cam kết FRI-Binius, coi đó là phương pháp đúng đắn để thực hiện SNARK trong nhiều ứng dụng. Ngay cả khi điều này xảy ra, SNARK nhanh dựa trên đường cong vẫn hữu ích, trừ khi cả thế giới hoàn toàn từ bỏ mật mã đường cong elliptic (ví dụ, sau khi xã hội chuyển đổi hoàn toàn khỏi các hệ thống mã hóa không an toàn trước máy tính lượng tử).
Tóm tắt:
Cam kết dựa trên đường cong cạnh tranh trực tiếp với tất cả các zkVM khác hiện có (tất cả các zkVM khác hiện nay đều dùng sơ đồ cam kết hàm băm để xử lý trường nhỏ).
Khi chứng minh các khẳng định về đường cong elliptic (ít nhất là khi chưa có tiến bộ lớn nào trong các thuật toán trường phi nguyên sinh), người ta sẽ muốn dùng Jolt tích hợp đường cong.
Là một zkVM thuần túy, sự kết hợp Jolt với cam kết Binius sẽ nhanh hơn nhiều so với các phương án thay thế khác – ngoại trừ việc chứng minh các khẳng định về đường cong hoặc chứng minh trên trường nhỏ (trong trường hợp này, người ta sẽ dùng Jolt tích hợp đường cong), còn lại thì nên dùng sự kết hợp Jolt và Binius.
Trước khi xuất bản chứng minh lên chuỗi, SNARK dựa trên đường cong elliptic sẽ tiếp tục được dùng để nén kích thước chứng minh và chi phí bộ xác minh. Trong trường hợp này, zkVM xử lý trường lớn sẽ phát huy vai trò. Ngay cả hiện nay, những dự án zkVM dựa trên hàm băm mà người ta nghĩ là "thuần túy" thực tế lại dùng zkVM định nghĩa trên đường cong BN254 như một phần của quá trình đệ quy.
4. Tiền biên dịch và tiêu chuẩn đánh giá zkVM
Hiện đã có một số thảo luận về các tiền biên dịch và vai trò của chúng trong zkVM và các tiêu chuẩn đánh giá. Trước khi giải thích, có lẽ nên làm rõ khái niệm "tiền biên dịch", vì từ này mang ý nghĩa khác nhau trong các ngữ cảnh khác nhau.
(1) «Tiền biên dịch» trong Ethereum
Trong Máy ảo Ethereum (EVM), tiền biên dịch là một thao tác thường xuyên được thực hiện và được hỗ trợ sẵn để nâng cao hiệu quả. Điều này giúp tránh được chi phí khổng lồ và chi phí gas quá cao do phải thực thi các thao tác này qua một chuỗi dài các mã vận hành EVM.
Sự khác biệt giữa «tiền biên dịch EVM» và «lệnh cơ bản» (mã vận hành) chủ yếu là về mặt ngữ nghĩa. Ví dụ, hàm băm Keccak là một mã vận hành EVM, còn SHA-2 là một tiền biên dịch EVM. Cả tiền biên dịch và mã vận hành đều là các thao tác thường xuyên được thực hiện, và Ethereum hỗ trợ chúng sẵn vì cùng một mục đích: tối ưu hiệu suất và chi phí gas. Không thể phủ nhận rằng tiền biên dịch là một phần của EVM, và EVM thường được dùng để mô tả rộng rãi môi trường thực thi Ethereum, bao gồm nhiều hơn chỉ các mã vận hành.
Nếu chức năng của EVM về cơ bản giống như các mã vận hành, thì tại sao lại cần tiền biên dịch? Chủ yếu là do thói quen. Một lý do khác có thể là tiền biên dịch bao gồm các thao tác tương đối phức tạp, ví dụ như các nguyên thủy mật mã có thể cần thay đổi trong tương lai – nếu chúng không được cấp mã vận hành, thì việc thay đổi trong tương lai sẽ dễ dàng hơn.
(2) «Tiền biên dịch» trong thiết kế zkVM
Trong thiết kế zkVM, tiền biên dịch ám chỉ các SNARK chuyên dụng cho các hàm cụ thể (như hàm băm Keccak hoặc SHA) hoặc một nhóm cụ thể các thao tác đường cong elliptic. Ngày nay, các tiền biên dịch SNARK thường được thực hiện thông qua các hệ thống ràng buộc được tối ưu hóa thủ công (mặc dù khi cộng đồng chuyển sang SNARK dựa trên sum-check, bản chất của các hệ thống ràng buộc này và cách chứng minh chúng cũng sẽ thay đổi).
Có sự tương đồng sâu sắc giữa tiền biên dịch EVM và tiền biên dịch zkVM. Trước khi Jolt ra mắt, các zkVM thực hiện các lệnh cơ bản bằng các hệ thống ràng buộc được tối ưu hóa thủ công, mỗi lệnh một hệ thống, giống như cách họ thực hiện các tiền biên dịch. Sự khác biệt giữa «tiền biên dịch zkVM» và «lệnh cơ bản» hoàn toàn mang tính ngữ nghĩa. Về mặt thực tế, không có sự khác biệt nào cả.
Trong Jolt, chúng tôi sử dụng các lookup để thực hiện các lệnh cơ bản, thay vì dùng ràng buộc truyền thống. Tuy nhiên, việc chọn thực hiện một số lệnh cơ bản bằng ràng buộc cũng không có vấn đề gì lớn. (Thực tế, các lookup thậm chí có thể được coi là một dạng ràng buộc.) Như tôi từng nói, thực tế là khi chuyển sang sơ đồ cam kết Binius, chúng tôi có thể sẽ phải dùng ràng buộc truyền thống để thực hiện phép cộng và nhân RISC-V.
5. Đánh giá hiệu suất zkVM
Với những nền tảng trên, dưới đây là quan điểm của tôi về tiền biên dịch liên quan đến zkVM và đánh giá hiệu suất.
Thứ nhất, việc đánh giá hiệu suất các zkVM RISC-V khác nhau mà không có tiền biên dịch chính là bản chất của việc đánh giá zkVM RISC-V. Từ «zkVM» là một thuật ngữ không chính thức, do đó chắc chắn sẽ có tranh cãi, nhưng theo tôi, một zkVM RISC-V có một hoặc nhiều tiền biên dịch không còn là zkVM RISC-V nữa: nó là một zkVM dựa trên tập lệnh mới, mở rộng RISC-V bằng cách thêm mỗi tiền biên dịch như một lệnh cơ bản. Ít nhất, mỗi tiền biên dịch thêm vào zkVM đều làm suy yếu giá trị cốt lõi của mô hình zkVM – mỗi mạch thêm vào đều làm tăng diện tích lỗi tiềm tàng, và các chương trình hiện có sẽ không thể tận dụng ngay lập tức các tiền biên dịch mới này.
Một số người còn nhầm lẫn khái niệm tiền biên dịch EVM trong zkEVM với khái niệm tiền biên dịch trong zkVM. Nhưng đây là hai thứ hoàn toàn khác nhau. Dù một số thao tác then chốt trong zkEVM – như băm Merkle và xác minh chữ ký số – thực sự phức tạp hơn các lệnh RISC-V cơ bản, điều đó không làm thay đổi thực tế rằng không có sự khác biệt chức năng nào giữa tiền biên dịch EVM và lệnh EVM cơ bản. zkEVM phải hỗ trợ các tiền biên dịch EVM để tuyên bố tương thích với EVM. Nói cách khác, một zkEVM không hỗ trợ các tiền biên dịch EVM là khác biệt so với một zkVM RISC-V như Jolt, vốn sử dụng tiền biên dịch để mở rộng tập lệnh vượt ra ngoài RISC-V.
Một vấn đề khác là làm thế nào để chọn một tập hợp «công bằng» các hàm để đánh giá zkVM. Nhưng đối với zkVM RISC-V, bất kỳ tập hàm nào cũng là công bằng. Thời gian bộ chứng minh gần như hoàn toàn phụ thuộc vào số chu kỳ mà CPU RISC-V chạy, vì hai lý do. Thứ nhất, bộ chứng minh dành một phần nhỏ thời gian vào phần "thực thi" trong vòng lặp "lấy-giải mã-thực thi". Thứ hai, thời gian chứng minh của các lệnh RISC-V khác nhau, cũng như truy cập bộ nhớ, là rất tương đồng. (Trong Jolt, chúng được xử lý thông qua kỹ thuật kiểm tra bộ nhớ ngoại tuyến.)
Cuối cùng, nếu sử dụng tiền biên dịch, hiệu suất của Jolt có thể sẽ không thua kém các phương án thay thế khác. Thực tế, tôi dự đoán nó sẽ còn tốt hơn, bởi vì các tiền biên dịch dựa trên sum-check sẽ là nhanh nhất, và có thể được tích hợp vào Jolt mà không có chi phí, vì nó chuyên dùng PIOP dựa trên sum-check. Về điểm này, một số người lo ngại rằng các tiền biên dịch dùng sơ đồ cam kết đường cong elliptic sẽ kém xa so với các tiền biên dịch dùng sơ đồ dựa trên hàm băm. Hiện tại Jolt dùng đường cong, nhưng điều này không bắt buộc, và chúng tôi luôn cởi mở với kế hoạch chuyển sang Binius.
6. Suy ngẫm rộng hơn về tiêu chuẩn đánh giá
Mục tiêu chính của việc đánh giá hiệu suất là xác định hiệu suất nội tại của các hệ thống chứng minh khác nhau, ở mức độ nào đó, có thể tách rời khỏi việc triển khai cụ thể. Phương pháp này giúp cộng đồng hiểu và tập trung vào các công nghệ đúng đắn để thiết kế SNARK hiệu suất cao và an toàn. Tuy nhiên, khi cố gắng so sánh hai SNARK khác nhau, vô số yếu tố gây nhầm lẫn thường khiến việc so sánh chặt chẽ trở nên bất khả thi.
Nỗ lực kỹ thuật là một trong những yếu tố gây nhầm lẫn này, mặc dù nhiều người trong cộng đồng dường như có quan điểm trái ngược. Tư tưởng dường như là: nếu một dự án thêm các «tính năng», ví dụ như tiền biên dịch cho phần cứng cụ thể hoặc các tối ưu hóa, thì nó nên được «vinh danh» trong mọi đánh giá hiệu suất.
Cả hai quan điểm đều có điểm hay. Nhưng về lâu dài, quan điểm thứ hai rõ ràng là không đứng vững. Các phương pháp mới sẽ luôn bị bất lợi trong mọi đánh giá hiệu suất, vì chúng không có thời gian phát triển tương đương với các dự án cũ. Quan điểm như vậy chính là cản trở tiến bộ.
Theo thời gian, tôi dự đoán các yếu tố gây nhầm lẫn trong đánh giá hiệu suất sẽ giảm dần. Khi các công cụ phát triển SNARK trưởng thành, lượng công việc kỹ thuật cần thiết để đạt được hiệu suất tốt sẽ giảm. Chi phí zkVM chủ yếu phụ thuộc vào số chu kỳ, chứ không phải vào các đặc điểm riêng của ứng dụng cụ thể – đây là một điều kỳ diệu nhỏ (ít nhất là đối với RISC-V). Nếu mọi người tập trung vào việc lựa chọn hệ thống ràng buộc (thay vì trạng thái phân mảnh hiện nay như R1CS, AIR, Plonkish...), có thể các SNARK dựa trên ràng buộc cũng sẽ có tình huống tương tự, sử dụng một thước đo đơn giản về kích thước hệ thống ràng buộc thay vì số chu kỳ.
Cho đến lúc đó, thật khó để đạt được sự cân bằng thích hợp giữa kiểm soát quá ít và kiểm soát quá mức các yếu tố gây nhiễu. Sự bất đồng là không thể tránh khỏi, và các nhà xây dựng sẽ phải cung cấp đầy đủ bối cảnh, chi tiết và lý do đằng sau bất kỳ tiêu chuẩn đánh giá nào, để cộng đồng có thể hiểu và thảo luận.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
a16z
