Từ Type1 đến Type4, sự khác biệt giữa các loại ZK-EVM khác nhau là gì?

Tác giả gốc| Lisa Akselrod

Tổng hợp | Odaily Planet Daily 0xAyA

*Ghi chú của biên tập viên: Tác giả biên soạn dựa trên bài viết giới thiệu ZK-EVM của Vitalik trước đây và giới thiệu chi tiết về các loại ZK-EVM cũng như sự khác biệt giữa chúng. *

Khoảng một năm trước, một nhóm ZK-EVM đã thông báo rằng họ sắp ra mắt mạng thử nghiệm. Những động thái này đã khơi dậy sự tò mò của cộng đồng Ethereum và làm dấy lên cuộc thảo luận về các sắc thái đằng sau các thuật ngữ như tương đương Ethereum và tương đương EVM.

Để làm rõ, Vitalik đã viết một bài báo quan trọng có tiêu đề "Các loại ZK-EVM khác nhau" phân loại các ZK-EVM khác nhau thành bốn loại và giải thích sự khác biệt của chúng.

Ý tưởng cốt lõi là: Loại 1 (ví dụ Taiko) hoàn toàn tương đương với Ethereum, trong khi Loại 4 (ví dụ zkSync) vượt trội trong việc tạo bằng chứng hiệu quả. Tất cả các loại khác, Loại 2, Loại 2.5 và Loại 3, đều nằm ở giữa (ví dụ: Polygon zkEVM, Scroll, Linea).

Hầu hết các ZK-EVM ban đầu là Loại 2.5 và Loại 3, với một số ý định phát triển theo Loại 1 hoặc Loại 2 đã được tiết lộ, mặc dù các dự án này chưa đưa ra các mốc thời gian hoặc cam kết cụ thể cho việc này.

**Bài viết này tập trung vào sự khác biệt giữa Loại 1 và Loại 2/Loại 2.5, đồng thời mô tả những hậu quả có thể xảy ra khi phá vỡ tính tương đương của Ethereum. Chúng tôi cũng sẽ đề cập ngắn gọn về các loại khác. **

Mục tiêu chính của ZK-EVM là mở rộng quy mô Ethereum, tức là tăng thông lượng của Ethereum trong khi vẫn giữ được các tính năng khác của nó (bảo mật, trải nghiệm của nhà phát triển, v.v.). Lý tưởng nhất là ZK-EVM có thể:

• Chứng minh việc thực thi mã byte gốc chưa sửa đổi (bao gồm 100% các mã Ethereum) theo thông số kỹ thuật của Máy ảo Ethereum trong Sách vàng.
• Nhanh chóng tạo ra bằng chứng với chi phí thấp.
• Cho phép tái sử dụng 100% các công cụ và cơ sở hạ tầng được phát triển cho Ethereum.
• Cho phép triển khai lại bất kỳ dApp Ethereum nào trên ZK-EVM "nguyên trạng" ("nguyên trạng" nghĩa là không cần thay đổi, không thỏa hiệp).

Sự khác biệt giữa các loại ZK-EVM

Trong thế giới ZK-EVM, sự khác biệt chủ yếu đến từ mức độ tương đương Ethereum/EVM, tác động của các yếu tố không thân thiện với ZK đối với chi phí và tốc độ tạo bằng chứng cũng như độ phức tạp của việc triển khai mạch (chẳng hạn như xây dựng VM hoặc trạng thái cây).

Hãy phân tích những khác biệt này, cụ thể là phân biệt Loại 1 với Loại 2/Loại 2.5. Chúng tôi cũng sẽ đề cập đến các trường hợp sử dụng phù hợp nhất với từng loại.

Khi so sánh các loại khác nhau, biểu đồ sau thường được sử dụng:

Đối với những người không làm việc toàn thời gian trong lĩnh vực ZK-EVM, bảng này có thể có vẻ khó hiểu, vì vậy hãy dịch các thuật ngữ này sang thuật ngữ thông thường và xem qua:

Sơ đồ này cung cấp một bức tranh rõ ràng hơn về từng loại thực sự trông như thế nào, nhưng nó vẫn có thể hơi mơ hồ. Hãy cùng khám phá đầy đủ thế giới ZK-EVM bằng cách giải thích từng loại riêng lẻ.

Loại 1: Tương đương với Ethereum

Vitalik Buterin:

“ZK-EVM loại 1 là thứ cuối cùng chúng tôi cần để làm cho lớp 1 của Ethereum có khả năng mở rộng cao hơn.”

Loại 1 có nghĩa là không thay đổi bất kỳ phần nào của hệ thống Ethereum để tạo bằng chứng dễ dàng hơn. Không có thay đổi nào đối với Ethereum có nghĩa là không ảnh hưởng đến bảo mật, vì hầu hết các nguyên tắc mã hóa (ví dụ: hàm băm), cơ sở hạ tầng dành cho nhà phát triển (ví dụ: trình gỡ lỗi) hoặc cơ sở hạ tầng chuỗi (ví dụ: ứng dụng khách thực thi) đã được thử nghiệm thực địa 9 năm.

ZK-EVM loại 1 không thay thế bất cứ thứ gì: băm, cây trạng thái, cây giao dịch, biên dịch trước hoặc bất kỳ logic đồng thuận nào khác, mọi thứ đều giống hệt như EVM của mạng chính.

• Loại 1 là loại duy nhất có thể tự xác minh chuỗi Ethereum - từ toàn bộ khối đến thực hiện giao dịch, hợp đồng thông minh và logic tài khoản.

Loại 2: Tương đương EVM

Loại 2 giúp tạo bằng chứng nhanh hơn và phát triển mạch dễ dàng hơn bằng cách loại bỏ một số phần không có lợi cho ZK. Tuy nhiên, do hậu quả của việc này, nó có thể khiến việc phát triển các phần khác của ZK-rollup (chẳng hạn như phần mềm nút) trở nên phức tạp hơn. Những sự phức tạp này có thể do sự không tương thích giữa các phương pháp thực hành tốt nhất và các công cụ kiểm tra đã được thiết lập và những thay đổi đang được triển khai (chẳng hạn như cây trạng thái bị thay đổi).

*Lưu ý: Tương đương với Ethereum và tương đương với EVM là không giống nhau. Mặc dù tương đương với Ethereum có nghĩa là không có phần nào của Ethereum bị thay đổi, điều đó có nghĩa là nó hoàn toàn tương thích với tất cả các dApps Ethereum, tương đương với EVM cho phép thay đổi cấu trúc dữ liệu (chẳng hạn như cấu trúc khối hoặc cây trạng thái). *

Mặc dù những điều chỉnh này có vẻ nhỏ nhưng chúng ảnh hưởng đến khả năng tương thích của Ethereum. Việc thay đổi cấu trúc dữ liệu có thể khiến Ethereum dApps không tương thích với ZK-EVM Loại 2, đặc biệt là khi xác thực bằng chứng Merkle về các giao dịch, biên lai hoặc trạng thái trong quá khứ (chẳng hạn như qua các cầu nối chuỗi).

Xóa các phần tử không thân thiện với ZK

Các sửa đổi đối với Ethereum nhằm đơn giản hóa việc phát triển và tăng tốc độ tạo bằng chứng. Mục tiêu là loại bỏ các phần của Ethereum dựa vào mật mã không có kiến thức không thân thiện. Theo thuật ngữ kỹ thuật hơn, các phần yêu cầu số lượng lớn cổng (phép tính cộng và nhân) do các miền không cục bộ (chẳng hạn như hàm băm), số lượng lớn các phép nhân đa vô hướng và/hoặc biến đổi Fourier nhanh (FFT); hoặc Chỉ phần cần nhiều thao tác.

Các ví dụ cụ thể về các yếu tố không có kiến thức không thân thiện mà ZK-EVM Loại 2 có thể sửa đổi:

• Hàm băm: Trong khi Ethereum sử dụng hàm băm Keccak, nhiều ZK-EVM sử dụng hàm băm Poseidon, hàm này yêu cầu số lượng cổng nhỏ hơn đáng kể. Ví dụ: hãy ước tính có thể tính được bao nhiêu hàm băm của từng loại mỗi giây (tức là so sánh thể hiện tốc độ tạo).

Hàm băm Poseidon có lợi thế đáng kể về tốc độ trong việc tạo bằng chứng.

Tuy nhiên, điều quan trọng cần lưu ý là các mật mã nguyên thủy mới hơn không phổ biến bằng các mật mã nguyên thủy đã được thiết lập và được cộng đồng công nhận rộng rãi. Mặc dù Poseidon có thể mang lại tốc độ nhưng các đặc tính đã được thử nghiệm trong chiến đấu của Keccak khiến nó trở nên mạnh mẽ và an toàn hơn vì nó được áp dụng rộng rãi.

Đây là lý do tại sao Keccak, mặc dù lâu đời hơn và được cộng đồng rộng rãi hơn chấp nhận (trong các ngành khác, chẳng hạn như hệ thống bảo mật hoặc cảm biến trong thiết bị thông minh), có thể được coi là đã được thử nghiệm nhiều hơn Poseidon, xét cho cùng thì nó vẫn nằm trong cộng đồng ZK. chức năng tạo và sử dụng.

• Cây trạng thái để lưu trữ dữ liệu: Ví dụ: trong khi Ethereum sử dụng cây Merkle Patricia (sử dụng băm Keccak), một số ZK-EVM Loại 2 chọn cây Merkle thưa thớt (sử dụng băm Poseidon). Việc thay đổi cây trạng thái có thể gây ra một số vấn đề không tương thích. Ví dụ: cây Merkle của Ethereum có các loại nút khác nhau và sử dụng RLP để mã hóa dữ liệu, đây là một điều khó thực hiện trong ZK.
• Cấu trúc khối: Các khối chứa một lượng lớn thông tin. Tuy nhiên, khi khám phá L2, chúng tôi chỉ quan tâm đến ution_payload_header (tức là hàm băm khối). Trong hình ảnh bên dưới, có cấu trúc (khối băm) của tất cả dữ liệu có trong ution_payload_header.

**Xin lưu ý: việc thay đổi bất kỳ thành phần nào trong số này sẽ phá vỡ tính tương đương của Ethereum. **

Loại 2.5: Tương đương EVM, xét đến chi phí gas

Loại 2.5 ZK-EVM làm tăng chi phí khí đốt cho các hoạt động cụ thể khó chứng minh bằng công nghệ ZK trong EVM.

Với giới hạn gas của Ethereum trên mỗi khối (30 M gas), việc tăng chi phí gas cho mỗi opcode sẽ dẫn đến ít opcode hơn trên mỗi khối. Do đó, các opcode ít phức tạp hơn có thể được đưa vào một khối. Các mã hoạt động đơn giản hơn cho phép các mạch nhỏ hơn và tạo ra bằng chứng nhanh hơn.

• khí là đơn vị đo công.
• Giá opcode được tính bằng gas.
• Các mã hoạt động chỉ định các thao tác trong hướng dẫn ngôn ngữ máy.
• Một chương trình là một danh sách tĩnh các opcode. Việc thực thi chương trình là dấu vết thực thi.
• Dấu vết thực thi là danh sách các mã hoạt động được sắp xếp cụ thể được thực hiện bởi một chương trình.

Những phần khó chứng minh ZK bao gồm:

• Opcode Keccak và một số opcode khác phụ thuộc vào Keccak.
• Biên dịch trước: các chức năng có thể truy cập được vào EVM. Một số trong số chúng cung cấp các tác vụ phức tạp hoặc phức tạp về mặt toán học, chẳng hạn như các hàm mật mã (chẳng hạn như blake 2 f hoặc sha 256). Chúng không thực thi trong EVM mà thay vào đó là các chức năng được mã hóa cứng trong máy khách thực thi và hiển thị với EVM bằng cách sử dụng CALL tới các địa chỉ đặc biệt.
• Truy cập bộ nhớ: ví dụ: tăng kích thước khe cắm bộ nhớ (ví dụ: Ethereum sử dụng bộ nhớ được căn chỉnh theo byte, trong khi Polygon zkEVM sử dụng khe cắm bộ nhớ 32 byte). Để thực hiện được sự thay đổi này, logic bên trong của một số opcode nhất định (chẳng hạn như MLOAD) phải được thay đổi.
• Lưu trữ (tức là thay đổi hàm băm hoặc cây trạng thái như mô tả ở trên).

Việc thay đổi chi phí gas có thể làm giảm khả năng tương thích của các công cụ dành cho nhà phát triển và phá vỡ một số dApp. Ví dụ: một hợp đồng thông minh thường xuyên thực hiện các opcode với chi phí gas ngày càng tăng có thể vượt quá giới hạn gas khối và không thực thi được.

Loại 3: Gần tương đương với EVM

ZK-EVM loại 3 bỏ qua quá trình biên dịch trước không áp dụng cho ZK và có thể điều chỉnh quyền truy cập bộ nhớ và bộ lưu trữ.

Các dApp dựa trên các ứng dụng được biên dịch trước đã bị xóa sẽ cần phải được viết lại. Trong các trường hợp bất thường, sự khác biệt trong cách xử lý các trường hợp đặc biệt của ZK-EVM Loại 3 và EVM ban đầu có thể yêu cầu điều chỉnh dApp.

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

Loại 4 đã cách xa EVM rất xa.

Mã nguồn hợp đồng thông minh được viết bằng ngôn ngữ cấp cao (ví dụ: Solidity, Zinc) được biên dịch thành dạng biểu diễn trung gian, tạo ra các mã hoạt động phù hợp cho các máy ảo thân thiện với ZK.

• Phương pháp này tránh tạo ra các bằng chứng ZK cho từng bước thực hiện EVM, do đó làm giảm đáng kể công việc chứng minh.
• Ngay cả khi hợp đồng có thể được biên dịch, vẫn cần phải thực hiện thêm công việc nếu dApp sử dụng mã byte viết tay EVM. *ZK-EVM loại 4 cũng yêu cầu các công cụ dành cho nhà phát triển riêng (chỉ ở cấp độ mã hoạt động) chẳng hạn như trình gỡ lỗi và trình theo dõi.

Trong mạch ZK chứng minh quỹ đạo thực thi, mỗi bước thực hiện ràng buộc và chi phí của mỗi bước là tổng của tất cả các opcode. Do đó, ZK-EVM Loại 4 được thiết kế để sử dụng càng ít mã hoạt động phức tạp càng tốt để tối ưu hóa hiệu quả.

Điều đáng nói là các opcode tùy chỉnh (opcode không có trong Ethereum) giúp có thể chuyển các tính năng mới không có trên Ethereum theo mặc định. Ví dụ: thực hiện nhiều lệnh gọi để thực thi thông qua tính năng trừu tượng hóa tài khoản hoặc khởi chạy ví hợp đồng thông minh bằng giải pháp sẵn dùng như Argent.

Tóm tắt

Các loại ZK-EVM khác nhau ưu tiên các mục tiêu và đặc điểm khác nhau. Loại 1 tập trung vào tính tương đương của Ethereum, trong khi Loại 4 ưu tiên tạo ra bằng chứng hiệu quả. Các loại khác nằm ở giữa các thái cực này và nhiều giao thức ZK-EVM Loại 2 và 3 đã công bố ý định chuyển sang các giao thức tương đương Ethereum.

Bốn loại phân loại này có thể không phải là trạng thái cuối cùng của bản tổng hợp ZK và có thể phải sửa đổi thêm trong tương lai. Ví dụ: một số ZK-EVM có thể trở thành kết hợp, Loại 1/2 có thể phát triển các giải pháp Loại 4 (với hiệu quả cao nhất có thể) và cung cấp cho dApp cả hai tùy chọn, trong khi ZK-EVM Loại 3 và 4 có thể thêm tùy chọn tương đương Ethereum.