a16z: Làm thế nào để triển khai zkVM an toàn và hiệu quả theo từng giai đoạn?
Tuyển chọn TechFlowTuyển chọn TechFlow
a16z: Làm thế nào để triển khai zkVM an toàn và hiệu quả theo từng giai đoạn?
Dành cho nhà phát triển
Chuyên sâu báo cáo Web3Tác giả: a16z crypto
Biên dịch: Golem, Odaily Star Daily
zkVM (máy ảo kiến thức không) hứa hẹn "phổ cập SNARK", cho phép bất kỳ ai (ngay cả những người không có chuyên môn sâu về SNARK) chứng minh rằng họ đã chạy chính xác một chương trình nào đó với đầu vào (hoặc bằng chứng) nhất định. Lợi thế cốt lõi của chúng nằm ở trải nghiệm nhà phát triển, nhưng hiện tại chúng đang đối mặt với những thách thức lớn về bảo mật và hiệu suất. Để hiện thực hóa viễn cảnh zkVM, 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 liệt kê các giai đoạn phát triển zkVM có thể xảy ra — việc hoàn thành các giai đoạn này sẽ mất vài năm.
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 chứa nhiều lỗ hổng. Về hiệu suất, tốc độ tạo bằng chứng cho việc thực thi đúng chương trình có thể chậm hơn tới hàng trăm nghìn lần so với thực thi bản địa, khiến hầu hết ứng dụng hiện nay không thể triển khai trong thế giới thực.
Mặc dù có những thách thức thực tế này, phần lớn các công ty trong ngành blockchain vẫn mô tả zkVM như thể có thể triển khai ngay lập tức. Thực tế, một số dự án đã chi trả chi phí tính toán khổng lồ để tạo bằng chứng cho hoạt động trên chuỗi. Nhưng vì zkVM vẫn chưa hoàn thiện, đây chỉ là cách tốn kém để giả vờ hệ thống được bảo vệ bởi SNARK, trong khi thực tế nó hoặc được bảo vệ bằng quyền hạn, hoặc tệ hơn là dễ bị tấn công.
Chúng ta vẫn còn cách xa mục tiêu đạt được zkVM an toàn và hiệu quả. Bài viết này đề xuất một loạt mục tiêu cụ thể theo từng giai đoạn để theo dõi tiến độ của zkVM — những mục tiêu này có thể loại bỏ sự thổi phồng và giúp cộng đồng tập trung vào những tiến bộ 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:
-
Hệ thống chứng minh Oracle tương tác đa thức (PIOP): khuôn khổ chứng minh tương tác dùng để chứng minh các khẳng định liên quan đến đa thức (hoặc các ràng buộc suy ra từ chúng).
-
Sơ đồ cam kết đa thức (PCS): đảm bảo người chứng minh không thể gian lận khi đánh giá đa thức mà không bị phát hiện.
zkVM về cơ bản mã hóa lịch sử thực thi hợp lệ thành một hệ thống ràng buộc — nói rộng ra là buộc máy ảo sử dụng đúng thanh ghi và bộ nhớ — sau đó áp dụng SNARK để chứng minh rằng các ràng buộc này được thỏa mãn.
Con đường duy nhất để đảm bảo một hệ thống phức tạp như zkVM không có lỗi là kiểm chứng hình thức. Dưới đây là phân tích chi tiết 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 hình thức về tính đáng tin cậy của PIOP;
-
Bằng chứng hình thức rằng PCS có tính ràng buộc dưới một số giả định mật mã học nhất định hoặc trong mô hình lý tưởng;
-
Nếu sử dụng Fiat-Shamir, bằng chứng hình thức rằng lập luận 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 tiên tri ngẫu nhiên (có thể tăng cường bằng các giả định mật mã khác nếu cần);
-
Bằng chứng hình thức rằng hệ thống ràng buộc mà PIOP áp dụng tương đương với ngữ nghĩa của VM;
-
Kết hợp toàn diện tất cả các phần trên thành một bằng chứng SNARK duy nhất, đã được kiểm chứng hình thức, cho việc chạy bất kỳ chương trình nào được chỉ định bởi bytecode VM. Nếu giao thức nhằm đạt được tính kiến thức không, thì thuộc tính này cũng phải được kiểm chứng hình thức để đảm bảo không rò rỉ thông tin nhạy cảm về bằng chứng.
Cảnh báo về đệ quy: nếu zkVM sử dụng đệ quy, thì mọi PIOP, sơ đồ cam kết và hệ thống ràng buộc liên quan trong quá trình đệ quy đều phải được xác minh trước khi xem giai đoạn này là hoàn thành.
Giai đoạn bảo mật 2: Triển khai bộ xác minh đúng
Bằng chứng hình thức rằng triển khai thực tế của bộ xác minh zkVM (bằng Rust, Solidity, v.v.) phù hợp với giao thức đã được xác minh ở giai đoạn 1. Việc đạt được điều này đảm bảo rằng giao thức được triển khai là hợp lệ (chứ không chỉ là thiết kế trên giấy hay đặc tả không hiệu quả được viết bằng Lean, v.v.).
Lý do giai đoạn 2 chỉ tập trung vào bộ xác minh (thay vì bộ chứng minh) có hai khía cạnh. Thứ nhất, việc sử dụng bộ xác minh đúng đã đủ để đảm bảo tính đáng tin cậy (tức là đảm bảo bộ xác minh không thể tin vào bất kỳ khẳng định sai nào là đúng). Thứ hai, việc triển khai bộ xác minh zkVM đơn giản hơn ít nhất một bậc so với triển khai bộ chứng minh.
Giai đoạn bảo mật 3: Triển khai bộ chứng minh đúng
Triển khai thực tế của bộ chứng minh zkVM tạo ra đúng các bằng chứng của hệ thống chứng minh đã được xác minh ở giai đoạn 1 và 2, tức là được kiểm chứng hình thức. Điều này đảm bảo tính toàn vẹn, nghĩa là bất kỳ hệ thống nào sử dụng zkVM cũng sẽ không bị mắc kẹt bởi các khẳng định không thể chứng minh. Nếu bộ chứng minh nhằm đạt được tính kiến thức không, thuộc tính này cũng phải được kiểm chứng hình thức.
Dự kiến thời gian biểu
Tiến độ giai đoạn 1: Chúng ta có thể kỳ vọng những thành tựu từng bước trong năm tới (ví dụ như ZKLib). Nhưng ít nhất trong hai năm tới, không có zkVM nào có thể hoàn toàn đáp ứng yêu cầu của giai đoạn 1;
Giai đoạn 2 và 3: Các giai đoạn này có thể được thúc đẩy 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 triển khai bộ xác minh Plonk phù hợp với giao thức trong bài báo (mặc dù bản thân giao thức trong bài báo có thể chưa được xác minh đầy đủ). Tuy vậy, tôi dự đoán sẽ không có zkVM nào đạt đến giai đoạn 3 trong vòng ít nhất bốn năm — và có thể còn lâu hơn.
Lưu ý quan trọng: An ninh Fiat-Shamir và Bytecode đã được xác minh
Một yếu tố phức tạp chính là vẫn còn những vấn đề nghiên cứu chưa giải quyết xung quanh độ an toàn của chuyển đổi Fiat-Shamir. Cả ba giai đoạn đều coi Fiat-Shamir và tiên tri ngẫu nhiên là một phần trong độ an toàn tuyệt đối của chúng, nhưng trên thực tế toàn bộ mô hình này có thể tồn tại lỗ hổng. Điều này bắt nguồn từ sự khác biệt giữa tiên tri ngẫu nhiên quá lý tưởng và các hàm băm được sử dụng thực tế. Trong trường hợp xấu nhất, các hệ thống đã đạt đến giai đoạn 2 có thể sau đó bị phát hiện là hoàn toàn không an toàn do vấn đề Fiat-Shamir. Điều này gây lo ngại nghiêm trọng và đang là chủ đề nghiên cứu liên tục. Chúng ta có thể cần sửa đổi chính bản thân chuyển đổi để phòng tránh tốt hơn các lỗ hổng như vậy.
Các hệ thống không dùng đệ quy về mặt lý thuyết vững chắc 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ư những mạch dùng trong chứng minh đệ quy.
Một điểm đáng chú ý khác là, nếu bản thân bytecode có lỗi, thì giá trị của việc chứng minh rằng chương trình máy tính đã được thực thi đúng (theo bytecode đã chỉ định) là rất hạn chế. Do đó, tính hữu ích của zkVM phụ thuộc rất lớn vào phương pháp tạo bytecode đã được kiểm chứng hình thức — đây là một thách thức khổng lồ, vượt quá phạm vi của bài viết này.
Về độ an toàn trong kỷ nguyên hậu lượng tử
Ít nhất trong năm năm tới (có thể lâu hơn), máy tính lượng tử sẽ không tạo thành mối đe dọa nghiêm trọng, trong khi các lỗ hổng lại là rủi ro sinh tồn. Vì vậy, trọng tâm hiện tại nên là đá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ể nhanh chóng đáp ứng các yêu cầu bảo mật bằng SNARK không an toàn trước lượng tử, thì chúng ta nên làm như vậy, cho đến khi có SNARK an toàn trước lượng tử bắt kịp, hoặc con người thực sự lo lắng về máy tính lượng tử liên quan đến mật mã mới xuất hiện trong tầm ngắm.
Hiện trạng hiệu suất của zkVM
Hiện tại, hệ số chi phí do bộ chứng minh zkVM tạo ra gần như gấp một triệu lần chi phí thực thi bản địa. Nếu một chương trình cần X chu kỳ để chạy, thì chi phí chứng minh việc thực thi đúng sẽ khoảng X nhân với một triệu chu kỳ CPU. Một năm trước là như vậy, và ngày hôm nay vẫn vậy.
Câu chuyện phổ biến thường mô tả chi phí này theo cách nghe 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 mỗi năm sẽ không đến một triệu đô la.”
-
“Chúng tôi gần như có thể sử dụng một cụm gồm hàng chục GPU để tạo bằng chứng khối Ethereum theo thời gian thực.”
-
“zkVM mới nhất của chúng tôi nhanh hơn phiên bản trước 1000 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 nếu thiếu bối cảnh thích hợp, chúng có thể gây hiểu lầm. Ví dụ:
-
Nhanh hơn zkVM cũ 1000 lần, nhưng tốc độ tuyệt đối vẫn rất chậm. Điều này nói lên nhiều hơn về việc tình hình tồi tệ thế nào chứ không phải tốt thế nào.
-
Đã có người đề xuất tăng khối lượng tính toán mà mạng chính Ethereum xử lý lên 10 lần. Điều này sẽ khiến hiệu suất zkVM hiện tại trở nên chậm hơn nữa.
-
Việc nói “gần như tạo bằng chứng thời gian thực cho khối Ethereum” vẫn chậm hơn rất nhiều so với yêu cầu của nhiều ứng dụng blockchain khác (ví dụ: Optimism có thời gian khối 2 giây, nhanh hơn nhiều so với 12 giây của Ethereum).
-
“Hàng chục GPU chạy liên tục, không lỗi” không thể đạt được mức đảm bảo hoạt tính chấp nhận được.
-
Chi phí dưới một triệu đô mỗi năm để chứng minh mọi hoạt động trên mạng chính Ethereum phản ánh thực tế rằng một nút đầy đủ Ethereum chỉ cần khoảng 25 đô mỗi năm để thực hiện tính toán.
Đối với các ứng dụng ngoài blockchain, chi phí như vậy rõ ràng là quá cao. Bất kỳ song song hóa hay kỹ thuật nào cũng không thể bù đắp được chi phí khổng lồ như vậy. Chúng ta nên lấy mốc cơ bản là zkVM chậm hơn thực thi bản địa không quá 100.000 lần — ngay cả khi đây chỉ là bước đầu tiên. Việc áp dụng đại trà thực sự có thể cần chi phí gần 10.000 lần hoặc thấp hơn.
Cách đo hiệu suất
Hiệu suất SNARK có ba thành phần chính:
-
Hiệu quả nội tại của hệ thống chứng minh nền tảng.
-
Tối ưu hóa dành riêng cho ứng dụng (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 nhân).
Mặc dù hai yếu tố sau cực kỳ quan trọng đối với triển khai thực tế, nhưng chúng thường áp dụng cho mọi hệ thống chứng minh, do đó không nhất thiết phản ánh chi phí cơ bản. Ví dụ, thêm tăng tốc GPU và biên dịch trước vào zkEVM có thể dễ dàng đạt được tốc độ nhanh hơn 50 lần so với phương pháp chỉ dùng CPU và không có biên dịch trước — đủ để khiến một hệ thống vốn kém hiệu quả về mặt nội tại trông tốt hơn một hệ thống chưa được tối ưu hóa tương tự.
Vì vậy, phần dưới đây tập trung vào hiệu suất của SNARK mà không dùng phần cứng chuyên dụng và biên dịch trước. Điều này khác với phương pháp chuẩn hóa hiện tại, thường gộp cả ba yếu tố thành một “con số nổi bật”. Điều này giống như đánh giá giá trị viên kim cương dựa trên thời gian đánh bóng thay vì độ tinh khiết vốn có của nó. Mục tiêu của chúng ta là loại trừ chi phí nội tại của hệ thống chứng minh tổng quát — giúp cộng đồng loại bỏ nhiễu loạn và tập trung vào tiến bộ thực sự trong thiết kế hệ thống chứng minh.
Giai đoạn hiệu suất
Dưới đây là 5 cột mốc thực hiện hiệu suất. Trước tiên, chúng ta cần giảm chi phí bộ chứng minh trên CPU xuống nhiều bậc độ lớn. Chỉ khi đó, trọng tâm mới nên chuyển sang giảm tiếp thông qua phần cứng. Sử dụng bộ nhớ cũng phải được cải thiện.
Ở tất cả các giai đoạn dưới đây, nhà phát triển không cần phải viết mã tùy chỉnh theo cấu hình zkVM để đạt được hiệu suất cần thiết. Trải nghiệm nhà phát triển là lợi thế chính của zkVM. Đánh đổi DevEx để đáp ứng các tiêu chuẩn hiệu suất sẽ đi ngược lại bản chất của zkVM.
Các chỉ số này tập trung vào chi phí bộ chứng minh. Tuy nhiên, nếu cho phép chi phí bộ xác minh không giới hạn (tức là kích thước bằng chứng hoặc thời gian xác minh không giới hạn), thì bất kỳ chỉ số bộ chứng minh nào cũng có thể dễ dàng đáp ứng. Do đó, để một hệ thống phù hợp với các giai đoạn nêu trên, phải xác định giá trị tối đa cho kích thước bằng chứng và thời gian xác minh.
Yêu cầu 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: phải nhỏ hơn kích thước bằng chứng.
-
Thời gian xác minh: thời gian xác minh bằng chứng không được chậm hơn việc chạy chương trình bản địa (tức là thực hiện tính toán mà không cần bằng chứng đúng đắn).
Đây là các yêu cầu tối thiểu về tính ngắn gọn. Chúng đả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 bằng chứng cho bộ xác minh và để họ kiểm tra trực tiếp tính đúng đắn.
Yêu cầu giai đoạn 2 trở đi:
-
Kích thước bằng chứng tối đa: 256 KB.
-
Thời gian xác minh tối đa: 16 mili giây.
Các ngưỡng này được đặt cố ý cao để thích nghi với các công nghệ chứng minh nhanh mới có thể mang lại chi phí xác minh cao hơn. Đồng thời, chúng loại trừ các bằng chứng quá đắt đỏ đến mức rất ít dự án muốn đưa chúng vào blockchain.
Giai đoạn tốc độ 1
Chứng minh đơn luồng phải chậm hơn thực thi bản địa tối đa một trăm nghìn lần, được đo trên một loạt ứng dụng (không chỉ chứng minh khối Ethereum), mà không dựa vào biên dịch trước.
Cụ thể, hãy tưởng tượng một tiến trình RISC-V chạy trên laptop hiện đại với khoảng 3 tỷ chu kỳ mỗi giây. Đạt được giai đoạn 1 nghĩa là bạn có thể chứng minh khoảng 30.000 chu kỳ RISC-V mỗi giây (đơn luồng) trên cùng chiếc laptop đó. Nhưng chi phí xác minh phải “hợp lý và không tầm thường” như đã nêu.
Giai đoạn tốc độ 2
Chứng minh đơn luồng phải chậm hơn thực thi bản địa tối đa mười nghìn lần.
Hoặc, do một số phương pháp SNARK đầy hứa hẹn (đặc biệt là các 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ể so sánh bằng cách sử dụng FPGA (hoặc thậm chí ASIC) để đạt đến giai đoạn này:
-
Số lượng lõi RISC-V mà FPGA có thể mô phỏng với tốc độ bản địa;
-
Số lượng FPGA cần để mô phỏng và chứng minh việc thực thi RISC-V (gần như) thời gian thực.
Nếu số thứ hai nhiều nhất chỉ gấp 10.000 lần số thứ nhất, bạn đủ đ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 256 KB, thời gian bộ xác minh tối đa 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í chứng minh dưới 1000 lần bằng cách sử dụng biên dịch trước được tổng hợp tự động và kiểm chứng hình thức (áp dụng cho nhiều ứng dụng). Về bản chất, có thể tùy chỉnh bộ lệnh động cho mỗi chương trình để tăng tốc chứng minh, nhưng theo cách dễ sử dụng và kiểm chứng hình thức.
Giai đoạn bộ nhớ 1
Giai đoạn tốc độ 1 được đạt được khi bộ chứng minh sử dụng ít hơn 2 GB bộ nhớ (đồng thời đạt được tính kiến thức không).
Điều này cực kỳ 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 khách hàng. Chứng minh phía khách hàng rất quan trọng vì điện thoại của chúng ta là điểm liên hệ liên tục với thế giới thực: chúng theo dõi vị trí, thông tin đăng nhập, v.v. Nếu việc tạo bằng chứng cần hơn 1-2 GB bộ nhớ, thì điều đó quá nhiều đối với hầu hết thiết bị di động hiện nay. Cần làm rõ hai điểm:
-
Giới hạn 2 GB áp dụng cho các khẳng định lớn (những khẳng định cần hàng nghìn tỷ chu kỳ CPU để chạy bản địa). Hệ thống chứng minh chỉ đạt giới hạn không gian cho các khẳng định nhỏ sẽ thiếu tính ứng dụng rộng rãi.
-
Nếu bộ chứng minh rất chậm, thì dễ dàng giữ bộ nhớ bộ chứng minh dưới 2 GB. Vì vậy, để giai đoạn bộ nhớ 1 không trở nên đơn giản, tôi yêu cầu phải đạt được giai đoạn tốc độ 1 trong giới hạn 2 GB.
Giai đoạn bộ nhớ 2
Giai đoạn tốc độ 1 được đạt được khi sử dụng bộ nhớ dưới 200 MB (tốt hơn 10 lần so với giai đoạn bộ nhớ 1).
Tại sao phải giảm dưới 2 GB? Hãy xem xét một ví dụ ngoài blockchain: mỗi lần bạn truy cập trang web qua HTTPS, bạn tải xuống chứng chỉ để xác thực và mã hóa. Thay vào đó, trang web có thể gửi bằng chứng zk về việc sở hữu các chứng chỉ đó. Các trang web lớn có thể phát hành hàng triệu bằng chứng như vậy mỗi giây. Nếu mỗi bằng chứng cần 2 GB bộ nhớ để tạo, tổng cộng sẽ cần RAM cấp PB. Việc giảm tiếp mức sử dụng bộ nhớ là cực kỳ quan trọng đối với triển khai ngoài blockchain.
Biên dịch trước: Dặm cuối cùng hay cây gậy chống?
Trong thiết kế zkVM, biên dịch trước (precompiles) đề cập đến các SNARK chuyên dụng (hoặc hệ thống ràng buộc) được tùy chỉnh cho chức năng cụ thể, chẳng hạn như hàm băm Keccak/SHA hoặc phép toán nhóm đường cong elliptic cho chữ ký số. Trong Ethereum (nơi phần lớn công việc nặng liên quan đến băm Merkle và kiểm tra chữ ký), một số biên dịch trước được viết thủ công có thể giảm chi phí bộ chứng minh. Nhưng việc phụ thuộc vào chúng như một cây gậy chống sẽ không đưa SNARK đến nơi chúng cần. Lý do như sau:
-
Vẫn quá chậm đối với hầu hết ứng dụng (trong và ngoài blockchain): ngay cả khi có biên dịch trước cho băm và chữ ký, zkVM hiện tại vẫn quá chậm (cả trong và ngoài môi trường blockchain), vì hệ thống chứng minh nền tảng kém hiệu quả.
-
Sự cố an ninh: các biên dịch trước viết tay chưa được kiểm chứng hình thức gần như chắc chắn chứa đầy lỗi, có khả năng dẫn đến sự cố an ninh thảm khốc.
-
Trải nghiệm nhà phát triển kém: trong hầu hết zkVM hiện nay, việc thêm biên dịch trước mới nghĩa là phải viết thủ công hệ thống ràng buộc cho mỗi chức năng — về cơ bản quay trở lại quy trình kiểu những năm 1960. Ngay cả khi sử dụng các biên dịch trước hiện có, nhà phát triển cũng phải cấu trúc lại mã để gọi từng cái. Chúng ta nên tối ưu hóa cho an ninh và trải nghiệm nhà phát triển, chứ không nên hy sinh cả hai để đổi lấy hiệu suất tăng dần. Làm như vậy chỉ chứng minh rằng hiệu suất chưa đạt mức cần thiết.
-
Chi phí I/O cao và không dùng RAM: mặc dù biên dịch trước có thể cải thiện hiệu suất cho các nhiệm vụ mã hóa nặng, nhưng chúng có thể không cung cấp tăng tốc đáng kể cho khối lượng công việc đa dạng hơn, vì chúng tạo ra chi phí lớn khi truyền dữ liệu vào/ra và không thể sử dụng RAM. Ngay cả trong môi trường blockchain, miễn là bạn vượt ra khỏi lớp 1 monolithic như Ethereum (ví dụ: bạn muốn xây dựng một chuỗi cầu nối xuyên chuỗi), bạn sẽ gặp các hàm băm và lược đồ chữ ký khác nhau. Việc lặp lại biên dịch trước cho từng vấn đề sẽ không thể mở rộng và mang lại rủi ro an ninh khổng lồ.
Vì tất cả những lý do này, ưu tiên hàng đầu của chúng ta nên là nâng cao hiệu quả của zkVM nền tảng. Công nghệ tạo ra zkVM tốt nhất cũng sẽ tạo ra các biên dịch trước tốt nhất. Tôi tin rằng biên dịch trước vẫn sẽ cực kỳ quan trọng về lâu dài, nhưng前提是 chúng được tổng hợp tự động và kiểm chứng hình thức. Như vậy, có thể duy trì lợi thế trải nghiệm nhà phát triển của zkVM, đồng thời tránh được rủi ro an ninh thảm khốc. Quan điểm này được phản ánh trong giai đoạn tốc độ 3.
Dự kiến thời gian biểu
Tôi dự đoán một vài zkVM sẽ đạt được 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 sẽ đạt được giai đoạn tốc độ 2 trong vòng hai năm tới, nhưng hiện tại chưa 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ù trong bài viết này tôi xác định riêng các giai đoạn bảo mật và hiệu suất của zkVM, nhưng những 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, dự kiến một số lỗ hổng chỉ có thể sửa chữa với sự giảm hiệu suất đáng kể. Trước khi zkVM đạt đến giai đoạn bảo mật 2, hiệu suất nên được tạm dừng.
zkVM hứa hẹn sẽ khiến chứng minh kiến thức không trở nên thực sự phổ biến, nhưng chúng vẫn đang ở giai đoạn đầu — đầy thách thức về bảo mật và chi phí hiệu suất khổng lồ. Sự thổi phồng và quảng cáo khiến việc đánh giá tiến bộ thực sự trở nên khó khăn. Bằng cách làm rõ các cột mốc bảo mật và hiệu suất cụ thể, hy vọng có thể cung cấp một lộ trình loại bỏ nhiễu loạn. Chúng ta sẽ đạt được mục tiêu, nhưng điều đó cần thời gian và nỗ lực liên tục.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
a16z
