a16z: Cách triển khai zkVM an toàn và hiệu quả theo từng giai đoạn (phải đọc đối với các nhà phát triển)

Tiêu đề gốc: Con đường đến zkVM an toàn và hiệu quả: Cách theo dõi tiến trình

Tác giả gốc: a16z crypto

Bản dịch gốc: Golem, Odaily Planet Daily

zkVM (máy ảo không kiến thức) 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 nhân 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 đă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ách thức

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 đầy 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 công nghiệp 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ó thể đạt được một zkVM an toàn và hiệu suất cao. 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

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

· Bằng chứng Oracle tương tác trên đa thức (PIOP): Một khuôn khổ bằng chứng tương tác để chứng minh các tuyên bố về đa thức (hoặc các ràng buộc bắt nguồn từ chúng).

· Phương án 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 buộc máy ảo sử dụng đúng các thanh ghi và bộ nhớ — 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

1. Bằng chứng xác minh chính thức về tính hợp lệ của PIOP;

2. Bằng chứng xác minh chính thức rằng PCS có tính ràng buộc theo một số giả định mật mã hoặc mô hình lý tưởng;

3. Bằng chứng xác minh chính thức rằng đối số ngắn gọn thu được bằng cách kết hợp PIOP và PCS là an toàn trong mô hình oracle ngẫu nhiên nếu Fiat-Shamir được sử dụng (được bổ sung bằng các giả định mật mã khác nếu cần);

4. Bằng chứng xác minh chính thức rằng hệ thống ràng buộc do PIOP áp dụng tương đương với ngữ nghĩa của VM;

5. "Dán" toàn diện tất cả các phần trên thành một bằng chứng SNARK an toàn, được xác minh chính thức duy nhất có thể được sử dụng để chạy bất kỳ chương trình nào do mã byte của VM chỉ định. 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 trình 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 trong 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.).

Lý do tại sao 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) là có hai mặt. Đầ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 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.

Dòng 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 (ví dụ: ZKLib) trong năm tới. 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à vẫn còn những câu hỏi nghiên cứu chưa được giải quyết xung quanh tính bảo mật của phép biế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ể xuyên thủng 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, 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 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ư các mạch được sử dụng trong các bằng chứng đệ quy.

Một lưu ý nữa là việc chứng minh một chương trình máy tính chạy đúng (như được chỉ định bởi mã bytecode) sẽ không có giá trị nếu chính 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 hậu lượng tử

Trong ít nhất năm năm tới (và có thể lâu hơn), máy tính lượng tử sẽ không gây ra mối đe dọa nghiêm trọng, 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 sớm 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.

Trạng thái hiệu suất của ZkVM

Hiện tại, hệ số chi phí chung phát sinh bởi 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 có vẻ chấp nhận được. Ví dụ: · “Chi phí tạo bằng chứng cho toàn bộ mạng chính Ethereum chưa đến một triệu đô la mỗi năm.” · “Chúng tôi có thể tạo 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 1000 lần so với phiên bản tiền nhiệm.” · Mặc dù về mặt kỹ thuật là chính xác, nhưng những tuyên bố này 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 zkVM cũ 1000 lần, nhưng xét về mặt tuyệt đối 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 mà không có lỗi” không thể đạt được mức độ đảm bảo hoạt động có thể chấp nhận được.

· Chi phí để chứng minh mọi hoạt động trên mạng chính Ethereum là chưa đến một triệu đô la mỗi năm, phản ánh thực tế là một nút đầy đủ của 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—kể 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 SNARK có 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 ứng dụng cụ thể (ví dụ: biên dịch trước).

· Kỹ thuật và tăng tốc phần cứng (ví dụ: GPU, FPGA hoặc CPU đa lõi).

Mặc dù hai điều sau rất quan trọng đối với việc triển khai thực tế, nhưng 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.

Các giai đoạn thực hiện

Dưới đây là 5 cột mốc đạt được hiệu suất. Đầ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 sau, 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ằng chứng: Kích thước bằng chứng phải nhỏ hơn kích thước chứng kiến.

· 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 thiểu để đảm bảo sự đơn 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 từ Giai đoạn 2 trở đi:

· Kích thước bản in thử tối đa: 256 KB.

· Thời gian xác minh tối đa: 16 mili giây.

Những ngưỡng cắt này được cố ý thiết kế lớn để phù hợp với các kỹ thuật kiểm tra nhanh mới có thể làm tăng chi phí xác minh. Đồ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.

Giai đoạn tốc độ 1

Các bằng chứng luồng đơn phải chậm hơn tới 100.000 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.

Giai đoạn tốc độ 2

Các bằng chứng luồng đơn phải 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) bằng cách so sánh:

số lõi RISC-V mà FPGA có thể mô phỏng ở tốc độ gốc;

số lượng FPGA cần thiết để mô phỏng và chứng minh khả năng thực thi (gần) thời gian thực của RISC-V.

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.

Giai đoạn tốc độ 3

Ngoài việc đạt được Giai đoạn tốc độ 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ề bản chất, 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 bộ nhớ 1

Tốc độ của Giai đoạn 1 đạt được trong khi yêu cầu bộ nhớ cho trình chứng minh chưa đến 2 GB (đồ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ần làm rõ hai điểm:

· Giới hạn dung lượng 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ữ kích thước trình chứng minh dưới 2 GB bộ nhớ. Vì vậy, để 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 bộ nhớ 2

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

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 về việc sở hữu các 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.

Tiền biên dịch: 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. Đây là 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.

· Trải nghiệm kém của nhà phát triển: Trong hầu hết các zkVM hiện nay, việc thêm một 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 phong cách 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 độ tăng 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.

Dòng thời gian dự kiến

Tôi hy vọng một số ít zkVM sẽ đạt đến giai đoạn tốc độ 1 và giai đoạn bộ nhớ 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 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 ngày càng có nhiều lỗ hổng được phát hiện 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 lớn. 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ỉ.

Liên kết gốc