Vitalik: Tương lai của các loại ZK-EVM khác nhau
Tiêu đề ban đầu: "The different types of ZK-EVMs》
Tác giả gốc: Vitalik
Biên soạn gốc: Khối kỳ lân
Tiêu đề ban đầu: "
Tác giả gốc: Vitalik
Biên soạn gốc: Khối kỳ lân
Gần đây, đã có nhiều thông báo nổi tiếng về các dự án "ZK-EVM". Polygon đã mã nguồn mở dự án ZK-EVM của họ, ZKSync đã phát hành các gói ZKSync 2.0 của họ và Scroll tương đối mới gần đây đã phát hành ZK-EVM của họ. Ngoài ra còn có những nỗ lực không ngừng từ các nhóm Khám phá mở rộng và Quyền riêng tư, các nhóm của Nicolas Liochon và cộng sự, từ EVM đến trình biên dịch alpha cho ngôn ngữ thân thiện với zk của Starkware ở Cairo, và tất nhiên có một số dự án mà tôi sẽ bỏ lỡ.
Mục tiêu cốt lõi của tất cả các dự án này là giống nhau: sử dụng công nghệ ZK-SNARK để chứng minh bằng mật mã việc thực hiện giao dịch giống như Ethereum, giúp việc xác minh chính chuỗi Ethereum dễ dàng hơn hoặc xây dựng nội dung tương tự như những gì Ethereum cung cấp (gần hơn) nhưng hơn thế nữa cuộn zk có thể mở rộng. Nhưng có những khác biệt tinh tế giữa các dự án này và sự đánh đổi của chúng giữa tiện ích và tốc độ. Bài đăng này sẽ cố gắng mô tả phân loại các "loại" tương đương EVM khác nhau, cũng như lợi ích và chi phí của việc cố gắng triển khai từng loại.
Tổng quan (dạng sơ đồ)
Loại 1 (hoàn toàn tương đương với Ethereum)
Loại ZK-EVM đầu tiên cố gắng hoàn toàn tương đương với Ethereum. Họ không thay đổi bất kỳ phần nào của hệ thống Ethereum để giúp tạo bằng chứng dễ dàng hơn. Chúng không thay thế các giá trị băm, cây trạng thái, cây giao dịch, tiền biên dịch hoặc bất kỳ logic đồng thuận nào khác, bất kể nó ngoại vi như thế nào.
Ưu điểm: khả năng tương thích hoàn hảo
Mục tiêu của chúng tôi là có thể xác thực các khối Ethereum như chúng tôi hiện đang làm hoặc ít nhất là lớp thực thi (vì vậy không bao gồm logic đồng thuận chuỗi đèn hiệu, nhưng bao gồm tất cả thực thi giao dịch, hợp đồng thông minh và logic tài khoản).
Loại 1: ZK-EVM là thứ cuối cùng chúng ta cần để làm cho bản thân lớp Ethernet 1 có khả năng mở rộng hơn. Về lâu dài, các sửa đổi đối với ether đã được thử nghiệm trong ZK-EVM loại 2 hoặc loại 3 có thể được đưa vào chính ether, nhưng thiết kế lại như vậy đi kèm với sự phức tạp của chính nó.
Loại 1: ZK-EVM cũng lý tưởng cho các bản tổng hợp, vì chúng cho phép các bản tổng hợp sử dụng lại nhiều cơ sở hạ tầng. Ví dụ: ứng dụng khách Thực thi Etherum có thể được sử dụng nguyên trạng để tạo và xử lý các khối ROLLUP (hoặc ít nhất, chúng có thể được sử dụng lại sau khi triển khai tìm nạp và chức năng đó có thể được sử dụng lại để hỗ trợ tiền gửi ETH vào ROLLUP), do đó, các tài nguyên khối Các công cụ như trình quản lý, sản xuất khối, v.v. rất dễ sử dụng lại.
Nhược điểm: thời gian xác minh
Ethereum ban đầu không được thiết kế dựa trên sự thân thiện với zk, vì vậy nhiều phần của giao thức ethereum yêu cầu rất nhiều tính toán để xác minh zk. Loại 1 nhằm mục đích sao chép chính xác Ethereum, vì vậy nó không có cách nào để giảm thiểu những điểm kém hiệu quả này. Hiện tại, bằng chứng về khối Ethereum mất nhiều giờ để tạo. Tình trạng này có thể được giảm thiểu bằng kỹ thuật thông minh để song song hóa ồ ạt trình xác minh hoặc về lâu dài bằng ASIC ZK-SNARK.
Ai là người xây dựng?
Nhóm Khám phá Quyền riêng tư và Mở rộng Quy mô ZK-EVM đang xây dựng ZK-EVM Loại 1.
Loại 2 (tương đương hoàn toàn EVM)
Loại ZK thứ hai - EVM cố gắng tương đương hoàn toàn với EVM, nhưng không hoàn toàn tương đương với Ethereum. Nghĩa là, chúng trông giống hệt Ethereum "từ bên trong", nhưng chúng có một số khác biệt ở bên ngoài, đặc biệt là về cấu trúc dữ liệu như cấu trúc khối và cây trạng thái.
Mục tiêu là tương thích hoàn toàn với các ứng dụng hiện có, nhưng với những sửa đổi nhỏ đối với Ethereum để giúp việc phát triển dễ dàng hơn và tạo ra bằng chứng nhanh hơn.
Ưu điểm: Hoàn toàn ngang hàng ở cấp độ máy ảo
ZK-EVM loại 2 thực hiện các thay đổi đối với cấu trúc dữ liệu chứa những thứ như trạng thái của ether. May mắn thay, bản thân EVM không thể truy cập trực tiếp các cấu trúc này, vì vậy các ứng dụng hoạt động trên Ethereum hầu như sẽ luôn hoạt động trên các bản tổng hợp ZK-EVM Loại 2. Bạn sẽ không thể sử dụng các ứng dụng khách Etherum Execution nguyên trạng, nhưng bạn có thể sử dụng chúng với một số sửa đổi và bạn sẽ vẫn có quyền truy cập vào các công cụ sửa lỗi EVM và hầu hết cơ sở hạ tầng dành cho nhà phát triển khác.
Nhưng có một vài trường hợp ngoại lệ. Sự không tương thích phát sinh đối với các ứng dụng xác minh bằng chứng Merkle về các khối ether lịch sử để xác minh các khiếu nại về các giao dịch, biên lai hoặc trạng thái lịch sử (ví dụ: đôi khi cầu làm điều này). Việc thay thế ZK-EVM của Keccak bằng một hàm băm khác sẽ phá vỡ các bằng chứng này. Tuy nhiên, tôi thường khuyên không nên xây dựng các ứng dụng theo cách này, vì những thay đổi ether trong tương lai (chẳng hạn như Verkle Trees) có thể phá vỡ các ứng dụng như vậy ngay cả trên chính ether. Một giải pháp thay thế tốt hơn cho bản thân Ethereum là bổ sung tính năng biên dịch trước truy cập lịch sử đáng tin cậy trong tương lai.
Nhược điểm: Cải thiện thời gian xác thực, nhưng vẫn còn chậm
ZK-EVM loại 2 cung cấp thời gian xác minh nhanh hơn Loại 1, chủ yếu bằng cách loại bỏ các phần của ngăn xếp Ethereum dựa trên mã hóa ZK phức tạp và không thân thiện không cần thiết. Đặc biệt, họ có thể thay đổi cây Merkle Patricia dựa trên RLP và Keccak của Ethereum, đồng thời có thể chặn và nhận các cấu trúc. ZK-EVM loại 2 có thể sử dụng một hàm băm khác, chẳng hạn như Poseidon. Một sửa đổi tự nhiên khác là sửa đổi cây trạng thái để lưu trữ mã băm và keccak, do đó, mã băm xác minh không còn cần thiết để xử lý mã lệnh EXTCODEHASH và EXTCODECOPY.
Những sửa đổi này cải thiện đáng kể thời gian xác minh, nhưng chúng không giải quyết được mọi vấn đề. Do tính kém hiệu quả vốn có và tính không thân thiện với zk của EVM, quá trình chứng minh EVM nguyên trạng vẫn còn chậm. Một ví dụ đơn giản là bộ nhớ: vì MLOAD có thể đọc bất kỳ khối 32 byte nào, kể cả các khối "không được phân bổ" (trong đó bắt đầu và kết thúc không phải là bội số của 32), MLOAD không thể được hiểu đơn giản là đọc một khối; thay vào đó, nó có thể cần đọc hai khối liên tiếp và thực hiện các thao tác bit để kết hợp các kết quả.
Ai là người xây dựng?
Dự án ZK-EVM của Scroll đang hướng tới ZK-EVM Loại 2, cũng như Polygon Hermez. Điều đó nói rằng, không có dự án nào kết thúc (công việc ZKEVM chưa hoàn thành); đặc biệt, nhiều phần biên dịch trước phức tạp hơn vẫn chưa được triển khai. Do đó, loại 3 được xem xét tốt nhất cho cả hai dự án tại thời điểm này.
Loại 2.5 (tương đương với EVM, không bao gồm chi phí gas)
Một cách để cải thiện đáng kể thời gian xác minh trong trường hợp xấu nhất là tăng đáng kể chi phí chung của một số hoạt động khó chứng minh trong EVM. Điều này có thể liên quan đến tiền biên dịch, mã KECCAK, nhưng cũng có thể gọi các quy ước hoặc chế độ truy cập bộ nhớ, lưu trữ hoặc khôi phục cụ thể.
Thay đổi chi phí gas có thể làm giảm khả năng tương thích của công cụ dành cho nhà phát triển và làm hỏng một số ứng dụng, nhưng thường được coi là ít rủi ro hơn so với các thay đổi EVM "sâu hơn". Các nhà phát triển nên cẩn thận để không yêu cầu nhiều gas trong giao dịch hơn khả năng của khối và không thực hiện cuộc gọi với số tiền phí gas được mã hóa cứng (đây là lời khuyên tiêu chuẩn cho các nhà phát triển trong một thời gian dài).
Loại 3 (gần tương đương với EVM)
ZK-EVM loại 3 gần như tương đương với EVM, nhưng để đạt được điều tương tự, cần phải hy sinh một số điều để cải thiện hơn nữa thời gian xác minh và giúp EVM dễ phát triển hơn.
Ưu điểm: Dễ xây dựng hơn, thời gian xác minh nhanh hơn
ZK-EVM loại 3 có thể loại bỏ một số tính năng đặc biệt khó triển khai trong triển khai ZK-EVM. Ở đây, tiền biên dịch thường ở đầu danh sách; hơn nữa, ZK-EVM Loại 3 đôi khi có những khác biệt tinh tế trong cách chúng xử lý mã hợp đồng, bộ nhớ hoặc ngăn xếp.
Nhược điểm: nhiều sự không tương thích
ZK-EVM Loại 3 nhằm mục đích tương thích với hầu hết các ứng dụng và yêu cầu viết lại phần còn lại ở mức tối thiểu. Điều đó nói rằng, một số ứng dụng cần phải được viết lại, bởi vì chúng sử dụng tiền biên dịch mà ZK-EVM Loại 3 loại bỏ hoặc do sự phụ thuộc tinh vi vào các trường hợp cạnh được EVM xử lý khác nhau.
Ai là người xây dựng?
Cuộn và Đa giác đều là loại 3 ở dạng hiện tại, mặc dù chúng được mong đợi sẽ cải thiện khả năng tương thích theo thời gian. Đa giác có thiết kế độc đáo, họ sử dụng ZK để xác minh ngôn ngữ nội bộ zkASM của riêng họ và sử dụng triển khai zkASM để diễn giải mã ZK-EVM. Bất chấp chi tiết triển khai này, tôi vẫn gọi nó là Type3ZK-EVM thực sự; nó vẫn có thể xác minh mã EVM, nó chỉ sử dụng một số logic bên trong khác để làm như vậy.
Ngày nay, không nhóm ZK-EVM nào muốn trở thành Loại 3; Loại 3 chỉ là một giai đoạn chuyển tiếp cho đến khi công việc phức tạp bổ sung tiền biên dịch hoàn tất và các dự án có thể chuyển sang Loại 2.5. Tuy nhiên, trong tương lai, ZK-EVM Loại 1 hoặc Loại 2 có thể tự nguyện trở thành ZK-EVM Loại 3 bằng cách thêm một trình biên dịch trước thân thiện với ZK-SNARK mới cung cấp cho các nhà phát triển các tính năng về chi phí gas và thời gian xác minh thấp.
Loại 4 (tương đương ngôn ngữ bậc cao)
Các hệ thống loại 4 hoạt động bằng cách lấy mã nguồn hợp đồng thông minh được viết bằng ngôn ngữ cấp cao (ví dụ: SOLIDITY, VYPER hoặc một số ngôn ngữ trung gian mà cả hai đều biên dịch thành) và biên dịch nó thành một loại ngôn ngữ được thiết kế rõ ràng để trở thành ngôn ngữ thân thiện với ZK-snark.
Ưu điểm: Thời gian xác minh rất nhanh
Bằng cách không sử dụng ZK để chứng minh tất cả các phần khác nhau của từng bước thực thi EVM và bắt đầu trực tiếp từ mã cấp cao hơn, có thể tránh được rất nhiều chi phí.
Tôi mô tả ưu điểm này trong một câu trong bài đăng này (so với danh sách lớn các nhược điểm liên quan đến khả năng tương thích được gạch đầu dòng bên dưới), nhưng điều này không nên được hiểu là một đánh giá về giá trị! Biên dịch trực tiếp từ một ngôn ngữ cấp cao thực sự có thể giảm đáng kể chi phí và giúp phân cấp bằng cách làm cho việc trở thành một người chứng minh dễ dàng hơn.
Nhược điểm: nhiều sự không tương thích
Một ứng dụng "bình thường" được viết bằng Vyper hoặc Solidity có thể được biên dịch và nó sẽ "hoạt động bình thường", nhưng có một số khía cạnh quan trọng mà nhiều ứng dụng không "chỉ hoạt động":
Địa chỉ của hợp đồng trong hệ thống loại 4 có thể khác với địa chỉ của chúng trong EVM, vì địa chỉ hợp đồng CREATE2 phụ thuộc vào mã byte chính xác. Điều này phá vỡ các ứng dụng phụ thuộc vào "hợp đồng đối chứng", ví ERC-4337, đĩa đơn EIP-2470 và nhiều ứng dụng khác chưa được triển khai.
Mã byte EVM viết tay khó làm việc hơn. Để đạt hiệu quả, nhiều ứng dụng sử dụng mã byte EVM viết tay cho một số phần. Các hệ thống Loại 4 có thể không hỗ trợ nó, mặc dù có nhiều cách để triển khai hỗ trợ mã byte EVM hạn chế nhằm đáp ứng các trường hợp sử dụng này mà không cần cố gắng trở thành ZK-EVM Loại 3 đầy đủ.
Phần lớn cơ sở hạ tầng gỡ lỗi không thể tiếp tục vì nó chạy trên mã byte EVM. Điều đó nói rằng, thiếu sót này được giảm thiểu bằng cách truy cập cơ sở hạ tầng gỡ lỗi nhiều hơn từ các ngôn ngữ trung cấp hoặc cấp cao "truyền thống" (ví dụ: LLVM).
Các nhà phát triển nên nhận thức được những vấn đề này.
Ai là người xây dựng?
ZKSync là hệ thống loại 4, mặc dù theo thời gian, nó có thể tăng khả năng tương thích với mã byte EVM. Dự án Warp của NetherMind đang xây dựng một trình biên dịch Cairo từ Solidity sang Starkware, sẽ biến StarkNet thành một hệ thống Loại 4 trên thực tế.
Tương lai của một số loại ZK-EVM
Những loại này không rõ ràng là "tốt hơn" hoặc "tệ hơn" so với những loại khác. Thay vào đó, chúng là những điểm khác biệt trong không gian đánh đổi: các loại ít khó viết mã hơn thì tương thích hơn với cơ sở hạ tầng hiện có, nhưng chậm hơn; các loại khó viết mã hơn thì ít tương thích hơn với cơ sở hạ tầng hiện có, nhưng nhanh hơn. Nhìn chung, tất cả những kiểu người này đều đang khám phá, điều này có lợi cho lĩnh vực này.
ZK-EVM có thể bắt đầu với loại 3, quyết định không bao gồm một số tính năng đặc biệt khó chứng minh ZK. Sau đó, họ có thể thêm các tính năng này theo thời gian và chuyển sang Loại 2.
ZK-EVM có thể bắt đầu dưới dạng Loại 2 và sau đó trở thành ZK-EVM Loại 2/Loại 1 kết hợp bằng cách cung cấp khả năng chạy ở chế độ tương thích Ethernet đầy đủ hoặc sử dụng cây trạng thái đã sửa đổi có thể được chứng minh nhanh hơn. Sroll đang xem xét di chuyển theo hướng này.
Các hệ thống bắt đầu với Loại 4 có thể trở thành Loại 3 theo thời gian vì khả năng xử lý mã EVM được thêm vào sau này (mặc dù các nhà phát triển vẫn được khuyến khích biên dịch trực tiếp từ các ngôn ngữ cấp cao để giảm chi phí và thời gian xác minh).
Cá nhân tôi mong rằng theo thời gian, mọi thứ sẽ trở thành Loại 1, bằng cách cải tiến ZK-EVM và cải tiến chính Ethereum để nó phù hợp hơn với ZK-Snark. Trong tương lai như vậy, chúng tôi sẽ có nhiều triển khai ZK-EVM, cho cả các bản tổng hợp ZK và để xác thực chính Ethereum. Về lý thuyết, Ethereum không cần phải chuẩn hóa trên một triển khai ZK-EVM duy nhất được sử dụng bởi L1; các khách hàng khác nhau có thể sử dụng các bằng chứng khác nhau, vì vậy chúng tôi tiếp tục hưởng lợi từ dự phòng mã.
