Vitalik: Tương lai của các loại ZK-EVM khác nhau
Tuyển chọn TechFlowTuyển chọn TechFlow
Vitalik: Tương lai của các loại ZK-EVM khác nhau
hy vọng nhiều hơn có thể thông qua việc cải tiến ZK-EVM và cải thiện bản thân Ethereum để làm cho nó phù hợp hơn với ZK-Snark, Ethereum không cần phải chuẩn hóa một triển khai ZK-EVM duy nhất được sử dụng cho L1.
Chuyên sâu báo cáo Web3Tác giả: Vitalik
Biên dịch: Block unicorn, Foresight News
Gần đây có rất nhiều dự án "ZK-EVM" công bố một cách ồn ào. Polygon đã mở rộng dự án ZK-EVM của họ, ZKSync công bố kế hoạch ZKSync 2.0, và Scroll - một dự án tương đối mới gần đây cũng phát hành ZK-EVM của mình. Ngoài ra còn có những nỗ lực liên tục từ nhóm Privacy and Scaling Explorations, nhóm của Nicolas Liochon, v.v., với trình biên dịch alpha từ EVM sang ngôn ngữ thân thiện với zk của Starkware là Cairo, và tất nhiên sẽ có một vài dự án mà tôi bỏ lỡ.
Mục tiêu cốt lõi của tất cả các dự án này đều giống nhau: sử dụng công nghệ ZK-SNARK để tạo bằng chứng mật mã cho việc thực thi giao dịch kiểu Ethereum, nhằm mục đích hoặc giúp xác minh chuỗi Ethereum dễ dàng hơn, hoặc xây dựng một zk rollup có khả năng mở rộng cao hơn nhưng cung cấp nội dung gần giống như Ethereum. Tuy nhiên, giữa các dự án này tồn tại những khác biệt tinh tế, cũng như sự đánh đổi giữa tính thực tiễn và tốc độ. Bài viết này sẽ cố gắng mô tả phân loại về các "loại" khác nhau của sự tương đương EVM, cùng với lợi ích và chi phí khi cố gắng đạt được từng loại.
Tổng quan (dưới dạng biểu đồ)
Loại 1 (tương đương hoàn toàn với Ethereum)
ZK-EVM Loại 1 hướng tới sự tương đương hoàn toàn và không khoan nhượng với Ethereum. Chúng không thay đổi bất kỳ phần nào của hệ thống Ethereum để làm cho việc tạo bằng chứng dễ dàng hơn. Chúng không thay thế hàm băm, cây trạng thái, cây giao dịch, precompile hay bất kỳ logic đồng thuận nào khác, dù chỉ là phần ngoại vi.
Lợi thế: Tương thích hoàn hảo
Mục tiêu là có thể xác minh khối Ethereum như hiện tại, hoặc ít nhất là xác minh tầng thực thi (do đó, logic đồng thuận Beacon Chain không bao gồm, nhưng tất cả việc thực thi giao dịch, logic hợp đồng thông minh và tài khoản đều được bao gồm).
ZK-EVM Loại 1 là thứ chúng ta cuối cùng cần để làm cho bản thân lớp 1 Ethereum có khả năng mở rộng tốt hơn. Về lâu dài, những sửa đổi đối với Ethereum được thử nghiệm trong ZK-EVM Loại 2 hoặc Loại 3 có thể được đưa vào chính Ethereum, nhưng thiết kế lại như vậy đi kèm với độ phức tạp riêng của nó.
ZK-EVM Loại 1 cũng là lựa chọn lý tưởng cho rollup vì chúng cho phép tái sử dụng lượng lớn cơ sở hạ tầng. Ví dụ, các client thực thi Ethereum có thể được dùng nguyên样 để tạo và xử lý khối ROLLUP (hoặc ít nhất, một khi chức năng rút tiền được triển khai, chúng có thể được tái sử dụng, và chức năng này có thể được tận dụng để hỗ trợ ETH gửi vào ROLLUP), do đó các công cụ như block explorer, sản xuất khối, v.v. rất dễ dàng tái sử dụng.
Nhược điểm: Thời gian xác minh
Ethereum ban đầu không được thiết kế theo hướng thân thiện với zk, nên nhiều phần của giao thức Ethereum đòi hỏi lượng tính toán lớn để xác minh zk. Mục tiêu của Loại 1 là sao chép hoàn toàn Ethereum, do đó không thể giảm thiểu những hiệu quả kém này. Hiện tại, việc tạo bằng chứng cho một khối Ethereum mất nhiều giờ. Tình trạng này có thể được cải thiện nhờ kỹ thuật tinh vi để song song hóa mạnh mẽ trình xác minh, hoặc về lâu dài, thông qua mạch tích hợp chuyên dụng cho ZK-SNARK.
Ai đang xây dựng?
Đội ngũ Privacy and Scaling Explorations đang xây dựng ZK-EVM Loại 1.
Loại 2 (tương đương hoàn toàn với EVM)
ZK-EVM Loại 2 hướng đến sự 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à, "bên trong" chúng trông giống hệt Ethereum, nhưng ở bên ngoài có một số khác biệt, đặ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à đảm bảo tương thích hoàn toàn với các ứng dụng hiện có, nhưng tiến hành một vài chỉnh sửa nhỏ đối với Ethereum để việc phát triển dễ dàng hơn và tạo bằng chứng nhanh hơn.
Lợi thế: Đạt được sự tương đương hoàn toàn ở cấp độ máy ảo
ZK-EVM Loại 2 thay đổi các cấu trúc dữ liệu lưu trữ trạng thái Ethereum, v.v. May mắn thay, những cấu trúc này không thể truy cập trực tiếp bởi chính EVM, do đó các ứng dụng hoạt động trên Ethereum hầu như luôn hoạt động trên rollup ZK-EVM Loại 2. Bạn sẽ không thể dùng nguyên bản các client thực thi Ethereum, nhưng bạn có thể dùng chúng với một vài sửa đổi, và vẫn có thể dùng công cụ gỡ lỗi EVM cũng như phần lớn cơ sở hạ tầng nhà phát triển khác.
Tuy nhiên, vẫn có một vài ngoại lệ. Một sự không tương thích xuất hiện đối với các ứng dụng xác minh các tuyên bố về giao dịch lịch sử, biên lai hoặc trạng thái bằng cách sử dụng bằng chứng Merkle từ các khối Ethereum trước đó (ví dụ, cầu nối đôi khi làm điều này). Một ZK-EVM thay thế Keccak bằng 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 ứng dụng theo cách này, vì những thay đổi tương lai của Ethereum (ví dụ, Cây Verkle) thậm chí sẽ phá vỡ các ứng dụng như vậy ngay cả trên chính Ethereum. Một giải pháp thay thế tốt hơn cho Ethereum là thêm precompile hỗ trợ truy cập lịch sử đáng tin cậy trong tương lai.
Nhược điểm: Thời gian xác minh được cải thiện nhưng vẫn chậm
ZK-EVM Loại 2 cung cấp thời gian xác minh nhanh hơn so với Loại 1, chủ yếu bằng cách loại bỏ các phần của ngăn xếp Ethereum phụ thuộc vào mật mã phức tạp và không thân thiện với zk. Cụ thể, chúng có thể thay đổi Keccak của Ethereum và cây Merkle Patricia dựa trên RLP, và có thể cả cấu trúc khối và biên nhận. ZK-EVM Loại 2 có thể sử dụng hàm băm khác, ví dụ Poseidon. Một sửa đổi tự nhiên khác là sửa đổi cây trạng thái để lưu trữ băm mã và keccak, do đó không cần xác minh băm để xử lý các opcode EXTCODEHASH và EXTCODECOPY.
Những thay đổi này cải thiện đáng kể thời gian xác minh, nhưng không thể giải quyết mọi vấn đề. Do sự kém hiệu quả vốn có và tính chất không thân thiện với zk của EVM, việc chứng minh EVM nguyên bản 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, bao gồm cả các khối "không căn chỉnh" (bắt đầu và kết thúc không phải bội số của 32), MLOAD không thể đơn giản được hiểu 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 thao tác bit để hợp nhất kết quả.
Ai đang 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. Tuy nhiên, cả hai dự án này đều chưa hoàn thành (chưa hoàn thành công việc ZKEVM); đặc biệt, nhiều precompile phức tạp hơn vẫn chưa được triển khai. Vì vậy, hiện tại cả hai dự án đều nên được xem xét ở Loại 3.
Loại 2.5 (tương đương với EVM, trừ phí gas)
Một cách để cải thiện đáng kể thời gian xác minh trường hợp xấu nhất là tăng mạnh chi phí gas đối với các thao tác cụ thể khó chứng minh trong EVM. Điều này có thể liên quan đến precompile, opcode KECCAK, và có thể cả quy ước gọi hoặc các mẫu truy cập bộ nhớ, lưu trữ hoặc khôi phục.
Việc thay đổi chi phí gas có thể làm giảm tính tương thích với công cụ phát triển và làm hỏng một số ứng dụng, nhưng thường được coi là rủi ro thấp hơn so với những thay đổi "sâu hơn" đối với EVM. Các nhà phát triển nên lưu ý rằng không nên yêu cầu lượng gas vượt quá dung lượng khối trong giao dịch, và không nên sử dụng số lượng gas cứng nhắc khi gọi (đây đã là lời khuyên tiêu chuẩn dành cho nhà phát triển trong thời gian dài).
Loại 3 (gần như tương đương với EVM)
ZK-EVM Loại 3 gần như tương đương với EVM, nhưng phải hy sinh một số điều để đạt được sự tương đương hoàn toàn, nhằm cải thiện thêm thời gian xác minh và làm cho việc phát triển EVM dễ dàng hơn.
Lợi thế: 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 việc thực hiện ZK-EVM. Trong trường hợp này, precompile thường nằm ở đầu danh sách; ngoài ra, ZK-EVM Loại 3 đôi khi cũng có sự khác biệt tinh tế trong cách 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 hơn
Mục tiêu của ZK-EVM Loại 3 là tương thích với phần lớn các ứng dụng, phần còn lại chỉ cần viết lại tối thiểu. Tức là, một số ứng dụng cần viết lại, hoặc vì chúng sử dụng precompile bị loại bỏ bởi ZK-EVM Loại 3, hoặc vì phụ thuộc tinh vi vào các trường hợp cạnh mà EVM xử lý theo cách khác.
Ai đang xây dựng?
Scroll và Polygon ở dạng hiện tại đều là Loại 3, mặc dù theo thời gian, họ kỳ vọng cải thiện tính tương thích. Polygon có thiết kế độc đáo khi họ dùng ZK để xác minh ngôn ngữ nội bộ riêng zkASM, và dùng zkASM để triển khai trình thông dịch mã ZK-EVM. Mặc dù có chi tiết triển khai như vậy, tôi vẫn gọi nó là ZK-EVM Loại 3 thực sự; nó vẫn có thể xác minh mã EVM, chỉ là dùng logic nội bộ khác để hoàn thành.
Hiện nay, không có nhóm ZK-EVM nào muốn trở thành Loại 3; Loại 3 chỉ là giai đoạn chuyển tiếp cho đến khi công việc phức tạp thêm precompile hoàn thành và 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 các precompile thân thiện với ZK-SNARK mới, cung cấp cho nhà phát triển các chức năng với thời gian xác minh và chi phí gas thấp.
Loại 4 (tương đương ngôn ngữ cấp cao)
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 ngôn ngữ trung gian nào đó mà cả hai đều biên dịch sang), và biên dịch nó sang một ngôn ngữ được thiết kế rõ ràng để thân thiện với ZK-snark.
Lợi thế: Thời gian xác minh cực nhanh
Bằng cách không dùng ZK để chứng minh từng bước thực thi EVM khác nhau, và bắt đầu trực tiếp từ mã cấp cao hơn, có thể tránh được nhiều chi phí phát sinh.
Tôi chỉ mô tả lợi thế này bằng một câu trong bài viết này (so với danh sách dài các nhược điểm liên quan đến tương thích bên dưới), nhưng điều này không nên được hiểu là phán xét giá trị! Việc biên dịch trực tiếp từ ngôn ngữ cấp cao thực sự có thể giảm đáng kể chi phí và giúp phân quyền bằng cách làm cho việc trở thành người chứng minh dễ dàng hơn.
Nhược điểm: Nhiều sự không tương thích hơn
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 xuống và sẽ "hoạt động bình thường", nhưng có một số khía cạnh quan trọng khiến nhiều ứng dụng không "hoạt động bình thường":
- Địa chỉ của hợp đồng trong hệ thống Loại 4 có thể khác với địa chỉ trong EVM, vì địa chỉ thỏa thuận CREATE2 phụ thuộc vào chính xác bytecode. Điều này làm hỏng các ứng dụng dựa vào "hợp đồng phản thực tế" chưa được triển khai, ví ERC-4337, EIP-2470 singleton và nhiều ứng dụng khác.
- Bytecode EVM viết tay khó sử dụng hơn. Để nâng cao hiệu quả, nhiều ứng dụng sử dụng bytecode EVM viết tay ở một số phần. Hệ thống Loại 4 có thể không hỗ trợ điều này, mặc dù có một số cách để thực hiện hỗ trợ bytecode EVM giới hạn nhằm đáp ứng các trường hợp sử dụng này mà không cần nỗ lực trở thành một Type3ZK-EVM đầy đủ.
- Nhiều cơ sở hạ tầng gỡ lỗi không thể tiếp tục hoạt động vì chúng chạy trên bytecode EVM. Tuy nhiên, nhược điểm này được giảm nhẹ bằng cách truy cập cơ sở hạ tầng gỡ lỗi nhiều hơn từ ngôn ngữ cấp cao hoặc trung gian "truyền thống" (ví dụ, LLVM).
Các nhà phát triển nên lưu ý những vấn đề này.
Ai đang xây dựng?
ZKSync là một hệ thống Loại 4, mặc dù theo thời gian, nó có thể tăng tính tương thích với bytecode EVM. Dự án Warp của NetherMind đang xây dựng một trình biên dịch từ Solidity sang Cairo của Starkware, điều này sẽ biến StarkNet thành một hệ thống Loại 4 trên thực tế.
Tương lai của các loại ZK-EVM
Các loại này không rõ ràng là "tốt hơn" hoặc "kém hơn" các loại khác. Thay vào đó, chúng đại diện cho các điểm khác nhau trong không gian đánh đổi: các loại dễ mã hóa hơn thì tương thích tốt hơn với cơ sở hạ tầng hiện có, nhưng chậm hơn; các loại khó mã hóa hơn thì tương thích kém hơn với cơ sở hạ tầng hiện có, nhưng nhanh hơn. Nhìn chung, việc khám phá tất cả các loại này là lành mạnh cho lĩnh vực này.
- ZK-EVM có thể bắt đầu từ Loại 3, quyết định không bao gồm một số chức năng đặc biệt khó chứng minh bằng ZK. Sau đó, họ có thể thêm dần các chức năng này theo thời gian và chuyển sang Loại 2.
- ZK-EVM có thể bắt đầu từ Loại 2, sau đó trở thành ZK-EVM hỗn hợp Loại 2/Loại 1 bằng cách cung cấp khả năng chạy ở chế độ tương thích toàn bộ Ethereum hoặc sử dụng cây trạng thái đã sửa đổi có thể chứng minh nhanh hơn. Sroll đang cân nhắc hướng đi này.
- Hệ thống bắt đầu từ Loại 4 có thể dần trở thành Loại 3 khi bổ sung khả năng xử lý mã EVM (mặc dù vẫn khuyến khích nhà phát triển biên dịch trực tiếp từ ngôn ngữ cấp cao để giảm phí và thời gian xác minh).
- Nếu bản thân Ethereum áp dụng các sửa đổi để nỗ lực trở nên thân thiện hơn với ZK, thì ZK-EVM Loại 2 hoặc Loại 3 có thể trở thành ZK-EVM Loại 1.
- ZK-EVM Loại 1 hoặc Loại 2 có thể trở thành ZK-EVM Loại 3 bằng cách thêm precompile để xác minh mã trong ngôn ngữ thân thiện với ZK-SNARK. Điều này sẽ cho phép nhà phát triển lựa chọn giữa tương thích Ethereum và tốc độ, điều này sẽ là Loại 3 vì nó phá vỡ sự tương đương hoàn hảo của EVM, nhưng về mục đích thực tế, nó sẽ có nhiều lợi ích của Loại 1 và Loại 2. Nhược điểm chính có thể là một số công cụ phát triển không hiểu precompile tùy chỉnh của ZK-EVM, mặc dù điều này có thể khắc phục được: các công cụ phát triển có thể thêm hỗ trợ precompile tổng quát bằng cách hỗ trợ định dạng cấu hình bao gồm các triển khai tương đương mã EVM cho precompile.
Theo cá nhân tôi, tôi hy vọng theo thời gian, mọi thứ sẽ trở thành Loại 1, thông qua việc cải thiện ZK-EVM và cải thiện bản thân Ethereum để phù hợp hơn với ZK-Snark. Trong tương lai như vậy, chúng ta sẽ có nhiều triển khai ZK-EVM, vừa dùng cho ZK rollup, vừa dùng để xác minh bản thân Ethereum. Về lý thuyết, Ethereum không cần chuẩn hóa một triển khai ZK-EVM duy nhất cho L1; các client khác nhau có thể dùng các bằng chứng khác nhau, do đó chúng ta tiếp tục hưởng lợi từ sự dư thừa mã.
Tuy nhiên, chúng ta cần một khoảng thời gian khá dài để đạt được tương lai như vậy. Trong lúc đó, chúng ta sẽ chứng kiến nhiều đổi mới trên các con đường khác nhau để mở rộng Ethereum và các ZK-rollup dựa trên Ethereum.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@VitalikButerin
