Được viết bởi: a16z crypto

Máy ảo không kiến ​​thức (zkVM) hứa hẹn sẽ “dân chủ hóa SNARK”, cho phép bất kỳ ai (kể cả những người không có chuyên môn về SNARK) chứng minh rằng họ đã chạy đúng bất kỳ chương trình nào trên một đầu vào nhất định (hoặc bằng chứng). Điểm mạnh cốt lõi của họ nằm ở trải nghiệm của nhà phát triển, nhưng hiện tại họ đang phải đối mặt với những thách thức lớn về cả bảo mật và hiệu suất. Để tầm nhìn của zkVM có thể thực hiện được như lời hứa, các nhà thiết kế phải vượt qua những thách thức này. Trong bài viết này, tôi đã phác thảo các giai đoạn phát triển zkVM có thể mất vài năm để hoàn thành.

thử thách

Về mặt bảo mật, zkVM là một dự án phần mềm cực kỳ phức tạp và vẫn còn nhiều lỗ hổng. Về mặt hiệu suất, việc chứng minh một chương trình thực thi đúng có thể chậm hơn hàng trăm nghìn lần so với việc chạy chương trình gốc, khiến cho hầu hết các ứng dụng hiện không thể triển khai trong thế giới thực.

Bất chấp những thách thức thực tế này, hầu hết các công ty trong ngành blockchain đều mô tả zkVM có thể triển khai ngay lập tức. Trên thực tế, một số dự án đã phải trả chi phí tính toán đáng kể để tạo ra bằng chứng về hoạt động trên chuỗi. Nhưng vì zkVM vẫn chưa hoàn hảo nên đây chỉ là một cách tốn kém để giả vờ rằng hệ thống được bảo vệ bởi SNARK, trong khi trên thực tế, hệ thống được bảo vệ bằng quyền hoặc tệ hơn là dễ bị tấn công.

Chúng ta vẫn còn phải mất nhiều năm nữa mới có được một zkVM an toàn và hiệu quả. Bài đăng này đề xuất một loạt các mục tiêu cụ thể theo từng giai đoạn để theo dõi tiến độ của zkVM — các mục tiêu giúp loại bỏ sự cường điệu và giúp cộng đồng tập trung vào tiến độ thực sự.

Giai đoạn bảo mật

Các zkVM dựa trên SNARK thường bao gồm hai thành phần chính:

Về cơ bản, zkVM mã hóa một dấu vết thực thi hợp lệ dưới dạng một hệ thống ràng buộc — nghĩa rộng là chúng thực thi việc sử dụng đúng các thanh ghi và bộ nhớ của máy ảo — và sau đó áp dụng SNARK để chứng minh rằng các ràng buộc này được đáp ứng.

Cách duy nhất để đảm bảo một hệ thống phức tạp như zkVM không có lỗi là thông qua xác minh chính thức. Sau đây là phân tích các giai đoạn bảo mật. Giai đoạn 1 tập trung vào giao thức đúng, trong khi giai đoạn 2 và 3 tập trung vào việc triển khai đúng.

Giai đoạn bảo mật 1: Giao thức đúng

Cảnh báo đệ quy: Nếu zkVM sử dụng đệ quy, thì mọi PIOP, lược đồ cam kết và hệ thống ràng buộc liên quan ở bất kỳ đâu trong đệ quy đó phải được xác minh để giai đoạn này được coi là hoàn tất.

Giai đoạn bảo mật 2: Triển khai xác thực chính xác

Xác minh chính thức chứng minh rằng việc triển khai thực tế của trình xác thực zkVM (trong Rust, Solidity, v.v.) khớp với giao thức đã xác minh ở giai đoạn 1. Việc thực hiện điều này đảm bảo rằng giao thức được triển khai là giao thức hợp lý (và không chỉ là thiết kế trên giấy hoặc thông số kỹ thuật kém hiệu quả được viết theo phương pháp Lean, v.v.).

Giai đoạn bảo mật 2: Triển khai xác thực chính xác

Xác minh chính thức chứng minh rằng việc triển khai thực tế của trình xác thực zkVM (trong Rust, Solidity, v.v.) khớp với giao thức đã xác minh ở giai đoạn 1. Việc thực hiện điều này đảm bảo rằng giao thức được triển khai là giao thức hợp lý (và không chỉ là thiết kế trên giấy hoặc thông số kỹ thuật kém hiệu quả được viết theo phương pháp Lean, v.v.).

Có hai lý do khiến Giai đoạn 2 chỉ tập trung vào việc triển khai trình xác minh (và không phải trình chứng minh). Đầu tiên, việc sử dụng đúng công cụ xác minh là đủ để đảm bảo tính hợp lý (tức là đảm bảo rằng người xác minh không thể tin rằng bất kỳ tuyên bố sai nào thực sự là sự thật). Thứ hai, việc triển khai trình xác thực zkVM đơn giản hơn rất nhiều so với việc triển khai trình chứng minh.

Giai đoạn bảo mật 3: Triển khai Prover đúng cách

Việc triển khai thực tế của trình chứng minh zkVM sẽ tạo ra các bằng chứng chính xác cho hệ thống bằng chứng được xác minh trong cả giai đoạn 1 và 2, tức là nó được xác minh chính thức. Điều này đảm bảo tính hoàn chỉnh, nghĩa là bất kỳ hệ thống nào sử dụng zkVM đều không thể bị "mắc kẹt" với các tuyên bố không thể chứng minh được. Thuộc tính này phải được xác minh chính thức nếu người chứng minh muốn đạt được mục tiêu không có kiến ​​thức.

Thời gian dự kiến

Tiến độ giai đoạn 1: Chúng ta có thể mong đợi những thành tựu gia tăng trong năm tới (ví dụ: ZKLib). Nhưng không có zkVM nào có thể đáp ứng đầy đủ các yêu cầu của Giai đoạn 1 trong ít nhất hai năm;

Giai đoạn 2 và 3: Các giai đoạn này có thể được tiến hành song song với một số khía cạnh của Giai đoạn 1. Ví dụ, một số nhóm đã chứng minh rằng việc triển khai trình xác thực Plonk của họ khớp với giao thức trong bài báo (mặc dù giao thức của bài báo có thể chưa được xác minh đầy đủ). Tuy nhiên, tôi không mong đợi bất kỳ zkVM nào có thể đạt đến giai đoạn 3 trong vòng chưa đầy bốn năm — và có thể còn lâu hơn.

Ghi chú chính: Bảo mật Fiat-Shamir và mã byte đã xác minh

Một vấn đề phức tạp lớn là vẫn còn những câu hỏi nghiên cứu chưa được giải đáp xung quanh tính an toàn của quá trình chuyển đổi Fiat-Shamir. Cả ba giai đoạn đều coi Fiat-Shamir và các nhà tiên tri ngẫu nhiên là một phần của hệ thống bảo mật không thể sai lầm của họ, nhưng trên thực tế toàn bộ mô hình đều có thể có lỗ hổng. Điều này là do sự khác biệt giữa thuật toán ngẫu nhiên lý tưởng và các hàm băm thực sự được sử dụng. Trong trường hợp xấu nhất, một hệ thống đã đạt đến giai đoạn 2 sau đó có thể bị phát hiện là hoàn toàn không an toàn do sự cố Fiat-Shamir. Điều này đã dẫn tới những lo ngại nghiêm trọng và các cuộc nghiên cứu đang được tiến hành. Chúng ta có thể cần phải sửa đổi quá trình chuyển đổi để bảo vệ tốt hơn trước loại lỗ hổng này.

Về mặt lý thuyết, các hệ thống không có đệ quy mạnh mẽ hơn vì một số cuộc tấn công đã biết liên quan đến các mạch tương tự như mạch được sử dụng trong các bằng chứng đệ quy.

Điều đáng lưu ý là việc chứng minh một chương trình máy tính chạy đúng (theo quy định của mã bytecode) sẽ không có giá trị nếu bản thân mã bytecode bị lỗi. Do đó, tính hữu ích của zkVM phụ thuộc rất nhiều vào các phương pháp tạo mã bytecode được xác minh chính thức - một thách thức lớn nằm ngoài phạm vi của bài viết này.

Về an ninh trong kỷ nguyên hậu lượng tử

Máy tính lượng tử sẽ không gây ra mối đe dọa nghiêm trọng trong ít nhất năm năm tới (và có thể lâu hơn), trong khi lỗ hổng bảo mật lại là rủi ro hiện hữu. Do đó, trọng tâm chính hiện nay là phải đáp ứng các giai đoạn bảo mật và hiệu suất được thảo luận trong bài viết này. Nếu chúng ta có thể đáp ứng các yêu cầu bảo mật này nhanh hơn bằng cách sử dụng SNARK không bảo mật lượng tử, thì chúng ta nên làm như vậy cho đến khi SNARK hậu lượng tử bắt kịp hoặc cho đến khi mọi người thực sự lo ngại về máy tính lượng tử có liên quan đến mật mã trước khi cân nhắc các lựa chọn khác.

Hiệu suất hiện tại của zkVM

Hiện tại, chi phí chung phát sinh do trình chứng minh zkVM gần gấp 1 triệu lần chi phí thực thi gốc. Nếu một chương trình mất X chu kỳ để chạy, thì chi phí để chứng minh việc thực thi đúng là khoảng X lần 1 triệu chu kỳ CPU. Tình trạng này đã xảy ra cách đây một năm và vẫn tiếp diễn cho đến ngày nay.

Những câu chuyện phổ biến thường mô tả việc chi tiêu này theo cách khiến nó có vẻ chấp nhận được. Ví dụ:

Mặc dù về mặt kỹ thuật, những tuyên bố này là chính xác, nhưng chúng có thể gây hiểu lầm nếu không có bối cảnh phù hợp. Ví dụ:

Mặc dù về mặt kỹ thuật, những tuyên bố này là chính xác, nhưng chúng có thể gây hiểu lầm nếu không có bối cảnh phù hợp. Ví dụ:

Đối với các ứng dụng khác ngoài blockchain, chi phí như vậy rõ ràng là quá cao. Không có lượng song song hóa hay kỹ thuật nào có thể bù đắp được chi phí khổng lồ như vậy. Chúng ta nên hướng tới mục tiêu cơ bản là zkVM không chậm hơn 100.000 lần so với thực thi gốc - ngay cả khi đây chỉ là bước đầu tiên. Việc áp dụng rộng rãi thực sự có thể sẽ đòi hỏi chi phí gần 10.000 lần hoặc ít hơn.

Cách đo lường hiệu suất

Hiệu suất của SNARK bao gồm ba thành phần chính:

Trong khi hai điều sau rất quan trọng đối với việc triển khai thực tế, chúng thường áp dụng cho bất kỳ hệ thống chứng minh nào, do đó chúng không nhất thiết phản ánh chi phí cơ bản. Ví dụ, việc thêm khả năng tăng tốc GPU và biên dịch trước vào zkEVM có thể dễ dàng tăng tốc gấp 50 lần so với phương pháp chỉ dựa trên CPU mà không cần biên dịch trước - đủ để khiến một hệ thống vốn kém hiệu quả trông vượt trội hơn so với hệ thống chưa được cải thiện tương tự.

Do đó, phần sau đây tập trung vào hiệu suất của SNARK mà không cần phần cứng chuyên dụng và biên dịch trước. Điều này khác với các phương pháp đánh giá chuẩn hiện tại, thường tổng hợp cả ba yếu tố thành một “con số tiêu đề” duy nhất. Điều này tương đương với việc đánh giá giá trị của một viên kim cương dựa trên thời gian đánh bóng thay vì độ trong suốt vốn có của nó. Mục tiêu của chúng tôi là loại bỏ chi phí cố hữu của các hệ thống chứng minh mục đích chung, giúp cộng đồng loại bỏ sự lộn xộn và tập trung vào tiến trình thực sự trong thiết kế hệ thống chứng minh.

Giai đoạn thực hiện

Sau đây là 5 cột mốc hiệu suất đã đạt được. Đầu tiên, chúng ta cần giảm đáng kể chi phí xử lý của CPU. Chỉ khi đó, trọng tâm mới chuyển sang việc giảm thiểu hơn nữa thông qua phần cứng. Việc sử dụng bộ nhớ cũng cần phải được cải thiện.

Trong tất cả các giai đoạn tiếp theo, các nhà phát triển không phải thiết lập mã tùy chỉnh dựa trên zkVM để đạt được hiệu suất cần thiết. Kinh nghiệm của nhà phát triển là lợi thế chính của zkVM. Việc hy sinh DevEx để đáp ứng các tiêu chuẩn hiệu suất sẽ phá vỡ mục đích của zkVM.

Các số liệu này tập trung vào chi phí chứng minh. Tuy nhiên, nếu cho phép chi phí xác minh không giới hạn (tức là không có giới hạn trên về kích thước bằng chứng hoặc thời gian xác minh), bất kỳ số liệu chứng minh nào cũng có thể dễ dàng đạt được. Do đó, để hệ thống tuân thủ các giai đoạn đã mô tả, cần phải chỉ định các giá trị tối đa cho kích thước bản kiểm tra và thời gian xác minh.

Yêu cầu về hiệu suất

Yêu cầu của Giai đoạn 1: “Chi phí xác minh hợp lý và không tầm thường”:

Đây là những yêu cầu tối giản. Họ đảm bảo rằng kích thước bằng chứng và thời gian xác minh không tệ hơn việc gửi nhân chứng đến người xác minh và để người xác minh kiểm tra tính chính xác trực tiếp.

Yêu cầu của Giai đoạn 2 trở đi:

Những ngưỡng này được cố tình thiết kế lớn để phù hợp với các kỹ thuật kiểm tra nhanh mới có thể gây ra chi phí xác minh cao hơn. Đồng thời, chúng loại trừ những bằng chứng quá tốn kém đến nỗi ít dự án nào muốn đưa chúng vào blockchain của mình.

Tốc độ giai đoạn 1

Bằng chứng luồng đơn phải chậm hơn tới một trăm nghìn lần so với thực thi gốc, được đo lường trên nhiều ứng dụng (không chỉ chứng minh các khối Ethereum) mà không cần dựa vào biên dịch trước.

Để hiểu rõ hơn, hãy tưởng tượng một quy trình RISC-V chạy ở tốc độ khoảng 3 tỷ chu kỳ mỗi giây trên một máy tính xách tay hiện đại. Đạt được giai đoạn 1 có nghĩa là bạn có thể chứng minh khoảng 30.000 chu kỳ RISC-V mỗi giây (luồng đơn) trên cùng một máy tính xách tay. Nhưng chi phí xác minh phải "hợp lý và không tầm thường" như đã đề cập ở trên.

Để hiểu rõ hơn, hãy tưởng tượng một quy trình RISC-V chạy ở tốc độ khoảng 3 tỷ chu kỳ mỗi giây trên một máy tính xách tay hiện đại. Đạt được giai đoạn 1 có nghĩa là bạn có thể chứng minh khoảng 30.000 chu kỳ RISC-V mỗi giây (luồng đơn) trên cùng một máy tính xách tay. Nhưng chi phí xác minh phải "hợp lý và không tầm thường" như đã đề cập ở trên.

Tốc độ Giai đoạn 2

Bằng chứng luồng đơn có thể chậm hơn tới mười nghìn lần so với thực thi gốc.

Ngoài ra, vì một số phương pháp SNARK đầy hứa hẹn (đặc biệt là những phương pháp dựa trên trường nhị phân) bị cản trở bởi CPU và GPU hiện tại, bạn có thể đạt đến giai đoạn này bằng cách sử dụng FPGA (hoặc thậm chí là ASIC) để so sánh:

Nếu số tiền sau lớn hơn số tiền trước nhiều nhất là 10.000 lần, bạn sẽ đủ điều kiện vào Giai đoạn 2. Trên CPU tiêu chuẩn, kích thước bằng chứng phải tối đa là 256 KB và thời gian xác minh tối đa là 16 mili giây.

Tốc độ Giai đoạn 3

Ngoài việc đạt được tốc độ giai đoạn 2, có thể đạt được chi phí kiểm tra dưới 1000 lần (cho nhiều ứng dụng khác nhau) bằng cách sử dụng tổng hợp tự động và biên dịch trước xác minh chính thức. Về cơ bản, bộ hướng dẫn có thể được tùy chỉnh động cho từng chương trình để tăng tốc độ kiểm tra, nhưng theo cách dễ sử dụng và xác minh chính thức.

Giai đoạn ghi nhớ 1

Tốc độ của Giai đoạn 1 đạt được trong khi bộ chứng minh chỉ cần chưa đến 2 GB bộ nhớ (đồng thời đạt được mức kiến ​​thức bằng không).

Điều này rất quan trọng đối với nhiều thiết bị di động hoặc trình duyệt, do đó mở ra vô số trường hợp sử dụng zkVM ở phía máy khách. Xác nhận của khách hàng rất quan trọng vì điện thoại là phương tiện kết nối liên tục của chúng ta với thế giới thực: chúng theo dõi vị trí, thông tin đăng nhập và nhiều thông tin khác của chúng ta. Nếu việc tạo bằng chứng yêu cầu hơn 1-2 GB bộ nhớ thì sẽ quá nhiều đối với hầu hết các thiết bị di động hiện nay. Có hai điểm cần làm rõ:

Giai đoạn ghi nhớ 2

Tốc độ của giai đoạn 1 đạt được với mức sử dụng bộ nhớ dưới 200 MB (tốt hơn 10 lần so với giai đoạn 1 về mặt bộ nhớ).

Tại sao lại giảm xuống dưới 2 GB? Hãy xem xét một ví dụ không liên quan đến blockchain: mỗi khi bạn truy cập một trang web qua HTTPS, bạn sẽ tải xuống một chứng chỉ để xác thực và mã hóa. Thay vào đó, các trang web có thể gửi bằng chứng zk chứng minh rằng họ sở hữu những chứng chỉ này. Các trang web lớn có thể phát hành hàng triệu bản bằng chứng này mỗi giây. Nếu mỗi bằng chứng yêu cầu 2 GB bộ nhớ để tạo ra thì tổng cộng cần có PB RAM. Việc tiếp tục giảm thiểu việc sử dụng bộ nhớ là rất quan trọng đối với các triển khai không sử dụng blockchain.

Biên dịch trước: Dặm cuối cùng hay là sự hỗ trợ?

Trong thiết kế zkVM, biên dịch trước đề cập đến các SNARK chuyên biệt (hoặc hệ thống ràng buộc) được thiết kế riêng cho chức năng cụ thể, chẳng hạn như băm Keccak/SHA hoặc hoạt động nhóm đường cong elip cho chữ ký số. Trong Ethereum (nơi hầu hết các công việc nặng nhọc liên quan đến hàm băm Merkle và kiểm tra chữ ký), một vài bản biên dịch trước được tạo thủ công có thể giảm chi phí cho người chứng minh. Nhưng việc dựa vào chúng như một cái nạng sẽ không đưa SNARK đến nơi chúng cần đến. Sau đây là những lý do:

Trong thiết kế zkVM, biên dịch trước đề cập đến các SNARK chuyên biệt (hoặc hệ thống ràng buộc) được thiết kế riêng cho chức năng cụ thể, chẳng hạn như băm Keccak/SHA hoặc hoạt động nhóm đường cong elip cho chữ ký số. Trong Ethereum (nơi hầu hết các công việc nặng nhọc liên quan đến hàm băm Merkle và kiểm tra chữ ký), một vài bản biên dịch trước được tạo thủ công có thể giảm chi phí cho người chứng minh. Nhưng việc dựa vào chúng như một cái nạng sẽ không đưa SNARK đến nơi chúng cần đến. Sau đây là những lý do:

Vì tất cả những lý do này, ưu tiên hàng đầu của chúng ta là cải thiện hiệu quả của zkVM cơ bản. Các kỹ thuật tạo ra zkVM tốt nhất cũng tạo ra các trình biên dịch trước tốt nhất. Tôi tin rằng biên dịch trước sẽ vẫn cần thiết về lâu dài, nhưng chỉ khi chúng được tổng hợp tự động và xác minh chính thức. Theo cách này, lợi ích về trải nghiệm của nhà phát triển khi sử dụng zkVM vẫn được duy trì đồng thời tránh được những rủi ro bảo mật nghiêm trọng. Quan điểm này được phản ánh trong giai đoạn tốc độ 3.

Thời gian dự kiến

Tôi hy vọng một số ít zkVM sẽ đạt đến tốc độ giai đoạn 1 và bộ nhớ giai đoạn 1 vào cuối năm nay. Tôi nghĩ chúng ta sẽ đạt được Giai đoạn 2 của Tốc độ trong vòng hai năm tới, nhưng không rõ liệu chúng ta có thể đạt được điều đó nếu không có một số ý tưởng mới chưa xuất hiện hay không. Tôi dự đoán các giai đoạn còn lại (Giai đoạn tốc độ 3 và Giai đoạn bộ nhớ 2) sẽ mất vài năm để đạt được.

Tóm tắt

Mặc dù tôi xác định các giai đoạn bảo mật và hiệu suất của zkVM riêng biệt trong bài đăng này, nhưng các khía cạnh này của zkVM không hoàn toàn độc lập. Khi phát hiện thêm nhiều lỗ hổng trong zkVM, chúng tôi dự đoán rằng một số lỗ hổng sẽ chỉ được khắc phục nhưng hiệu suất sẽ giảm đáng kể. Hiệu suất sẽ bị tạm dừng cho đến khi zkVM đạt đến giai đoạn an toàn 2.

zkVM có tiềm năng biến chứng cứ không kiến ​​thức trở nên thực sự phổ biến, nhưng chúng vẫn còn trong giai đoạn sơ khai — đầy rẫy những thách thức về bảo mật và chi phí hiệu suất đáng kể. Sự cường điệu và tuyên truyền tiếp thị khiến việc đánh giá tiến độ thực sự trở nên khó khăn. Bằng cách nêu rõ các mốc quan trọng về an toàn và hiệu suất, chúng tôi hy vọng có thể cung cấp lộ trình để loại bỏ sự mất tập trung. Chúng ta sẽ đạt được điều đó, nhưng sẽ cần thời gian và nỗ lực bền bỉ.