1/ Cẩn thận với sự thổi phồng: mặc dù SNARKs và zkVMs cho thấy tiềm năng to lớn, chúng chưa sẵn sàng cho các triển khai phức tạp, có rủi ro cao. Lỗi xuất hiện khắp nơi, xác minh chính thức còn sơ khai, và các chứng minh có thể chậm hơn hàng trăm nghìn lần so với thực thi gốc.

2/ Tôi vừa đăng một bài viết phác thảo lộ trình phát triển zkVM có cấu trúc. Nó tách biệt “các giai đoạn bảo mật” khỏi “các giai đoạn tốc độ,” cung cấp cho chúng ta một cách minh bạch để theo dõi tiến độ. Đọc nó tại đây:

3/ Về bảo mật, tôi xác định ba giai đoạn cho việc xác minh chính thức: • Các giao thức đã được xác minh • Các trình xác minh đã được xác minh • Các trình chứng minh đã được xác minh Cho đến khi chúng ta đạt đến Giai đoạn 2, chúng ta không thể thực sự gọi một zkVM là “an toàn”—và việc đạt được điều đó vẫn có khả năng mất vài năm.

4/ Về hiệu suất, chi phí so với thực thi gốc vẫn vượt quá 100,000×—một khởi đầu không khả thi cho hầu hết các trường hợp sử dụng. Bài viết của tôi đề xuất năm “giai đoạn hiệu suất” để giảm chi phí đó theo cấp số nhân và cuối cùng cho phép chứng minh trên thiết bị.

5/ Quan trọng là chúng ta phải tách biệt hiệu quả cơ bản của một hệ thống chứng minh. Hiện tại, nhiều tiêu chuẩn đang gộp tất cả mọi thứ—hệ thống chứng minh, kỹ thuật, tăng cường phần cứng, và các tiền biên dịch được điều chỉnh thủ công—thành một con số tổng thể duy nhất, làm mờ đi vị trí thực sự của chúng ta.

6/ Vậy nên, zkVMs và SNARKs có tiềm năng to lớn, nhưng chúng ta sẽ gặp rủi ro nếu giả vờ rằng chúng đã sẵn sàng cho giờ cao điểm. Tôi sẽ sử dụng những giai đoạn này để theo dõi tiến trình của zkVM trong những năm tới—và hy vọng những người khác cũng sẽ làm như vậy. Xem bài viết của tôi tại đây: