Bài viết gốc từ a16z crypto
Biên soạn bởi Odaily Planet Daily Golem ( @web3_golem )
Máy ảo không kiến thức (zkVM) hứa hẹn sẽ “dân chủ hóa SNARK” bằng cách 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 ở kinh 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 đăng này, tôi đã phác thảo các giai đoạn phát triển zkVM có thể mất tới 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 là công nghệ sẵn sàng 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:
Bằng chứng về các Oracle tương tác đa thức (PIOP): Một khuôn khổ chứng minh tương tác để chứng minh các phát biểu về đa thức (hoặc các ràng buộc bắt nguồn từ chúng).
Sơ đồ cam kết đa thức (PCS): đảm bảo rằng người chứng minh không thể nói dối về việc đánh giá đa thức mà không bị phát hiện.
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
Bằng chứng xác minh chính thức về độ tin cậy của PIOP;
PCS có các bằng chứng xác minh chính thức ràng buộc theo một số giả định mật mã hoặc mô hình lý tưởng;
Nếu sử dụng Fiat-Shamir, lập luận ngắn gọn thu được bằng cách kết hợp PIOP và PCS sẽ được xác minh chính thức là an toàn trong mô hình oracle ngẫu nhiên (được bổ sung bằng các giả định mật mã khác nếu cần);
Hệ thống ràng buộc được PIOP áp dụng tương đương với bằng chứng xác minh chính thức về ngữ nghĩa của VM;
Tất cả các phần này đều được dán hoàn toàn với nhau thành một bằng chứng SNARK an toàn, được xác minh chính thức và có thể được sử dụng để chạy bất kỳ chương trình nào được chỉ định bởi mã bytecode của VM. Nếu giao thức muốn đạt được mục tiêu không có kiến thức, đặc tính này cũng phải được xác minh chính thức để đảm bảo thông tin nhạy cảm về nhân chứng không bị rò rỉ.
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.).
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 minh 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à giai đoạn 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 chặt chẽ 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à 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ụ:
“Việc tạo ra bằng chứng cho toàn bộ mạng chính Ethereum có chi phí ít hơn một triệu đô la mỗi năm.”
“Chúng tôi có thể tạo ra bằng chứng khối Ethereum gần như theo thời gian thực bằng cách sử dụng một cụm gồm hàng chục GPU.”
“ZkVM mới nhất của chúng tôi nhanh hơn phiên bản tiền nhiệm 1.000 lần.”
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ụ:
Nhanh hơn 1000 lần so với zkVM cũ, nhưng xét về mặt tuyệt đối thì vẫn rất chậm. Câu đó nói lên nhiều điều tệ hại hơn là tốt đẹp.
Đã có những đề xuất nhằm tăng lượng tính toán mà mạng chính Ethereum có thể xử lý lên gấp 10 lần. Điều này sẽ làm cho hiệu suất zkVM hiện tại thậm chí còn chậm hơn.
Những gì mọi người gọi là bằng chứng cổ phần gần thời gian thực cho các khối Ethereum vẫn chậm hơn nhiều so với yêu cầu của nhiều ứng dụng blockchain (ví dụ, thời gian khối 2 giây của Optimism nhanh hơn nhiều so với thời gian khối 12 giây của Ethereum).
“Hàng chục GPU chạy liên tục, không xảy ra lỗi” không đảm bảo được độ hoạt động ổn định.
Thực tế là chi phí để chứng minh mọi hoạt động trên mạng chính Ethereum ít hơn một triệu đô la mỗi năm phản ánh thực tế là một nút đầy đủ Ethereum chỉ tốn khoảng 25 đô la mỗi năm để thực hiện các phép tính.
Đố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:
Hiệu quả vốn có của hệ thống chứng minh cơ bản.
Tối ưu hóa theo từng ứng dụng cụ thể (chẳng hạn như biên dịch trước).
Kỹ thuật và tăng tốc phần cứng (như GPU, FPGA hoặc CPU đa lõi).
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 giai đoạn 1: “Chi phí xác minh hợp lý và không tầm thường”:
Kích thước bản in thử: Kích thước bản in thử phải nhỏ hơn kích thước bản làm chứng.
Thời gian xác minh: Việc xác minh bằng chứng không được chậm hơn việc chạy chương trình gốc (tức là thực hiện tính toán mà không cần chứng minh tính đúng đắn).
Đâ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:
Kích thước bản in thử tối đa: 256 KB.
Thời gian xác thực tối đa: 16 ms.
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ước đó.
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:
Số lượng lõi RISC-V mà FPGA có thể mô phỏng ở tốc độ gốc;
Mô phỏng và chứng minh số lượng FPGA cần thiết để thực thi RISC-V theo thời gian thực (gần như).
Nếu số tiền sau cao 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õ:
Giới hạn 2 GB áp dụng cho các câu lệnh lớn (những câu lệnh yêu cầu hàng nghìn tỷ chu kỳ CPU để chạy cục bộ). Các hệ thống chứng minh chỉ áp dụng giới hạn không gian cho các câu lệnh nhỏ sẽ thiếu khả năng ứng dụng rộng rãi.
Nếu trình chứng minh rất chậm, bạn có thể dễ dàng giữ dung lượng bộ nhớ của trình chứng minh dưới 2 GB. Do đó, để làm cho giai đoạn bộ nhớ 1 trở nên không tầm thường, tôi yêu cầu tốc độ giai đoạn 1 phải được đáp ứng trong ranh giới không gian 2 GB.
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:
Vẫn quá chậm đối với hầu hết các ứng dụng (cả bên trong và bên ngoài blockchain) : Ngay cả với biên dịch trước hàm băm và chữ ký, zkVM hiện tại vẫn quá chậm (cả bên trong và bên ngoài môi trường blockchain) do hệ thống chứng minh cốt lõi không hiệu quả.
Lỗi bảo mật : Các bản biên dịch viết tay chưa được xác minh chính thức gần như chắc chắn chứa đầy lỗi có thể dẫn đến lỗi bảo mật nghiêm trọng.
Kinh nghiệm phát triển kém: Trong hầu hết các zkVM hiện nay, việc thêm biên dịch trước mới có nghĩa là phải viết thủ công một hệ thống ràng buộc cho từng tính năng — về cơ bản là quay lại quy trình làm việc theo kiểu những năm 1960. Ngay cả với các biên dịch trước hiện có, các nhà phát triển vẫn phải cấu trúc lại mã của họ để gọi từng biên dịch trước. Chúng ta nên tối ưu hóa bảo mật và trải nghiệm của nhà phát triển, không nên hy sinh cả hai để theo đuổi hiệu suất gia tăng. Làm như vậy chỉ chứng tỏ hiệu suất không tốt như mong đợi.
Chi phí I/O và không có RAM : Mặc dù biên dịch trước có thể cải thiện hiệu suất cho các tác vụ mã hóa nặng, nhưng chúng có thể không cung cấp tốc độ đáng kể cho các khối lượng công việc đa dạng hơn vì chúng gây ra chi phí đáng kể khi truyền đầu vào/đầu ra và chúng không thể sử dụng RAM. Ngay cả trong bối cảnh blockchain, ngay khi bạn vượt ra ngoài L1 đơn khối như Ethereum (ví dụ: bạn muốn xây dựng một loạt các cầu nối chuỗi chéo), bạn sẽ phải đối mặt với các hàm băm và lược đồ chữ ký khác nhau. Việc biên dịch trước nhiều lần cho từng vấn đề không thể mở rộng quy mô và gây ra rủi ro bảo mật rất lớn.
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ỉ.
