zkEVM là gì ? 5 loại zkEVM nắm giữ tương lai mở rộng của Ethereum

zkEVM là gì ? 5 loại zkEVM nắm giữ tương lai mở rộng của Ethereum

EthereumKiến thức
ZkEVM là một giải pháp đột phá mới được sử dụng để giải quyết vấn đề mở rộng của các blockchain lớp 2 ( layer 2) trong mạng Ethereum. Đầu năm 2021 khi crypto bùng nổ, khối lượng giao dịch tăng cao cũng là lúc cộng đồng sử dụng blockchain chứng kiến ​​rất nhiều vấn đề với việc Ethereum như bị tắc nghẽn giao dịch, phí gas tăng cao, treo lệnh…
ZkEVM được kỳ vọng là giải pháp tương lai cho ETH để giải quyết các vấn đề mà nó đang gặp phải, trong bài viết ngày hôm nay chúng ta sẽ cùng tìm hiểu rõ thêm về nó nhé.

ZkEVM là gì ?

ZkEVM (Máy ảo Ethereum không kiến thức) là một biến thể của Máy ảo Ethereum (EVM), nó cho phép tạo và thực hiện các hợp đồng thông minh trong môi trường không có kiến thức. Điều này được giải thích rõ ràng hơn ở bên dưới.

zkEVM cho phép thực hiện các hợp đồng thông minh theo cách bảo vệ quyền riêng tư của các điều khoản và dữ liệu hợp đồng. Bằng chứng không kiến ​​thức (Zk) là bằng chứng mật mã cho phép một bên chứng minh với bên kia rằng một tuyên bố là đúng, mà không tiết lộ bất kỳ thông tin bổ sung nào liên quan tới tuyên bố đó.
Các dự án zkEVM đang cố gắng xây dựng zkEVM tốt nhất, nhưng đều chưa đạt được mục tiêu này, họ đang xây dựng theo các cách khác nhau nên hiện tại đang có khá là nhiều loại ZkEVM tương ứng với các tiêu chuẩn mà dự án theo đuổi. Ngay bên dưới chúng ta sẽ cùng phân biệt giữa chúng, để tìm hiểu sự khác nhau này.

5 Loại ZkEVM bạn cần biết

ZkEVM type

  1. ZkEVM loại 1: Đây là loại tương thích hoàn toàn với Ethereum. Không có bất kì thay đổi thứ gì từ hệ thống của Ethereum, để giúp tạo ra bằng chứng dễ dàng hơn. Không thay đổi hàm băm, cây trạng thái, hay bất kì logic đồng thuận nào.
  2. ZkEVM loại 2 (hoàn toàn tương thích với EVM) có vẻ ngoài giống với Ethereum, nhưng lại khác nhau về cấu trúc dữ liệu cơ bản. ScrollHermez Polygon là hai dự án điển hình như vậy. Để phù hợp với một số quá trình nhất định trong EVM mà rất khó để chứng minh. Nói cách khác thì ZkEVM loại 2 này dễ dàng tương thích với EVM, nhưng lại chưa chắc đã tương thích với Ethereum.
  3. ZkEVM loại 2.5: ( giống hệt EVM, ngoại trừ phí gas ) zkEVM tăng đáng kể chi phí gas so với EVM. Cần cẩn thận khi triển khai các dApps trên mạng lưới của nó, vì điều này có thể gây ra các vấn đề liên quan tới chi phí của nhà phát triển và người sử dụng.
  4. ZkEVM loại 3: (gần như tương thích với EVM) phải chấp nhận hi sinh và bỏ qua một số chức năng của EVM, vì nếu không làm như vậy thì sẽ là thách thức đối với một hệ thống zk EVM. Loại 3 là một loại trạng thái mà ít dự án mong muốn đạt được; thay vào đó, nó là một điểm dừng giữa các sáng kiến Loại 2.5 và Loại 2.
  5. ZkEVM loại 4: (ngôn ngữ so sánh cấp cao ) zkEVMs có thể được viết bằng các ngôn ngữ cấp cao như Solidity hoặc Vyper. Các hợp đồng thông minh được tạo ra bằng các ngôn ngữ này có thể được chuyển đổi thành ngôn ngữ phát triển chính của hệ thống zkEVM. zkSync là một dự án hiện tại phát triển của zkEVM loại 4.

Bạn có thể tham khảo thêm tại blog của Vitalik để hiểu rõ thêm tại đây hoặc đọc tham khảo bài được Coinbold dịch lại ngay bên dưới.

ZkEVM loại 1 (hoàn toàn tương thích Ethereum)

ZK-EVM loại 1 tương thích với Ethereum một cách hoàn toàn và nhất quán. Họ không thay đổi bất kỳ phần nào của hệ thống Ethereum để giúp 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, tiền biên dịch hoặc bất kỳ logic không đồng thuận nào khác, bất kể ngoại vi như thế nào.

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

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

ZK-EVM loại 1 là thứ cuối cùng chúng ta cần làm cho bản thân lớp Ethereum 1 để có khả năng mở rộng hơn. Về lâu dài, các 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 Ethereum đúng cách, nhưng việc tái cấu trúc như vậy đi kèm với sự phức tạp của chính nó.

ZK-EVM loại 1 cũng lý tưởng cho các bản tổng hợp, vì chúng cho phép các bản tổng hợp sử dụng lại nhiều cơ sở hạ tầng. Ví dụ: các ứng dụng khách thực thi Ethereum có thể được sử dụng nguyên trạng để tạo và xử lý các khối tổng số (hoặc ít nhất, chúng có thể được xử lý sau khi việc rút tiền được thực hiện và chức năng đó có thể được sử dụng lại để hỗ trợ ETH được gửi vào danh sách tổng số), vì vậy các công cụ chẳng hạn như trình khám phá khối, sản xuất khối, v.v. rất dễ sử dụng lại.

Nhược điểm: Thời gian chứng minh

Ethereum ban đầu không được thiết kế dựa trên tính thân thiện với ZK, do đó, có nhiều phần của giao thức Ethereum cần một lượng lớn tính toán để chứng minh ZK. Loại 1 nhằm mục đích sao chép chính xác Ethereum và do đó, nó không có cách nào giảm thiểu được những điểm kém hiệu quả này. Hiện tại, bằng chứng cho các khối Ethereum mất nhiều giờ để tạo ra. Điều này có thể được giảm thiểu bằng kỹ thuật thông minh để song song hóa ồ ạt bộ chuẩn hoặc về lâu dài bằng ASIC ZK-SNARK.

Dự án đang xây dựng?

Phiên bản SPecs ZK-EVM (được khởi động bởi những người đóng góp cho cộng đồng bao gồm Khám phá Quyền riêng tư và Mở rộng , nhóm Scroll, Taiko và những người khác) là ZK-EVM Cấp 1.

 


Loại 2 (tương thích hoàn toàn với EVM)

ZK-EVM loại 2 cố gắng tương thích chính xác với EVM, nhưng không hoàn toàn tương thích với Ethereum. Nghĩa là, chúng trông giống hệt Ethereum “từ bên trong”, nhưng chúng có một số khác biệt ở bên ngoài, đặ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à 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 để giúp việc phát triển dễ dàng hơn và tạo ra bằng chứng nhanh hơn.

Ưu điểm: tương thích hoàn hảo ở cấp độ EVM

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

Bạn sẽ không thể sử dụng nguyên trạng các máy khách thực thi Ethereum, 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ụ sửa lỗi EVM và hầu hết cơ sở hạ tầng dành cho nhà phát triển khác.

Có một số ít trường hợp ngoại lệ. Một sự không tương thích phát sinh đối với các ứng dụng xác minh bằng chứng Merkle về lịch sử các khối Ethereum  để xác minh các khiếu nại về các giao dịch, biên lai hoặc trạng thái lịch sử. Một ZK-EVM thay thế Keccak bằng một hàm băm khác sẽ phá vỡ các bằng chứng này.

Tuy nhiên, bạn không nên xây dựng các ứng dụng theo cách này, bởi vì những thay đổi Ethereum trong tương lai (ví dụ: tree Verkle ) 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 là chính Ethereum sẽ bổ sung các bản biên dịch trước truy cập lịch sử bằng chứng trong tương lai .

Nhược điểm: Cải thiện nhưng vẫn còn chậm thời gian chuẩn

ZK-EVM loại 2 cung cấp thời gian chứng minh nhanh hơn Loại 1 chủ yếu bằng cách loại bỏ các phần sắp xếp của Ethereum dựa trên mật mã phức tạp không cần thiết và không thân thiện với ZK. Đặc biệt, họ có thể thay đổi cây Merkle Patricia dựa trên Keccak và RLP của Ethereum và có lẽ cả cấu trúc khối và xác nhận giao dịch.

Thay vào đó, các ZK-EVM loại 2 có thể sử dụng một 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 mã băm và keccak, loại bỏ nhu cầu xác minh băm để xử lý mã EXTCODEHASHvà mã EXTCODECOPY.

Những sửa đổi này cải thiện đáng kể thời gian lý thuyết, nhưng chúng không giải quyết được mọi vấn đề. Sự chậm chạp trong việc phải chứng minh EVM nguyên vẹn, những sự kém hiệu quả và tính không thân thiện với ZK vốn có của EVM, vẫn còn.

Một ví dụ đơn giản về điều này là bộ nhớ: bởi vì một MLOADcó thể đọc bất kỳ 32 byte nào, kể cả các đoạn “không được phân bổ” (trong đó bắt đầu và kết thúc không phải là bội số của 32), MLOAD không thể được hiểu đơn giản là đọc một đoạn; thay vào đó, nó có thể yêu cầu đọc hai đoạn liên tiếp và thực hiện các thao tác byte để kết hợp kết quả.

Ai đang xây dựng nó?

Dự án ZK-EVM của Scroll đang xây dựng hướng tới ZK-EVM Loại 2, cũng như Polygon Hermez . Tức là không có dự án nào là đàn được xây dựng hoàn toàn ở đó; đặc biệt, rất nhiều công việc trước biên dịch phức tạp hơn vẫn chưa được triển khai. Do đó, tại thời điểm này, cả hai dự án nên được coi là Loại 3 thì tốt hơn .

 


Loại 2.5 (tương thích EVM, trừ chi phí gas)

Một cách để cải thiện đáng kể thời gian chứng minh trong trường hợp xấu nhất là tăng đáng kể chi phí gas của các hoạt động cụ thể trong EVM rất khó chứng minh ZK. Điều này có thể liên quan đến quá trình trước biên dịch, opcode KECCAK và có thể gọi là các mẫu hợp đồng cụ thể hoặc truy cập bộ nhớ hoặc bộ lưu trữ hoặc hoàn nguyên.

Thay đổi chi phí gas có thể làm giảm khả năng tương thích của công cụ dành cho nhà phát triển và làm hỏng một vài ứng dụng , nhưng nó thường được coi là ít rủi ro hơn so với những thay đổi EVM “chuyên sâu hơn”.

Các nhà phát triển nên cẩn thận để không yêu cầu nhiều phí gas hơn trong một giao dịch so với lượng phù hợp với một khối, không bao giờ thực hiện lệnh gọi với lượng phí gas được mã hóa cứng (đâ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).

Một cách khác để quản lý các ràng buộc tài nguyên là chỉ cần đặt các giới hạn cứng về số lần mỗi hoạt động có thể được gọi. Điều này dễ thực hiện hơn trong các mạch, nhưng hoạt động kém hơn nhiều với các giả định bảo mật EVM. Cách tiếp cận này nên được gọi là Loại 3 thay vì Loại 2.5.


Loại 3 (gần như tương thích với EVM)

ZK-EVM loại 3 gần như tương thích với EVM, nhưng phải hy sinh một chút để đạt được sự tương đương chính xác nhằm cải thiện hơn nữa thời gian chuẩn hóa và giúp EVM dễ dàng phát triển hơn.

Ưu điểm: Dễ xây dựng hơn và thời gian chứng 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 triển khai ZK-EVM. Công việc trước biên dịch thường ở đầu danh sách này;. Ngoài ra, ZK-EVM Loại 3 đôi khi cũng có những khác biệt nhỏ trong cách chúng xử lý mã hợp đồng, bộ nhớ hoặc sự sắp xếp.

Nhược điểm: Không tương thích nhiều hơn

Mục tiêu của ZK-EVM Loại 3 là tương thích với hầu hết các ứng dụng và chỉ yêu cầu viết lại tối thiểu cho phần còn lại. Tức là sẽ có một số ứng dụng cần phải được viết lại vì chúng sử dụng các bản biên dịch trước mà ZK-EVM Loại 3 loại bỏ hoặc do sự phụ thuộc nhiều vào các trường hợp khác mà máy ảo phải xử lý khác nhau.

Ai đang xây dựng nó?

Scroll và Polygon đều là Loại 3 ở dạng hiện tại, mặc dù chúng được kỳ vọng sẽ cải thiện khả năng tương thích theo thời gian. Polygon có một thiết kế độc đáo trong đó họ đang xác minh ZK bằng ngôn ngữ nội bộ của riêng họ được gọi là zkASM và họ diễn giải mã ZK-EVM bằng cách sử dụng triển khai zkASM.

Bất chấp chi tiết triển khai này, đây vẫn được gọi là ZK-EVM Loại 3 ; nó có thể xác minh mã EVM nhưng nó chỉ sử dụng một số logic bên trong khác để làm điều đó.

Ngày nay, không có nhóm ZK-EVM nào muốn trở thành Loại 3; Loại 3 chỉ đơn giản là một giai đoạn chuyển tiếp cho đến khi công việc phức tạp thêm trước khi biên dịch kết thúc 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 vào các bản biên dịch trước thân thiện với ZK-SNARK mới cung cấp chức năng cho các nhà phát triển với thời gian kiểm chứng và chi phí gas thấp.

 


Loại 4 (Tương thích ngôn ngữ bậc 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 số trung gian mà cả hai đều biên dịch thành) và biên dịch mã nguồn đó sang một số ngôn ngữ được thiết kế rõ ràng để thân thiện với ZK-SNARK .

Ưu điểm: Thời gian chứng minh rất nhanh

Có rất nhiều chi phí mà bạn có thể tránh được bằng cách không chứng minh tất cả các ZK là các phần khác nhau của từng bước thực thi EVM mà bắt đầu trực tiếp từ mã cấp cao hơn.

Các ưu điểm được nói cụ thể trong bài đăng này (so với danh sách gạch đầu dòng lớn bên dưới về các nhược điểm liên quan đến khả năng tương thích), nhưng điều đó không có nghĩa đó là một đánh giá về giá trị! Biên dịch trực tiếp từ các ngôn ngữ cấp cao thực sự có thể giảm đáng kể chi phí và giúp phân cấp bằng cách giúp cho việc trở thành một người chứng minh dễ dàng hơn.

Nhược điểm: Không tương thích nhiều 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 và nó sẽ “hoạt động bình thường”, nhưng có một số cách quan trọng khiến rất nhiều ứng dụng không “bình thường”:

  • Các hợp đồng có thể không có cùng địa chỉ trong hệ thống Loại 4 như trong EVM, vì địa chỉ hợp đồng CREATE2 phụ thuộc vào mã byte chính xác. Điều này phá vỡ các ứng dụng dựa trên “hợp đồng đối chứng” chưa được triển khai, ví ERC-4337,  EIP-2470 và nhiều ứng dụng khác.
  • Mã byte EVM viết tay khó sử dụng hơn. Nhiều ứng dụng sử dụng mã byte EVM viết tay ở một số phần để đạt hiệu quả. Các hệ thống Loại 4 có thể không hỗ trợ nó, mặc dù có nhiều cách để triển khai hỗ trợ mã byte EVM hạn chế 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 ZK-EVM Loại 3 đầy đủ.
  • Rất nhiều cơ sở hạ tầng gỡ lỗi không thể được chuyển sang , bởi vì cơ sở hạ tầng như vậy chạy trên mã byte EVM. Điều đó nói rằng, 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ừ các ngôn ngữ trung cấp hoặc cấp cao “truyền thống” (ví dụ: LLVM).

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

Ai đang xây dựng nó?

ZKSync là một hệ thống Loại 4, mặc dù nó có thể bổ sung khả năng tương thích cho mã byte EVM theo thời gian. Dự án Warp của Nethermind đang xây dựng một trình biên dịch từ Solidity đến Cairo của Starkware, sẽ biến StarkNet thành một hệ thống Loại 4 trên thực tế.

 


6 dự án ZkEVM hàng đầu

 

zksync era jpeg

zkSync

Starkware StarkNet

Starkware StarkNet

Polygon Hermez

Polygon Hermez

 

bridge screenshot.a3464561f387d9ff3295 scaled

Scroll

 

consensys 2020 featured image

Consensys và Infura

Backdrop Matrix Black Horiz 1 jpeg

Taiko

 


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

ZK-EVM vẫn đang trong giai đoạn phát triển ban đầu, nhưng nó đã cho thấy tiềm năng to lớn. Khả năng mở rộng quy mô Ethereum mà không ảnh hưởng đến bảo mật hoặc phân cấp là một yếu tố thay đổi cuộc chơi cho ngành công nghiệp DeFi.

Thật khó để đánh giá các loại ZkEVM cái nào là “tốt hơn” hay “tệ hơn” so với các loại khác. Thay vào đó, chúng là những điểm khác nhau về không gian đánh đổi: các loại có số thứ tự 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 và các loại có số thứ tự 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. Nói chung, nó tốt cho không gian mà tất cả các loại này đang được khám phá.

Ngoài ra, các dự án ZK-EVM có thể dễ dàng bắt đầu ở các loại được đánh số cao hơn và chuyển sang các loại được đánh số thấp hơn (hoặc ngược lại) theo thời gian. Ví dụ:

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

Trong tương lai, chúng ta có thể hy vọng rằng mọi thứ sẽ trở thành Loại 1 theo thời gian, thông qua sự kết hợp giữa các cải tiến trong ZK-EVM và các cải tiến đối với chính Ethereum để làm cho nó trở nên thân thiện với ZK-SNARK hơn. Trong tương lai sẽ có nhiều triển khai ZK-EVM có thể được sử dụng cho cả các bản tổng hợp ZK và để xác minh chính chuỗi Ethereum.

Về mặt lý thuyết, Ethereum không cần phải chuẩn hóa trên một triển khai ZK-EVM duy nhất để sử dụng L1; các khách hàng khác nhau có thể sử dụng các bằng chứng khác nhau, vì vậy chúng ta sẽ tiếp tục hưởng lợi từ việc dự phòng mã.

Tuy nhiên, sẽ mất khá nhiều thời gian cho đến khi chúng ta có được một tương lai như vậy. Trong thời gian chờ đợi, chúng ta sẽ thấy rất nhiều sự đổi mới trong các con đường khác nhau để mở rộng quy mô Ethereum và ZK-rollup dựa trên Ethereum.

Viết một bình luận