Hôm nay, LayerZero đã ra mắt chuỗi mới của họ là Zero, bao gồm nhiều tiến bộ công nghệ — trong đó có một phương pháp chứng minh không kiến thức hoàn toàn mới, giúp tách rời việc thực thi giao dịch và xác minh. Tất cả nhờ vào “Jolt Inside”.
Jolt là gì? Jolt là một máy ảo zkVM mã nguồn mở dựa trên kiến trúc RISC-V (hoặc chính xác hơn là một “máy ảo đơn giản”), nhanh chóng, an toàn và dễ sử dụng. Nó đại diện cho một phương pháp thiết kế SNARK tiên tiến, hoàn toàn mới dựa trên ba năm nghiên cứu của a16z crypto, và chúng tôi sẽ mở mã nguồn để bất kỳ ai cũng có thể sử dụng hoặc phát triển thêm. Nhưng sự ra đời của Jolt thực chất là kết quả của một câu chuyện đã ấp ủ hàng chục năm.
Tại sao thiết kế zkVM và SNARK lại quan trọng đến vậy?
Trước khi đi sâu vào quá trình phát triển của SNARK, chúng ta cần hiểu rõ zkVM là gì.
Loại máy ảo này thường được gọi là “zk” virtual machine, nhưng đặc điểm phổ biến hơn là tính đơn giản. Mặc dù “zero knowledge” (không kiến thức) rất quan trọng trong bảo vệ quyền riêng tư, nhưng “đơn giản” nghĩa là chứng minh ngắn gọn và dễ xác minh — hai đặc tính hữu ích nhưng khác nhau, thường bị nhầm lẫn với nhau. (Jolt đã có tính đơn giản, và sắp tới cũng sẽ tích hợp zero knowledge.)
Tại sao zkVM lại quan trọng? zkVM và các chứng minh, luận chứng không kiến thức (SNARK) rộng hơn là thành phần cốt lõi cho khả năng mở rộng, quyền riêng tư và an toàn của blockchain. Các chứng minh, luận chứng và zero knowledge (gọi chung là công nghệ tính toán có thể xác thực) này có vô số ứng dụng trong ngành mã hóa và các lĩnh vực khác.
Do cấu trúc thiết kế truyền thống và các lý do khác, ngành công nghiệp đến nay vẫn chủ yếu xây dựng zkVM theo các phương pháp phức tạp; phần sau sẽ trình bày chi tiết hơn. Tuy nhiên, Jolt từ đầu đã tập trung vào một phương pháp thiết kế SNARK hoàn toàn khác, nhằm đạt hiệu quả, khả năng sử dụng và hiệu suất cao hơn.
Nói ngắn gọn, zkVM là một phương pháp chứng minh rằng bạn đã chạy đúng một chương trình máy tính. Ưu điểm của zkVM so với các SNARK khác là thân thiện với nhà phát triển. Nhờ tận dụng hạ tầng tính toán hiện có (ví dụ như hệ sinh thái compiler mã nguồn mở LLVM), nhà phát triển không cần dùng ngôn ngữ đặc thù (DSL) mà vẫn có thể khai thác sức mạnh của SNARK trong ngôn ngữ lập trình họ chọn.
Điều này khá giống với các tiêu chuẩn, thư viện tích hợp trong lĩnh vực mật mã hiện nay — các nhà phát triển bình thường hàng ngày vẫn dùng chúng mà không cần hiểu rõ cách hoạt động bên trong. Jolt cung cấp một lớp trừu tượng tương tự: chỉ cần sử dụng mã chương trình hiện có và xác thực nó, không cần lo lắng về cách hai phần này tương tác. Đây là điều kiện tiên quyết để phổ biến các ứng dụng mật mã mới.
Nhà phát triển có thể tập trung vào các thao tác thực tế. Nhờ Jolt, họ không cần kiến thức chuyên sâu về SNARK, chỉ cần nhấn một nút để tạo ra chứng minh Jolt từ mã máy tính đã viết.
Tuy nhiên, dù Jolt đã đạt nhiều tiến bộ, việc chứng minh các phép tính trung bình phức tạp (ví dụ như một phép tính chạy trong một giây trên một CPU tiêu chuẩn) vẫn đòi hỏi sức mạnh tính toán lớn. Để tạo chứng minh phức tạp trong thời gian hợp lý, bạn cần nhiều GPU. LayerZero đã chuyển mã chứng minh Jolt sang CUDA và ra mắt Zero: kết hợp thuật toán song song hóa cao của Jolt với phần cứng GPU, giúp mở rộng quy mô hơn nữa.
LayerZero hướng tới mục tiêu đưa Jolt trở thành hệ thống chứng minh GPU sản xuất, bao gồm hợp tác phát triển phiên bản GPU thân thiện với Jolt, điều này cực kỳ quan trọng để nâng cao khả năng mở rộng của zkVM và chứng minh.
Nghiên cứu mã nguồn mở
Jolt là mã nguồn mở, ai cũng có thể dùng hoặc phát triển dựa trên các công nghệ sáng tạo của nó. Mã nguồn mở chính là yếu tố thúc đẩy mạnh mẽ nhất: chia sẻ kết quả công việc để hệ sinh thái có thể sử dụng, tái sử dụng, kiểm thử, rà soát, sửa lỗi, cải tiến và sáng tạo thêm.
Việc các quỹ đầu tư mạo hiểm đầu tư vào các dự án mã nguồn mở có vẻ không phổ biến, nhưng cấu trúc nghiên cứu và phát triển hiện nay phần lớn diễn ra trong nội bộ các công ty — như các phòng thí nghiệm doanh nghiệp trước đây hoặc các phòng thí nghiệm của quỹ đầu tư ngày nay — hoặc trong giới học thuật. Mục tiêu của chúng tôi khi thành lập tổ chức nghiên cứu a16z crypto là xây dựng một phòng thí nghiệm nghiên cứu và kỹ thuật kết nối lý thuyết học thuật với thực tiễn công nghiệp. Là một quỹ đầu tư mạo hiểm, chúng tôi còn có thể tài trợ cho các dự án mà các tổ chức khác không thể, đặc biệt trong các trường hợp đầu tư ngược.
Hỗ trợ các phương pháp thiết kế SNARK theo hướng ngược lại đặc biệt quan trọng đối với Jolt, vì nó đại diện cho một “cách mạng tư duy” hoàn toàn khác biệt so với các phương pháp thiết kế truyền thống. Quá trình này đã diễn ra trong nhiều năm.
Câu chuyện về đổi mới thường xoay quanh sự thay đổi kiến trúc
Để hiểu rõ về bước đột phá của Jolt trong thiết kế SNARK, ta phải quay lại hơn hai nghìn năm trước: người Hy Lạp cổ đại đã mở đầu cho sự phát triển của hệ thống chứng minh toán học hình thức, sau đó các học giả Trung Đông, châu Á và các nơi khác cũng mở rộng lĩnh vực này.
Các chứng minh sơ khai — dựa trên các luận lý được viết theo trình tự — được ghi lại bằng ngôn ngữ hình thức hoặc công thức, để bất kỳ ai cũng có thể xác minh. Ví dụ, một nhà toán học có thể viết chứng minh trong một “quyển sách”, rồi người khác đọc từng chữ để kiểm tra. Khái niệm chứng minh tĩnh này chính là biểu hiện của lớp NP trong các lớp độ phức tạp “P vs NP”.
Chú ý rằng, phương pháp chứng minh truyền thống này là tuần tự, cần có sự chờ đợi của từng bước: nó là tĩnh, không tương tác.
Nhưng đến năm 1985*, Shafi Goldwasser, Silvio Micali và Charles Rackoff đã đề xuất khái niệm chứng minh tương tác (“IP”).[* Thực tế, bài báo của họ ra đời vài năm trước đó, nhưng bị từ chối nhiều lần mới được chấp nhận.] Phương pháp chứng minh tương tác này dựa trên ý tưởng: ví dụ, nếu hai nhà toán học trao đổi trực tiếp, họ không cần chờ một người viết chứng minh rồi thuyết phục người kia. Thay vào đó, họ có thể hỏi đáp trực tiếp; nói cách khác, chứng minh có thể được xác minh qua tương tác.
Sức mạnh của chứng minh tương tác — so với các chứng minh tĩnh của người Hy Lạp cổ — chỉ thực sự được nhận thức rõ vào năm 1990, khi Carsten Lund, Lance Fortnow, Howard Karloff và Noam Nisan đề xuất giao thức kiểm tra tổng hợp (sum-check): một phương pháp dựa trên đại số cho hệ thống chứng minh tương tác. Kết hợp với các công trình của Adi Shamir, điều này nhanh chóng dẫn đến kết luận nền tảng “IP=PSPACE” — một cách nói kỹ thuật, tóm tắt ý nghĩa sau:
Nếu người chứng minh và người xác minh có thể tương tác — như các hệ thống chứng minh truyền thống, qua thử thách và phản hồi — (với giả thiết rằng người giả mạo không thể trả lời các thử thách mà không bị lộ), thì chúng ta có thể xác minh các phát biểu phức tạp hơn rất nhiều trong thời gian ngắn hơn so với chứng minh tĩnh của người Hy Lạp cổ.
Nói cách khác: tính tương tác mang lại lợi thế lớn cho hệ thống chứng minh. Giao thức kiểm tra tổng hợp (sum-check) là trung tâm để chuyển đổi lợi thế này thành khả năng xác minh hiệu quả — cho phép xác minh kết quả của các phép tính phức tạp mà không cần tái tạo toàn bộ quá trình tính toán.
Sau đó vài năm, Joe Kilian đề xuất xây dựng các chứng minh không kiến thức ngắn gọn dựa trên các chứng minh có thể xác thực xác suất (PCP). Trong lý thuyết PCP, người chứng minh (có thể hình dung như nhà toán học Hy Lạp, nhưng giờ là máy tính) viết một chứng minh trong một “quyển sách” có độ dư thừa cao. Điều đặc biệt, nhờ độ dư thừa này, người xác minh chỉ cần lấy ngẫu nhiên vài vị trí trong sách — ví dụ như ba “từ” — để đánh giá tính hợp lệ của toàn bộ chứng minh với độ tin cậy cao.
Tuy nhiên, vấn đề là chứng minh PCP dài, mặc dù việc xác minh rất nhanh.
Kilian đã chứng minh cách kết hợp PCP với mật mã học, cho phép người chứng minh “cam kết” về toàn bộ quyển sách dài đó, rồi chỉ công bố một vài phần đã chọn cùng các chứng thực mật mã ngắn gọn. Trong giao thức Kilian, chứng minh cuối cùng chính là các phần này (cộng thêm các dữ liệu xác thực mật mã) — đủ để người xác minh tin rằng toàn bộ quyển sách là hợp lệ.
Các chứng minh này ban đầu vẫn là tương tác. Sau đó, Micali đã chứng minh cách dùng phép biến đổi Fiat-Shamir để chuyển các chứng minh dựa trên PCP của Kilian thành chứng minh phi tương tác. Nói ngắn gọn, phép biến đổi Fiat-Shamir “loại bỏ” thử thách ngẫu nhiên của người xác minh, giúp người chứng minh tự sinh ra thử thách và xuất ra toàn bộ chứng minh trong một lần.
Ảnh hưởng lâu dài của kiến trúc cũ
Nhìn lại lịch sử và quá trình phát triển của hệ thống chứng minh, ta thấy từ tĩnh → tương tác → xác suất và phi tương tác (PCP), rồi lại quay về tương tác (xem Kilian), rồi cuối cùng lại trở về phi tương tác (xem Micali). SNARK xuất hiện ở giai đoạn cuối của quá trình này: sau khi áp dụng phép biến đổi Fiat-Shamir vào chứng minh tương tác của Kilian, Micali đã tạo ra SNARK đầu tiên.
Tuy nhiên, trong các SNARK dựa trên PCP ban đầu, công việc của người chứng minh rất nặng — tốn thời gian tính toán lớn — khiến chúng khó ứng dụng thực tế.
Dẫu vậy, cách thiết kế SNARK đã duy trì trong hàng chục năm. Ngay cả khi ngành cố gắng thoát khỏi các phương pháp dựa trên PCP, các nhà thiết kế vẫn dùng các khái niệm liên quan (ví dụ như “linear PCP”), vốn chỉ là các biến thể của kỹ thuật PCP. Dù các phương pháp này có thể tạo ra SNARK ngắn, nhưng chưa bao giờ đạt tốc độ chứng minh nhanh nhất.
Các nhà thiết kế SNARK vẫn chưa quay trở lại nguồn gốc — các giao thức kiểm tra tổng hợp — để tận dụng khả năng tạo chứng minh nhanh hơn, dễ dùng hơn mà công nghệ tính toán hiện đại đã cho phép.
Trong quá trình chuyển từ (a) → (b), thách thức chính là làm sao giữ tính đơn giản của xác minh trong khi loại bỏ tính tương tác khỏi hệ thống chứng minh. Điều này khiến các nhà thiết kế từ bỏ các giao thức kiểm tra tổng hợp (tức phần tương tác).
Tuy nhiên, nếu chúng ta muốn dùng Fiat-Shamir để loại bỏ tương tác… thì nên bỏ qua luôn bước trung gian (b), tức các chứng minh có thể xác thực xác suất! Bỏ qua bước này chính là ý tưởng cốt lõi của phương pháp Jolt, giúp xây dựng SNARK trực tiếp từ chứng minh tương tác — đi thẳng vào kiểm tra tổng hợp.
Tại sao nhiều người chưa sớm chuyển sang thiết kế dựa trên kiểm tra tổng hợp? Có thể do các nhà thiết kế SNARK ban đầu chưa nhận ra rằng, PCP và SNARK về cơ bản đều hướng tới mục tiêu xác minh ngắn gọn — và các kiến trúc sau này, cùng với những hiểu lầm, vẫn duy trì quan điểm này.
Đối với chúng tôi, việc đầu tư mạnh vào zkVM dựa trên kiểm tra tổng hợp như Jolt là một cược ngược lại, vì nó đi ngược lại với các mô hình đã thống trị trong hàng chục năm qua của lĩnh vực SNARK.
‘Jolt Inside’
Phương pháp thiết kế SNARK của Jolt (dựa trên các phép đánh giá theo lô và cơ chế kiểm tra bộ nhớ, như Twist + Shout) dựa trên các chứng minh tương tác và kiểm tra tổng hợp.
Giờ đây, sau vài năm xây dựng Jolt, các nhà khác cũng bắt đầu áp dụng phương pháp kiểm tra tổng hợp trong thiết kế của họ. Vậy, Jolt có những đặc điểm nổi bật nào trong các zkVM ngày nay? Jolt tận dụng tối đa cấu trúc lặp lại trong quá trình thực thi của CPU. Bằng cách quan sát cách mô hình “lấy-giải mã-thực thi” của từng nhân CPU phù hợp với cơ chế kiểm tra tổng hợp theo lô, Jolt đạt hiệu quả vượt trội với độ phức tạp tối thiểu.
Trong khi đó, các zkVM khác lại phụ thuộc nặng nề vào “tiền biên dịch” (tương tự như các bộ tăng tốc ASIC dành riêng cho các đoạn mã đặc thù) để đạt hiệu năng hợp lý. Jolt loại bỏ các tiền biên dịch này vì chúng dễ dẫn đến các lỗi trong thiết kế SNARK, và làm khó mở rộng cho nhà phát triển. Mục tiêu của Jolt là phổ cập SNARK.
Việc xác minh tính đúng đắn của quá trình thực thi CPU chính là giá trị cốt lõi của zkVM — đồng thời là bước đột phá trong trải nghiệm nhà phát triển — vì nó cho phép tái sử dụng hạ tầng tính toán phổ biến, đã được tối ưu hóa. Hạ tầng tính toán toàn cầu đều hướng tới CPU, và Jolt tận dụng tối đa “cấu trúc” vốn có của CPU để nâng cao tính đơn giản và hiệu suất.
Jolt từ đầu đã đặt khả năng sử dụng và hiệu năng sản xuất làm ưu tiên: nhà phát triển có thể xác minh trực tiếp các chương trình hiện có; thậm chí để xác minh nhanh, không cần chỉnh sửa mã. Jolt không bắt buộc phải xây dựng lại ứng dụng dựa trên “tiền biên dịch” hoặc API đặc thù, giúp giữ nguyên mã gốc, dễ tiếp cận, dễ kiểm tra và giảm chi phí phát triển.
Quan trọng hơn, Jolt không chỉ nhanh hơn mà còn đơn giản hơn. Các phương pháp khác yêu cầu nhà thiết kế zkVM phải tạo một mạch điện cho từng lệnh cơ bản — còn Jolt thì không. Trong Jolt, mỗi lệnh cơ bản chỉ cần khoảng mười dòng Rust để định nghĩa. Không cần mạch điện, chỉ cần mười dòng mã.
Tiếp theo của Jolt là gì?
Chúng tôi đã dẫn đầu về tốc độ. Với các tối ưu và tính năng mới như recursive và zero knowledge, đặc biệt là chuyển đổi từ mật mã elliptic đến mật mã lattice, dự kiến cuối năm nay chúng tôi sẽ nâng cao tốc độ gấp nhiều lần nữa, chưa kể đến thời kỳ hậu lượng tử.
Jolt mở ra nhiều khả năng mới. Trong blockchain, khả năng mở rộng và phi tập trung mà mọi người mong đợi sẽ dễ dàng hơn để triển khai. Các chứng minh không kiến thức có thể dùng ngay mà không cần tốn nhiều tháng, nhiều năm phát triển mật mã.
Và khi Jolt tiếp tục phát triển — ví dụ như xây dựng một zkVM nhanh, dễ dùng, có thể chạy trên điện thoại và laptop — các nhà phát triển sẽ có thể mở khóa nhiều ứng dụng mới trong bảo vệ quyền riêng tư và xử lý dữ liệu tại chỗ. Ví dụ, các ứng dụng bảo vệ quyền riêng tư trên điện thoại có thể dễ dàng duy trì và vận hành, thay vì khó khăn như trước.
Trong dài hạn, các hệ thống chứng minh này sẽ trở thành thành phần cốt lõi của hạ tầng số toàn cầu, tương tự như mã hóa và chữ ký số. Công nghệ nén mật mã phổ quát này — chỉ cần gửi một tệp chứng minh 50 KB thay vì toàn bộ dữ liệu vài GB để chứng minh quyền sở hữu các thuộc tính nhất định — có khả năng mạnh mẽ đến mức khó dự đoán các ứng dụng mà con người sẽ phát triển dựa trên đó. Tương lai vô hạn.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
a16z:Các yếu tố then chốt của nhà sáng tạo: ‘Jolt Inside’
_ Tác giả bài viết: a16z crypto_
_ Dịch bài viết: Block unicorn_
Lời giới thiệu
Hôm nay, LayerZero đã ra mắt chuỗi mới của họ là Zero, bao gồm nhiều tiến bộ công nghệ — trong đó có một phương pháp chứng minh không kiến thức hoàn toàn mới, giúp tách rời việc thực thi giao dịch và xác minh. Tất cả nhờ vào “Jolt Inside”.
Jolt là gì? Jolt là một máy ảo zkVM mã nguồn mở dựa trên kiến trúc RISC-V (hoặc chính xác hơn là một “máy ảo đơn giản”), nhanh chóng, an toàn và dễ sử dụng. Nó đại diện cho một phương pháp thiết kế SNARK tiên tiến, hoàn toàn mới dựa trên ba năm nghiên cứu của a16z crypto, và chúng tôi sẽ mở mã nguồn để bất kỳ ai cũng có thể sử dụng hoặc phát triển thêm. Nhưng sự ra đời của Jolt thực chất là kết quả của một câu chuyện đã ấp ủ hàng chục năm.
Tại sao thiết kế zkVM và SNARK lại quan trọng đến vậy?
Trước khi đi sâu vào quá trình phát triển của SNARK, chúng ta cần hiểu rõ zkVM là gì.
Loại máy ảo này thường được gọi là “zk” virtual machine, nhưng đặc điểm phổ biến hơn là tính đơn giản. Mặc dù “zero knowledge” (không kiến thức) rất quan trọng trong bảo vệ quyền riêng tư, nhưng “đơn giản” nghĩa là chứng minh ngắn gọn và dễ xác minh — hai đặc tính hữu ích nhưng khác nhau, thường bị nhầm lẫn với nhau. (Jolt đã có tính đơn giản, và sắp tới cũng sẽ tích hợp zero knowledge.)
Tại sao zkVM lại quan trọng? zkVM và các chứng minh, luận chứng không kiến thức (SNARK) rộng hơn là thành phần cốt lõi cho khả năng mở rộng, quyền riêng tư và an toàn của blockchain. Các chứng minh, luận chứng và zero knowledge (gọi chung là công nghệ tính toán có thể xác thực) này có vô số ứng dụng trong ngành mã hóa và các lĩnh vực khác.
Do cấu trúc thiết kế truyền thống và các lý do khác, ngành công nghiệp đến nay vẫn chủ yếu xây dựng zkVM theo các phương pháp phức tạp; phần sau sẽ trình bày chi tiết hơn. Tuy nhiên, Jolt từ đầu đã tập trung vào một phương pháp thiết kế SNARK hoàn toàn khác, nhằm đạt hiệu quả, khả năng sử dụng và hiệu suất cao hơn.
Nói ngắn gọn, zkVM là một phương pháp chứng minh rằng bạn đã chạy đúng một chương trình máy tính. Ưu điểm của zkVM so với các SNARK khác là thân thiện với nhà phát triển. Nhờ tận dụng hạ tầng tính toán hiện có (ví dụ như hệ sinh thái compiler mã nguồn mở LLVM), nhà phát triển không cần dùng ngôn ngữ đặc thù (DSL) mà vẫn có thể khai thác sức mạnh của SNARK trong ngôn ngữ lập trình họ chọn.
Điều này khá giống với các tiêu chuẩn, thư viện tích hợp trong lĩnh vực mật mã hiện nay — các nhà phát triển bình thường hàng ngày vẫn dùng chúng mà không cần hiểu rõ cách hoạt động bên trong. Jolt cung cấp một lớp trừu tượng tương tự: chỉ cần sử dụng mã chương trình hiện có và xác thực nó, không cần lo lắng về cách hai phần này tương tác. Đây là điều kiện tiên quyết để phổ biến các ứng dụng mật mã mới.
Nhà phát triển có thể tập trung vào các thao tác thực tế. Nhờ Jolt, họ không cần kiến thức chuyên sâu về SNARK, chỉ cần nhấn một nút để tạo ra chứng minh Jolt từ mã máy tính đã viết.
Tuy nhiên, dù Jolt đã đạt nhiều tiến bộ, việc chứng minh các phép tính trung bình phức tạp (ví dụ như một phép tính chạy trong một giây trên một CPU tiêu chuẩn) vẫn đòi hỏi sức mạnh tính toán lớn. Để tạo chứng minh phức tạp trong thời gian hợp lý, bạn cần nhiều GPU. LayerZero đã chuyển mã chứng minh Jolt sang CUDA và ra mắt Zero: kết hợp thuật toán song song hóa cao của Jolt với phần cứng GPU, giúp mở rộng quy mô hơn nữa.
LayerZero hướng tới mục tiêu đưa Jolt trở thành hệ thống chứng minh GPU sản xuất, bao gồm hợp tác phát triển phiên bản GPU thân thiện với Jolt, điều này cực kỳ quan trọng để nâng cao khả năng mở rộng của zkVM và chứng minh.
Nghiên cứu mã nguồn mở
Jolt là mã nguồn mở, ai cũng có thể dùng hoặc phát triển dựa trên các công nghệ sáng tạo của nó. Mã nguồn mở chính là yếu tố thúc đẩy mạnh mẽ nhất: chia sẻ kết quả công việc để hệ sinh thái có thể sử dụng, tái sử dụng, kiểm thử, rà soát, sửa lỗi, cải tiến và sáng tạo thêm.
Việc các quỹ đầu tư mạo hiểm đầu tư vào các dự án mã nguồn mở có vẻ không phổ biến, nhưng cấu trúc nghiên cứu và phát triển hiện nay phần lớn diễn ra trong nội bộ các công ty — như các phòng thí nghiệm doanh nghiệp trước đây hoặc các phòng thí nghiệm của quỹ đầu tư ngày nay — hoặc trong giới học thuật. Mục tiêu của chúng tôi khi thành lập tổ chức nghiên cứu a16z crypto là xây dựng một phòng thí nghiệm nghiên cứu và kỹ thuật kết nối lý thuyết học thuật với thực tiễn công nghiệp. Là một quỹ đầu tư mạo hiểm, chúng tôi còn có thể tài trợ cho các dự án mà các tổ chức khác không thể, đặc biệt trong các trường hợp đầu tư ngược.
Hỗ trợ các phương pháp thiết kế SNARK theo hướng ngược lại đặc biệt quan trọng đối với Jolt, vì nó đại diện cho một “cách mạng tư duy” hoàn toàn khác biệt so với các phương pháp thiết kế truyền thống. Quá trình này đã diễn ra trong nhiều năm.
Câu chuyện về đổi mới thường xoay quanh sự thay đổi kiến trúc
Để hiểu rõ về bước đột phá của Jolt trong thiết kế SNARK, ta phải quay lại hơn hai nghìn năm trước: người Hy Lạp cổ đại đã mở đầu cho sự phát triển của hệ thống chứng minh toán học hình thức, sau đó các học giả Trung Đông, châu Á và các nơi khác cũng mở rộng lĩnh vực này.
Các chứng minh sơ khai — dựa trên các luận lý được viết theo trình tự — được ghi lại bằng ngôn ngữ hình thức hoặc công thức, để bất kỳ ai cũng có thể xác minh. Ví dụ, một nhà toán học có thể viết chứng minh trong một “quyển sách”, rồi người khác đọc từng chữ để kiểm tra. Khái niệm chứng minh tĩnh này chính là biểu hiện của lớp NP trong các lớp độ phức tạp “P vs NP”.
Chú ý rằng, phương pháp chứng minh truyền thống này là tuần tự, cần có sự chờ đợi của từng bước: nó là tĩnh, không tương tác.
Nhưng đến năm 1985*, Shafi Goldwasser, Silvio Micali và Charles Rackoff đã đề xuất khái niệm chứng minh tương tác (“IP”).[* Thực tế, bài báo của họ ra đời vài năm trước đó, nhưng bị từ chối nhiều lần mới được chấp nhận.] Phương pháp chứng minh tương tác này dựa trên ý tưởng: ví dụ, nếu hai nhà toán học trao đổi trực tiếp, họ không cần chờ một người viết chứng minh rồi thuyết phục người kia. Thay vào đó, họ có thể hỏi đáp trực tiếp; nói cách khác, chứng minh có thể được xác minh qua tương tác.
Sức mạnh của chứng minh tương tác — so với các chứng minh tĩnh của người Hy Lạp cổ — chỉ thực sự được nhận thức rõ vào năm 1990, khi Carsten Lund, Lance Fortnow, Howard Karloff và Noam Nisan đề xuất giao thức kiểm tra tổng hợp (sum-check): một phương pháp dựa trên đại số cho hệ thống chứng minh tương tác. Kết hợp với các công trình của Adi Shamir, điều này nhanh chóng dẫn đến kết luận nền tảng “IP=PSPACE” — một cách nói kỹ thuật, tóm tắt ý nghĩa sau:
Nếu người chứng minh và người xác minh có thể tương tác — như các hệ thống chứng minh truyền thống, qua thử thách và phản hồi — (với giả thiết rằng người giả mạo không thể trả lời các thử thách mà không bị lộ), thì chúng ta có thể xác minh các phát biểu phức tạp hơn rất nhiều trong thời gian ngắn hơn so với chứng minh tĩnh của người Hy Lạp cổ.
Nói cách khác: tính tương tác mang lại lợi thế lớn cho hệ thống chứng minh. Giao thức kiểm tra tổng hợp (sum-check) là trung tâm để chuyển đổi lợi thế này thành khả năng xác minh hiệu quả — cho phép xác minh kết quả của các phép tính phức tạp mà không cần tái tạo toàn bộ quá trình tính toán.
Sau đó vài năm, Joe Kilian đề xuất xây dựng các chứng minh không kiến thức ngắn gọn dựa trên các chứng minh có thể xác thực xác suất (PCP). Trong lý thuyết PCP, người chứng minh (có thể hình dung như nhà toán học Hy Lạp, nhưng giờ là máy tính) viết một chứng minh trong một “quyển sách” có độ dư thừa cao. Điều đặc biệt, nhờ độ dư thừa này, người xác minh chỉ cần lấy ngẫu nhiên vài vị trí trong sách — ví dụ như ba “từ” — để đánh giá tính hợp lệ của toàn bộ chứng minh với độ tin cậy cao.
Tuy nhiên, vấn đề là chứng minh PCP dài, mặc dù việc xác minh rất nhanh.
Kilian đã chứng minh cách kết hợp PCP với mật mã học, cho phép người chứng minh “cam kết” về toàn bộ quyển sách dài đó, rồi chỉ công bố một vài phần đã chọn cùng các chứng thực mật mã ngắn gọn. Trong giao thức Kilian, chứng minh cuối cùng chính là các phần này (cộng thêm các dữ liệu xác thực mật mã) — đủ để người xác minh tin rằng toàn bộ quyển sách là hợp lệ.
Các chứng minh này ban đầu vẫn là tương tác. Sau đó, Micali đã chứng minh cách dùng phép biến đổi Fiat-Shamir để chuyển các chứng minh dựa trên PCP của Kilian thành chứng minh phi tương tác. Nói ngắn gọn, phép biến đổi Fiat-Shamir “loại bỏ” thử thách ngẫu nhiên của người xác minh, giúp người chứng minh tự sinh ra thử thách và xuất ra toàn bộ chứng minh trong một lần.
Ảnh hưởng lâu dài của kiến trúc cũ
Nhìn lại lịch sử và quá trình phát triển của hệ thống chứng minh, ta thấy từ tĩnh → tương tác → xác suất và phi tương tác (PCP), rồi lại quay về tương tác (xem Kilian), rồi cuối cùng lại trở về phi tương tác (xem Micali). SNARK xuất hiện ở giai đoạn cuối của quá trình này: sau khi áp dụng phép biến đổi Fiat-Shamir vào chứng minh tương tác của Kilian, Micali đã tạo ra SNARK đầu tiên.
Tuy nhiên, trong các SNARK dựa trên PCP ban đầu, công việc của người chứng minh rất nặng — tốn thời gian tính toán lớn — khiến chúng khó ứng dụng thực tế.
Dẫu vậy, cách thiết kế SNARK đã duy trì trong hàng chục năm. Ngay cả khi ngành cố gắng thoát khỏi các phương pháp dựa trên PCP, các nhà thiết kế vẫn dùng các khái niệm liên quan (ví dụ như “linear PCP”), vốn chỉ là các biến thể của kỹ thuật PCP. Dù các phương pháp này có thể tạo ra SNARK ngắn, nhưng chưa bao giờ đạt tốc độ chứng minh nhanh nhất.
Các nhà thiết kế SNARK vẫn chưa quay trở lại nguồn gốc — các giao thức kiểm tra tổng hợp — để tận dụng khả năng tạo chứng minh nhanh hơn, dễ dùng hơn mà công nghệ tính toán hiện đại đã cho phép.
Nói cách khác, để sớm hơn áp dụng các giao thức kiểm tra tổng hợp, chúng ta cần nhìn nhận lịch sử SNARK theo hướng phi tuyến tính: từ (a) chứng minh tương tác → (b) PCP → © chứng minh tương tác đơn giản hóa → (d) SNARK sơ khai. Trong quá trình chuyển đổi này, ngành đã trải qua các bước:
Trong quá trình chuyển từ (a) → (b), thách thức chính là làm sao giữ tính đơn giản của xác minh trong khi loại bỏ tính tương tác khỏi hệ thống chứng minh. Điều này khiến các nhà thiết kế từ bỏ các giao thức kiểm tra tổng hợp (tức phần tương tác).
Khi từ (b) chuyển sang ©, tính tương tác lại xuất hiện… và cuối cùng, qua phép biến đổi Fiat-Shamir, nó bị loại bỏ, dẫn đến bước chuyển từ chứng minh tương tác đơn giản sang SNARK sơ khai.
Xem xét theo chiều dài, các bước (a) → (b) → © → (d) rõ ràng cho thấy, các nhà thiết kế SNARK đã hai lần bỏ qua tính tương tác — một lần từ (a) → (b), lần nữa từ © → (d).
Tuy nhiên, nếu chúng ta muốn dùng Fiat-Shamir để loại bỏ tương tác… thì nên bỏ qua luôn bước trung gian (b), tức các chứng minh có thể xác thực xác suất! Bỏ qua bước này chính là ý tưởng cốt lõi của phương pháp Jolt, giúp xây dựng SNARK trực tiếp từ chứng minh tương tác — đi thẳng vào kiểm tra tổng hợp.
Tại sao nhiều người chưa sớm chuyển sang thiết kế dựa trên kiểm tra tổng hợp? Có thể do các nhà thiết kế SNARK ban đầu chưa nhận ra rằng, PCP và SNARK về cơ bản đều hướng tới mục tiêu xác minh ngắn gọn — và các kiến trúc sau này, cùng với những hiểu lầm, vẫn duy trì quan điểm này.
Đối với chúng tôi, việc đầu tư mạnh vào zkVM dựa trên kiểm tra tổng hợp như Jolt là một cược ngược lại, vì nó đi ngược lại với các mô hình đã thống trị trong hàng chục năm qua của lĩnh vực SNARK.
‘Jolt Inside’
Phương pháp thiết kế SNARK của Jolt (dựa trên các phép đánh giá theo lô và cơ chế kiểm tra bộ nhớ, như Twist + Shout) dựa trên các chứng minh tương tác và kiểm tra tổng hợp.
Giờ đây, sau vài năm xây dựng Jolt, các nhà khác cũng bắt đầu áp dụng phương pháp kiểm tra tổng hợp trong thiết kế của họ. Vậy, Jolt có những đặc điểm nổi bật nào trong các zkVM ngày nay? Jolt tận dụng tối đa cấu trúc lặp lại trong quá trình thực thi của CPU. Bằng cách quan sát cách mô hình “lấy-giải mã-thực thi” của từng nhân CPU phù hợp với cơ chế kiểm tra tổng hợp theo lô, Jolt đạt hiệu quả vượt trội với độ phức tạp tối thiểu.
Trong khi đó, các zkVM khác lại phụ thuộc nặng nề vào “tiền biên dịch” (tương tự như các bộ tăng tốc ASIC dành riêng cho các đoạn mã đặc thù) để đạt hiệu năng hợp lý. Jolt loại bỏ các tiền biên dịch này vì chúng dễ dẫn đến các lỗi trong thiết kế SNARK, và làm khó mở rộng cho nhà phát triển. Mục tiêu của Jolt là phổ cập SNARK.
Việc xác minh tính đúng đắn của quá trình thực thi CPU chính là giá trị cốt lõi của zkVM — đồng thời là bước đột phá trong trải nghiệm nhà phát triển — vì nó cho phép tái sử dụng hạ tầng tính toán phổ biến, đã được tối ưu hóa. Hạ tầng tính toán toàn cầu đều hướng tới CPU, và Jolt tận dụng tối đa “cấu trúc” vốn có của CPU để nâng cao tính đơn giản và hiệu suất.
Jolt từ đầu đã đặt khả năng sử dụng và hiệu năng sản xuất làm ưu tiên: nhà phát triển có thể xác minh trực tiếp các chương trình hiện có; thậm chí để xác minh nhanh, không cần chỉnh sửa mã. Jolt không bắt buộc phải xây dựng lại ứng dụng dựa trên “tiền biên dịch” hoặc API đặc thù, giúp giữ nguyên mã gốc, dễ tiếp cận, dễ kiểm tra và giảm chi phí phát triển.
Quan trọng hơn, Jolt không chỉ nhanh hơn mà còn đơn giản hơn. Các phương pháp khác yêu cầu nhà thiết kế zkVM phải tạo một mạch điện cho từng lệnh cơ bản — còn Jolt thì không. Trong Jolt, mỗi lệnh cơ bản chỉ cần khoảng mười dòng Rust để định nghĩa. Không cần mạch điện, chỉ cần mười dòng mã.
Tiếp theo của Jolt là gì?
Chúng tôi đã dẫn đầu về tốc độ. Với các tối ưu và tính năng mới như recursive và zero knowledge, đặc biệt là chuyển đổi từ mật mã elliptic đến mật mã lattice, dự kiến cuối năm nay chúng tôi sẽ nâng cao tốc độ gấp nhiều lần nữa, chưa kể đến thời kỳ hậu lượng tử.
Jolt mở ra nhiều khả năng mới. Trong blockchain, khả năng mở rộng và phi tập trung mà mọi người mong đợi sẽ dễ dàng hơn để triển khai. Các chứng minh không kiến thức có thể dùng ngay mà không cần tốn nhiều tháng, nhiều năm phát triển mật mã.
Và khi Jolt tiếp tục phát triển — ví dụ như xây dựng một zkVM nhanh, dễ dùng, có thể chạy trên điện thoại và laptop — các nhà phát triển sẽ có thể mở khóa nhiều ứng dụng mới trong bảo vệ quyền riêng tư và xử lý dữ liệu tại chỗ. Ví dụ, các ứng dụng bảo vệ quyền riêng tư trên điện thoại có thể dễ dàng duy trì và vận hành, thay vì khó khăn như trước.
Trong dài hạn, các hệ thống chứng minh này sẽ trở thành thành phần cốt lõi của hạ tầng số toàn cầu, tương tự như mã hóa và chữ ký số. Công nghệ nén mật mã phổ quát này — chỉ cần gửi một tệp chứng minh 50 KB thay vì toàn bộ dữ liệu vài GB để chứng minh quyền sở hữu các thuộc tính nhất định — có khả năng mạnh mẽ đến mức khó dự đoán các ứng dụng mà con người sẽ phát triển dựa trên đó. Tương lai vô hạn.