Giải thích chi tiết về năm loại ZK-EVM: cấu trúc, ưu nhược điểm và giải pháp

Tác giả của văn bản gốc: s Biên soạn văn bản gốc: Deep Tide TechFlow

Bài viết này khám phá chi tiết năm loại ZK-EVM, mỗi loại có kiến trúc độc đáo, ưu điểm và nhược điểm cũng như các giải pháp khả thi.

Ngoài ra, bài viết cũng liệt kê một số ví dụ dự án thực tế để bạn đọc hiểu rõ hơn về hiệu suất của các loại này trong ứng dụng thực tế. Cho dù bạn là nhà phát triển chuỗi khối hay độc giả quan tâm đến công nghệ chuỗi khối, bài viết này sẽ cung cấp cho bạn những hiểu biết sâu sắc và ngắn gọn.

Hãy cùng khám phá các loại ZK-EVM, ưu và nhược điểm của chúng.

1. Loại 1: hoàn toàn tương đương với Ethereum;

2. Loại 2: tương đương hoàn toàn với EVM;

3. Loại 2.5: Tương đương một phần với EVM;

4. Loại 3: gần tương đương với EVM;

5. Loại 4: tương đương với ngôn ngữ bậc cao.

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

Kiến trúc: Nó hoàn toàn giống với Ethereum và không thay đổi bất kỳ phần nào của hệ thống Ethereum.

lợi thế

Khả năng tương thích hoàn hảo:

• Khả năng xác minh các khối Ethereum;
• Giúp Ethereum L1 có khả năng mở rộng hơn;
• Thích hợp cho Rollup vì chúng có thể tái sử dụng nhiều cơ sở hạ tầng.

sự thiếu sót

Khả năng tương thích hoàn hảo:

• Ethereum ban đầu không được thiết kế cho chức năng ZK;
• Nhiều thành phần của Ethereum yêu cầu rất nhiều tính toán để tạo bằng chứng ZK (ZKP);
• Bằng chứng cho các khối Ethereum mất nhiều giờ để tạo.

Giải pháp cho vấn đề:

• Phương ngôn song hóa quy mô lớn;
• ASIC ZK-SNARK.

Loại 2: hoàn toàn tương đương với EVM

Ngành kiến trúc:

• Cấu trúc dữ liệu (cấu trúc khối và cây trạng thái) khác biệt đáng kể so với Ethereum;
• Hoàn toàn tương thích với các ứng dụng hiện có;
• Các sửa đổi nhỏ đối với Ethereum để phát triển dễ dàng hơn và tạo bằng chứng nhanh hơn.

lợi thế

• Cung cấp thời gian chứng minh nhanh hơn Loại 1;
• Cấu trúc dữ liệu không được EVM truy cập trực tiếp;
• Các ứng dụng chạy trên Ethereum: có khả năng chạy trên Loại 2;
• Hỗ trợ các công cụ sửa lỗi EVM hiện có và cơ sở hạ tầng phát triển khác.

sự thiếu sót

Trước khi hiểu những nhược điểm, trước tiên hãy hiểu "Keccak" là gì:

• Thuật toán băm của chuỗi khối Ethereum;
• Được sử dụng để bảo vệ dữ liệu trên Ethereum;
• Đảm bảo tin nhắn được chuyển đổi thành hàm băm.

Loại 2 không tương thích với các ứng dụng xác minh bằng chứng Merkle về các khối lịch sử để xác minh thông tin về các giao dịch, biên nhận/trạng thái lịch sử. Điều này là do nếu thuật toán băm thay đổi (không còn Keccak), bằng chứng sẽ trở nên không hợp lệ.

Chúng ta có thể coi Keccak là ngôn ngữ sử dụng bằng chứng Merkle (bảng chữ cái) Nếu ZK-EVM thay thế Keccak bằng một thuật toán băm khác (chẳng hạn như Poseidon), bằng chứng Merkle sẽ trở nên xa lạ và các ứng dụng sẽ không thể đọc và xác thực các yêu cầu của chúng.

Giải pháp tiềm năng cho những thiếu sót: Ethereum có thể bổ sung tính năng tiền biên dịch truy cập lịch sử có thể mở rộng trong tương lai.

dự án

• Cuộn;
• Đa giác Hermez.

Tuy nhiên, các dự án này vẫn chưa thực hiện tiền biên dịch tinh vi hơn, do đó, chúng có thể được coi là Loại 2 chưa hoàn chỉnh.

Loại 2.5: Tương đương một phần với EVM

Ngành kiến trúc:

Tăng chi phí gas của các hoạt động EVM cụ thể khó chứng minh ZK;

• Biên dịch trước;
• Mã lệnh Keccak;
• Phương thức gọi là hợp đồng;
• Truy cập bộ nhớ;
• kho.

lợi thế

• Cải thiện đáng kể thời gian chứng minh trường hợp xấu nhất;
• An toàn hơn là thực hiện các thay đổi sâu hơn đối với ngăn xếp EVM.

sự thiếu sót

• Khả năng tương thích của các công cụ phát triển bị giảm sút;
• Một số ứng dụng sẽ không hoạt động.

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

Ngành kiến trúc:

• Trong quá trình triển khai ZK-EVM, một số chức năng cực kỳ khó triển khai sẽ bị xóa, thường được biên dịch sẵn;
• ZK-EVM có một số khác biệt nhỏ trong cách xử lý mã hợp đồng, bộ nhớ hoặc ngăn xếp.

lợi thế

• rút ngắn thời gian xác minh;
• Làm cho EVM dễ phát triển hơn;
• Mục tiêu là yêu cầu viết lại tối thiểu cho các ứng dụng ít tương thích hơn.

sự thiếu sót

• Không tương thích nhiều hơn;
• Các ứng dụng sử dụng tiền biên dịch đã bị xóa trong Loại 3 sẽ cần được viết lại.

dự án

Hiện tại, Cuộn và Đa giác được coi là Loại 3, tuy nhiên, nhóm ZK-EVM không nên hài lòng với Loại 3, Loại 3 là giai đoạn chuyển tiếp trong đó ZK-EVM bổ sung tính năng tiền biên dịch để cải thiện khả năng tương thích và chuyển sang Loại 2.5.

Loại 4: tương đương ngôn ngữ bậc cao

Ngành kiến trúc:

• Chấp nhận mã hợp đồng thông minh được viết bằng ngôn ngữ cấp cao (chẳng hạn như Solidity, Vyper);
• Được biên dịch thành ngôn ngữ được thiết kế thân thiện với ZK-SNARK.

lợi thế

• Thời gian chứng minh rất nhanh;
• Giảm chi phí hoạt động (chi phí, thời gian và nỗ lực tính toán);
• Hạ thấp rào cản trở thành minh tinh: tăng mức độ phân quyền.

sự thiếu sót

• Trong hệ thống loại 4, địa chỉ của hợp đồng có thể khác với địa chỉ trong EVM, vì địa chỉ phụ thuộc vào mã byte chính xác;
• Điều này có nghĩa là nếu ZK-EVM loại 4 không có mã byte, chúng sẽ không thể tạo địa chỉ;
• Loại 4 sẽ không tương thích với các đơn dựa vào hợp đồng đối chứng trong các trường hợp trên;
• Nhiều cơ sở hạ tầng gỡ lỗi không khả dụng vì chúng chạy trên mã byte EVM.

dự án

• zkSync

Cuối cùng, chúng ta có thể so sánh các loại trên với nhau để giúp mọi người hiểu sơ qua về các zkEVM khác nhau.