Vitalik: Tương lai của các loại ZK-EVM khác nhau

Tiêu đề gốc: 《Các loại ZK-EVM khác nhau》

Tác giả: Vitalik

Biên dịch: Block unicorn, Foresight News

Gần đây có nhiều dự án "ZK-EVM" công bố thông báo một cách rầm rộ. Polygon đã mở ra dự án ZK-EVM của họ, ZKSync đã công bố kế hoạch ZKSync 2.0, và dự án tương đối mới là Scroll cũng đã công bố ZK-EVM của họ. Còn có những nỗ lực liên tục từ các đội ngũ khám phá về quyền riêng tư và mở rộng, như đội ngũ của Nicolas Liochon, từ trình biên dịch alpha ngôn ngữ thân thiện với zk từ EVM đến Starkware, tất nhiên có một số dự án mà tôi có thể đã bỏ lỡ.

Tất cả những dự án này có mục tiêu cốt lõi giống nhau: sử dụng công nghệ ZK-SNARK để tạo ra chứng minh mã hóa cho việc thực hiện giao dịch tương tự như Ethereum, hoặc làm cho việc xác minh chuỗi Ethereum trở nên dễ dàng hơn, hoặc xây dựng zk rollup có khả năng mở rộng cao hơn nhưng cung cấp nội dung (gần như) tương tự như Ethereum. Nhưng giữa các dự án này có 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 các "loại" khác nhau của tính tương đương EVM, cũng như cố gắng thực hiện lợi ích và chi phí của mỗi loại.

Tổng quan (dưới dạng biểu đồ)

Loại 1 (hoàn toàn tương đương với Ethereum)

Loại ZK-EVM đầu tiên cố gắng đạt được sự tương đương hoàn toàn và không thỏa hiệp 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 ra chứng minh dễ dàng hơn. Chúng sẽ không thay thế hàm băm, cây trạng thái, cây giao dịch, các hàm tiền biên hay bất kỳ logic đồng thuận nào khác, bất kể nó có bao nhiêu phần ngoại vi.

Ưu điểm: Tính tương thích hoàn hảo

Mục tiêu của chúng tôi là có thể xác minh các khối Ethereum như hiện tại, hoặc ít nhất là xác minh lớp thực thi (do đó, logic đồng thuận của chuỗi beacon không bao gồm, nhưng bao gồm tất cả các thực thi giao dịch và logic hợp đồng thông minh và tài khoản).

Loại 1: ZK-EVM là điều mà chúng tôi cuối cùng cần, để làm cho lớp 1 của Ethereum trở nên có khả năng mở rộng hơn. Về lâu dài, những sửa đổi đối với Ethereum được thử nghiệm trong loại 2 hoặc loại 3 ZK-EVM có thể được đưa vào Ethereum bản thân, nhưng việc thiết kế lại như vậy đi kèm với sự phức tạp riêng của nó.

Loại 1: ZK-EVM cũng là lựa chọn lý tưởng cho việc tổng hợp, vì chúng cho phép tái sử dụng một lượng lớn cơ sở hạ tầng. Ví dụ, khách hàng thực thi Etherum có thể được sử dụng như hiện tại để tạo ra và xử lý các khối ROLLUP (hoặc ít nhất, một khi việc trích xuất được thực hiện, chúng có thể được tái sử dụng, và chức năng đó có thể được tái sử dụng để hỗ trợ việc lưu trữ ETH vào ROLLUP), do đó các công cụ như trình quản lý tài nguyên khối, sản xuất khối rất dễ tái sử dụng.

Nhược điểm: Thời gian xác minh

Ethereum ban đầu không được thiết kế với sự thân thiện với zk, vì vậy nhiều phần của giao thức Ethereum cần phải thực hiện rất nhiều tính toán để xác minh zk. Mục tiêu của loại 1 là sao chép hoàn toàn Ethereum, vì vậy nó không có cách nào để giảm thiểu những sự không hiệu quả này. Hiện tại, việc chứng minh khối Ethereum cần nhiều giờ để tạo ra. Tình huống này có thể được giảm thiểu bằng cách kỹ thuật khéo léo để xác minh song song quy mô lớn, hoặc về lâu dài, có thể được giảm thiểu bằng cách sử dụng mạch tích hợp chuyên dụng cho ZK-SNARK.

Người xây dựng là ai?

Đội ngũ khám phá quyền riêng tư và mở rộng ZK-EVM đang xây dựng loại 1 ZK-EVM.

Loại 2 (hoàn toàn tương đương EVM)

Loại ZK-EVM thứ hai cố gắng đạt được 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. Nói cách khác, chúng "trông giống như Ethereum từ bên trong", 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 của nó là hoàn toàn tương thích với các ứng dụng hiện có, nhưng thực hiện một số sửa đổi nhỏ đối với Ethereum để làm cho việc phát triển dễ dàng hơn và tạo ra chứng minh nhanh hơn.

Ưu điểm: Thực hiện hoàn toàn tương đương ở cấp độ máy ảo

Loại 2 ZK-EVM thực hiện các thay đổi đối với cấu trúc dữ liệu như lưu trữ trạng thái Ethereum. May mắn thay, những cấu trúc này không thể được EVM truy cập trực tiếp, vì vậy các ứng dụng hoạt động trên Etherum gần như luôn hoạt động trên tổng hợp loại 2 ZK-EVM. Bạn sẽ không thể sử dụng khách hàng thực thi Etherum như hiện tại, nhưng bạn có thể sử dụng chúng với một số sửa đổi, và bạn vẫn có thể sử dụng các công cụ gỡ lỗi EVM và hầu hết các cơ sở hạ tầng phát triển khác.

Nhưng cũng có một số ngoại lệ. Đối với việc xác minh chứng minh Merkle của các khối Ethereum lịch sử để xác minh các tuyên bố về giao dịch, biên lai hoặc trạng thái lịch sử, đã xuất hiện một sự không tương thích (ví dụ, cầu đôi khi làm như vậy). Việc thay thế hàm băm Keccak bằng ZK-EVM sẽ phá vỡ những chứng minh 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 trong tương lai của Ethereum (ví dụ, Cây Verkle) thậm chí sẽ phá vỡ những ứng dụng như vậy trên chính Ethereum. Một giải pháp thay thế tốt hơn cho Ethereum bản thân là thêm các hàm tiền biên 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 minh, nhưng vẫn chậm

Loại 2 ZK-EVM 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 sự phức tạp không cần thiết và không thân thiện với mã hóa ZK. Đặc biệt, chúng có thể thay đổi Keccak của Etherum và cây Merkle Patricia dựa trên RLP, có thể còn thay đổi cấu trúc khối và nhận. Loại 2 ZK-EVM có thể sử dụng các hàm băm khác nhau, chẳng hạn như Poseidon. Một sửa đổi tự nhiên khác là thay đổi cây trạng thái để lưu trữ hàm băm mã và keccak, do đó không còn cần phải xác minh hàm băm để xử lý mã opcode 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 thể giải quyết tất cả các vấn đề. Do sự không hiệu quả vốn có của EVM và sự không thân thiện với zk, quá trình chứng minh EVM như hiện tại vẫn rất chậm. Một ví dụ đơn giản là bộ nhớ: vì MLOAD có thể đọc bất kỳ 32 byte nào, bao gồm các khối "không căn chỉnh" (trong đó bắt đầu và kết thúc không phải là 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 các phép toán bit để kết hợp kết quả.

Người xây dựng là ai?

Dự án ZK-EVM của Scroll đang phát triển theo hướng ZK-EVM loại 2, giống như Polygon Hermez. Nói cách khác, cả hai dự án này vẫn chưa hoàn thành (chưa hoàn thành công việc ZKEVM); đặc biệt, nhiều hàm tiền biên phức tạp hơn vẫn chưa được thực hiện. Do đó, hiện tại cả hai dự án đều tốt nhất nên xem xét loại 3.

Loại 2.5 (tương đương với EVM, không bao gồm phí gas)

Một cách đáng kể để cải thiện thời gian xác minh trong trường hợp xấu nhất là tăng đáng kể chi phí cho các thao tác cụ thể khó chứng minh trong EVM. Điều này có thể liên quan đến các hàm tiền biên, mã opcode KECCAK, và có thể liên quan đến các quy tắc gọi hoặc các mẫu truy cập bộ nhớ, lưu trữ hoặc khôi phục cụ thể.

Chi phí phí gas thay đổi liên tục có thể làm giảm tính tương thích của các công cụ phát triển và phá vỡ một số ứng dụng, nhưng thường được coi là rủi ro nhỏ hơn so với những thay đổi "sâu hơn" trong EVM. Các nhà phát triển nên lưu ý rằng phí gas cần thiết trong giao dịch không vượt quá dung lượng của khối, và không sử dụng số lượng phí gas được mã hóa cứng để thực hiện các cuộc gọi (điều nà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 (hầu như tương đương với EVM)

Loại ZK-EVM thứ 3 hầu như tương đương với EVM, nhưng để đạt được sự tương đương hoàn toàn, cần phải hy sinh một số điều để cải thiện thời gian xác minh và làm cho 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

Loại 3 ZK-EVM có thể loại bỏ một số chức năng đặc biệt khó thực hiện trong việc triển khai ZK-EVM. Tại đây, các hàm tiền biên thường nằm ở đầu danh sách; ngoài ra, loại 3 ZK-EVM đôi khi cũng có những 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 loại 3 ZK-EVM là tương thích với hầu hết các ứng dụng, trong khi phần còn lại chỉ cần viết lại tối thiểu. Nói cách khác, một số ứng dụng cần phải được viết lại, hoặc vì chúng sử dụng các hàm tiền biên bị loại bỏ trong loại 3 ZK-EVM, hoặc vì sự phụ thuộc tinh tế vào các tình huống biên, mà những tình huống này được EVM xử lý theo cách khác nhau.

Người xây dựng là ai?

Scroll và Polygon hiện tại đều là loại 3, mặc dù theo thời gian, họ hy vọng cải thiện tính tương thích. Polygon có một thiết kế độc đáo, họ sử dụng ngôn ngữ nội bộ zkASM để xác minh ZK và sử dụng zkASM để triển khai mã ZK-EVM. Mặc dù có những chi tiết thực hiện như vậy, tôi vẫn gọi nó là loại Type3ZK-EVM thực sự; nó vẫn có thể xác minh mã EVM, chỉ là sử dụng một số logic nội bộ khác nhau để hoàn thành.

Hiện tại, không có đội ngũ 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 của việc thêm hàm tiền biên hoàn thành, dự án có thể chuyển sang loại 2.5. Tuy nhiên, trong tương lai, loại 1 hoặc loại 2 ZK-EVM có thể tự nguyện trở thành loại 3 ZK-EVM bằng cách thêm các trình biên dịch thân thiện với ZK-SNARK mới, cung cấp cho các nhà phát triển khả năng có thời gian xác minh và chi phí gas thấp.

Loại 4 (tương đương với ngôn ngữ cấp cao)

Cách thức hoạt động của hệ thống loại 4 là sử dụng 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 được biên dịch thành) và biên dịch nó thành một ngôn ngữ nào đó được thiết kế rõ rà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 mỗi 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 nhiều chi phí.

Tôi chỉ mô tả ưu điểm này trong bài viết này bằng một câu (so với danh sách các nhược điểm liên quan đến tính tương thích ở dưới), nhưng điều này không nên được hiểu là một phán xét về 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 tán bằng cách làm cho nó dễ dàng hơn để trở thành người chứng minh.

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, 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 "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ỉ của chúng trong EVM, vì địa chỉ theo quy tắc 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 phản thực" chưa được triển khai, ví dụ như ví ERC-4337, EIP-2470 đơn thể và nhiều ứng dụng khác.
• Mã byte EVM viết tay khó sử dụng hơn. Để cải thiện hiệu suất, nhiều ứng dụng sử dụng mã byte 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ợ mã byte EVM hạn chế để đáp ứng những trường hợp sử dụng này mà không cần nỗ lực trở thành một Type3ZK-EVM hoàn chỉnh.
• Nhiều cơ sở hạ tầng gỡ lỗi không thể tiếp tục, vì những cơ sở hạ tầng này hoạt động trên mã byte EVM. Nói cách khác, nhược điểm này được giảm thiểu bằng cách truy cập nhiều hơn vào cơ sở hạ tầng gỡ lỗi từ ngôn ngữ cấp cao "truyền thống" hoặc ngôn ngữ trung gian (ví dụ, LLVM).

Các nhà phát triển nên lưu ý đến những vấn đề này.

Người xây dựng là ai?

ZKSync là một hệ thống loại 4, mặc dù theo thời gian, nó có thể tăng cường tính 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 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 thực tế.

Tương lai của các loại ZK-EVM

Những loại này không rõ ràng là "tốt hơn" hoặc "kém hơn" so với các loại khác. Ngược lại, chúng là những điểm khác nhau trong không gian đánh đổi: loại có độ khó mã hóa thấp hơn tương thích hơn với cơ sở hạ tầng hiện có, nhưng chậm hơn; loại có độ khó mã hóa cao hơn ít tương thích hơn với cơ sở hạ tầng hiện có, nhưng nhanh hơn. Tổng thể, tất cả những loại này đều đang khám phá, điều này là tốt 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 ZK. Sau đó, họ có thể thêm những 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 đó có thể trở thành loại 2/loại 1 ZK-EVM hỗn hợp bằng cách cung cấp khả năng hoạt động trong chế độ tương thích hoàn toàn với Ethereum hoặc sử dụng cây trạng thái đã được sửa đổi có thể chứng minh nhanh hơn. Scroll đang xem xét phát triển theo hướng này.
• Hệ thống bắt đầu từ loại 4 có thể trở thành loại 3 theo thời gian, vì sau đó đã thêm khả năng xử lý mã EVM (mặc dù vẫn khuyến khích các nhà phát triển biên dịch trực tiếp từ ngôn ngữ cấp cao để giảm chi phí và thời gian xác minh).
• Nếu Ethereum bản thân áp dụng những sửa đổi của nó để cố gắng trở nên thân thiện hơn với zk, thì loại 2 hoặc loại 3 ZK-EVM có thể trở thành loại 1 ZK-EVM.
• Loại 1 hoặc loại 2 ZK-EVM có thể trở thành loại 3 ZK-EVM bằng cách thêm các trình biên dịch cho ngôn ngữ thân thiện với ZK-SNARK. Điều này sẽ cho phép các nhà phát triển đưa ra lựa chọn giữa tính tương thích với 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 từ 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 các hàm tiền biên tùy chỉnh của ZK-EVM, mặc dù điều này có thể được khắc phục: các công cụ phát triển có thể thêm hỗ trợ cho các hàm tiền biên chung bằng cách hỗ trợ định dạng cấu hình bao gồm các hàm tiền biên tương đương với mã EVM.

Về phần tôi, tôi hy vọng rằng theo thời gian, mọi thứ sẽ trở thành loại 1, bằng cách cải thiện ZK-EVM và cải thiện Ethereum bản thân để làm cho nó phù hợp hơn với ZK-Snark. Trong một tương lai như vậy, chúng ta sẽ có nhiều triển khai ZK-EVM, có thể được sử dụng cho cả zk rollups và xác minh Ethereum bản thân. Về lý thuyết, Ethereum không cần phải chuẩn hóa một triển khai ZK-EVM duy nhất cho L1; các khách hàng khác nhau có thể sử dụng các chứng minh 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 một tương lai như vậy. Trong khi đó, chúng ta sẽ thấy nhiều đổi mới trên nhiều con đường khác nhau để mở rộng Ethereum và zk tổng hợp dựa trên Ethereum.