a16z: Khám phá hiệu quả và bảo mật của zkVM

Tác giả: Justin Thaler Nguồn: a16z Biên dịch: Shan Ou Ba, Golden Finance

Máy ảo không kiến ​​thức (zkVM) hướng đến mục tiêu “dân chủ hóa SNARK” để ngay cả những người không có chuyên môn về SNARK cũng có thể chứng minh rằng họ đã chạy một chương trình đúng trên một đầu vào cụ thể (hoặc nhân chứng). Ưu điểm cốt lõi của nó nằm ở trải nghiệm của nhà phát triển, nhưng hiện tại zkVM vẫn phải đối mặt với những thách thức lớn về mặt bảo mật và hiệu suất. Các nhà thiết kế phải vượt qua những trở ngại này nếu zkVM muốn thực hiện được lời hứa của mình. Bài viết này sẽ khám phá các giai đoạn có thể có trong quá trình phát triển zkVM, một quá trình có thể mất vài năm để hoàn thành - đừng để ai nói với bạn rằng nó sẽ diễn ra nhanh chóng.

Thách thức

Về mặt bảo mật, zkVM là các 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 việc thực thi đúng một chương trình có thể chậm hơn hàng trăm nghìn lần so với việc thực thi gốc, khiến hầu hết các ứng dụng vẫn chưa khả thi để triển khai trong thế giới thực.

Mặc dù vậy, nhiều tiếng nói trong ngành công nghiệp blockchain vẫn quảng bá zkVM là sẵn sàng để triển khai ngay lập tức và một số dự án thậm chí đã phải trả chi phí tính toán cao để tạo ra bằng chứng không cần kiến ​​thức về hoạt động trên chuỗi. Tuy nhiên, do zkVM vẫn còn nhiều lỗ hổng nên cách tiếp cận này thực chất chỉ là một biện pháp ngụy trang tốn kém để khiến hệ thống trông giống như được bảo vệ bởi SNARK, trong khi thực tế nó dựa vào các biện pháp kiểm soát quyền hoặc tệ hơn là có nguy cơ bị tấn công.

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

Giai đoạn phát triển bảo mật

Bối cảnh

Các zkVM dựa trên SNARK thường bao gồm hai thành phần cốt lõi:

1. Bằng chứng Oracle tương tác đa thức (PIOP): một khuôn khổ bằng chứng tương tác để chứng minh các đa thức (hoặc các ràng buộc có nguồn gốc từ các đa thức).

2. Phương án cam kết đa thức (PCS): Đảm bảo rằng trình chứng minh không thể làm giả kết quả đánh giá đa thức mà không bị phát hiện.

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

Trong một hệ thống phức tạp như vậy, cách duy nhất để đảm bảo zkVM không có lỗ hổng là thông qua xác minh chính thức. Dưới đây là các giai đoạn khác nhau của bảo mật zkVM, trong đó giai đoạn đầu tiên tập trung vào tính chính xác của giao thức và giai đoạn thứ hai và thứ ba tập trung vào tính chính xác của việc triển khai.

an ninh pha 1: giao thức chính xác Các giả định ptographic hoặc mô hình lý tưởng;

Nếu zkVM sử dụng đệ quy, thì tất cả PIOP, lược đồ cam kết và hệ thống ràng buộc liên quan đến quá trình đệ quy đều phải được xác minh, nếu không thì giai đoạn con không thể được coi là hoàn thành.

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

Giai đoạn này yêu cầu xác minh chính thức việc triển khai thực tế của trình xác thực zkVM (như Rust, Solidity, v.v.) để đảm bảo rằng nó tuân thủ giao thức đã được xác minh trong giai đoạn đầu tiên. Hoàn tất giai đoạn này có nghĩa là việc triển khai zkVM nhất quán với thiết kế lý thuyết, chứ không chỉ là giao thức bảo mật trên giấy hoặc một thông số kỹ thuật kém hiệu quả được viết bằng ngôn ngữ như Lean.

Có hai lý do chính khiến chúng tôi chỉ tập trung vào trình xác minh chứ không phải trình chứng minh: thứ nhất, đảm bảo trình xác minh là đúng có thể đảm bảo tính hoàn chỉnh của hệ thống chứng minh zkVM (tức là đảm bảo trình xác minh không thể bị lừa chấp nhận một chứng minh sai). Thứ hai, việc triển khai trình xác minh của zkVM đơn giản hơn rất nhiều so với việc triển khai trình chứng minh và tính chính xác của trình xác minh cũng dễ đảm bảo hơn trong thời gian ngắn.

Giai đoạn bảo mật 3: Triển khai trình chứng minh chính xác

Giai đoạn này yêu cầu xác minh chính thức việc triển khai thực tế của trình chứng minh zkVM để đảm bảo rằng nó có thể tạo ra bằng chứng chính xác cho các hệ thống bằng chứng đã xác minh trong giai đoạn 1 và 2. Mục tiêu của giai đoạn này là tính hoàn thiện, nghĩa là bất kỳ hệ thống nào sử dụng zkVM sẽ không bị kẹt do không thể chứng minh được tuyên bố hợp pháp. Nếu zkVM cần có thuộc tính không kiến ​​thức, phải cung cấp xác minh chính thức để đảm bảo rằng bằng chứng không làm rò rỉ bất kỳ thông tin nào về nhân chứng.

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

Tiến độ giai đoạn 1: Chúng ta có thể mong đợi một số tiến triển vào năm tới (ví dụ, ZKLiblà một trong những nỗ lực như vậy). 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 nữa.

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 nhất đị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 minh 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ể lâu hơn.

Lưu ý chính: Bảo mật Fiat-Shamir so với Bytecode đã xác minh

Một vấn đề phức tạp lớn là tính bảo mật của phép biến đổi Fiat-Shamir vẫn là một vấn đề nghiên cứu chưa được giải quyết. Cả ba giai đoạn bảo mật đều coi Fiat-Shamir và các oracle ngẫu nhiên là hoàn toàn an toàn, 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 mô hình lý tưởng của oracle ngẫu nhiên 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 bảo mật 2 có thể được xác định là hoàn toàn không an toàn do các vấn đề liên quan đến Fiat-Shamir. Điều này đáng được chúng ta quan tâm và tiếp tục nghiên cứu. Chúng ta có thể cần sửa đổi chính quá trình biến đổi Fiat-Shamir để bảo vệ tốt hơn trước những lỗ hổng như vậy.

Về mặt lý thuyết, các hệ thống không sử dụng đệ quy an toàn 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. Nhưng rủi ro này vẫn là một câu hỏi cơ bản chưa có lời giải.

Một vấn đề khác cần lưu ý là ngay cả khi zkVM chứng minh được rằng một chương trình máy tính (được chỉ định bởi bytecode) được thực thi đúng, nếu bản thân bytecode có lỗi, thì giá trị của bằng chứng này cực kỳ hạn chế. Do đó, tính thực tế của zkVM phụ thuộc rất nhiều vào việc tạo ra mã bytecode được xác minh chính thức, một thách thức cực kỳ lớn và vượt quá phạm vi của bài báo này.

Về bảo mật 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 5 năm tới (hoặc thậm chí lâu hơn), trong khi lỗ hổng phần mềm là vấn đề sống còn. Do đó, ưu tiên hiện tại là đạt được các mục tiêu về bảo mật và hiệu suất được đề xuất trong bài báo này. Nếu SNARK không kháng lượng tử có thể đạt được các mục tiêu này nhanh hơn, chúng ta nên sử dụng chúng trước. Hãy đợi cho đến khi SNARK chống lượng tử phát triển hoặc cho đến khi có dấu hiệu cho thấy máy tính lượng tử có thể gây ra mối đe dọa thực sự trước khi cân nhắc chuyển đổi.

Mức độ bảo mật cụ thể

Mức độ bảo mật cổ điển 100 bit là tiêu chuẩn tối thiểu đối với bất kỳ SNARK nào để bảo vệ các tài sản có giá trị (nhưng vẫn có một số hệ thống không đáp ứng được tiêu chuẩn thấp này). Mặc dù vậy, điều này không nên được chấp nhận; các thông lệ mã hóa tiêu chuẩn thường yêu cầu bảo mật 128 bit trở lên. Nếu SNARK thực sự hoạt động như mong đợi, chúng ta không nên đánh đổi tính bảo mật để cải thiện hiệu suất.

Giai đoạn hiệu suất

Tình hình hiện tại

Hiện tại, chi phí tính toán của trình chứng minh zkVM cao hơn khoảng 1 triệu lần so với thực thi gốc. Nói cách khác, nếu một chương trình mất X chu kỳ CPU để thực thi gốc, thì việc tạo bằng chứng thực thi đúng mất khoảng X × 1.000.000 chu kỳ CPU. Điều này đúng vào một năm trước và vẫn đúng cho đến ngày nay (bất chấp một số hiểu lầm). <. Ved gần như tạo ra các khối Ethereum, chỉ có vài chục GPU. : trái; "> • 1000x nhanh hơn ZKVM cũ vẫn có thể rất chậm , điều này nói nhiều hơn về nó xấu như thế nào trong quá khứ so với mức độ tốt của nó .

• Sức mạnh tính toán của mạng chính Ethereum có thể tăng gấp 10 lần trong tương lai, điều này sẽ khiến hiệu suất zkVM hiện tại kém xa so với nhu cầu.

• Cái gọi là tạo bằng chứng “gần như thời gian thực” vẫn quá chậm so với nhu cầu của nhiều ứng dụng blockchain (ví dụ: thời gian khối của Optimism là 2 giây, nhanh hơn nhiều so với 12 giây của Ethereum).

• “Hàng chục GPU chạy 24/7 trong thời gian dài” không cung cấp đảm bảo độ hoạt động ổn định.

• Những thời gian tạo bản in thử này thường dành cho các bản in thử có kích thước trên 1MB, quá lớn đối với nhiều ứng dụng.

• “Chi phí ít hơn 1 triệu đô la mỗi năm” đơn giản vì một nút đầy đủ của Ethereum chỉ thực hiện khoảng 25 đô la tính toán mỗi năm.

Đối với các tình huống ứng dụng bên ngoài blockchain, chi phí điện toán này rõ ràng là quá cao. Không có lượng tính toán song song hay tối ưu hóa kỹ thuật nào có thể bù đắp được chi phí tính toán khổng lồ như vậy.

Mục tiêu cơ bản mà chúng ta nên đặt ra là: chi phí hiệu năng không được vượt quá 100.000 lần so với thực thi gốc. Nhưng dù vậy, đây vẫn chỉ là bước đầu tiên. Để đạt được sự áp dụng rộng rãi trên quy mô lớn, chúng ta có thể cần phải giảm chi phí thực thi xuống còn 10.000 lần hoặc ít hơn so với chi phí thực thi gốc.

Đo lường hiệu suất

Hiệu suất SNARK có ba thành phần chính:

1. Hiệu quả vốn có của hệ thống chứng minh cơ bản.

2. Tối ưu hóa cho các ứng dụng cụ thể (chẳng hạn như biên dịch trước).

3. 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ù (2) và (3) rất quan trọng đối với việc triển khai thực tế, chúng áp dụng cho bất kỳ hệ thống chứng minh nào và do đó có thể không nhất thiết phản ánh sự cải thiện về 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 việc chỉ dựa vào CPU — có khả năng khiến một hệ thống vốn kém hiệu quả hơn trở nên vượt trội hơn so với một hệ thống khác chưa được tối ưu hóa tương tự.

Do đó, bài báo này tập trung vào việc đo lường hiệu suất cơ bản 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 kết hợp cả ba yếu tố thành một “con số tổng thể” duy nhất. Giống như việc đánh giá một viên kim cương dựa trên thời gian đánh bóng, thay vì đánh giá độ trong suốt vốn có của nó.

Mục tiêu của chúng tôi là phân lập chi phí cố hữu của các hệ thống chứng minh mục đích chung, giảm rào cản gia nhập đối với các kỹ thuật chưa được khám phá và giúp cộng đồng loại bỏ những yếu tố gây mất tập trung để họ có thể tập trung vào tiến bộ 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à các mốc quan trọng của năm giai đoạn thực hiện mà tôi đề xuất. Đầu tiên, chúng ta cần giảm đáng kể chi phí hoạt động của CPU trước khi có thể giảm thêm chi phí hoạt động của phần cứng. Đồng thời, việc sử dụng bộ nhớ cũng phải được cải thiện.

Ở mọi giai đoạn, các nhà phát triển không nên điều chỉnh mã của họ để đạt hiệu suất zkVM. Trải nghiệm của nhà phát triển là lợi thế cốt lõi của zkVM. Nếu DevEx bị hy sinh để đáp ứng các tiêu chuẩn hiệu suất, nó không chỉ mất đi ý nghĩa của việc đánh giá chuẩn mà còn đi ngược lại mục đích ban đầu của zkVM.

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

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

• Kích thước bản in thử: Phải nhỏ hơn kích thước chứng thực.

• Thời gian xác minh: Việc xác minh bằng chứng không được chậm hơn quá trình thực thi gốc của chương trình (tức là không chậm hơn quá trình thực hiện tính toán trực tiếp).

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

Giai đoạn 2 trở lên

• 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 nắp này được thiết kế lỏng lẻo một cách có chủ đích để phù hợp với các kỹ thuật kiểm tra nhanh mới, ngay cả khi chúng có thể làm tăng chi phí xác minh. Đồng thời, các giới hạn này loại trừ các bằng chứng quá đắt đến nỗi ít dự án nào muốn sử dụng chúng trên blockchain.

Giai đoạn tốc độ 1

Bằng chứng luồng đơn không được chậm hơn 100.000 lần so với thực thi gốc (áp dụng cho nhiều ứng dụng, không chỉ bằng chứng khối Ethereum) và không được dựa vào biên dịch trước.

Nói một cách cụ thể, giả sử bộ xử lý RISC-V trên máy tính xách tay hiện đại chạy ở tốc độ khoảng 3 tỷ chu kỳ/giây, thì đạt đến giai đoạn 1 có nghĩa là máy tính xách tay có thể tạo ra bằng chứng ở tốc độ 30.000 chu kỳ RISC-V/giây (luồng đơn).

Chi phí xác thực phải đáp ứng tiêu chí "chi phí xác minh hợp lý, không tầm thường" đã xác định trước đó.

Giai đoạn tốc độ 2

Các bằng chứng luồng đơn không được chậm hơn 10.000 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à SNARK miền nhị phân) bị giới hạn bởi CPU và GPU hiện tại, nên giai đoạn này có thể được đáp ứng bằng FPGA (hoặc thậm chí là ASIC):

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

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

3. Nếu số lượng (2) không vượt quá 10.000 lần số lượng (1) thì Giai đoạn 2 được thỏa mãn.

• 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 trên CPU tiêu chuẩn.

Giai đoạn tốc độ 3

Dựa trên việc đạt được Giai đoạn tốc độ 2, phải đạt được chi phí chứng minh nhỏ hơn 1000× (phù hợp với nhiều ứng dụng khác nhau) và phải sử dụng tổng hợp tự động và biên dịch trước được xác minh chính thức. Về cơ bản, tập lệnh của mỗi chương trình được tùy chỉnh động để tăng tốc quá trình tạo bằng chứng, nhưng phải đảm bảo tính dễ sử dụng và xác minh chính thức. (Xem phần tiếp theo để biết thêm lý do tại sao tiền biên dịch là con dao hai lưỡi và tại sao tiền biên dịch "viết tay" không phải là phương pháp bền vững.)

Giai đoạn bộ nhớ 1

Đạt được Giai đoạn tốc độ 1 với bộ nhớ dưới 2 GB trong khi vẫn đáp ứng được yêu cầu không cần kiến ​​thức. Giai đoạn này rất quan trọng đối với thiết bị di động hoặc trình duyệt và mở ra cánh cửa cho nhiều trường hợp sử dụng zkVM phía máy khách. Ví dụ, điện thoại thông minh được sử dụng để bảo mật vị trí, thông tin xác thực danh tính, v.v. Hầu hết các thiết bị di động sẽ không thể chạy chức năng tạo chứng thực nếu nó yêu cầu bộ nhớ lớn hơn 1-2 GB.

Hai lưu ý quan trọng:

1. Ngay cả đối với các phép tính quy mô lớn (yêu cầu hàng nghìn tỷ chu kỳ CPU thực thi gốc), hệ thống chứng minh phải duy trì giới hạn bộ nhớ 2 GB, nếu không khả năng áp dụng của nó sẽ bị hạn chế.

2. Nếu quá trình này diễn ra cực kỳ chậm, bạn có thể dễ dàng duy trì giới hạn bộ nhớ 2 GB. Do đó, để giai đoạn bộ nhớ 1 có ý nghĩa, tốc độ giai đoạn 1 phải đạt được trong giới hạn bộ nhớ 2 GB.

Giai đoạn bộ nhớ 2

Đạt được Giai đoạn tốc độ 1 với bộ nhớ dưới 200 MB (cải thiện gấp 10 lần so với Giai đoạn bộ nhớ 1).

Tại sao phải giảm xuống còn 200 MB? Hãy xem xét một tình huống không phải blockchain: khi bạn truy cập một trang web HTTPS, chứng chỉ xác thực và mã hóa sẽ được tải xuống. Nếu các trang web gửi zk-proof của các chứng chỉ này, các trang web lớn có thể cần tạo hàng triệu bằng chứng mỗi giây. Nếu mỗi bằng chứng yêu cầu 2 GB bộ nhớ, yêu cầu về tài nguyên tính toán sẽ đạt đến mức PB, điều này rõ ràng là không khả thi. Do đó, 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 ứng dụng không phải blockchain.

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

Tiền biên dịch đề cập đến hệ thống ràng buộc SNARK được tối ưu hóa cho các chức năng cụ thể (chẳng hạn như băm, chữ ký đường cong elip). Trong Ethereum, biên dịch trước có thể giảm chi phí băm Merkle và xác minh chữ ký, nhưng việc quá phụ thuộc vào biên dịch trước không thực sự cải thiện hiệu quả cốt lõi của SNARK.

Vấn đề với biên dịch trước

1. Vẫn quá chậm: Ngay cả với biên dịch trước hàm băm và chữ ký, zkVM vẫn còn kém hiệu quả trong hệ thống chứng minh cốt lõi bên trong và bên ngoài blockchain.

2. Lỗ hổng bảo mật: Nếu bản biên dịch viết tay không được xác minh chính thức, gần như chắc chắn sẽ có lỗ hổng, có thể dẫn đến lỗi bảo mật nghiêm trọng.

3. Kinh nghiệm phát triển kém: Hiện nay, nhiều zkVM yêu cầu các nhà phát triển phải viết tay các hệ thống ràng buộc, tương tự như phương pháp lập trình vào những năm 1960, ảnh hưởng nghiêm trọng đến trải nghiệm phát triển.

4. Điểm chuẩn gây hiểu lầm: Nếu điểm chuẩn dựa trên việc tối ưu hóa một biên dịch trước cụ thể, nó có thể khiến mọi người tập trung vào việc tối ưu hóa hệ thống ràng buộc thủ công thay vì cải thiện bản thân thiết kế SNARK.

5. Chi phí I/O và không truy cập RAMMặ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ật mã 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 môi trường blockchain, ngay khi bạn vượt ra ngoài một L1 duy nhất 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 nhiều hàm băm và lược đồ chữ ký khác nhau. Việc liên tục biên dịch trước để giải quyết vấn đề này không thể mở rộng quy mô và gây ra rủi ro bảo mật rất lớn.

Tôi tin rằng việc biên dịch trước sẽ vẫn đóng vai trò quan trọng trong thời gian dài, nhưng chỉ sau khi chúng được tổng hợp tự động và xác minh chính thức. Bằng cách này, chúng ta có thể duy trì lợi ích về trải nghiệm của nhà phát triển trên zkVM đồ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 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 cũng có thể đạt được Giai đoạn tốc độ 2 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ó ý tưởng nghiên cứu mới 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.

Mặc dù bài viết này liệt kê các giai đoạn bảo mật và hiệu suất của zkVM riêng biệt, nhưng hai giai đoạn này không hoàn toàn độc lập. Khi các lỗ hổng trong zkVM tiếp tục được phát hiện, tôi dự đoán rằng việc khắc phục một số lỗ hổng chắc chắn sẽ dẫn đến sự suy giảm hiệu suất đáng kể. Do đó, cho đến khi zkVM đạt đến giai đoạn an toàn 2, kết quả kiểm tra hiệu suất của nó chỉ được coi là dữ liệu tạm thời.

zkVM có tiềm năng lớn trong việc khiến chứng minh không kiến ​​thức thực sự trở nên phổ biến, nhưng nó vẫn đang trong giai đoạn đầu - đầy thách thức về bảo mật và tình trạng tắc nghẽn hiệu suất nghiêm trọng. Sự cường điệu của thị trường và hoạt động tuyên truyền tiếp thị khiến việc đo lường tiến độ thực sự trở nên khó khăn. Bằng cách xác định các mốc quan trọng về bảo mật và hiệu suất rõ ràng, tôi hy vọng có thể cung cấp một lộ trình có thể giúp giải quyết vấn đề. Cuối cùng chúng ta sẽ đạt được điều đó, nhưng sẽ cần thời gian và nỗ lực liên tục trong nghiên cứu và kỹ thuật.