Nghe Buterin giải thích về tương lai của các loại ZK-EVM
Tiêu đề gốc: "Các loại ZK-EVM khác nhau"
Nguồn gốc: Trang chủ cá nhân của Vitalik Buterin
Tác giả gốc: Vitalik Buterin
Bản tổng hợp gốc ：Chặn kỳ lân
Gần đây nhiều Các dự án "ZK-EVM" đã đưa ra những thông báo nổi bật. Polygon đã mở dự án ZK-EVM của họ, ZKSync đã phát hành sáng kiến ZKSync 2.0 của họ và Scroll tương đối mới gần đây đã phát hành ZK-EVM của họ. Ngoài ra còn có những nỗ lực không ngừng từ các nhóm khám phá tiện ích và quyền riêng tư, Nicolas Liochon và những người khác, từ EVM đến trình biên dịch alpha của Starkware cho ngôn ngữ thân thiện với zk Cairo và chắc chắn có một số dự án mà tôi sẽ bỏ lỡ.
Mục tiêu cốt lõi của tất cả các dự án này là như nhau: Sử dụng công nghệ ZK-SNARK để bảo mật các giao dịch giống Ethereum. bằng chứng mật mã, giúp việc xác minh chính chuỗi Ethereum dễ dàng hơn hoặc xây dựng một bản tổng hợp zk (gần giống) giống như những gì Ethereum cung cấp nhưng có khả năng mở rộng cao hơn. Nhưng có những khác biệt nhỏ giữa các dự án này và sự cân bằng giữa tính thực tế và tốc độ của chúng. Bài viết này sẽ cố gắng mô tả cách phân loại các "loại" tương đương EVM khác nhau, cũng như lợi ích và chi phí của việc cố gắng triển khai từng loại.
Tổng quan (dạng biểu đồ)
Loại 1 (hoàn toàn tương đương với Ethereum)
Loại 1 ZK - EVM phấn đấu để đạt được sự tương đương hoàn toàn và không khoan nhượng với Ethereum. Họ không thay đổi bất kỳ phần nào của hệ thống Ethereum để tạo ra 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, biên dịch trước hoặc bất kỳ logic đồ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 thực các khối Ethereum như chúng tôi hiện tại hoặc ít nhất là xác thực lớp thực thi (vì vậy logic đồng thuận của Beacon Chain không được bao gồm, nhưng tất cả việc thực thi giao dịch và trí thông minh đều được bao gồm hợp đồng và logic tài khoản).
ZK-EVM Loại 1 là thứ cuối cùng chúng tôi cần để làm cho Ethernet Lớp 1 có khả năng mở rộng dễ dà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 chính Ethereum, nhưng việc thiết kế lại như vậy đi kèm với những phức tạp riêng.
ZK-EVM loại 1 cũng lý tưởng cho việc tổng hợp vì chúng cho phép triển khai để tái sử dụng một lượng lớn cơ sở hạ tầng. Ví dụ: ứng dụng khách Thực thi Etherum có thể được sử dụng nguyên trạng để tạo và xử lý các khối ROLLUP (hoặc ít nhất, sau khi triển khai trích xuất, chúng có thể được sử dụng lại và chức năng có thể được sử dụng lại để hỗ trợ ETH gửi vào ROLLUP), do đó khối tài nguyên Các công cụ như người quản lý và nhà sản xuất khối rất dễ sử dụng lại.
Nhược điểm: Thời gian xác minh
Ethereum ban đầu không được thiết kế theo hướng thân thiện với ZooKeeper, vì vậy nhiều phần của giao thức Ethereum yêu cầu tính toán rộng rãi để xác minh ZooKeeper. Loại 1 nhằm mục đích sao chép hoàn toàn Ethereum, vì vậy nó không có cách nào để giảm thiểu sự thiếu hiệu quả này. Hiện tại, bằng chứng cho các khối Ethereum phải mất nhiều giờ để tạo ra. Tình trạng này có thể được giảm thiểu bằng kỹ thuật thông minh để song song hóa quy mô lớn bộ xác nhận hoặc về lâu dài bằng các mạch tích hợp dành riêng cho ứng dụng ZK-SNARK.
Ai là người xây dựng?
Nhóm khám phá quy mô và quyền riêng tư ZK-EVM đang xây dựng ZK-EVM Loại 1.
Loại 2 (hoàn toàn tương đương với EVM)
ZK loại 2 - EVM phấn đấu để hoàn toàn tương đương với EVM, nhưng không hoàn toàn tương đương 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, chẳng hạn 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 bằng chứng nhanh hơn.
Ưu điểm: Tính chẵn lẻ hoàn toàn ở cấp độ máy ảo
ZK-EVM loại 2 thực hiện các thay đổi đối với cấu trúc dữ liệu để lưu trạng thái Ether và các nội dung khác. May mắn thay, bản thân EVM không thể truy cập trực tiếp vào các cấu trúc này, vì vậy các ứng dụng hoạt động trên Etherum hầu như sẽ luôn hoạt động trên các bản tổng hợp ZK-EVM loại 2. Bạn sẽ không thể sử dụng các ứng dụng khách 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ơ sở hạ tầng dành cho nhà phát triển khác.
Nhưng vẫn có một số trường hợp ngoại lệ. 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ề các khối Ethereum lịch sử để 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ử (ví dụ: các cầu nối đôi khi thực hiện việc này). Việc thay thế ZK-EVM của 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, tôi thường khuyên bạn không nên xây dựng các ứng dụng theo cách này, vì những thay đổi của Ethereum trong tương lai (ví dụ: Verkle Trees) có thể phá vỡ các ứng dụng đó ngay cả trên chính Ethereum. Một giải pháp thay thế tốt hơn cho chính Ethereum sẽ là thêm tính năng biên dịch trước truy cập lịch sử đáng tin cậy trong tương lai.
Nhược điểm: Thời gian xác minh được cải thiện nhưng vẫn còn chậm
ZK-EVM loại 2 cung cấp thời gian xác minh nhanh hơn Loại 1, chủ yếu bằng cách loại bỏ nhu cầu dựa vào phần mã hóa ZK phức tạp và không thân thiện không cần thiết của Ethereum. Đặc biệt, họ có thể thay đổi cây Merkle Patricia dựa trên Keccak và RLP của Etherum, cũng như có thể cả cấu trúc khối và nhận. ZK-EVM loại 2 có thể sử dụng các hàm băm khác nhau, 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 trữ các mã băm và keccak, loại bỏ nhu cầu xác minh các hàm băm để xử lý các 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 giải quyết được mọi vấn đề. Quá trình chứng minh EVM hiện tại vẫn còn chậm do tính kém hiệu quả vốn có và tính thân thiện bằng không. Một ví dụ đơn giản là bộ nhớ: vì MLOAD có thể đọc bất kỳ 32 byte nào, kể cả các khối "không được sắp xếp" (trong đó phần đầu và phần cuối không phải là bội số của 32), MLOAD không thể hiểu đơn giản là đọc một khối, thay vào đó, nó có thể cần hai khối liên tiếp; được đọc và thực hiện các thao tác bit để kết hợp các kết quả.
Ai là người xây dựng?
Dự án ZK-EVM của Scroll đang hướng tới ZK-EVM Loại 2, giống như Polygon Hermez. Điều đó có nghĩa là cả hai dự án đều chưa hoàn thành (không có công việc ZKEVM nào được thực hiện); đặc biệt, phần lớn quá trình biên dịch trước phức tạp hơn vẫn chưa được triển khai. Vì vậy, tốt nhất hiện nay nên xem xét Loại 3 cho cả hai dự án.
loại 2,5 (tương đương EVm, chưa bao gồm chi phí gas)
Một cách để cải thiện đáng kể 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 hoạt động cụ thể khó chứng minh trong EVM. Điều này có thể liên quan đến quá trình biên dịch trước, mã opcode KECCAK và có thể liên quan đến các quy ước gọi điện hoặc các chế độ truy cập bộ nhớ, lưu trữ hoặc khôi phục cụ thể.
Việc thay đổi chi phí gas có thể khiến các công cụ dành cho nhà phát triển kém tương thích hơn và làm hỏng một số ứng dụng, nhưng thường được coi là ít rủi ro hơn so với "sâu hơn" "EVM thay đổi. Các nhà phát triển nên cẩn thận để không yêu cầu nhiều gas hơn trong một giao dịch so với dung lượng khối và không thực hiện lệnh gọi với lượng 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).
Loại 3 (gần giống với EVM)
Zk-EVM loại 3 gần như tương đương với EVM, nhưng để giống hệt nhau, cần phải hy sinh một số điều để cải thiện hơn nữa thời gian xác minh và làm cho EVM dễ dàng hơn phát triển .
Ưu điểm: dễ xây dựng hơn, thời gian xác minh nhanh hơn
h4>
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 ZK - Triển khai EVM. Ở đây, quá trình biên dịch trước thường nằm ở đầu danh sách; đồng thời, ZK-EVM loại 3 đôi khi có những khác biệt nhỏ về cách chúng xử lý mã hợp đồng, bộ nhớ hoặc ngăn xếp.
Nhược điểm: không tương thích nhiều hơn
ZK-EVM loại 3 nhằm mục đích tương thích với hầu hết các ứng dụng, phần còn lại yêu cầu viết lại ở mức tối thiểu. Điều đó có nghĩa là, một số ứng dụng sẽ cần phải được viết lại, vì chúng sử dụng tính năng biên dịch trước loại bỏ ZK-EVM loại 3 hoặc do sự phụ thuộc tinh tế vào các trường hợp biên được EVM xử lý khác nhau.
Ai là người xây dựng?
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ó thiết kế độc đáo ở chỗ chúng xác thực ngôn ngữ nội bộ của riêng mình, zkASM, bằng ZK và sử dụng triển khai zkASM để diễn giải mã ZK-EVM. Bất chấp chi tiết triển khai này, tôi vẫn gọi nó là Type3ZK-EVM thực sự; nó vẫn xác minh mã EVM, nó chỉ sử dụng một số logic nội bộ khác để thực hiện điều đó.
Ngày nay, không nhóm ZK-EVM nào muốn trở thành Loại 3; được thêm vào Công việc đã hoàn thành và dự án có thể được 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 trình biên dịch trước thân thiện với ZK-SNARK mới, cung cấp cho các nhà phát triển 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)
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ố ngôn ngữ trung gian được biên dịch sang cả hai) và biên dịch nó thành 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 xác minh rất nhanh
Có thể tránh được nhiều chi phí 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 từng bước thực thi EVM và bắt đầu trực tiếp với mã cấp cao hơn .
Tôi mô tả ưu điểm này (kết hợp với những nhược điểm liên quan đến khả năng tương thích bên dưới) chỉ trong một câu trong danh sách Bullet so sánh. ), nhưng điều này không nên được hiểu là một phán đoán giá trị! Việc biên dịch trực tiếp từ một ngôn ngữ cấp cao sẽ giúp giảm đáng kể chi phí và giúp phân cấp bằng cách giúp việc trở thành người chứng minh trở nên 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" viết bằng Vyper hoặc Solidity có thể được biên dịch và nó sẽ "chỉ hoạt động", nhưng có một số cách quan trọng mà nhiều ứng dụng không "chỉ hoạt động" ":
1. Đị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ỉ giao thức 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 phản thực tế” chưa được triển khai, ví ERC-4337, đơn lẻ EIP-2470 và nhiều ứng dụng khác.
2. Mã byte EVM viết tay khó sử dụng hơn. Để nâng cao hiệu quả, nhiều ứng dụng sử dụng mã byte EVM viết tay cho một số phần nhất định. 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 cố gắng trở thành Type3ZK-EVM đầy đủ.
3. Nhiều cơ sở hạ tầng gỡ lỗi không thể tiếp tục vì các cơ sở hạ tầng này chạy ở mã byte EVM vượt trội. Điều đó có nghĩa là, thiếu sót 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ữ cấp cao hoặc trung cấp "truyền thống" (ví dụ: LLVM).
Các nhà phát triển nên nhận thức được những vấn đề này.
Ai là người xây dựng?
ZKSync là hệ thống loại 4, mặc dù theo thời gian, nó có thể bổ sung khả năng tương thích với giới tính mã byte EVM. Dự án Warp của NetherMind đang xây dựng trình biên dịch Cairo từ Solidity đến Starkware để biến StarkNet thành hệ thống Loại 4 trên thực tế.
Tương lai của loại ZK-EVM
Những loại này không rõ ràng là "tốt hơn" hay "xấu hơn" so với các loại khác. Đúng hơn, chúng là những điểm khác nhau trong không gian đánh đổi: các loại ít khó mã hóa hơn thì tương thích hơn với cơ sở hạ tầng hiện có nhưng chậm hơn; các loại khó mã hóa hơn thì ít tương thích hơn với cơ sở hạ tầng hiện có nhưng lại nhanh hơn. Nhìn chung, việc có tất cả những kiểu người này khám phá là điều tốt cho lĩnh vực này.
1. ZK-EVM có thể bắt đầu từ loại 3, quyết định không đưa vào một số tính năng đặc biệt khó chứng minh ZK. Sau này, họ có thể thêm các tính năng này theo thời gian và chuyển sang Loại 2.
2.ZK-EVM có thể bắt đầu từ loại 2 và sau đó cung cấp chế độ tương thích Ethernet đầy đủ bằng Possibility để chạy ZK-EVM lai loại 2/loại 1 hoặc sử dụng cây trạng thái đã sửa đổi để có thể được chứng minh nhanh hơn. Sroll đang cân nhắc việc đi theo hướng này.
3. Hệ thống bắt đầu bằng Loại 4 có thể trở thành Loại 3 theo thời gian vì sau này đã thêm khả năng xử lý mã EVM (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 chi phí và thời gian xác minh).
4. Nếu bản thân Etherum áp dụng các sửa đổi của mình trong nỗ lực trở nên thân thiện hơn với ZK, thì hãy nhập ZK-EVM Loại 2 hoặc Loại 3 có thể trở thành ZK-EVM Loại 1.
5. ZK-EVM Loại 1 hoặc Loại 2 có thể được xác minh bằng cách thêm Mã tiền biên dịch vào ngôn ngữ thân thiện với ZK-SNARK, do đó trở thành ZK-EVM loại 3. Điều này sẽ cho phép các nhà phát triển lựa chọn giữa khả năng tương thích và tốc độ Ethernet, nó sẽ là loại 3 vì nó phá vỡ tính chẵn lẻ của EVM hoàn hảo, nhưng đối với tất cả các mục đích thực tế, nó sẽ có nhiều lợi ích loại 1 và loại 2. Hạn chế chính có thể là một số công cụ dành cho nhà phát triển không hiểu quá trình biên dịch trước tùy chỉnh của ZK-EVM, mặc dù điều này có thể khắc phục được: các công cụ dành cho nhà phát triển có thể thêm hỗ trợ biên dịch trước chung bằng cách hỗ trợ định dạng cấu hình bao gồm các triển khai tương đương của mã EVM được biên dịch trước.
Cá nhân tôi hy vọng rằng theo thời gian, mọi thứ sẽ trở thành loại 1, bởi cải thiện ZK-EVM và cải thiện chính Ethereum để phù hợp hơn với ZK-Snark. Trong tương lai như vậy, chúng tôi sẽ có nhiều triển khai ZK-EVM, cho cả việc tổng hợp ZK và để xác thực chính chuỗi Ethereum. Về lý thuyết, Ethereum không cần phải tiêu chuẩn hóa trên một triển khai ZK-EVM duy nhất được L1 sử dụng; 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 tôi tiếp tục được hưởng lợi từ việc dự phòng mã.
Tuy nhiên, chúng ta sẽ mất khá nhiều thời gian để đạt được một tương lai như vậy. Đồng thời, chúng ta sẽ thấy rất nhiều sự đổi mới trong các cách khác nhau để mở rộng quy mô của Ethereum và các bản ZK dựa trên Ethereum.
Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:
Nhóm Telegram đăng ký: https://t.me/theblockbeats
Nhóm Telegram thảo luận: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia
Bài viết liên quan
