Viết bởi: cookies

Biên dịch: TechFlow

Bạn có thực sự hiểu rõ về ZK-EVM không?

Bài viết này đi sâu vào phân tích năm loại ZK-EVM, mỗi loại đều có kiến trúc, ưu điểm và nhược điểm riêng biệt, cùng với các giải pháp tiềm năng.

Ngoài ra, bài viết còn liệt kê một số dự án thực tiễn để người đọc dễ hình dung hơn về cách các loại này hoạt động trong thực tế. Dù bạn là nhà phát triển blockchain hay chỉ đơn giản là người quan tâm đến công nghệ blockchain, bài viết này sẽ mang đến cho bạn những cái nhìn sâu sắc, súc tích và rõ ràng.

Hãy cùng tìm hiểu về các loại ZK-EVM cũng như ưu-nhược điểm của chúng.

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

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

3. Loại 2.5: Một phần tương đương EVM;

4. Loại 3: Gần như tương đương EVM;

5. Loại 4: Tương đương ở cấp độ ngôn ngữ cao.

Loại 1 | Hoàn toàn tương đương Ethereum

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

Loại 1 | Ưu điểm

Tương thích hoàn hảo:

· Có khả năng xác minh khối Ethereum;

· Giúp cải thiện khả năng mở rộng của Ethereum L1;

· Phù hợp với Rollups vì có thể tái sử dụng nhiều cơ sở hạ tầng hiện có.

Loại 1 | Nhược điểm

Tương thích hoàn hảo:

· Ethereum ban đầu không được thiết kế cho tính năng ZK;

· Nhiều thành phần của Ethereum đòi hỏi lượng tính toán lớn để tạo bằng chứng ZK (ZKP);

· Việc tạo bằng chứng cho khối Ethereum mất hàng giờ đồng hồ.

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

· Song song hóa quy trình tạo bằng chứng trên quy mô lớn;

· ASIC dành riêng cho ZK-SNARK.

Loại 2 | Hoàn toàn tương đương EVM

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;

· Tương thích hoàn toàn với các ứng dụng hiện tại;

· Chỉ sửa đổi nhỏ đối với Ethereum nhằm giúp việc phát triển dễ dàng hơn và tạo bằng chứng nhanh hơn.

Loại 2 | Ưu điểm

· Cung cấp thời gian tạo bằng chứng nhanh hơn loại 1;

· Cấu trúc dữ liệu không bị truy cập trực tiếp bởi EVM;

· Các ứng dụng đang chạy trên Ethereum: rất có thể sẽ chạy được trên loại 2;

· Hỗ trợ các công cụ gỡ lỗi EVM hiện có và các cơ sở hạ tầng phát triển khác.

Loại 2 | Nhược điểm

Trước khi tìm hiểu nhược điểm, cần hiểu "Keccak" là gì:

· Là thuật toán băm của chuỗi khối Ethereum;

· Được dùng để bảo vệ dữ liệu trên Ethereum;

· Đảm bảo thông tin được chuyển đổi thành dạng băm.

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

Chúng ta có thể xem Keccak như một ngôn ngữ, sử dụng bằng chứng Merkle (như chữ cái). Nếu ZK-EVM thay thế Keccak bằng một thuật toán băm khác (ví dụ Poseidon), bằng chứng Merkle sẽ trở nên xa lạ, khiến các ứng dụng không thể đọc hoặc xác minh tuyên bố của chúng.

Giải pháp tiềm năng cho nhược điểm: Ethereum có thể thêm chức năng tiền biên dịch hỗ trợ truy cập lịch sử trong tương lai.

Dự án thuộc loại 2

· Scroll;

· Polygon Hermez.

Tuy nhiên, các dự án này vẫn chưa triển khai các tiền biên dịch phức tạp hơn, do đó, chúng có thể được coi là loại 2 chưa hoàn chỉnh.

Loại 2.5 | Một phần tương đương EVM

Kiến trúc:

· Tăng chi phí Gas cho các thao tác EVM nhất định vốn khó tạo bằng chứng ZK;

· Tiền biên dịch;

· Mã lệnh Keccak;

· Mô hình gọi hợp đồng;

· Truy cập bộ nhớ;

· Lưu trữ.

Loại 2.5 | Ưu điểm

· Cải thiện đáng kể thời gian tạo bằng chứng trong trường hợp xấu nhất;

· An toàn hơn so với việc thay đổi sâu vào ngăn xếp EVM.

Loại 2.5 | Nhược điểm

· Khả năng tương thích với công cụ phát triển giảm xuống;

· Một số ứng dụng sẽ không hoạt động được.

Loại 3 | Gần như tương đương EVM

Kiến trúc:

· Trong quá trình triển khai ZK-EVM, loại bỏ một số chức năng đặc biệt khó thực hiện, thường là các tiền biên dịch;

· ZK-EVM có sự khác biệt nhẹ trong xử lý mã hợp đồng, bộ nhớ hoặc ngăn xếp.

Loại 3 | Ưu điểm

· Rút ngắn thời gian xác minh;

· Làm cho việc phát triển EVM dễ dàng hơn;

· Mục tiêu là chỉ yêu cầu viết lại tối thiểu cho các ứng dụng ít tương thích.

Loại 3 | Nhược điểm

· Tính không tương thích cao hơn;

· Các ứng dụng sử dụng tiền biên dịch đã bị loại bỏ trong loại 3 sẽ cần được viết lại.

Loại 3 | Dự án

Hiện tại, Scroll và Polygon được coi là thuộc loại 3, tuy nhiên, các nhóm phát triển ZK-EVM không nên hài lòng với mức loại 3 – đây chỉ là giai đoạn chuyển tiếp, nơi ZK-EVM bổ sung tiền biên dịch để nâng cao khả năng tương thích và tiến tới loại 2.5.

Loại 4 | Tương đương ở cấp độ ngôn ngữ cao

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 như Solidity, Vyper;

· Biên dịch sang ngôn ngữ được thiết kế thân thiện với ZK-SNARK.

Loại 4 | Ưu điểm

· Thời gian tạo bằng chứng cực nhanh;

· Giảm chi phí phát sinh (chi phí, thời gian và khối lượng tính toán);

· Hạ thấp rào cản trở thành người tạo bằng chứng: tăng tính phi tập trung.

Loại 4 | Nhược điểm

· Trong hệ thống loại 4, địa chỉ hợp đồng có thể khác với địa chỉ trong EVM, vì địa chỉ phụ thuộc chính xác vào bytecode;

· Điều này có nghĩa là nếu ZK-EVM loại 4 không có bytecode, chúng sẽ không thể tạo được địa chỉ;

· Trong trường hợp nói trên, loại 4 sẽ không tương thích với các ứng dụng dựa trên hợp đồng phản thực tế (counterfactual contracts);

· Nhiều cơ sở hạ tầng gỡ lỗi không thể di chuyển được vì chúng hoạt động trên bytecode EVM.

Loại 4 | Dự án

· zkSync

Cuối cùng, chúng ta có thể đặt tất cả các loại trên đây cạnh nhau để so sánh, giúp mọi người dễ dàng nắm bắt và hiểu rõ sự khác biệt giữa các loại zkEVM.