Tác giả: Justin Thaler Nguồn: a16z Dịch: Shanooba, Kinh tế màu vàng
Máy ảo không biết (zkVMs) nhằm mục đích "đưa SNARKs đến với đại chúng", cho phép ngay cả những người không có kiến thức chuyên sâu về SNARK cũng có thể chứng minh rằng họ đã chạy đúng một chương trình nào đó trên một đầu vào cụ thể (hoặc bằng 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 zkVMs vẫn đối mặt với những thách thức lớn về an ninh và hiệu suất. Nếu zkVMs muốn thực hiện những cam kết, nhà thiết kế phải vượt qua những rào cản này. Bài viết này sẽ thảo luận về các giai đoạn phát triển của zkVM, một quá trình có thể mất vài năm để hoàn thành - đừng tin vào bất kỳ ai nói rằng điều này có thể thực hiện nhanh chóng.
Thách thức đối diện
Về mặt ** an ninh **, zkVMs là một dự án phần mềm rất phức tạp và vẫn còn đầy lỗ hổng.
Trong mặt hiệu suất, việc chứng minh sự thực hiện chính xác của một chương trình có thể chậm hàng trăm nghìn lần so với việc chạy nguyên bản, làm cho việc triển khai của hầu hết ứng dụng trong thế giới thực tạm thời không khả thi.
Mặc dù vậy, nhiều giọng nói trong ngành công nghiệp blockchain vẫn đang quảng cáo rằng zkVMs đã có thể triển khai ngay lập tức, thậm chí một số dự án đã phải trả chi phí tính toán đắt đỏ để tạo ra chứng minh không biết gì về hoạt động trên chuỗi. Tuy nhiên, do zkVMs vẫn còn nhiều lỗ hổng, phương pháp này thực tế chỉ là một loại trang phục đắt tiền, làm cho hệ thống trở nên giống như được bảo vệ bởi SNARK, trong khi thực tế nó dựa vào kiểm soát quyền hạn, hoặc tệ hơn nữa — bị tiếp xúc với nguy cơ tấn công.
Tình hình hiện tại là, chúng ta còn một vài năm xa lạ để xây dựng một zkVM thực sự an toàn và hiệu quả. Bài viết này đưa ra một loạt các mục tiêu cụ thể và theo từng giai đoạn để giúp chúng ta theo dõi tiến triển thực sự của zkVM, làm yếu đi sự sốt sắng và hướng dẫn cộng đồng chú ý đến những đột phá công nghệ thực sự.
Giai đoạn phát triển an ninh
Bối cảnh
Dựa trên SNARK của zkVMs thường bao gồm hai thành phần cốt lõi:
Chứng minh máy trò chuyện tương tác đa thức (Polynomial Interactive Oracle Proof, PIOP): Sử dụng để chứng minh khung chứng minh tương tác cho đa thức (hoặc ràng buộc được tạo ra từ đa thức).
Chương trình cam kết đa thức (Polynomial Commitment Scheme, PCS): Đảm bảo bằng chứng không thể giả mạo 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ủa đăng ký và bộ nhớ của máy ảo bằng cách mã hóa các dấu vết thực thi hiệu quả thành hệ thống ràng buộc, sau đó sử dụng SNARK để chứng minh sự thoả mãn của những ràng buộc này.
Trong một hệ thống phức tạp như vậy, duy nhất cách mà có thể đảm bảo zkVM không có lỗ hổng là xác minh hình thức. Dưới đây là các giai đoạn an toàn của zkVM, trong đó giai đoạn đầu tiên tập trung vào tính đúng đắn của giao thức, giai đoạn thứ hai và thứ ba tập trung vào tính đúng đắn của việc triển khai.
Giai đoạn 1 về tính bảo mật: Giao thức chính xác
Chứng nhận xác minh chính thức về độ tin cậy của PIOP;
PCS được chứng minh hình thức có hiệu lực trong một số giả thiết mật mã hoặc mô hình lý tưởng.
Nếu sử dụng Fiat-Shamir, việc kết hợp chứng minh ngắn được thu thập từ PIOP và PCS là một bằng chứng chính thức an toàn trong mô hình tiên đoán ngẫu nhiên (được củng cố bằng các giả thuyết mật mã khác khi cần thiết);
Hệ thống ràng buộc được áp dụng bởi PIOP tương đương với bằng chứng xác minh hình thức của cú pháp VM;
Tất cả các phần trên được "liên kết" thành một chứng minh SNARK an toàn, đã được xác minh hình thức, để chạy bất kỳ chương trình nào được chỉ định bởi VM bytecode. Nếu giao thức dự định triển khai kiến thức không, cần phải xác minh hình thức 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 kiến.
Nếu zkVM sử dụng đệ quy, thì trong quá trình đệ quy, PIOP, gói cam kết và hệ thống ràng buộcđều phải được xác minh, nếu không, giai đoạn con đó không được coi là hoàn thành.
Bước 2: Triển khai validator đúng đắn
Trong giai đoạn này, yêu cầu thực hiện xác minh hình thức cho trình diễn viên zkVM (ví dụ: Rust, Solidity) để đả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 thành giai đoạn này có nghĩa là việc thực hiện zkVM là nhất quán với thiết kế lý thuyết, không chỉ là một giao thức an toàn trên giấy, hoặc một quy định không hiệu quả được viết bằng ngôn ngữ Lean.
Tại sao chỉ quan tâm đến người xác minh mà không quan tâm đến người chứng minh chính có hai lý do chính: Thứ nhất, đảm bảo người xác minh đúng, có thể đảm bảo tính đầy đủ của hệ thống chứng minh zkVM (tức là: đảm bảo người xác minh không thể bị lừa dối để chấp nhận một chứng minh sai). Thứ hai, việc triển khai người xác minh zkVM đơn giản hơn một số mức so với việc triển khai người chứng minh, tính đúng đắn của người xác minh dễ dàng được bảo đảm trong thời gian ngắn hơn.
Giai đoạn 3 về tính an toàn: Người chứng minh đúng đắn
Yêu cầu trong giai đoạn này là phải tiến hành xác minh hình thức của chứng minh viên zkVM, đảm bảo rằng nó có thể tạo ra chính xác các chứng minh của các hệ thống chứng minh đã được xác minh trong giai đoạn một và hai. Mục tiêu của giai đoạn này là hoàn chỉnh, nghĩa là: không có hệ thống nào sử dụng zkVM sẽ bị treo vì không thể chứng minh một câu lệnh hợp lệ nào đó. Nếu zkVM cần có tính chất không biết, thì phải cung cấp xác minh hình thức để đảm bảo rằng chứng minh sẽ không tiết lộ bất kỳ thông tin nào về bằng chứng.
Thời gian dự kiến
CẬP NHẬT 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ụ, ZKLib là một nỗ lực như vậy). Nhưng ít nhất trong vòng hai năm, 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 triển khai đồ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 việc triển khai trình xác minh Plonk phù hợ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 xác minh hoàn toàn). Tuy nhiên, dự đoán rằng bất kỳ zkVM nào cũng sẽ không đạt được giai đoạn 3 trong vòng chưa đầy bốn năm - hoặc thậm chí còn lâu hơn.
Lưu ý quan trọng: An toàn Fiat-Shamir và mã byte đã được xác minh
Một vấn đề phức tạp chính là, vẫn còn tồn tại các vấn đề nghiên cứu chưa giải quyết về tính an toàn của biến đổi Fiat-Shamir. Tất cả ba giai đoạn an toàn đều coi Fiat-Shamir và máy bói toán học ngẫu nhiên là tuyệt đối an toàn, 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ô hình lý tưởng của máy bói toán học ngẫu nhiên và hàm băm thực tế được sử dụng.
Trong trường hợp tồi tệ nhất, một hệ thống đã đạt đến giai đoạn bảo mật 2 có thể được phát hiện là hoàn toàn không an toàn do vấn đề liên quan tới Fiat-Shamir. Điều này đáng chú ý và cần tiếp tục nghiên cứu. Chúng ta có thể cần sửa đổi chính Fiat-Shamir biến đổi để bảo vệ hiệu quả hơn khỏi những lỗ hổng như vậy.
Hệ thống không sử dụng đệ quy lý thuyết an toàn hơn vì một số tấn công đã biết liên quan đến mạch tương tự như mạch được sử dụng trong chứng minh đệ quy. Nhưng rủi ro này vẫn là một vấn đề cơ bản chưa được giải quyết.
Một vấn đề khác cần lưu ý là, ngay cả khi zkVM chứng minh rằng một chương trình tính toán nào đó (do mã byte chỉ định) được thực thi đúng đắn, nhưng nếu mã byte chính nó có vấn đề, thì giá trị của chứng minh này rất hạn chế. Do đó, tính ứng dụng của zkVM phụ thuộc rất nhiều vào việc tạo ra mã byte đã được xác minh hình thức như thế nào, và thách thức này cực kỳ lớn lao, và vượt ra ngoài phạm vi thảo luận của bài viết.
Về tính an toàn chống lượng tử
Trong ít nhất 5 năm tới (thậm chí còn 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 phần mềm lại là một vấn đề sống chết. Do đó, nhiệm vụ hàng đầu hiện tại là đạt được các mục tiêu về an ninh và hiệu suất được đề xuất trong bài viết. Nếu SNARKs không chống lại lượng tử có thể đáp ứng các mục tiêu này nhanh hơn, chúng ta nên ưu tiên sử dụng chúng. Khi SNARKs chống lại lượng tử bắt kịp phát triển, hoặc có dấu hiệu cho thấy máy tính lượng tử có thực sự đe dọa sẽ xuất hiện, hãy xem xét chuyển đổi sau đó.
Cấp độ an toàn cụ thể
100-bit An ninh cổ điển là tiêu chuẩn tối thiểu mà bất kỳ SNARK nào sử dụng để bảo vệ tài sản có giá trị (nhưng vẫn có một số hệ thống chưa đạt đến tiêu chuẩn thấp này). Tuy nhiên, điều này vẫn không được chấp nhận, thực hành mật mã tiêu chuẩn thường yêu cầu an ninh 128-bit trở lên. Nếu hiệu suất của SNARK thực sự đạt chuẩn, chúng ta không nên giảm bớt an ninh để 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 chứng minh viên zkVM khoảng 1.000.000 lần thực thi nguyên thủy. Nói cách khác, nếu việc thực thi nguyên thủy của một chương trình cần X chu kỳ CPU, thì việc tạo ra bằng chứng thực thi đúng cần khoảng X × 1.000.000 chu kỳ CPU. Tình hình này đã diễn ra một năm trước và vẫn như vậy ngày hôm nay (mặc dù có một số hiểu lầm).
Một số cụm từ phổ biến trong ngành hiện tại có thể dẫn đến hiểu lầm, ví dụ:
“Chi phí sinh ra chứng thực cho toàn bộ mạng lưới chính Ethereum thấp hơn 1 triệu đô la Mỹ mỗi năm.”
Chúng tôi đã gần như thực hiện việc tạo ra chứng minh thời gian thực cho các khối Ethereum chỉ cần vài chục GPU.
“Chúng tôi đã cải tiến zkVM mới của chúng tôi lên 1000 lần so với thế hệ trước.”
Tuy nhiên, những phát ngôn này có thể gây hiểu lầm nếu thiếu bối cảnh:
• So với zkVM phiên bản cũ, nhanh hơn 1000 lần, vẫn có thể rất chậm, điều này càng chứng minh quá khứ đã tệ đến mức nào, chứ không phải hiện tại đã tốt đến đâu.
• Khả năng tính toán trên 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 của zkVM hiện tại không thể đáp ứng nhu cầu.
• Quá trình tạo ra bằng chứng 'gần như thời gian thực' vẫn quá chậm trong 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 Ethereum 12 giây).
• “Một số chục GPU chạy liên tục 24/7” không thể đảm bảo đủ sự hoạt động ổn định.
• Thời gian tạo ra chứng minh này thường là cho kích thước chứng minh lớn hơn 1MB, điều này là quá lớn đối với nhiều ứng dụng.
• Chi phí dưới 100 nghìn đô la mỗi năm chỉ là do một nút Ethereum hoàn chỉnh chỉ thực hiện khoảng 25 đô la tính toán mỗi năm.
Đối với các trường hợp sử dụng ngoài lĩnh vực blockchain, chi phí tính toán này rõ ràng quá cao. Bất kể có bao nhiêu tính toán song song hoặc tối ưu hóa kỹ thuật, cũng không thể bù đắp được chi phí tính toán lớn như vậy.
Mục tiêu cơ bản mà chúng ta nên đặt ra là: hiệu suất không vượt quá 100.000 lần thực thi nguyên bản. Nhưng ngay cả khi như vậy, điều này vẫn chỉ là bước đầu tiên. Nếu muốn thực sự triển khai ứng dụng phổ biến quy mô lớn, chúng ta có thể cần giảm chi phí xuống còn 10.000 lần thực thi nguyên bản hoặc ít hơn.
Đo lường hiệu suất
Hiệu suất SNARK có ba thành phần chính:
Hiệu quả cố định của hệ thống chứng minh cơ sở.
Tối ưu hóa cho ứng dụng cụ thể (ví dụ như trước biên dịch).
Công nghệ và tăng tốc phần cứng (ví dụ như GPU, FPGA hoặc CPU đa lõi).
Mặc dù (2) và (3) quan trọng đối với triển khai thực tế, nhưng chúng áp dụng cho bất kỳ hệ thống chứng minh nào, do đó 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 GPU tăng tốc và trước biên dịch vào zkEVM có thể dễ dàng tăng tốc độ lên 50 lần so với việc chỉ dựa vào CPU – điều này có thể khiến một hệ thống hiệu suất cố định thấp trở nên ưu việt hơn một hệ thống khác chưa trải qua các tối ưu hóa tương tự.
Do đó, bài viết này tập trung vào hiệu suất cơ bản của SNARK mà không cần phần cứng đặc biệt và mã nguồn được biên dịch trước. Điều này khác biệt với phương pháp kiểm tra hiện tại, thường gộp cả ba yếu tố lại thành một “giá trị tổng thể”. Điều này giống như đánh giá kim cương dựa trên thời gian mài mòn, thay vì đánh giá độ trong suốt tự nhiên của nó.
Mục tiêu của chúng tôi là cô lập chi phí cố định của hệ thống chứng minh chung, giảm thiểu rào cản của công nghệ chưa được nghiên cứu sâu và giúp cộng đồng loại bỏ yếu tố làm phiền, tập trung vào sự tiến triển thực sự của thiết kế hệ thống chứng minh.
Giai đoạn hiệu suất
Dưới đây là năm cột mốc hiệu suất mà tôi đề xuất. Đầu tiên, chúng ta cần giảm chi phí của người chứng minh trên CPU một cách đáng kể trước khi có thể tiến xa hơn thông qua việc giảm chi phí thông qua phần cứng. Đồng thời, việc sử dụng bộ nhớ cũng cần phải được cải thiện.
Ở tất cả các giai đoạn, nhà phát triển không nên điều chỉnh mã nguồn cho hiệu suất của zkVM. Trải nghiệm của nhà phát triển là ưu điểm cốt lõi của zkVM. Nếu hy sinh DevEx để đạt được tiêu chuẩn hiệu suất, không chỉ mất đi ý nghĩa của tiêu chuẩn hiệu suất mà còn vi phạm nguyên tắc ban đầu của zkVM.
Những chỉ số này chủ yếu tập trung vào Chi phí của người chứng minh. Tuy nhiên, nếu cho phép chi phí của người xác minh tăng không giới hạn (tức 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ì bất kỳ chỉ số nào của người chứng minh cũng có thể dễ dàng đáp ứng. Do đó, để đáp ứng yêu cầu của giai đoạn sau, phải đồng thời giới hạn kích thước chứng minh tối đa và thời gian xác minh tối đa.
Yêu cầu giai đoạn 1: "Chi phí xác thực hợp lý không tầm thường"
• Kích thước chứng minh: Phải nhỏ hơn kích thước chứng minh.
• Thời gian xác minh：Tốc độ xác minh không được chậm hơn việc thực thi nguyên bản của chương trình (tức là không được chậm hơn việc thực thi tính toán trực tiếp).
Đây là yêu cầu về sự đơn giản tối thiểu, đảm bảo rằng kích thước chứng minh và thời gian xác minh không tệ hơn việc gửi chứng minh trực tiếp cho người xác minh và cho họ kiểm tra trực tiếp.
Giai Đoạn 2 và cao hơn
• Kích thước chứng minh tối đa：256 KB。
• Thời gian xác thực tối đa：16 毫秒。
Các ngưỡng trên này được thiết lập rộng lớn để phù hợp với công nghệ chứng minh nhanh mới lạ, ngay cả khi chúng có thể mang lại chi phí xác minh cao hơn. Đồng thời, các ngưỡng này loại trừ các loại chứng minh quá đắt đỏ mà hầu như không có dự án nào muốn sử dụng trên chuỗi khối.
Giai đoạn 1 tốc độ
Chứng minh số thứ tự không được chậm hơn hơn 100,000 lần so với việc thực thi nguyên bản (áp dụng cho nhiều ứng dụng không chỉ là chứng minh khối của Ethereum), và không nên phụ thuộc vào việc biên dịch trước.
Cụ thể hơn, giả sử một bộ xử lý RISC-V trên một máy tính xách tay hiện đại chạy ở tốc độ khoảng 30 tỷ chu kỳ/giây, vậy nghĩa là đạt giai đoạn 1 có nghĩa là máy tính xách tay đó có thể tạo ra chứng minh với tốc độ 30.000 chu kỳ RISC-V/giây (một luồng).
Chi phí của máy xác minh phải đáp ứng tiêu chuẩn "Chi phí xác minh hợp lý không tầm thường" được xác định trước đó.
Giai đoạn 2 tốc độ
Chứng minh đơn luồng không được chậm hơn so với thực thi nguyên bản hơn 10,000 lần.
Hoặc, do hạn chế về CPU và GPU hiện tại, có thể sử dụng FPGA (hoặc thậm chí ASIC) để thỏa mãn giai đoạn này nhờ một số phương pháp SNARK triển vọng (đặc biệt là SNARK trên trường nhị phân).
Tính số lõi RISC-V được mô phỏng bằng tốc độ nguyên thuỷ của FPGA.
Tính toán mô phỏng và chứng minh số lượng FPGA cần thiết để thực hiện RISC-V (gần thời gian thực).
Nếu số lượng của (2) không vượt quá 10,000 lần (1), thì đạt được giai đoạn 2.
• Kích thước chứng minh：Tối đa 256 KB。
• Thời gian xác minh : tối đa 16 miligiây trên CPU tiêu chuẩn.
Giai đoạn 3 tốc độ
Đạt được chi phí chứng minh trong vòng 1000× trên Giai đoạn Tốc độ 2 (cho một loạt các ứng dụng) và phải sử dụng biên dịch trước để tổng hợp tự động và 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 độ tạo bằng chứng, nhưng nó phải dễ sử dụng và được xác minh chính thức. (Xem phần tiếp theo về 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 soạn "viết tay" không phải là một cách tiếp cận bền vững.) ）
Giai đoạn 1 Bộ nhớ
Trong vòng 2 GB bộ nhớ để đạt đượcgiai đoạn tốc độ 1 và đồng thời đáp ứng yêu cầuzero knowledge. Giai đoạn này quan trọng đối vớithiết bị di động hoặc trình duyệt, và mở ra cánh cửa chonhiều trường hợp sử dụng zkVM trên phía máy khách. Ví dụ, điện thoại thông minh được sử dụng choquyền riêng tư vị trí, giấy tờ tùy thân, v.v. Nếu việc tạo chứng minh đòi hỏi hơn 1-2 GB bộ nhớ, hầu hết thiết bị di động sẽ không thể chạy được.
Hai điểm quan trọng cần lưu ý:
Ngay cả khi là tính toán quy mô lớn (yêu cầu hàng ngàn tỷ chu kỳ CPU thực thi), hệ thống chứng minh cũng phải duy trì giới hạn bộ nhớ 2 GB, nếu không sẽ hạn chế tính ứng dụng.
Nếu chứng minh tốc độ cực kỳ chậm, việc giữ ngưỡng bộ nhớ 2 GB rất dễ dàng. Do đó, để giai đoạn bộ nhớ 1 có ý nghĩa, phải đạt được giai đoạn 1 với ngưỡng bộ nhớ 2 GB.
Giai đoạn 2 bộ nhớ
Trong trường hợp bộ nhớ dưới 200 MB đạt giai đoạn tốc độ 1 (tăng gấp 10 lần so với giai đoạn bộ nhớ 1).
Tại sao cần giảm xuống còn 200 MB? Hãy xem một kịch bản ngoài chuỗi khối: khi bạn truy cập trang web HTTPS, bạn sẽ tải xuống chứng nhận xác thực và mã chứng thực. Nếu trang web chuyển sang gửi các chứng chỉ này dưới dạng chứng minh zk, các trang web lớn có thể cần tạo ra ** hàng triệu chứng chỉ mỗi giây**. Nếu mỗi chứng chỉ cần 2 GB bộ nhớ, nhu cầu tài nguyên tính toán sẽ đạt đến ** cấp độ PB , rõ ràng là không thể. Do đó, việc giảm bộ nhớ tiếp tục là rất quan trọng đối với ** ứng dụng ngoài chuỗi khối.
**Viết sẵn: Một dặm cuối cùng, vẫn là cái nạng?
Việc biên soạn trước đề cập đến hệ thống ràng buộc SNARK được tối ưu hóa đặc biệt cho các chức năng cụ thể (như băm, chữ ký đường cong elliptic). Trong Ethereum, việc biên soạn trước giúp giảm chi phí của Merkle hash và xác minh chữ ký, nhưng phụ thuộc quá mức vào việc biên soạn trước không thực sự cải thiện hiệu suất cốt lõi của SNARK.
Vấn đề được biên soạn trước
1. Vẫn quá chậm: Ngay cả khi sử dụng tiền mã hóa và chữ ký được biên soạn trước, zkVM vẫn gặp vấn đề hiệu suất lõi trong hệ thống chứng minh cốt lõi bên trong và bên ngoài chuỗi khối.
2. Lỗ hổng an ninh: Nếu việc viết trước không được xác minh hình thức, hầu như chắc chắn sẽ tồn tại lỗ hổng, có thể dẫn đến thất bại an ninh thảm họa.
3. Trải nghiệm phát triển kém: Hiện tại, nhiều zkVM cần phải viết thủ công hệ thống ràng buộc, giống như cách lập trình vào thập niên 1960, ảnh hưởng nghiêm trọng đến trải nghiệm phát triển.
4. Sự đánh lừa trong kiểm tra cơ sở：Nếu kiểm tra cơ sở phụ thuộc vào việc tối ưu hóa cụ thể trước biên dịch, 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 thiết kế SNARK chính nó.
5. Chi phí I/O và truy cập không RAM Mặc dù việc biên dịch trước có thể cải thiện hiệu suất của 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 có ý nghĩa cho các tải công việc đa dạng hơn vì chúng tạo ra chi phí lớn khi truyền đầu vào/ra và chúng không thể sử dụng RAM.
Ngay cả trong môi trường blockchain, nếu bạn vượt qua các L1 đơn lẻ như Ethereum (ví dụ, bạn muốn xây dựng một loạt cầu nối qua các chuỗi khác nhau), bạn sẽ đối mặt với các hàm băm và các phương pháp chữ ký khác nhau. Để giải quyết vấn đề này mà không ngừng tiến hành biên dịch trước, điều này không chỉ không mở rộng được mà còn mang lại rủi ro bảo mật lớn.
Tôi thực sự tin rằng việc biên soạn trước là quan trọng trong tương lai, nhưng chỉ khi chúng tự động tổng hợp và được xác minh chính thức sau đó mới như vậy. Điều này giúp duy trì lợi thế trải nghiệm của nhà phát triển zkVM, đồng thời tránh xa rủi ro bảo mật thảm họa. Quan điểm này được phản ánh trong giai đoạn 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 trong vòng hai năm tới, chúng ta cũng có thể đạt được giai đoạn tốc độ 2, 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 mà không cần có hướng nghiên cứu mới hay không.
Tôi dự đoán rằng các giai đoạn còn lại (Giai đoạn Tốc độ 3 và Bộ nhớ 2) sẽ cần mất vài năm nữa mới có thể đạt được.
Mặc dù bài viết này liệt kê riêng biệt giai đoạn an toàn và hiệu suất của zkVM, nhưng hai điều này không hoàn toàn độc lập. Khi các lỗi trong zkVM liên tục được phát hiện, tôi dự đoán việc sửa chữa một số lỗi sẽ không thể tránh khỏi dẫn đến giảm hiệu suất đáng kể. Do đó, kết quả kiểm thử hiệu suất của zkVM trước khi đạt Giai đoạn An toàn 2 nên được xem xét là dữ liệu tạm thời.
zkVM có tiềm năng lớn trong việc thúc đẩy sự phổ biến thực sự của chứng minh không cần biết, nhưng hiện nay vẫn đang ở giai đoạn sớm - đầy thách thức về an ninh và có những hạn chế nghiêm trọng về hiệu suất. Sự quảng bá và tiếp thị thị trường làm cho việc đo lường tiến triển thực sự trở nên khó khăn. Tôi hy vọng cung cấp một lộ trình có thể xua tan sương mù thông qua các mốc an ninh và hiệu suất rõ ràng. Chúng ta sẽ đạt được mục tiêu cuối cùng, nhưng điều này cần thời gian và nỗ lực liên tục trong nghiên cứu và kỹ thuật.
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: Khám phá con đường hiệu quả và an toàn của zkVM
Tác giả: Justin Thaler Nguồn: a16z Dịch: Shanooba, Kinh tế màu vàng
Máy ảo không biết (zkVMs) nhằm mục đích "đưa SNARKs đến với đại chúng", cho phép ngay cả những người không có kiến thức chuyên sâu về SNARK cũng có thể chứng minh rằng họ đã chạy đúng một chương trình nào đó trên một đầu vào cụ thể (hoặc bằng 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 zkVMs vẫn đối mặt với những thách thức lớn về an ninh và hiệu suất. Nếu zkVMs muốn thực hiện những cam kết, nhà thiết kế phải vượt qua những rào cản này. Bài viết này sẽ thảo luận về các giai đoạn phát triển của zkVM, một quá trình có thể mất vài năm để hoàn thành - đừng tin vào bất kỳ ai nói rằng điều này có thể thực hiện nhanh chóng.
Thách thức đối diện
Về mặt ** an ninh **, zkVMs là một dự án phần mềm rất phức tạp và vẫn còn đầy lỗ hổng.
Trong mặt hiệu suất, việc chứng minh sự thực hiện chính xác của một chương trình có thể chậm hàng trăm nghìn lần so với việc chạy nguyên bản, làm cho việc triển khai của hầu hết ứng dụng trong thế giới thực tạm thời không khả thi.
Mặc dù vậy, nhiều giọng nói trong ngành công nghiệp blockchain vẫn đang quảng cáo rằng zkVMs đã có thể triển khai ngay lập tức, thậm chí một số dự án đã phải trả chi phí tính toán đắt đỏ để tạo ra chứng minh không biết gì về hoạt động trên chuỗi. Tuy nhiên, do zkVMs vẫn còn nhiều lỗ hổng, phương pháp này thực tế chỉ là một loại trang phục đắt tiền, làm cho hệ thống trở nên giống như được bảo vệ bởi SNARK, trong khi thực tế nó dựa vào kiểm soát quyền hạn, hoặc tệ hơn nữa — bị tiếp xúc với nguy cơ tấn công.
Tình hình hiện tại là, chúng ta còn một vài năm xa lạ để xây dựng một zkVM thực sự an toàn và hiệu quả. Bài viết này đưa ra một loạt các mục tiêu cụ thể và theo từng giai đoạn để giúp chúng ta theo dõi tiến triển thực sự của zkVM, làm yếu đi sự sốt sắng và hướng dẫn cộng đồng chú ý đến những đột phá công nghệ thực sự.
Giai đoạn phát triển an ninh
Bối cảnh
Dựa trên SNARK của zkVMs thường bao gồm hai thành phần cốt lõi:
Chứng minh máy trò chuyện tương tác đa thức (Polynomial Interactive Oracle Proof, PIOP): Sử dụng để chứng minh khung chứng minh tương tác cho đa thức (hoặc ràng buộc được tạo ra từ đa thức).
Chương trình cam kết đa thức (Polynomial Commitment Scheme, PCS): Đảm bảo bằng chứng không thể giả mạo 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ủa đăng ký và bộ nhớ của máy ảo bằng cách mã hóa các dấu vết thực thi hiệu quả thành hệ thống ràng buộc, sau đó sử dụng SNARK để chứng minh sự thoả mãn của những ràng buộc này.
Trong một hệ thống phức tạp như vậy, duy nhất cách mà có thể đảm bảo zkVM không có lỗ hổng là xác minh hình thức. Dưới đây là các giai đoạn an toàn của zkVM, trong đó giai đoạn đầu tiên tập trung vào tính đúng đắn của giao thức, giai đoạn thứ hai và thứ ba tập trung vào tính đúng đắn của việc triển khai.
Giai đoạn 1 về tính bảo mật: Giao thức chính xác
Nếu zkVM sử dụng đệ quy, thì trong quá trình đệ quy, PIOP, gói cam kết và hệ thống ràng buộc đều phải được xác minh, nếu không, giai đoạn con đó không được coi là hoàn thành.
Bước 2: Triển khai validator đúng đắn
Trong giai đoạn này, yêu cầu thực hiện xác minh hình thức cho trình diễn viên zkVM (ví dụ: Rust, Solidity) để đả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 thành giai đoạn này có nghĩa là việc thực hiện zkVM là nhất quán với thiết kế lý thuyết, không chỉ là một giao thức an toàn trên giấy, hoặc một quy định không hiệu quả được viết bằng ngôn ngữ Lean.
Tại sao chỉ quan tâm đến người xác minh mà không quan tâm đến người chứng minh chính có hai lý do chính: Thứ nhất, đảm bảo người xác minh đúng, có thể đảm bảo tính đầy đủ của hệ thống chứng minh zkVM (tức là: đảm bảo người xác minh không thể bị lừa dối để chấp nhận một chứng minh sai). Thứ hai, việc triển khai người xác minh zkVM đơn giản hơn một số mức so với việc triển khai người chứng minh, tính đúng đắn của người xác minh dễ dàng được bảo đảm trong thời gian ngắn hơn.
Giai đoạn 3 về tính an toàn: Người chứng minh đúng đắn
Yêu cầu trong giai đoạn này là phải tiến hành xác minh hình thức của chứng minh viên zkVM, đảm bảo rằng nó có thể tạo ra chính xác các chứng minh của các hệ thống chứng minh đã được xác minh trong giai đoạn một và hai. Mục tiêu của giai đoạn này là hoàn chỉnh, nghĩa là: không có hệ thống nào sử dụng zkVM sẽ bị treo vì không thể chứng minh một câu lệnh hợp lệ nào đó. Nếu zkVM cần có tính chất không biết, thì phải cung cấp xác minh hình thức để đảm bảo rằng chứng minh sẽ không tiết lộ bất kỳ thông tin nào về bằng chứng.
Thời gian dự kiến
CẬP NHẬT 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ụ, ZKLib là một nỗ lực như vậy). Nhưng ít nhất trong vòng hai năm, 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 triển khai đồ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 việc triển khai trình xác minh Plonk phù hợ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 xác minh hoàn toàn). Tuy nhiên, dự đoán rằng bất kỳ zkVM nào cũng sẽ không đạt được giai đoạn 3 trong vòng chưa đầy bốn năm - hoặc thậm chí còn lâu hơn.
Lưu ý quan trọng: An toàn Fiat-Shamir và mã byte đã được xác minh
Một vấn đề phức tạp chính là, vẫn còn tồn tại các vấn đề nghiên cứu chưa giải quyết về tính an toàn của biến đổi Fiat-Shamir. Tất cả ba giai đoạn an toàn đều coi Fiat-Shamir và máy bói toán học ngẫu nhiên là tuyệt đối an toàn, 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ô hình lý tưởng của máy bói toán học ngẫu nhiên và hàm băm thực tế được sử dụng.
Trong trường hợp tồi tệ nhất, một hệ thống đã đạt đến giai đoạn bảo mật 2 có thể được phát hiện là hoàn toàn không an toàn do vấn đề liên quan tới Fiat-Shamir. Điều này đáng chú ý và cần tiếp tục nghiên cứu. Chúng ta có thể cần sửa đổi chính Fiat-Shamir biến đổi để bảo vệ hiệu quả hơn khỏi những lỗ hổng như vậy.
Hệ thống không sử dụng đệ quy lý thuyết an toàn hơn vì một số tấn công đã biết liên quan đến mạch tương tự như mạch được sử dụng trong chứng minh đệ quy. Nhưng rủi ro này vẫn là một vấn đề cơ bản chưa được giải quyết.
Một vấn đề khác cần lưu ý là, ngay cả khi zkVM chứng minh rằng một chương trình tính toán nào đó (do mã byte chỉ định) được thực thi đúng đắn, nhưng nếu mã byte chính nó có vấn đề, thì giá trị của chứng minh này rất hạn chế. Do đó, tính ứng dụng của zkVM phụ thuộc rất nhiều vào việc tạo ra mã byte đã được xác minh hình thức như thế nào, và thách thức này cực kỳ lớn lao, và vượt ra ngoài phạm vi thảo luận của bài viết.
Về tính an toàn chống lượng tử
Trong ít nhất 5 năm tới (thậm chí còn 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 phần mềm lại là một vấn đề sống chết. Do đó, nhiệm vụ hàng đầu hiện tại là đạt được các mục tiêu về an ninh và hiệu suất được đề xuất trong bài viết. Nếu SNARKs không chống lại lượng tử có thể đáp ứng các mục tiêu này nhanh hơn, chúng ta nên ưu tiên sử dụng chúng. Khi SNARKs chống lại lượng tử bắt kịp phát triển, hoặc có dấu hiệu cho thấy máy tính lượng tử có thực sự đe dọa sẽ xuất hiện, hãy xem xét chuyển đổi sau đó.
Cấp độ an toàn cụ thể
100-bit An ninh cổ điển là tiêu chuẩn tối thiểu mà bất kỳ SNARK nào sử dụng để bảo vệ tài sản có giá trị (nhưng vẫn có một số hệ thống chưa đạt đến tiêu chuẩn thấp này). Tuy nhiên, điều này vẫn không được chấp nhận, thực hành mật mã tiêu chuẩn thường yêu cầu an ninh 128-bit trở lên. Nếu hiệu suất của SNARK thực sự đạt chuẩn, chúng ta không nên giảm bớt an ninh để 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 chứng minh viên zkVM khoảng 1.000.000 lần thực thi nguyên thủy. Nói cách khác, nếu việc thực thi nguyên thủy của một chương trình cần X chu kỳ CPU, thì việc tạo ra bằng chứng thực thi đúng cần khoảng X × 1.000.000 chu kỳ CPU. Tình hình này đã diễn ra một năm trước và vẫn như vậy ngày hôm nay (mặc dù có một số hiểu lầm).
Một số cụm từ phổ biến trong ngành hiện tại có thể dẫn đến hiểu lầm, ví dụ:
“Chi phí sinh ra chứng thực cho toàn bộ mạng lưới chính Ethereum thấp hơn 1 triệu đô la Mỹ mỗi năm.”
Chúng tôi đã gần như thực hiện việc tạo ra chứng minh thời gian thực cho các khối Ethereum chỉ cần vài chục GPU.
“Chúng tôi đã cải tiến zkVM mới của chúng tôi lên 1000 lần so với thế hệ trước.”
Tuy nhiên, những phát ngôn này có thể gây hiểu lầm nếu thiếu bối cảnh:
• So với zkVM phiên bản cũ, nhanh hơn 1000 lần, vẫn có thể rất chậm, điều này càng chứng minh quá khứ đã tệ đến mức nào, chứ không phải hiện tại đã tốt đến đâu.
• Khả năng tính toán trên 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 của zkVM hiện tại không thể đáp ứng nhu cầu.
• Quá trình tạo ra bằng chứng 'gần như thời gian thực' vẫn quá chậm trong 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 Ethereum 12 giây).
• “Một số chục GPU chạy liên tục 24/7” không thể đảm bảo đủ sự hoạt động ổn định.
• Thời gian tạo ra chứng minh này thường là cho kích thước chứng minh lớn hơn 1MB, điều này là quá lớn đối với nhiều ứng dụng.
• Chi phí dưới 100 nghìn đô la mỗi năm chỉ là do một nút Ethereum hoàn chỉnh chỉ thực hiện khoảng 25 đô la tính toán mỗi năm.
Đối với các trường hợp sử dụng ngoài lĩnh vực blockchain, chi phí tính toán này rõ ràng quá cao. Bất kể có bao nhiêu tính toán song song hoặc tối ưu hóa kỹ thuật, cũng không thể bù đắp được chi phí tính toán lớn như vậy.
Mục tiêu cơ bản mà chúng ta nên đặt ra là: hiệu suất không vượt quá 100.000 lần thực thi nguyên bản. Nhưng ngay cả khi như vậy, điều này vẫn chỉ là bước đầu tiên. Nếu muốn thực sự triển khai ứng dụng phổ biến quy mô lớn, chúng ta có thể cần giảm chi phí xuống còn 10.000 lần thực thi nguyên bản hoặc ít hơn.
Đo lường hiệu suất
Hiệu suất SNARK có ba thành phần chính:
Hiệu quả cố định của hệ thống chứng minh cơ sở.
Tối ưu hóa cho ứng dụng cụ thể (ví dụ như trước biên dịch).
Công nghệ và tăng tốc phần cứng (ví dụ như GPU, FPGA hoặc CPU đa lõi).
Mặc dù (2) và (3) quan trọng đối với triển khai thực tế, nhưng chúng áp dụng cho bất kỳ hệ thống chứng minh nào, do đó 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 GPU tăng tốc và trước biên dịch vào zkEVM có thể dễ dàng tăng tốc độ lên 50 lần so với việc chỉ dựa vào CPU – điều này có thể khiến một hệ thống hiệu suất cố định thấp trở nên ưu việt hơn một hệ thống khác chưa trải qua các tối ưu hóa tương tự.
Do đó, bài viết này tập trung vào hiệu suất cơ bản của SNARK mà không cần phần cứng đặc biệt và mã nguồn được biên dịch trước. Điều này khác biệt với phương pháp kiểm tra hiện tại, thường gộp cả ba yếu tố lại thành một “giá trị tổng thể”. Điều này giống như đánh giá kim cương dựa trên thời gian mài mòn, thay vì đánh giá độ trong suốt tự nhiên của nó.
Mục tiêu của chúng tôi là cô lập chi phí cố định của hệ thống chứng minh chung, giảm thiểu rào cản của công nghệ chưa được nghiên cứu sâu và giúp cộng đồng loại bỏ yếu tố làm phiền, tập trung vào sự tiến triển thực sự của thiết kế hệ thống chứng minh.
Giai đoạn hiệu suất
Dưới đây là năm cột mốc hiệu suất mà tôi đề xuất. Đầu tiên, chúng ta cần giảm chi phí của người chứng minh trên CPU một cách đáng kể trước khi có thể tiến xa hơn thông qua việc giảm chi phí thông qua phần cứng. Đồng thời, việc sử dụng bộ nhớ cũng cần phải được cải thiện.
Ở tất cả các giai đoạn, nhà phát triển không nên điều chỉnh mã nguồn cho hiệu suất của zkVM. Trải nghiệm của nhà phát triển là ưu điểm cốt lõi của zkVM. Nếu hy sinh DevEx để đạt được tiêu chuẩn hiệu suất, không chỉ mất đi ý nghĩa của tiêu chuẩn hiệu suất mà còn vi phạm nguyên tắc ban đầu của zkVM.
Những chỉ số này chủ yếu tập trung vào Chi phí của người chứng minh. Tuy nhiên, nếu cho phép chi phí của người xác minh tăng không giới hạn (tức 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ì bất kỳ chỉ số nào của người chứng minh cũng có thể dễ dàng đáp ứng. Do đó, để đáp ứng yêu cầu của giai đoạn sau, phải đồng thời giới hạn kích thước chứng minh tối đa và thời gian xác minh tối đa.
Yêu cầu giai đoạn 1: "Chi phí xác thực hợp lý không tầm thường"
• Kích thước chứng minh: Phải nhỏ hơn kích thước chứng minh.
• Thời gian xác minh：Tốc độ xác minh không được chậm hơn việc thực thi nguyên bản của chương trình (tức là không được chậm hơn việc thực thi tính toán trực tiếp).
Đây là yêu cầu về sự đơn giản tối thiểu, đảm bảo rằng kích thước chứng minh và thời gian xác minh không tệ hơn việc gửi chứng minh trực tiếp cho người xác minh và cho họ kiểm tra trực tiếp.
Giai Đoạn 2 và cao hơn
• Kích thước chứng minh tối đa：256 KB。
• Thời gian xác thực tối đa：16 毫秒。
Các ngưỡng trên này được thiết lập rộng lớn để phù hợp với công nghệ chứng minh nhanh mới lạ, ngay cả khi chúng có thể mang lại chi phí xác minh cao hơn. Đồng thời, các ngưỡng này loại trừ các loại chứng minh quá đắt đỏ mà hầu như không có dự án nào muốn sử dụng trên chuỗi khối.
Giai đoạn 1 tốc độ
Chứng minh số thứ tự không được chậm hơn hơn 100,000 lần so với việc thực thi nguyên bản (áp dụng cho nhiều ứng dụng không chỉ là chứng minh khối của Ethereum), và không nên phụ thuộc vào việc biên dịch trước.
Cụ thể hơn, giả sử một bộ xử lý RISC-V trên một máy tính xách tay hiện đại chạy ở tốc độ khoảng 30 tỷ chu kỳ/giây, vậy nghĩa là đạt giai đoạn 1 có nghĩa là máy tính xách tay đó có thể tạo ra chứng minh với tốc độ 30.000 chu kỳ RISC-V/giây (một luồng).
Chi phí của máy xác minh phải đáp ứng tiêu chuẩn "Chi phí xác minh hợp lý không tầm thường" được xác định trước đó.
Giai đoạn 2 tốc độ
Chứng minh đơn luồng không được chậm hơn so với thực thi nguyên bản hơn 10,000 lần.
Hoặc, do hạn chế về CPU và GPU hiện tại, có thể sử dụng FPGA (hoặc thậm chí ASIC) để thỏa mãn giai đoạn này nhờ một số phương pháp SNARK triển vọng (đặc biệt là SNARK trên trường nhị phân).
Tính số lõi RISC-V được mô phỏng bằng tốc độ nguyên thuỷ của FPGA.
Tính toán mô phỏng và chứng minh số lượng FPGA cần thiết để thực hiện RISC-V (gần thời gian thực).
Nếu số lượng của (2) không vượt quá 10,000 lần (1), thì đạt được giai đoạn 2.
• Kích thước chứng minh：Tối đa 256 KB。
• Thời gian xác minh : tối đa 16 miligiây trên CPU tiêu chuẩn.
Giai đoạn 3 tốc độ
Đạt được chi phí chứng minh trong vòng 1000× trên Giai đoạn Tốc độ 2 (cho một loạt các ứng dụng) và phải sử dụng biên dịch trước để tổng hợp tự động và 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 độ tạo bằng chứng, nhưng nó phải dễ sử dụng và được xác minh chính thức. (Xem phần tiếp theo về 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 soạn "viết tay" không phải là một cách tiếp cận bền vững.) ）
Giai đoạn 1 Bộ nhớ
Trong vòng 2 GB bộ nhớ để đạt đượcgiai đoạn tốc độ 1 và đồng thời đáp ứng yêu cầuzero knowledge. Giai đoạn này quan trọng đối vớithiết bị di động hoặc trình duyệt, và mở ra cánh cửa chonhiều trường hợp sử dụng zkVM trên phía máy khách. Ví dụ, điện thoại thông minh được sử dụng choquyền riêng tư vị trí, giấy tờ tùy thân, v.v. Nếu việc tạo chứng minh đòi hỏi hơn 1-2 GB bộ nhớ, hầu hết thiết bị di động sẽ không thể chạy được.
Hai điểm quan trọng cần lưu ý:
Ngay cả khi là tính toán quy mô lớn (yêu cầu hàng ngàn tỷ chu kỳ CPU thực thi), hệ thống chứng minh cũng phải duy trì giới hạn bộ nhớ 2 GB, nếu không sẽ hạn chế tính ứng dụng.
Nếu chứng minh tốc độ cực kỳ chậm, việc giữ ngưỡng bộ nhớ 2 GB rất dễ dàng. Do đó, để giai đoạn bộ nhớ 1 có ý nghĩa, phải đạt được giai đoạn 1 với ngưỡng bộ nhớ 2 GB.
Giai đoạn 2 bộ nhớ
Trong trường hợp bộ nhớ dưới 200 MB đạt giai đoạn tốc độ 1 (tăng gấp 10 lần so với giai đoạn bộ nhớ 1).
Tại sao cần giảm xuống còn 200 MB? Hãy xem một kịch bản ngoài chuỗi khối: khi bạn truy cập trang web HTTPS, bạn sẽ tải xuống chứng nhận xác thực và mã chứng thực. Nếu trang web chuyển sang gửi các chứng chỉ này dưới dạng chứng minh zk, các trang web lớn có thể cần tạo ra ** hàng triệu chứng chỉ mỗi giây**. Nếu mỗi chứng chỉ cần 2 GB bộ nhớ, nhu cầu tài nguyên tính toán sẽ đạt đến ** cấp độ PB , rõ ràng là không thể. Do đó, việc giảm bộ nhớ tiếp tục là rất quan trọng đối với ** ứng dụng ngoài chuỗi khối.
**Viết sẵn: Một dặm cuối cùng, vẫn là cái nạng?
Việc biên soạn trước đề cập đến hệ thống ràng buộc SNARK được tối ưu hóa đặc biệt cho các chức năng cụ thể (như băm, chữ ký đường cong elliptic). Trong Ethereum, việc biên soạn trước giúp giảm chi phí của Merkle hash và xác minh chữ ký, nhưng phụ thuộc quá mức vào việc biên soạn trước không thực sự cải thiện hiệu suất cốt lõi của SNARK.
Vấn đề được biên soạn trước
1. Vẫn quá chậm: Ngay cả khi sử dụng tiền mã hóa và chữ ký được biên soạn trước, zkVM vẫn gặp vấn đề hiệu suất lõi trong hệ thống chứng minh cốt lõi bên trong và bên ngoài chuỗi khối.
2. Lỗ hổng an ninh: Nếu việc viết trước không được xác minh hình thức, hầu như chắc chắn sẽ tồn tại lỗ hổng, có thể dẫn đến thất bại an ninh thảm họa.
3. Trải nghiệm phát triển kém: Hiện tại, nhiều zkVM cần phải viết thủ công hệ thống ràng buộc, giống như cách lập trình vào thập niên 1960, ảnh hưởng nghiêm trọng đến trải nghiệm phát triển.
4. Sự đánh lừa trong kiểm tra cơ sở：Nếu kiểm tra cơ sở phụ thuộc vào việc tối ưu hóa cụ thể trước biên dịch, 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 thiết kế SNARK chính nó.
5. Chi phí I/O và truy cập không RAM Mặc dù việc biên dịch trước có thể cải thiện hiệu suất của 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 có ý nghĩa cho các tải công việc đa dạng hơn vì chúng tạo ra chi phí lớn khi truyền đầu vào/ra và chúng không thể sử dụng RAM.
Ngay cả trong môi trường blockchain, nếu bạn vượt qua các L1 đơn lẻ như Ethereum (ví dụ, bạn muốn xây dựng một loạt cầu nối qua các chuỗi khác nhau), bạn sẽ đối mặt với các hàm băm và các phương pháp chữ ký khác nhau. Để giải quyết vấn đề này mà không ngừng tiến hành biên dịch trước, điều này không chỉ không mở rộng được mà còn mang lại rủi ro bảo mật lớn.
Tôi thực sự tin rằng việc biên soạn trước là quan trọng trong tương lai, nhưng chỉ khi chúng tự động tổng hợp và được xác minh chính thức sau đó mới như vậy. Điều này giúp duy trì lợi thế trải nghiệm của nhà phát triển zkVM, đồng thời tránh xa rủi ro bảo mật thảm họa. Quan điểm này được phản ánh trong giai đoạn 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 trong vòng hai năm tới, chúng ta cũng có thể đạt được giai đoạn tốc độ 2, 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 mà không cần có hướng nghiên cứu mới hay không.
Tôi dự đoán rằng các giai đoạn còn lại (Giai đoạn Tốc độ 3 và Bộ nhớ 2) sẽ cần mất vài năm nữa mới có thể đạt được.
Mặc dù bài viết này liệt kê riêng biệt giai đoạn an toàn và hiệu suất của zkVM, nhưng hai điều này không hoàn toàn độc lập. Khi các lỗi trong zkVM liên tục được phát hiện, tôi dự đoán việc sửa chữa một số lỗi sẽ không thể tránh khỏi dẫn đến giảm hiệu suất đáng kể. Do đó, kết quả kiểm thử hiệu suất của zkVM trước khi đạt Giai đoạn An toàn 2 nên được xem xét là dữ liệu tạm thời.
zkVM có tiềm năng lớn trong việc thúc đẩy sự phổ biến thực sự của chứng minh không cần biết, nhưng hiện nay vẫn đang ở giai đoạn sớm - đầy thách thức về an ninh và có những hạn chế nghiêm trọng về hiệu suất. Sự quảng bá và tiếp thị thị trường làm cho việc đo lường tiến triển thực sự trở nên khó khăn. Tôi hy vọng cung cấp một lộ trình có thể xua tan sương mù thông qua các mốc an ninh và hiệu suất rõ ràng. Chúng ta sẽ đạt được mục tiêu cuối cùng, nhưng điều này cần thời gian và nỗ lực liên tục trong nghiên cứu và kỹ thuật.