Con đường đến zkVM an toàn và hiệu quả: Làm thế nào để theo dõi tiến triển
Tác giả gốc: a16z crypto
Golem, Odaily báo cáo hàng ngày về hành tinh
zkVM（Zero Knowledge Virtual Machine）cam kết "phổ biến hóa SNARK", cho phép bất kỳ ai (kể cả những người không có kiến thức chuyên môn về SNARK) chứng minh rằng họ đã chạy đúng chương trình nào đó trên đầu vào (hoặc bằng chứng) cụ thể. Ưu điểm cốt lõi của chúng là trải nghiệm phát triển, nhưng hiện tại chúng đều đối mặt với thách thức lớn về an ninh và hiệu suất. Để thực hiện cam kết của zkVM, 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ể đi qua, và hoàn thành những giai đoạn này sẽ mất vài năm.
Thách thức
Về mặt an ninh, zkVM là dự án phần mềm rất phức tạp và vẫn còn tồn tại nhiều lỗ hổng. Về hiệu suất, tốc độ chứng minh chương trình thực thi đúng có thể chậm hàng trăm nghìn lần so với việc chạy cục bộ, điều này khiến cho hầu hết các ứng dụng hiện tại không thể triển khai trong thế giới thực.
Mặc dù đối mặt với 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 như là một giải pháp có thể triển khai ngay lập tức. Trên thực tế, một số dự án đã chi trả một lượng lớn chi phí tính toán để tạo ra bằng chứng cho hoạt động trên chuỗi. Nhưng vì zkVM vẫn chưa hoàn thiện, điều này chỉ là một cách đắt tiền giả vờ hệ thống được bảo vệ bằng SNARK, trong khi thực tế, nó hoặc được bảo vệ thông qua sự cho phép hoặc tệ hơn nữa, dễ bị tấn công.
Chúng ta còn mất vài năm nữa mới có thể thực hiện được zkVM an toàn và hiệu suất cao. Bài viết 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 triển của zkVM - những mục tiêu này có thể loại bỏ sự bàn tán và giúp cộng đồng tập trung vào tiến bộ thực sự.
Giai đoạn an toàn
zkVM dựa trên SNARK thường bao gồm hai thành phần chính:
· **Chứng minh Oracle tương tác đa thức (PIOP)：**Khung chứng minh tương tác cho các tuyên bố về đa thức (hoặc ràng buộc được suy ra từ đó).
· **Chương trình cam kết đa thức (PCS)：**Đảm bảo người chứng minh không thể nói dối trong việc đánh giá đa thức mà không bị phát hiện.
zkVM bản chất là mã hóa thực hiện hiệu quả thành hệ thống ràng buộc - nghĩa là nó buộc phải sử dụng đúng các thanh ghi và bộ nhớ của máy ảo, sau đó áp dụng SNARK để chứng minh rằng những ràng buộc này được đáp ứng.
Đảm bảo rằng hệ thống phức tạp như zkVM không có lỗi duy nhất là thông qua xác thực hình thức. Dưới đây là phân đoạn an toàn. Phân đoạn 1 tập trung vào giao thức chính xác, trong khi phân đoạn 2 và phân đoạn 3 tập trung vào việc triển khai đúng.
Giai đoạn an toàn 1: Giao thức chính xác
1、Chứng chỉ xác thực chính thức về độ tin cậy của PIOP；
2、PCS được chứng minh dưới dạng có hiệu lực trong một số giả thuyết hoặc mô hình lý tưởng trong một số trường hợp;
3、Nếu sử dụng Fiat-Shamir, việc kết hợp chứng minh ngắn được lấy từ PIOP và PCS trong mô hình tiên đoán ngẫu nhiên là một chứng minh chính thức an toàn (được củng cố bằng các giả thiết mã hóa khác nếu cần).
4、Hệ thống ràng buộc được áp dụng bởi PIOP tương đương với chứng minh hình thức của cú pháp của VM;
5、Tất cả các phần trên được "liên kết" một cách toàn diện thành một chứng minh SNARK an toàn đã được hình thức hóa, được sử dụng cho bất kỳ chương trình nào được chỉ định bởi bytecode của VM. Nếu giao thức dự định thực hiện zero-knowledge, cần phải thực hiện hình thức hóa xác minh cho tính chất này để đảm bảo không tiết lộ thông tin nhạy cảm về người chứng minh.
Cảnh báo Đệ quy: Nếu zkVM sử dụng đệ quy, thì cần xác minh mỗi PIOP, cam kết và hệ thống ràng buộc liên quan tại mọi nơi trong đệ quy đó trước khi coi giai đoạn này là hoàn thành.
Giai đoạn an toàn 2: Thực hiện xác thực đúng
Chứng minh xác thực hình thức của trình xác thực zkVM (sử dụng Rust, Solidity, v.v.) phù hợp với giao thức xác thực 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à hợp lý (không chỉ là thiết kế trên giấy, hoặc quy định không hiệu quả được viết bằng Lean, v.v.).
Lý do duy nhất tập trung vào việc triển khai của máy chứng minh (thay vì bằng chứng) ở giai đoạn 2 có hai khía cạnh. Thứ nhất, việc sử dụng máy chứng minh một cách chính xác đã đủ để đảm bảo tính đáng tin cậy (nghĩa là đảm bảo rằng máy chứng minh không thể tin tưởng vào bất kỳ tuyên bố giả mạo nào thực sự là sự thật). Thứ hai, việc triển khai máy chứng minh của zkVM đơn giản hơn một cấp độ so với việc triển khai máy chứng minh.
Bước 3: Triển khai Chứng minh Đúng Đắn
Việc triển khai thực tế của trình chứng thực zkVM được xác thực chính thức khi nó tạo chính xác hệ thống chứng thực của hệ thống chứng thực đã được xác thực trong Giai đoạn 1 và Giai đoạn 2. Điều này đảm bảo tính toàn vẹn, tức là bất kỳ hệ thống nào sử dụng zkVM sẽ không bị "mắc kín" bởi các tuyên bố không thể chứng minh. Nếu người chứng minh có ý định thực hiện zero-knowledge, tài sản này phải được xác minh chính thức.
Kế hoạch dự kiến
· Tiến triển giai đoạn 1: Chúng ta có thể mong đợi những thành tựu từ từ trong năm tới (ví dụ như ZKLib). Nhưng ít nhất trong vòng hai năm nữa, không có zkVM nào có thể hoàn toàn đáp ứng được yêu cầu của giai đoạn 1;
· Các giai đoạn 2 và 3: Các giai đoạn này có thể tiến triển đồng thời 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 máy chứng thực Plonk khớp với giao thức trong bài báo (mặc dù chính giao thức trong bài báo có thể chưa được chứng minh hoàn toàn). Tuy nhiên, tôi dự đoán rằng bất kỳ zkVM nào cũng sẽ không đạt giai đoạn 3 trong vòng chưa đầy bốn năm - và có thể lâu hơn.
Lưu ý quan trọng: an toàn Fiat-Shamir và mã byte đã được xác minh
Một yếu tố phức tạp chính là, có các vấn đề nghiên cứu chưa được giải quyết về tính bảo mật của việc chuyển đổi Fiat-Shamir. Tất cả ba giai đoạn đều xem Fiat-Shamir và máy tiên tri ngẫu nhiên là một phần của tính bảo mật không thể xâm phạm của họ, nhưng thực tế toàn bộ mô hình có thể có lỗ hổng. Điều này là do sự khác biệt giữa máy tiên tri ngẫu nhiên quá lý tưởng và hàm băm được sử dụng thực tế. Trong trường hợp tồi tệ nhất, do vấn đề Fiat-Shamir, hệ thống ở giai đoạn 2 có thể sau này được phát hiện là hoàn toàn không an toàn. Điều này gây ra lo ngại nghiêm trọng và nghiên cứu liên tục. Chúng ta có thể cần điều chỉnh chính bản chuyển đổi để ngăn chặn tốt hơn những lỗ hổng như vậy.
Hệ thống không đệ quy trong lý thuyết có vẻ ổn định hơn vì một số mạch liên quan đến các cuộc tấn công đã biết tương tự như mạch được sử dụng trong chứng minh đệ quy.
Một điều đáng chú ý khác là, nếu bytecode chính nó có khuyết điểm, điều này chứng minh rằng giá trị của việc chạy chương trình máy tính đã chính xác (được chỉ định bằng bytecode) cũng có giới hạn. Do đó, tính thực tiễn của zkVM phụ thuộc nhiều vào cách tạo bytecode được xác minh hình thức - đây là một thách thức lớn, vượt ra ngoài phạm vi của bài viết này.
Về tính an toàn của thời đại sau lượng tử
Trong ít nhất năm năm tới (có thể lâu hơn), máy tính lượng tử sẽ không tạo ra mối đe dọa nghiêm trọng, trong khi lỗ hổng là một loại rủi ro tồn tại. Do đó, trọng tâm chính hiện tại nên là đáp ứng các giai đoạn an toàn và hiệu suất được thảo luận trong bài viết này. Nếu chúng ta có thể sử dụng SNARK không an toàn lượng tử để đáp ứng nhanh hơn các yêu cầu an toàn này, thì chúng ta nên làm như vậy cho đến khi SNARK sau lượng tử đuổi kịp hoặc mọi người bắt đầu lo lắng về việc xem xét máy tính lượng tử liên quan đến mật mã.
Hiện trạng hiệu suất của zkVM
Hiện tại, hệ số chi phí sinh ra bởi máy chứng minh zkVM gần 1 triệu lần chi phí thực thi ban đầu. Nếu chương trình cần X chu kỳ để chạy, thì chi phí chứng minh thực thi chính xác khoảng X nhân 1 triệu chu kỳ CPU. Một năm trước đã là trường hợp này, và hôm nay vẫn vậy.
Câu chuyện phổ biến thường được mô tả một cách dễ chấp nhận bằng cách nghe có vẻ hợp lý. Ví dụ:
·「Chi phí hàng năm để tạo ra bằng chứng trên mạng chính Ethereum không đến một triệu đô la.」
·「Chúng tôi gần như có thể sử dụng cụm GPU hàng chục máy tính để tạo ra chứng minh khối Ethereum trực tiếp.」
·"zkVM mới nhất của chúng tôi nhanh hơn 1000 lần so với trước đây."
Mặc dù về mặt kỹ thuật những phát ngôn này là chính xác, nhưng nếu thiếu kiến thức cần thiết, có thể dẫn đến hiểu lầm. Ví dụ:
· So với phiên bản cũ zkVM, tốc độ nhanh hơn 1000 lần, nhưng vẫn rất chậm. Điều này chỉ làm nổi bật điều tồi tệ hơn thay vì tốt đẹp.
· Đã có người đề xuất tăng gấp 10 lần lượng tính toán được xử lý trên mạng chính của Ethereum. Điều này sẽ làm cho hiệu suất zkVM hiện tại trở nên chậm hơn.
· Sự chứng minh gần như thời gian thực của các khối Ethereum mà mọi người đang nói vẫn chậm hơn rất nhiều so với những gì mà nhiều ứng dụng blockchain yêu cầu (ví dụ, thời gian khối của Optimism là 2 giây, nhanh hơn rất nhiều so với 12 giây thời gian khối của Ethereum).
Việc duy trì số lượng GPU hoạt động liên tục mà không gặp lỗi không thể đảm bảo được mức độ hoạt động chấp nhận được.
· Mỗi năm, việc chi không đến 1 triệu đô la Mỹ để chứng minh rằng tất cả hoạt động trên mạng chính Ethereum phản ánh sự thật rằng chỉ cần khoảng 25 đô la Mỹ mỗi năm để thực hiện tính toán trên một nút đầy đủ của Ethereum.
Đối với các ứng dụng ngoài chuỗi khối, chi phí này rõ ràng quá cao. Không có bất kỳ việc song song hóa hoặc kỹ thuật nào có thể cân bằng được chi phí lớn như vậy. Chúng ta nên xem xét tốc độ của zkVM so với việc thực thi native, không chậm hơn 100.000 lần là mức cơ bản - ngay cả khi đó chỉ là bước đầu tiên. Việc áp dụng chính thống thực sự có thể cần đến gần 10.000 lần hoặc ít hơn chi phí.
Cách đánh giá hiệu suất
Hiệu suất SNARK bao gồm ba phần chính:
· Hiệu suất nội tại của hệ thống chứng minh cơ sở.
· Tối ưu hóa cụ thể cho ứng dụng (ví dụ như việc biên dịch trước).
· Kỹ thuật và tăng tốc phần cứng (ví dụ như GPU, FPGA hoặc CPU đa lõi).
Mặc dù cả hai đều quan trọng đối với triển khai thực tế, nhưng chúng thường được áp dụng cho bất kỳ hệ thống chứng minh nào, vì vậy chúng không nhất thiết phản ánh chi phí cơ bản. Ví dụ, trong zkEVM, việc thêm GPU tăng tốc và trước biên dịch có thể dễ dàng đạt được tốc độ tăng gấp 50 lần, điều này nhanh hơn nhiều so với phương pháp không trước biên dịch dựa trên CPU thuần túy - đủ để khiến hệ thống vốn thiếu hiệu quả này trở nên ưu việt so với hệ thống chưa được mài mò như vậy.
Do đó, bài viết dưới đây tập trung giới thiệu hiệu suất của SNARK khi không có phần cứng và mã nguồn được biên dịch trước. Điều này khác với phương pháp kiểm tra cơ sở hiện tại, thường gom tất cả ba yếu tố thành một “số đầu mục”. Điều này tương đương với việc đánh giá giá trị của viên kim cương dựa trên thời gian mài bóng của nó chứ không phải độ trong sạch bẩm sinh của nó. Mục tiêu của chúng tôi là loại bỏ chi phí nội tại của hệ thống chứng minh thông thường—giúp cộng đồng loại bỏ yếu tố lẫn lộn, tập trung vào sự tiến bộ thực sự của thiết kế hệ thống chứng minh.
Cấp độ hiệu suất
Dưới đây là 5 cột mốc hiệu suất đã đạt được. Đầu tiên, chúng ta cần giảm chi phí chứng minh trên CPU một số cấp độ. Chỉ khi đó, sự chú ý mới nên chuyển sang việc giảm thiểu hơn nữa thông qua phần cứng. Tỷ lệ sử dụng bộ nhớ cũng phải được nâng cao.
Ở tất cả các giai đoạn dưới đây, các nhà phát triển không cần triển khai mã tùy chỉnh theo cài đặt zkVM để đạt hiệu suất cần thiết. Trải nghiệm của nhà phát triển là ưu điểm chính của zkVM. Hi sinh DevEx để đáp ứng chỉ số hiệu suất sẽ là vi phạm ý nghĩa cơ bản của zkVM.
Các chỉ số này tập trung vào chi phí của các bên chứng minh. Tuy nhiên, nếu cho phép chi phí của người xác minh không bị hạn chế (nghĩa là không có giới hạn về kích thước chứng minh hoặc thời gian xác minh), thì có thể dễ dàng đáp ứng bất kỳ chỉ số của bên chứng minh nào. Do đó, đối với hệ thống phải tuân thủ giai đoạn đã nói, cần phải xác định giá trị tối đa cho kích thước chứng minh 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 bình thường":
· Kích thước chứng minh: Kích thước chứng minh phải nhỏ hơn kích thước chứng thực.
· Thời gian xác minh: Tốc độ xác minh không được chậm hơn tốc độ chạy chương trình cục bộ (tức là thực thi tính toán mà không có bằng chứng về tính chính xác).
Đây là những yêu cầu tối thiểu về sự ngắn gọn. Chúng đảm bảo rằng kích thước chứng minh và thời gian xác minh không tồi tệ hơn cách gửi chứng minh cho người xác minh và cho phép họ kiểm tra độ chính xác một cách trực tiếp.
Yêu cầu từ giai đoạn 2 trở đi:
· Kích thước chứng minh tối đa: 256 KB.
· Thời gian xác thực tối đa: 16 miligiây.
Các giá trị giới hạn này đã được tăng cường một cách cố ý để phù hợp với 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 bỏ các bằng chứng rất đắt đỏ, đến mức hiếm có dự án nào sẵn lòng bao gồm chúng trong blockchain.
Giai đoạn tốc độ 1
Chứng minh đơn luồng phải chậm ít nhất mười vạn lần so với việc thực thi trên máy cục bộ, được đo lường trong một loạt các ứng dụng (không chỉ là chứng minh khối Ethereum) mà không phụ thuộc vào việc biên dịch trước.
Cụ thể là, hãy tưởng tượng một quá trình RISC-V chạy với khoảng 30 tỷ chu kỳ mỗi giây trên 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 trên cùng một chiếc máy tính xách tay (một luồng). Nhưng chi phí xác minh phải hợp lý và không phải là vấn đề nhỏ.
Giai đoạn 2 tốc độ
Chứng minh luồng đơn phải chậm tối đa mười nghìn lần so với thực hiện trên máy cục bộ.
Hoặc, do một số phương pháp SNARK triển vọng (đặc biệt là các phương pháp dựa trên trường nhị phân) bị hạn chế bởi CPU và GPU hiện tại, bạn có thể so sánh sử dụng FPGA (thậm chí ASIC) để đạt được giai đoạn này:
FPGA có thể mô phỏng số lượng nhân RISC-V theo tốc độ cục bộ;
Mô phỏng và chứng minh (gần như) số lượng FPGA cần thiết để thực hiện RISC-V gần như thời gian thực.
Nếu số lần lớn nhất của lần thứ hai so với lần thứ nhất là tối đa 10.000 lần, bạn sẽ đủ điều kiện để tiến vào giai đoạn 2. Trên CPU tiêu chuẩn, kích thước chứng minh phải tối đa là 256 KB, thời gian xác minh tối đa là 16 mili giây.
Giai đoạn 3 tốc độ
Ngoài việc đạt được giai đoạn 2 về tốc độ, bạn cũng có thể sử dụng việc tự động tổng hợp và xác thực hình thức để thực hiện chi phí chứng minh dưới 1000 lần (phù hợp với nhiều ứng dụng). Theo cách cơ bản, bạn có thể tùy chỉnh bộ chỉ thị động cho mỗi chương trình để tăng tốc độ chứng minh, nhưng phải thực hiện một cách dễ dàng sử dụng và xác thực hình thức.
Giai đoạn bộ nhớ 1
Tốc độ giai đoạn 1 được đạt được khi bộ nhớ cần thiết của bằng chứng viên ít hơn 2 GB (đồng thời cũng đạt được kiến thức không biết).
Đ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, vì vậy đã mở ra vô số trường hợp sử dụng zkVM cho khách hàng. Chứng minh của khách hàng rất quan trọng, vì điện thoại di động của chúng ta là liên lạc liên tục với thế giới thực: chúng theo dõi vị trí, chứng chỉ của chúng ta, v.v. Nếu việc tạo chứng minh đòi hỏi hơn 1-2 GB bộ nhớ, thì đối với hầu hết các thiết bị di động hiện nay đó là quá nhiều. Cần làm rõ hai điểm:
· 2 GB không gian giới hạn được áp dụng cho các câu lệnh lớn (cần hàng ngàn tỷ chu kỳ CPU để chạy cục bộ). Hệ thống chứng minh giới hạn không gian chỉ áp dụng cho các câu lệnh nhỏ thiếu tính phổ quát.
· Nếu bằng chứng quá chậm, việc duy trì không gian của bằng chứng dưới 2 GB sẽ trở nên dễ dàng. Do đó, để phần bộ nhớ 1 trở nên không đơn giản, tôi yêu cầu đáp ứng giai đoạn 1 với tốc độ trong giới hạn không gian 2 GB.
Giai đoạn Bộ nhớ 2
Tốc độ của giai đoạn 1 đã được đạt được mà không dùng quá 200 MB bộ nhớ (tốt hơn giai đoạn 1 với 10 lần).
Tại sao cần giảm xuống dưới 2 GB? Hãy xem xét một ví dụ không phải là blockchain: Mỗi khi bạn truy cập một trang web thông qua HTTPS, bạn sẽ tải xuống chứng chỉ để xác thực và mã hóa. Thay vào đó, trang web có thể gửi chứng chỉ zk mà có chứa các chứng chỉ này. Một trang web lớn có thể phát ra hàng triệu chứng chỉ như vậy mỗi giây. Nếu mỗi chứng chỉ cần 2 GB bộ nhớ để tạo ra, thì tổng cộng sẽ cần tới PB RAM. Việc giảm bớt việc sử dụng bộ nhớ với triển khai không phải là blockchain rất quan trọng.
Biên dịch: Cuối cùng vẫn là cây gậy hay không?
Trong thiết kế zkVM, việc biên soạn trước đó là việc tùy chỉnh SNARK chuyên dụng được thiết kế cho một chức năng cụ thể, ví dụ như băm Keccak/SHA hoặc phép toán nhóm đường cong elliptic được sử dụng cho chữ ký số. Trong Ethereum (hầu hết công việc nặng liên quan đến băm Merkle và kiểm tra chữ ký), một số việc biên soạn trước được tạo thủ công có thể giảm bớt chi phí chứng minh. Tuy nhiên, phụ thuộc vào chúng như một cây gậy không thể đạt được mục tiêu của SNARK. Lý do như sau:
· Đối với hầu hết các ứng dụng (cả trong và ngoài blockchain) vẫn quá chậm: Ngay cả khi sử dụng hash và chữ ký được biên dịch trước, zkVM hiện tại vẫn quá chậm (cả trong môi trường blockchain và ngoài môi trường blockchain) do hiệu suất của hệ thống chứng minh cốt lõi thấp.
· Lỗi an ninh: Việc biên soạn trước bằng tay chưa được xác thực chính thức hầu như chắc chắn sẽ đầy lỗi, có thể dẫn đến sự cố an ninh thảm khốc.
· Trải nghiệm của các nhà phát triển không tốt: Trong hầu hết các zkVM hiện nay, việc thêm mới các mã thông dịch có nghĩa là phải viết hệ thống ràng buộc cho mỗi chức năng một cách thủ công - tức là quay trở lại quy trình làm việc kiểu như thập niên 1960. Ngay cả khi sử dụng các mã thông dịch hiện có, các nhà phát triển cũng phải tái cấu trúc mã để gọi từng mã thông dịch. Chúng ta nên tối ưu hóa cho tính bảo mật và trải nghiệm của các nhà phát triển, thay vì hy sinh cả hai để theo đuổi 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 đến mức cần có.
· I/O overhead without RAM: Although precompilation can improve the performance of intensive encryption tasks, they may not provide meaningful acceleration for more diverse workloads because they incur significant overhead when passing input/output and cannot use RAM. Even in a blockchain environment, as long as you go beyond single-piece L1 like Ethereum (for example, you want to build a series of cross-chain bridges), you will encounter different hash functions and signature schemes. Repeated precompilation on the issue cannot scale and brings significant security risks.
Với tất cả những lý do này, nhiệm vụ hàng đầu của chúng tôi là nâng cao hiệu suất của zkVM ở tầng cơ bản. Công nghệ tạo ra zkVM tốt nhất cũng sẽ tạo ra các bản biên dịch tốt nhất. Tôi thực sự tin rằng các bản biên dịch vẫn rất quan trọng trong tương lai, nhưng điều kiện tiên quyết là chúng được tự động hợp thành và kiểm tra chính thức. Điều này giúp duy trì ưu thế trải nghiệm của nhà phát triển zkVM, đồng thời tránh xa rủi ro an ninh thảm họa. Quan điểm này được phản ánh trong giai đoạn tốc độ 3.
Kế hoạch dự kiến
Tôi dự đoán rằng một số zkVM sẽ đạt giai đoạn tốc độ 1 và giai đoạn bộ nhớ 1 vào cuối năm nay. Tôi nghĩ rằng chúng ta cũng sẽ đạt giai đoạn tốc độ 2 trong hai năm tới, nhưng hiện tại vẫn chưa rõ liệu chúng ta có thể đạt được mục tiêu này hay không nếu không có những ý tưởng mới chưa xuất hiện. Tôi dự đoán rằng các giai đoạn còn lại (giai đoạn tốc độ 3 và giai đoạn bộ nhớ 2) sẽ cần vài năm để đạt được.
Tóm tắt
Mặc dù tôi đã phân biệt rõ giai đoạn an ninh và hiệu suất của zkVM trong bài viết 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 ra nhiều lỗ hổng hơn trong zkVM, dự kiến một số lỗ hổng chỉ có thể được sửa chữa khi hiệu suất giảm đáng kể. Trước khi zkVM đạt đến giai đoạn an toàn 2, hiệu suất nên được tạm hoãn.
zkVM có thể giúp việc chứng minh không biết trở nên phổ biến, nhưng chúng vẫn đang ở giai đoạn ban đầu - đầy thách thức về an ninh và chi phí hiệu suất lớn. Sự quảng cáo và tiếp thị làm cho việc đánh giá tiến triển thực sự trở nên khó khăn. Hy vọng có thể cung cấp một bản đồ đường không có sự cản trở thông qua việc làm rõ các cột mốc an ninh và hiệu suất cụ thể. Chúng tôi sẽ đạt được mục tiêu, nhưng điều này cần thời gian và nỗ lực liên tục.
Liên kết gốc
：
Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
a16z: Cách triển khai zkVM an toàn và hiệu quả theo giai đoạn (dành cho nhà phát triển)
zkVM（Zero Knowledge Virtual Machine）cam kết "phổ biến hóa SNARK", cho phép bất kỳ ai (kể cả những người không có kiến thức chuyên môn về SNARK) chứng minh rằng họ đã chạy đúng chương trình nào đó trên đầu vào (hoặc bằng chứng) cụ thể. Ưu điểm cốt lõi của chúng là trải nghiệm phát triển, nhưng hiện tại chúng đều đối mặt với thách thức lớn về an ninh và hiệu suất. Để thực hiện cam kết của zkVM, 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ể đi qua, và hoàn thành những giai đoạn này sẽ mất vài năm.
Thách thức
Về mặt an ninh, zkVM là dự án phần mềm rất phức tạp và vẫn còn tồn tại nhiều lỗ hổng. Về hiệu suất, tốc độ chứng minh chương trình thực thi đúng có thể chậm hàng trăm nghìn lần so với việc chạy cục bộ, điều này khiến cho hầu hết các ứng dụng hiện tại không thể triển khai trong thế giới thực.
Mặc dù đối mặt với 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 như là một giải pháp có thể triển khai ngay lập tức. Trên thực tế, một số dự án đã chi trả một lượng lớn chi phí tính toán để tạo ra bằng chứng cho hoạt động trên chuỗi. Nhưng vì zkVM vẫn chưa hoàn thiện, điều này chỉ là một cách đắt tiền giả vờ hệ thống được bảo vệ bằng SNARK, trong khi thực tế, nó hoặc được bảo vệ thông qua sự cho phép hoặc tệ hơn nữa, dễ bị tấn công.
Chúng ta còn mất vài năm nữa mới có thể thực hiện được zkVM an toàn và hiệu suất cao. Bài viết 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 triển của zkVM - những mục tiêu này có thể loại bỏ sự bàn tán và giúp cộng đồng tập trung vào tiến bộ thực sự.
Giai đoạn an toàn
zkVM dựa trên SNARK thường bao gồm hai thành phần chính:
· **Chứng minh Oracle tương tác đa thức (PIOP)：**Khung chứng minh tương tác cho các tuyên bố về đa thức (hoặc ràng buộc được suy ra từ đó).
· **Chương trình cam kết đa thức (PCS)：**Đảm bảo người chứng minh không thể nói dối trong việc đánh giá đa thức mà không bị phát hiện.
zkVM bản chất là mã hóa thực hiện hiệu quả thành hệ thống ràng buộc - nghĩa là nó buộc phải sử dụng đúng các thanh ghi và bộ nhớ của máy ảo, sau đó áp dụng SNARK để chứng minh rằng những ràng buộc này được đáp ứng.
Đảm bảo rằng hệ thống phức tạp như zkVM không có lỗi duy nhất là thông qua xác thực hình thức. Dưới đây là phân đoạn an toàn. Phân đoạn 1 tập trung vào giao thức chính xác, trong khi phân đoạn 2 và phân đoạn 3 tập trung vào việc triển khai đúng.
Giai đoạn an toàn 1: Giao thức chính xác
1、Chứng chỉ xác thực chính thức về độ tin cậy của PIOP；
2、PCS được chứng minh dưới dạng có hiệu lực trong một số giả thuyết hoặc mô hình lý tưởng trong một số trường hợp;
3、Nếu sử dụng Fiat-Shamir, việc kết hợp chứng minh ngắn được lấy từ PIOP và PCS trong mô hình tiên đoán ngẫu nhiên là một chứng minh chính thức an toàn (được củng cố bằng các giả thiết mã hóa khác nếu cần).
4、Hệ thống ràng buộc được áp dụng bởi PIOP tương đương với chứng minh hình thức của cú pháp của VM;
5、Tất cả các phần trên được "liên kết" một cách toàn diện thành một chứng minh SNARK an toàn đã được hình thức hóa, được sử dụng cho bất kỳ chương trình nào được chỉ định bởi bytecode của VM. Nếu giao thức dự định thực hiện zero-knowledge, cần phải thực hiện hình thức hóa xác minh cho tính chất này để đảm bảo không tiết lộ thông tin nhạy cảm về người chứng minh.
Cảnh báo Đệ quy: Nếu zkVM sử dụng đệ quy, thì cần xác minh mỗi PIOP, cam kết và hệ thống ràng buộc liên quan tại mọi nơi trong đệ quy đó trước khi coi giai đoạn này là hoàn thành.
Giai đoạn an toàn 2: Thực hiện xác thực đúng
Chứng minh xác thực hình thức của trình xác thực zkVM (sử dụng Rust, Solidity, v.v.) phù hợp với giao thức xác thực 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à hợp lý (không chỉ là thiết kế trên giấy, hoặc quy định không hiệu quả được viết bằng Lean, v.v.).
Lý do duy nhất tập trung vào việc triển khai của máy chứng minh (thay vì bằng chứng) ở giai đoạn 2 có hai khía cạnh. Thứ nhất, việc sử dụng máy chứng minh một cách chính xác đã đủ để đảm bảo tính đáng tin cậy (nghĩa là đảm bảo rằng máy chứng minh không thể tin tưởng vào bất kỳ tuyên bố giả mạo nào thực sự là sự thật). Thứ hai, việc triển khai máy chứng minh của zkVM đơn giản hơn một cấp độ so với việc triển khai máy chứng minh.
Bước 3: Triển khai Chứng minh Đúng Đắn
Việc triển khai thực tế của trình chứng thực zkVM được xác thực chính thức khi nó tạo chính xác hệ thống chứng thực của hệ thống chứng thực đã được xác thực trong Giai đoạn 1 và Giai đoạn 2. Điều này đảm bảo tính toàn vẹn, tức là bất kỳ hệ thống nào sử dụng zkVM sẽ không bị "mắc kín" bởi các tuyên bố không thể chứng minh. Nếu người chứng minh có ý định thực hiện zero-knowledge, tài sản này phải được xác minh chính thức.
Kế hoạch dự kiến
· Tiến triển giai đoạn 1: Chúng ta có thể mong đợi những thành tựu từ từ trong năm tới (ví dụ như ZKLib). Nhưng ít nhất trong vòng hai năm nữa, không có zkVM nào có thể hoàn toàn đáp ứng được yêu cầu của giai đoạn 1;
· Các giai đoạn 2 và 3: Các giai đoạn này có thể tiến triển đồng thời 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 máy chứng thực Plonk khớp với giao thức trong bài báo (mặc dù chính giao thức trong bài báo có thể chưa được chứng minh hoàn toàn). Tuy nhiên, tôi dự đoán rằng bất kỳ zkVM nào cũng sẽ không đạt giai đoạn 3 trong vòng chưa đầy bốn năm - và có thể lâu hơn.
Lưu ý quan trọng: an toàn Fiat-Shamir và mã byte đã được xác minh
Một yếu tố phức tạp chính là, có các vấn đề nghiên cứu chưa được giải quyết về tính bảo mật của việc chuyển đổi Fiat-Shamir. Tất cả ba giai đoạn đều xem Fiat-Shamir và máy tiên tri ngẫu nhiên là một phần của tính bảo mật không thể xâm phạm của họ, nhưng thực tế toàn bộ mô hình có thể có lỗ hổng. Điều này là do sự khác biệt giữa máy tiên tri ngẫu nhiên quá lý tưởng và hàm băm được sử dụng thực tế. Trong trường hợp tồi tệ nhất, do vấn đề Fiat-Shamir, hệ thống ở giai đoạn 2 có thể sau này được phát hiện là hoàn toàn không an toàn. Điều này gây ra lo ngại nghiêm trọng và nghiên cứu liên tục. Chúng ta có thể cần điều chỉnh chính bản chuyển đổi để ngăn chặn tốt hơn những lỗ hổng như vậy.
Hệ thống không đệ quy trong lý thuyết có vẻ ổn định hơn vì một số mạch liên quan đến các cuộc tấn công đã biết tương tự như mạch được sử dụng trong chứng minh đệ quy.
Một điều đáng chú ý khác là, nếu bytecode chính nó có khuyết điểm, điều này chứng minh rằng giá trị của việc chạy chương trình máy tính đã chính xác (được chỉ định bằng bytecode) cũng có giới hạn. Do đó, tính thực tiễn của zkVM phụ thuộc nhiều vào cách tạo bytecode được xác minh hình thức - đây là một thách thức lớn, vượt ra ngoài phạm vi của bài viết này.
Về tính an toàn của thời đại sau lượng tử
Trong ít nhất năm năm tới (có thể lâu hơn), máy tính lượng tử sẽ không tạo ra mối đe dọa nghiêm trọng, trong khi lỗ hổng là một loại rủi ro tồn tại. Do đó, trọng tâm chính hiện tại nên là đáp ứng các giai đoạn an toàn và hiệu suất được thảo luận trong bài viết này. Nếu chúng ta có thể sử dụng SNARK không an toàn lượng tử để đáp ứng nhanh hơn các yêu cầu an toàn này, thì chúng ta nên làm như vậy cho đến khi SNARK sau lượng tử đuổi kịp hoặc mọi người bắt đầu lo lắng về việc xem xét máy tính lượng tử liên quan đến mật mã.
Hiện trạng hiệu suất của zkVM
Hiện tại, hệ số chi phí sinh ra bởi máy chứng minh zkVM gần 1 triệu lần chi phí thực thi ban đầu. Nếu chương trình cần X chu kỳ để chạy, thì chi phí chứng minh thực thi chính xác khoảng X nhân 1 triệu chu kỳ CPU. Một năm trước đã là trường hợp này, và hôm nay vẫn vậy.
Câu chuyện phổ biến thường được mô tả một cách dễ chấp nhận bằng cách nghe có vẻ hợp lý. Ví dụ:
·「Chi phí hàng năm để tạo ra bằng chứng trên mạng chính Ethereum không đến một triệu đô la.」
·「Chúng tôi gần như có thể sử dụng cụm GPU hàng chục máy tính để tạo ra chứng minh khối Ethereum trực tiếp.」
·"zkVM mới nhất của chúng tôi nhanh hơn 1000 lần so với trước đây."
Mặc dù về mặt kỹ thuật những phát ngôn này là chính xác, nhưng nếu thiếu kiến thức cần thiết, có thể dẫn đến hiểu lầm. Ví dụ:
· So với phiên bản cũ zkVM, tốc độ nhanh hơn 1000 lần, nhưng vẫn rất chậm. Điều này chỉ làm nổi bật điều tồi tệ hơn thay vì tốt đẹp.
· Đã có người đề xuất tăng gấp 10 lần lượng tính toán được xử lý trên mạng chính của Ethereum. Điều này sẽ làm cho hiệu suất zkVM hiện tại trở nên chậm hơn.
· Sự chứng minh gần như thời gian thực của các khối Ethereum mà mọi người đang nói vẫn chậm hơn rất nhiều so với những gì mà nhiều ứng dụng blockchain yêu cầu (ví dụ, thời gian khối của Optimism là 2 giây, nhanh hơn rất nhiều so với 12 giây thời gian khối của Ethereum).
Việc duy trì số lượng GPU hoạt động liên tục mà không gặp lỗi không thể đảm bảo được mức độ hoạt động chấp nhận được.
· Mỗi năm, việc chi không đến 1 triệu đô la Mỹ để chứng minh rằng tất cả hoạt động trên mạng chính Ethereum phản ánh sự thật rằng chỉ cần khoảng 25 đô la Mỹ mỗi năm để thực hiện tính toán trên một nút đầy đủ của Ethereum.
Đối với các ứng dụng ngoài chuỗi khối, chi phí này rõ ràng quá cao. Không có bất kỳ việc song song hóa hoặc kỹ thuật nào có thể cân bằng được chi phí lớn như vậy. Chúng ta nên xem xét tốc độ của zkVM so với việc thực thi native, không chậm hơn 100.000 lần là mức cơ bản - ngay cả khi đó chỉ là bước đầu tiên. Việc áp dụng chính thống thực sự có thể cần đến gần 10.000 lần hoặc ít hơn chi phí.
Cách đánh giá hiệu suất
Hiệu suất SNARK bao gồm ba phần chính:
· Hiệu suất nội tại của hệ thống chứng minh cơ sở.
· Tối ưu hóa cụ thể cho ứng dụng (ví dụ như việc biên dịch trước).
· Kỹ thuật và tăng tốc phần cứng (ví dụ như GPU, FPGA hoặc CPU đa lõi).
Mặc dù cả hai đều quan trọng đối với triển khai thực tế, nhưng chúng thường được áp dụng cho bất kỳ hệ thống chứng minh nào, vì vậy chúng không nhất thiết phản ánh chi phí cơ bản. Ví dụ, trong zkEVM, việc thêm GPU tăng tốc và trước biên dịch có thể dễ dàng đạt được tốc độ tăng gấp 50 lần, điều này nhanh hơn nhiều so với phương pháp không trước biên dịch dựa trên CPU thuần túy - đủ để khiến hệ thống vốn thiếu hiệu quả này trở nên ưu việt so với hệ thống chưa được mài mò như vậy.
Do đó, bài viết dưới đây tập trung giới thiệu hiệu suất của SNARK khi không có phần cứng và mã nguồn được biên dịch trước. Điều này khác với phương pháp kiểm tra cơ sở hiện tại, thường gom tất cả ba yếu tố thành một “số đầu mục”. Điều này tương đương với việc đánh giá giá trị của viên kim cương dựa trên thời gian mài bóng của nó chứ không phải độ trong sạch bẩm sinh của nó. Mục tiêu của chúng tôi là loại bỏ chi phí nội tại của hệ thống chứng minh thông thường—giúp cộng đồng loại bỏ yếu tố lẫn lộn, tập trung vào sự tiến bộ thực sự của thiết kế hệ thống chứng minh.
Cấp độ hiệu suất
Dưới đây là 5 cột mốc hiệu suất đã đạt được. Đầu tiên, chúng ta cần giảm chi phí chứng minh trên CPU một số cấp độ. Chỉ khi đó, sự chú ý mới nên chuyển sang việc giảm thiểu hơn nữa thông qua phần cứng. Tỷ lệ sử dụng bộ nhớ cũng phải được nâng cao.
Ở tất cả các giai đoạn dưới đây, các nhà phát triển không cần triển khai mã tùy chỉnh theo cài đặt zkVM để đạt hiệu suất cần thiết. Trải nghiệm của nhà phát triển là ưu điểm chính của zkVM. Hi sinh DevEx để đáp ứng chỉ số hiệu suất sẽ là vi phạm ý nghĩa cơ bản của zkVM.
Các chỉ số này tập trung vào chi phí của các bên chứng minh. Tuy nhiên, nếu cho phép chi phí của người xác minh không bị hạn chế (nghĩa là không có giới hạn về kích thước chứng minh hoặc thời gian xác minh), thì có thể dễ dàng đáp ứng bất kỳ chỉ số của bên chứng minh nào. Do đó, đối với hệ thống phải tuân thủ giai đoạn đã nói, cần phải xác định giá trị tối đa cho kích thước chứng minh 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 bình thường":
· Kích thước chứng minh: Kích thước chứng minh phải nhỏ hơn kích thước chứng thực.
· Thời gian xác minh: Tốc độ xác minh không được chậm hơn tốc độ chạy chương trình cục bộ (tức là thực thi tính toán mà không có bằng chứng về tính chính xác).
Đây là những yêu cầu tối thiểu về sự ngắn gọn. Chúng đảm bảo rằng kích thước chứng minh và thời gian xác minh không tồi tệ hơn cách gửi chứng minh cho người xác minh và cho phép họ kiểm tra độ chính xác một cách trực tiếp.
Yêu cầu từ giai đoạn 2 trở đi:
· Kích thước chứng minh tối đa: 256 KB.
· Thời gian xác thực tối đa: 16 miligiây.
Các giá trị giới hạn này đã được tăng cường một cách cố ý để phù hợp với 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 bỏ các bằng chứng rất đắt đỏ, đến mức hiếm có dự án nào sẵn lòng bao gồm chúng trong blockchain.
Giai đoạn tốc độ 1
Chứng minh đơn luồng phải chậm ít nhất mười vạn lần so với việc thực thi trên máy cục bộ, được đo lường trong một loạt các ứng dụng (không chỉ là chứng minh khối Ethereum) mà không phụ thuộc vào việc biên dịch trước.
Cụ thể là, hãy tưởng tượng một quá trình RISC-V chạy với khoảng 30 tỷ chu kỳ mỗi giây trên 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 trên cùng một chiếc máy tính xách tay (một luồng). Nhưng chi phí xác minh phải hợp lý và không phải là vấn đề nhỏ.
Giai đoạn 2 tốc độ
Chứng minh luồng đơn phải chậm tối đa mười nghìn lần so với thực hiện trên máy cục bộ.
Hoặc, do một số phương pháp SNARK triển vọng (đặc biệt là các phương pháp dựa trên trường nhị phân) bị hạn chế bởi CPU và GPU hiện tại, bạn có thể so sánh sử dụng FPGA (thậm chí ASIC) để đạt được giai đoạn này:
FPGA có thể mô phỏng số lượng nhân RISC-V theo tốc độ cục bộ;
Mô phỏng và chứng minh (gần như) số lượng FPGA cần thiết để thực hiện RISC-V gần như thời gian thực.
Nếu số lần lớn nhất của lần thứ hai so với lần thứ nhất là tối đa 10.000 lần, bạn sẽ đủ điều kiện để tiến vào giai đoạn 2. Trên CPU tiêu chuẩn, kích thước chứng minh phải tối đa là 256 KB, thời gian xác minh tối đa là 16 mili giây.
Giai đoạn 3 tốc độ
Ngoài việc đạt được giai đoạn 2 về tốc độ, bạn cũng có thể sử dụng việc tự động tổng hợp và xác thực hình thức để thực hiện chi phí chứng minh dưới 1000 lần (phù hợp với nhiều ứng dụng). Theo cách cơ bản, bạn có thể tùy chỉnh bộ chỉ thị động cho mỗi chương trình để tăng tốc độ chứng minh, nhưng phải thực hiện một cách dễ dàng sử dụng và xác thực hình thức.
Giai đoạn bộ nhớ 1
Tốc độ giai đoạn 1 được đạt được khi bộ nhớ cần thiết của bằng chứng viên ít hơn 2 GB (đồng thời cũng đạt được kiến thức không biết).
Đ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, vì vậy đã mở ra vô số trường hợp sử dụng zkVM cho khách hàng. Chứng minh của khách hàng rất quan trọng, vì điện thoại di động của chúng ta là liên lạc liên tục với thế giới thực: chúng theo dõi vị trí, chứng chỉ của chúng ta, v.v. Nếu việc tạo chứng minh đòi hỏi hơn 1-2 GB bộ nhớ, thì đối với hầu hết các thiết bị di động hiện nay đó là quá nhiều. Cần làm rõ hai điểm:
· 2 GB không gian giới hạn được áp dụng cho các câu lệnh lớn (cần hàng ngàn tỷ chu kỳ CPU để chạy cục bộ). Hệ thống chứng minh giới hạn không gian chỉ áp dụng cho các câu lệnh nhỏ thiếu tính phổ quát.
· Nếu bằng chứng quá chậm, việc duy trì không gian của bằng chứng dưới 2 GB sẽ trở nên dễ dàng. Do đó, để phần bộ nhớ 1 trở nên không đơn giản, tôi yêu cầu đáp ứng giai đoạn 1 với tốc độ trong giới hạn không gian 2 GB.
Giai đoạn Bộ nhớ 2
Tốc độ của giai đoạn 1 đã được đạt được mà không dùng quá 200 MB bộ nhớ (tốt hơn giai đoạn 1 với 10 lần).
Tại sao cần giảm xuống dưới 2 GB? Hãy xem xét một ví dụ không phải là blockchain: Mỗi khi bạn truy cập một trang web thông qua HTTPS, bạn sẽ tải xuống chứng chỉ để xác thực và mã hóa. Thay vào đó, trang web có thể gửi chứng chỉ zk mà có chứa các chứng chỉ này. Một trang web lớn có thể phát ra hàng triệu chứng chỉ như vậy mỗi giây. Nếu mỗi chứng chỉ cần 2 GB bộ nhớ để tạo ra, thì tổng cộng sẽ cần tới PB RAM. Việc giảm bớt việc sử dụng bộ nhớ với triển khai không phải là blockchain rất quan trọng.
Biên dịch: Cuối cùng vẫn là cây gậy hay không?
Trong thiết kế zkVM, việc biên soạn trước đó là việc tùy chỉnh SNARK chuyên dụng được thiết kế cho một chức năng cụ thể, ví dụ như băm Keccak/SHA hoặc phép toán nhóm đường cong elliptic được sử dụng cho chữ ký số. Trong Ethereum (hầu hết công việc nặng liên quan đến băm Merkle và kiểm tra chữ ký), một số việc biên soạn trước được tạo thủ công có thể giảm bớt chi phí chứng minh. Tuy nhiên, phụ thuộc vào chúng như một cây gậy không thể đạt được mục tiêu của SNARK. Lý do như sau:
· Đối với hầu hết các ứng dụng (cả trong và ngoài blockchain) vẫn quá chậm: Ngay cả khi sử dụng hash và chữ ký được biên dịch trước, zkVM hiện tại vẫn quá chậm (cả trong môi trường blockchain và ngoài môi trường blockchain) do hiệu suất của hệ thống chứng minh cốt lõi thấp.
· Lỗi an ninh: Việc biên soạn trước bằng tay chưa được xác thực chính thức hầu như chắc chắn sẽ đầy lỗi, có thể dẫn đến sự cố an ninh thảm khốc.
· Trải nghiệm của các nhà phát triển không tốt: Trong hầu hết các zkVM hiện nay, việc thêm mới các mã thông dịch có nghĩa là phải viết hệ thống ràng buộc cho mỗi chức năng một cách thủ công - tức là quay trở lại quy trình làm việc kiểu như thập niên 1960. Ngay cả khi sử dụng các mã thông dịch hiện có, các nhà phát triển cũng phải tái cấu trúc mã để gọi từng mã thông dịch. Chúng ta nên tối ưu hóa cho tính bảo mật và trải nghiệm của các nhà phát triển, thay vì hy sinh cả hai để theo đuổi 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 đến mức cần có.
· I/O overhead without RAM: Although precompilation can improve the performance of intensive encryption tasks, they may not provide meaningful acceleration for more diverse workloads because they incur significant overhead when passing input/output and cannot use RAM. Even in a blockchain environment, as long as you go beyond single-piece L1 like Ethereum (for example, you want to build a series of cross-chain bridges), you will encounter different hash functions and signature schemes. Repeated precompilation on the issue cannot scale and brings significant security risks.
Với tất cả những lý do này, nhiệm vụ hàng đầu của chúng tôi là nâng cao hiệu suất của zkVM ở tầng cơ bản. Công nghệ tạo ra zkVM tốt nhất cũng sẽ tạo ra các bản biên dịch tốt nhất. Tôi thực sự tin rằng các bản biên dịch vẫn rất quan trọng trong tương lai, nhưng điều kiện tiên quyết là chúng được tự động hợp thành và kiểm tra chính thức. Điều này giúp duy trì ưu thế trải nghiệm của nhà phát triển zkVM, đồng thời tránh xa rủi ro an ninh thảm họa. Quan điểm này được phản ánh trong giai đoạn tốc độ 3.
Kế hoạch dự kiến
Tôi dự đoán rằng một số zkVM sẽ đạt giai đoạn tốc độ 1 và giai đoạn bộ nhớ 1 vào cuối năm nay. Tôi nghĩ rằng chúng ta cũng sẽ đạt giai đoạn tốc độ 2 trong hai năm tới, nhưng hiện tại vẫn chưa rõ liệu chúng ta có thể đạt được mục tiêu này hay không nếu không có những ý tưởng mới chưa xuất hiện. Tôi dự đoán rằng các giai đoạn còn lại (giai đoạn tốc độ 3 và giai đoạn bộ nhớ 2) sẽ cần vài năm để đạt được.
Tóm tắt
Mặc dù tôi đã phân biệt rõ giai đoạn an ninh và hiệu suất của zkVM trong bài viết 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 ra nhiều lỗ hổng hơn trong zkVM, dự kiến một số lỗ hổng chỉ có thể được sửa chữa khi hiệu suất giảm đáng kể. Trước khi zkVM đạt đến giai đoạn an toàn 2, hiệu suất nên được tạm hoãn.
zkVM có thể giúp việc chứng minh không biết trở nên phổ biến, nhưng chúng vẫn đang ở giai đoạn ban đầu - đầy thách thức về an ninh và chi phí hiệu suất lớn. Sự quảng cáo và tiếp thị làm cho việc đánh giá tiến triển thực sự trở nên khó khăn. Hy vọng có thể cung cấp một bản đồ đường không có sự cản trở thông qua việc làm rõ các cột mốc an ninh và hiệu suất cụ thể. Chúng tôi sẽ đạt được mục tiêu, nhưng điều này cần thời gian và nỗ lực liên tục.
Liên kết gốc
：