Tổng quan về tiến độ của các dự án zkEVM lớn vào năm 2023

Tác giả: Alex Connolly, đồng sáng lập và CTO của Immutable; Bản dịch: Golden Finance xiaozou

Vào tháng 8 năm 2022, tôi đã viết một bài đăng trên blog về trạng thái phát triển hiện tại của zkEVM, có tiêu đề "Hướng dẫn cơ bản về tính tương thích và tổng hợp của ZkEVM, EVM" (Hướng dẫn cơ bản về zkEVM, Khả năng tương thích và tổng hợp EVM). Trong cùng tuần đó, V God đã xuất bản một bài báo giới thiệu các loại zkEVM khác nhau và thiết lập cách phân loại Loại 1 và Loại 2. Ngày nay, các loại zkEVM khác nhau thường được gọi là các loại khác nhau - sự cạnh tranh rất khốc liệt!

Trong bài đăng trên blog đó, tôi đã đưa ra dự đoán sau:

.. .Bạn cũng nên hiểu rõ về trạng thái hiện tại của hợp đồng thông minh rollup. Mỗi nhóm đều có động lực mạnh mẽ để tiếp thị mình là đội sắp thống trị thế giới - nhưng phải đến sớm nhất >Hợp đồng thông minh cấp sản xuất sẽ không xuất hiện trên Ethereum cho đến cuối năm 2022 và nhiều hợp đồng trong số đó những đội này sẽ không xuất hiện cho đến 2023 Sẽ sẵn sàng vào cuối năm nay.

Chúng ta hiện đã đi đến "cuối năm 2023" - quá trình phát triển và áp dụng zkEVM như thế nào? Đây là một năm quan trọng đối với zkEVM về nhiều mặt:

· Polygon zkEVM, Linea và Scroll được phát hành!

· Immutable thông báo đợt giới thiệu tiếp theo - Immutable zkEVM

· Polygon được công bố có kế hoạch nâng cấp Polygon PoS lên zkEVM Validium

· Optimism đã nêu kế hoạch hỗ trợ chuỗi OP Stack chạy dưới dạng zkEVM

Dù thế nào đi nữa, dữ liệu cũng có thể tự giải thích:

Tóm lại, việc phát triển zkEVM đang diễn ra nhưng không có trong sốzkEVM đã được áp dụng rộng rãi so với các blockchain hiện có. Mục đích của bài viết này là để trả lời một câu hỏi rõ ràng -Các dự án zkEVM khác nhau đang tiến triển như thế nào và chúng có thể thu hút được sự chú ý như thế nào?

Trước hết, chúng ta hãy xem nhanh “loại zkEVM” của Buterin để giúp hiểu dự án zkEVM:

Điều này có vẻ phức tạp nhưng thực ra rất dễ hiểu. Ban đầu, mọi người đều nghĩ trong đầu rằng zkEVM chỉ sử dụng một ứng dụng khách thực thi Ethereum hiện có (ví dụ: Geth, Nethermind, Erigon), tạo ra bằng chứng zk (không có kiến ​​thức) về dấu vết thực thi của nó và sử dụng những bằng chứng này để bảo mật việc bắc cầu thông báo L1-L2. Tuy nhiên, những cân nhắc về thiết kế ban đầu của EVM không bao gồm bằng chứng zk và cách tiếp cận này rất kém hiệu quả (ví dụ: hàm băm keccak của Ethereum rất đắt tiền). Vì vậy, chúng tôi có một số lựa chọn:

· Loại 1  – Cứ xử lý đi, người dùng của tôi/Tôi sẽ trả tiền . Có hai ưu điểm chính ở đây: bạn có thể sử dụng Nhà cung cấp loại 1 của blockchain hiện có và bạn không cần duy trì ứng dụng khách Ethereum của riêng mình (chi phí phát triển có thể cao bằng chi phí chứng minh), nhưng bạn phải duy trì Thực hiện cập nhật ứng dụng khách .

· Loại 2 -- không chạm vào "lớp ứng dụng" (ví dụ: không thay đổi chi phí opcode/ triển khai) nhưng thay đổi các nút trên chuỗi để có cấu trúc bên trong thân thiện hơn với người hoạt động (ví dụ: sử dụng cây Merkle thưa thớt để biểu thị trạng thái). Một nhược điểm lớn của phương pháp này là bạn cần duy trì ứng dụng khách Ethereum được phân nhánh vĩnh viễn. Xem xét rằng Ethereum đã phải vật lộn để duy trì nhiều khách hàng cấp sản xuất, đây là một nhiệm vụ rất quan trọng đòi hỏi một đội ngũ kỹ sư blockchain tận tâm.

· Loại 3 – Hoàn thành tất cả công việc trong Loại 2, sửa đổi EVM cùng lúc và xóa phần khó chứng minh nhất (ví dụ: một số phần biên dịch trước hiếm khi được sử dụng), điều này có thể làm tăng chi phí opcode của các hoạt động chuyên sâu về trình chứng minh. Đây là cách nhanh nhất để đưa sản phẩm chứng minh của bạn ra thị trường, nhưng bạn sẽ cần thực hiện tất cả các cập nhật ứng dụng khách được đề cập ở trên và gặp phải sự không tương thích với các ứng dụng và công cụ Ethereum hiện có (ví dụ: mọi hợp đồng sử dụng các công cụ biên dịch trước này sẽ bị phá vỡ).

· Loại 4 --Tạo một VM tùy chỉnh được thiết kế để chứng minh zk hiệu quả, đồng thời tạo và chạy tùy chỉnh A khách mời của VM. Điều này sẽ giảm đáng kể chi phí xác minh, nhưng yêu cầu xây dựng một hệ sinh thái lớn gồm các công cụ và cơ sở hạ tầng để hỗ trợ VM/khách tùy chỉnh của bạn. Bạn có thể cung cấp một số hình thức chuyển đổi mã Solidity, nhưng các nhà phát triển có thể phải thực hiện những thay đổi đáng kể đối với các hợp đồng và công cụ hiện có của họ để triển khai trên chuỗi của bạn. Theo ý kiến ​​​​của tôi, hầu hết các bản tổng hợp Loại 4 đều không đúng zkEVM - "hợp đồng thông minh zk-rollup" có thể là một mô tả chính xác hơn.

Có thể dễ hiểu hơn ở dạng bảng:

Cuối năm 2023, hầu như mọi dự án đang hoạt động Cả hai đều là Loại 3 hoặc Bản tổng hợp Loại 4 vì một lý do đơn giản: chúng được xây dựng nhanh hơn nhiều (với chi phí về khả năng tương thích và chi phí bảo trì ngày càng tăng)! Điều thú vị là, hầu hết tất cả các dự án hiện thuộc Loại 3 đều có kế hoạch trở thành bản tổng hợp Loại 2 hoặc Loại 1 để cải thiện khả năng tương thích với Ethereum và có khả năng loại bỏ nhu cầu phát triển ứng dụng khách của riêng họ.

Trong bài đăng trên blog năm ngoái, tôi chủ yếu tập trung vào cách các nhóm zkEVM khác nhau thiết kế bộ chứng minh của họ. Năm nay, tôi muốn đề cập đến các khía cạnh quan trọng khác trong cách tiếp cận của từng dự án, bao gồm cả những khía cạnh không thường được thảo luận (chẳng hạn như từng kế hoạch khách hàng thực thi zkEVM). Ví dụ: nhiều người nghĩ L2 như một "trình sắp xếp chuỗi" và trình xác minh, trong khi thiết kế zkEVM tiêu chuẩn thực sự trông giống thế này hơn!

p>

Có các thiết kế trình sắp xếp chuỗi khác (chúng ta sẽ thảo luận sau), nhưng hầu hết các zkEVM hiện có kế hoạch chạy một chuỗi khối riêng biệt dưới dạng trình sắp xếp chuỗi L2, với ứng dụng khách thực thi Riêng ( nhận và thực hiện các giao dịch) và khách hàng đồng thuận (đạt được sự đồng thuận về thứ tự giao dịch trên tất cả các nút L2).

Điều quan trọng là phải trả phí khi sửa đổi ứng dụng khách Ethereum tiêu chuẩn để tạo chuỗi tùy chỉnh của riêng bạn. Mỗi thay đổi của ứng dụng khách Ethereum (đặc biệt là mỗi đợt hard fork) sẽ là một quyết định quản trị đối với tất cả các nhóm zKEVM. Bạn càng tùy chỉnh nhiều phần thì càng khó thực hiện các thay đổi ngược dòng. Theo thời gian, rất dễ phát triển tính không đồng bộ của zkEVM - đến một thời điểm nhất định, zkEVM phù hợp với Ethereum sẽ nhanh chóng không đồng bộ.

1, zkEVMTrạng thái dự án

Vậy còn những dự án mà chúng ta đã thảo luận năm ngoái thì sao?

(1) Polygon zkEVM (và chuỗi Polygon CDK)< /p>

Polygon zkEVM được ra mắt trên mạng chính vào tháng 3 năm 2023 và cho đến nay đã xử lý gần 10 triệu giao dịch. Nó hiện là Loại 3, với mục tiêu trở thành Loại 2 vào năm 2024.

Tất nhiên, với tư cách là Loại 2/3, Polygon zkEVM yêu cầu triển khai ứng dụng khách tùy chỉnh của riêng nó. Polygon đã chọn xây dựng ứng dụng khách của riêng mình (nút zkevm) từ đầu để có khả năng tương thích, nhưng ứng dụng khách mới này đã gặp phải tình trạng ngừng hoạt động và thiếu nhiều tính năng có trong các ứng dụng khách Ethereum tiêu chuẩn.

Để khắc phục điều này, Polygon đang hợp tác với Gateway.fm để sửa đổi Erigon (trước đây là turbo-geth) nhằm hỗ trợ những thay đổi cần thiết cho bộ chuẩn Loại 2/3. Điều này sẽ cung cấp cho Polygon zkEVM một lớp cơ sở ổn định hơn và hiệu suất được tối ưu hóa hơn, mặc dù việc duy trì khả năng tương thích với Erigon ngược dòng vẫn là một thách thức đang diễn ra.

Nhiều nhóm cũng đã thông báo rằng họ sẽ sử dụng Bộ công cụ phát triển chuỗi đa giác (CDK) để xây dựng zkEVM, bao gồm Astar, OKX và Palm Network. Tầm nhìn của Polygon CDK là hỗ trợ các nhà phát triển xây dựng chuỗi tùy chỉnh của riêng họ theo nhu cầu của họ bằng cách kết hợp các khách hàng, nhà cung cấp và giải pháp sẵn có dữ liệu khác nhau (tức là xây dựng bộ công cụ zkEVM của riêng họ). Ngày nay, CDK hỗ trợ triển khai ứng dụng khách (nút zkevm) và bộ chuẩn (Polygon zkEVM). Trong tương lai, nhóm Polygon có kế hoạch bổ sung thêm nhiều triển khai ứng dụng khách (chẳng hạn như Type-2-Erigon) và bộ chứng minh (chẳng hạn như Polygon Zero) vào CDK.

p>

Điều này có nghĩa là bạn có thể triển khai phiên bản Polygon zkEVM của riêng mình ngay hôm nay! Tuy nhiên, bất kỳ nhóm nào triển khai với nút zkevm đều có thể cần di chuyển sang các ứng dụng khách khác trong tương lai, vì vậy có thể đợi cho đến khi họ sẵn sàng.

Chúng ta cũng cần lưu ý rằng Polygon đang có kế hoạch nâng cấp Polygon PoS (một trong những blockchain lớn nhất và thành công nhất trên thế giới) lên blockchain có dữ liệu ngoài chuỗi zkEVM nhưng lịch nâng cấp cụ thể vẫn chưa được xác định.

(2)Cuộn

Năm 2023, Scroll ra mắt hai mạng thử nghiệm và một mạng chính (tháng 10) - đây là năm xây dựng quy mô lớn! Scroll hiện là zkEVM Loại 3. Trước đây họ đã tuyên bố rằng họ có ý định chuyển đổi sang Loại 1/2 trong tương lai, nhưng thời gian cụ thể thì chưa rõ. Họ có một danh sách các điểm khác biệt so với Ethereum, bao gồm một số phần biên dịch trước chưa được triển khai và một số sửa đổi trạng thái nhỏ. Ứng dụng khách của Scroll là một nhánh của Geth v1.10.13 và hiện đang chạy ở chế độ trình tự sắp xếp đơn. Điều đáng chú ý là các bộ phận của ứng dụng thực thi của Scroll đã chậm hơn Ethereum hai năm (mặc dù họ đã chọn EIP cho ứng dụng khách thực thi Thượng Hải để giảm sai lệch lớp ứng dụng). Điều này không gây ra bất kỳ sự gián đoạn trực tiếp nào cho chuỗi, nhưng là dấu hiệu cho thấy những thách thức quản trị mà nhiều dự án sẽ phải đối mặt trong việc xác định mức độ tiến gần của Ethereum về lâu dài và cần bao nhiêu nỗ lực kỹ thuật để liên tục thu hẹp khoảng cách đó.

(3)ZkEVM bất biến

Kể từ tháng 7, zkEVM bất biến đã có mạng thử nghiệm công khai và có kế hoạch ra mắt mạng chính vào tháng 1. ZkEVM bất biến sử dụng phiên bản ứng dụng khách go-ethereum tiêu chuẩn đã được tùy chỉnh cho miền cốt lõi (trò chơi) của chúng tôi. Điều thú vị là cho đến nay, zkEVM bất biến là zkEVM dành riêng cho miền duy nhất được thảo luận trong bài viết này, mặc dù khả năng L2 được tùy chỉnh theo yêu cầu của từng miền cụ thể trong khi vẫn duy trì tính bảo mật của Ethereum là điểm thu hút chính của chúng. Ví dụ: zkEVM bất biến là nội dung sử dụng tính khả dụng của dữ liệu validium để giảm chi phí và chọn thiết kế PoSBFT cuối cùng một khối để cung cấp các xác nhận gần như ngay lập tức, các quyết định có thể không phù hợp với chuỗi có mục đích chung. Ngoài ra, nếu một số lượng lớn trò chơi và người dùng trò chơi đổ xô vào chuỗi này, có thể sẽ có hiệu ứng mạng - chúng tôi hy vọng sẽ có nhiều L2 theo miền cụ thể hơn xuất hiện trong tương lai.

Tuy nhiên, việc phát hành chuỗi này sẽ không cung cấp hỗ trợ cho người chứng minh. Điều này là do zkEVM bất biến có kế hoạch áp dụng bộ chứng minh Polygon Zero Loại 1 khi chúng có sẵn và tiết kiệm chi phí. Cách duy nhất để Immutable phát hành Loại 3 là thực hiện những thay đổi đáng kể đối với ứng dụng khách, điều mà chúng tôi không sẵn lòng thực hiện do tác động của việc ứng dụng khách rời xa Ethereum. Ngày nay, Polygon Zero được cung cấp bởi Plonky-2, trong đó Plonky-3 đang được phát triển tích cực và dự kiến ​​sẽ đạt cấp độ sản xuất vào giữa đến cuối năm 2024, điều này sẽ cải thiện hiệu suất lên khoảng một bậc. Điều này sẽ cung cấp cho Polygon hai bộ chuẩn độc lập (Polygon Zero và Polygon zkEVM) và các nhà phát triển sẽ có thể chọn bộ chuẩn nào để sử dụng trong chuỗi dựa trên CDK của họ.

(4)Linea

Linea đã phát hành mạng chính của họ vào tháng 8 và áp dụng cách tiếp cận tương tự với Polygon/Scroll: bắt đầu với bản tổng hợp Loại 3 và dần dần chuyển sang Loại 1 hoặc Loại 2. Linea hiện khác với Ethereum London chỉ ở một số điểm, như được hiển thị trong bảng.

Linea đang sử dụng phiên bản Geth cập nhật của riêng họ và họ đặt tên là "zkGeth". Điều đáng lưu ý là mã nguồn của ứng dụng khách này không phải là mã nguồn mở, cũng không phải là mã nguồn mở - người dùng không thể xác minh rằng chúng chạy như mong đợi. Họ có kế hoạch mở nguồn tất cả các thành phần này như một phần của lộ trình phân quyền được ghi chép rõ ràng của họ. Tài liệu của Linea chỉ ra rằng họ dự định chuyển từ "zkGeth" sang linea-besu, một phiên bản cập nhật của ứng dụng khách Besu do Consensys phát triển. Trong trung hạn, nhóm Linea có kế hoạch hợp nhất linea-besu và besu thông thường, đồng thời dựa vào hệ thống plugin của Besu để thực hiện các sửa đổi trạng thái cần thiết để trở thành zkEVM Loại 2.

（5)Taiko

Taiko đang hoàn thiện mạng thử nghiệm thứ năm của họ và có kế hoạch ra mắt mạng chính vào năm tới. Taiko đang phát triển trình chứng minh zk của riêng họ dựa trên việc triển khai PSE (tương tự như Scroll). Điều thú vị là Taiko là nhóm duy nhất trong bài viết này hiện không xem xét mẫu thiết kế phân cấp dần dần một người đặt hàng thành chuỗi khối L2. Thiết kế của Taiko dựa trên khái niệm Dựa trên Rollup được mô tả bởi Justin Drake - thay vì có một bộ trình xác thực được cấp phép, bất kỳ ai cũng có thể gửi gói giao dịch và bằng chứng tới Ethereum L1. Việc triển khai này có nghĩa là việc tổng hợp ủy quyền hoàn toàn việc đặt hàng cho Ethereum L1, cho phép nó tự động kế thừa các tính năng phân cấp và phân quyền của Ethereum L1. Tuy nhiên, nó có một nhược điểm quan trọng: trình sắp xếp chuỗi L2 không cung cấp xác nhận "cuối cùng nhanh", điều đó có nghĩa là người dùng phải chờ xác nhận giao dịch lâu hơn. Justin Drake đã đề xuất cơ chế "Xác nhận trước dựa trên" để cung cấp xác nhận xác suất với độ trễ chỉ 100 mili giây, nhưng không gần với mức sản xuất và đưa ra hệ thống "cam kết trước (xác nhận trước)" và "mẹo preconf" riêng biệt. Có thể có tác động trên các công cụ Ethereum hiện có. Đây là một lĩnh vực nghiên cứu tích cực!

Taiko đã tuyên bố ngay từ đầu rằng họ dự định trở thành zkEVM Loại 1. Họ tin rằng sự khác biệt về khả năng tương thích do các zkEVM khác mang lại sẽ tệ hơn chi phí tạo bằng chứng cao hơn và trong mọi trường hợp, khi công nghệ tiến bộ, chi phí cuối cùng sẽ giảm. Việc triển khai ứng dụng khách của Taiko rất thú vị - "ứng dụng khách thực thi" cốt lõi là Geth v1.13 đã được sửa đổi (taiko-geth). Tuy nhiên, họ cũng duy trì "khách hàng đồng thuận" (taiko-client) của riêng mình, xử lý việc liên lạc với L1 và giám sát quá trình đặt hàng dựa trên.

p>

(6)Kỷ nguyên zkSync

Kỷ nguyên zkSync được phát hành vào tháng 3 năm 2023 và đã thành công cho đến nay, với những tin đồn về đợt airdrop sắp tới đã đẩy TVL của nó lên hơn 500 triệu USD. zkSync là zkEVM Loại 4, họ đang kiểm tra VM (eraVM) tùy chỉnh của riêng mình thay vì cố gắng sửa đổi EVM trực tiếp. Họ hướng tới "khả năng tương thích ở cấp độ ngôn ngữ" với Ethereum và cung cấp trình biên dịch trực tiếp từ mã Solidity đến VM tùy chỉnh của họ. Họ đã thực hiện những thay đổi đáng kể đối với việc triển khai nhiều mã opcode EVM chính, đồng thời cũng thực hiện một số thay đổi đối với quy trình biên dịch, do đó, các nhà phát triển thường cần sửa đổi hợp đồng hoặc tập lệnh triển khai của họ để triển khai trên Kỷ nguyên zkSync.

zkSync Era có ứng dụng khách tùy chỉnh riêng, cho phép họ triển khai các tính năng không phải EVM như trừu tượng hóa tài khoản gốc. Vào tháng 7 năm 2023, họ đã nâng cấp trình chứng minh lên "Boojum", đây là một hệ thống chứng minh STARK, sau đó sử dụng gói SNARK để xác minh trên chuỗi, tương tự như Polygon zkEVM. Kỷ nguyên zkSync yêu cầu đầy đủ dữ liệu trên chuỗi, nhưng họ có kế hoạch giới thiệu “zkPorter” trong tương lai, điều này sẽ cho phép người dùng lựa chọn giữa các mô hình sẵn có dữ liệu khác nhau ở các mức giá khác nhau, tương tự như mô hình Volition do StarkWare đề xuất.

p>

(7)StarkNet

StarkNet là một trong những dự án đầy tham vọng nhất trong hệ sinh thái Ethereum: họ đang xây dựng hệ sinh thái và tổng hợp Loại 4 từ đầu, bao gồm VM mới (CairoVM), ngôn ngữ lập trình mới (Cairo), bộ chứng minh mới (Stone) và khách hàng mới (Pathfinder, Papyrus, Juno). StarkNet sẽ dần dần mở cửa vào năm 2021 và 2022 và hiện có hơn 150 triệu đô la Mỹ TVL và khối lượng xử lý hàng tháng là hơn 10 triệu giao dịch.

Xây dựng một hệ sinh thái mới từ đầu là vô cùng thách thức nhưng cũng mang lại cơ hội đổi mới cơ bản trong các lĩnh vực mà EVM đang làm việc chăm chỉ (chẳng hạn như trừu tượng hóa tài khoản gốc) và đáng kể hiệu suất được cải thiện. Phần lớn chuỗi công cụ đã được thử nghiệm rộng rãi thông qua các dự án dựa trên StarkEx như Immutable X, dydx v3 và Sorare, đã chạy từ năm 2020 và được áp dụng rộng rãi.

Ban đầu, hệ sinh thái StarkNet khám phá khả năng tương thích ở cấp độ ngôn ngữ thông qua các dự án như Warp Solidity→Cairo Translator mà tôi đã đề cập năm ngoái. Tuy nhiên, Warp hiện không được dùng nữa và hệ sinh thái StarkNet đã quyết định cam kết hoàn toàn với bộ công cụ CAIRO mới và không còn hỗ trợ bất kỳ loại khả năng tương thích ngược nào của Solidity nữa. Giờ đây, họ phải đối mặt với những thách thức tương tự như các hệ sinh thái không phải EVM như Solana hay Sui - bạn có thể thu hút nhiều nhà phát triển áp dụng công cụ mới của mình không? Hay EVM sẽ chiếm ưu thế nói chung?

Công việc đang được nhóm Kakarot thực hiện là ngoại lệ duy nhất. Họ đang phát triển EVM Loại 2.5 sử dụng ngôn ngữ CAIRO, ngôn ngữ này sẽ đóng vai trò như một bộ hợp đồng chạy trên StarkNet. . Thông qua Kakarot, người dùng sẽ có thể triển khai và tương tác với các hợp đồng EVM có mã/trạng thái trên StarkNet, cho phép người dùng hưởng lợi từ hiệu suất của StarkNet trong khi vẫn duy trì khả năng tương thích EVM. Vì môi trường thực thi cơ bản vẫn sẽ là StarkNet nên điều này sẽ hy sinh khả năng tương thích của công cụ Ethereum - nhưng đối với một số dự án, đây có thể là một sự đánh đổi có thể chấp nhận được. Kakarot vẫn chưa ở cấp độ sản xuất và tác động đến hiệu suất cũng như khả năng tương thích công cụ của phương pháp phân lớp này vẫn chưa rõ ràng, nhưng đây là một nỗ lực thú vị nhằm thu hẹp khoảng cách giữa các loại zkEVM khác nhau và cho thấy rằng chúng tôi đang khám phá Về mặt không gian thiết kế, chúng tôi đã hành động từ rất sớm.

p>

（8)Lạc quan

Vì những lý do hiển nhiên, Optimism thường được coi là một nhóm tập trung vào các kết quả lạc quan. Tuy nhiên, họ đã nhiều lần tuyên bố rằng họ có kế hoạch hỗ trợ các bằng chứng không có kiến ​​thức trong ZK như một lựa chọn trong tương lai và đã có những cuộc thảo luận sôi nổi với một số nhóm đóng góp tích cực. Các dự án hệ sinh thái zk thú vị như zeth hiện cung cấp hỗ trợ khối Optimism. Tuy nhiên, chúng tôi vẫn chưa thấy bất kỳ dòng thời gian hoặc thiết kế chính thức nào – có lẽ sẽ có những thay đổi thú vị trong bài đánh giá zkEVM năm tới!

Như bạn có thể thấy, có sự khác biệt lớn giữa các nhóm kEVM. Ngay cả các bản tổng hợp cùng loại thường có thiết kế hoàn toàn khác với người chứng minh, ứng dụng khách và cơ chế phân loại của chúng.

p>

Có một cách rất quan trọng khác để so sánh các zkEVM mới này - cấu hình thực tế của chúng! Nói chung, sẽ thú vị hơn khi phân tích kiến ​​trúc của khách hàng và người cung cấp dịch vụ của mỗi chuỗi vì nó liên quan đến các quyết định thiết kế cơ bản thay vì cấu hình cấp ứng dụng có thể dễ dàng thay đổi. Tuy nhiên, nếu bạn là nhà phát triển ứng dụng, cấu hình cụ thể chắc chắn là quan trọng, vì vậy hãy đảm bảo bạn nghiên cứu thời gian chặn của từng zkEVM, giới hạn gas khối, tần suất phát hành bằng chứng, cơ chế đồng thuận trình sắp xếp và mọi yếu tố có thể ảnh hưởng đến ứng dụng Kinh nghiệm người dùng!

Tóm lại: Vào năm 2023, nhiều nhóm đã tiến hành rất nhiều công việc phát triển. Vì vậy, nếu mọi thứ đang tiến triển, chúng ta có phải chờ xem không? Chúng ta cần giải quyết những vấn đề nào khác để zkEVM có được lực kéo đáng kể?

Các vấn đề chưa được giải quyết trong quá trình phát triển 2 và zkEVM là gì?

Trước hết, thiếu giao diện chuẩn hóa giữa máy khách và người thử nghiệm. Hiện tại, mỗi bộ chứng minh chỉ tương thích với ứng dụng khách mà chúng được xây dựng ban đầu. Bạn không thể sử dụng trình chứng minh của Polygon zkEVM với bất kỳ ứng dụng khách Loại 2/3 nào khác. Lý tưởng nhất là bất kỳ người chứng minh hoặc khách hàng mới nào cũng phải tương thích với càng nhiều người chứng minh/khách hàng hiện có càng tốt. Khuyến khích các nhóm zkEVM khác nhau tuân theo EIP của một giao diện duy nhất là một bước quan trọng để phát triển trong tương lai.

Có thể hiểu được, hầu hết các nhóm hiện đang ưu tiên cải thiện hoạt động triển khai của chính họ thay vì tìm kiếm khả năng tương thích với những nhóm khác. Điều này hiện có thể được chấp nhận, nhưng cuối cùng chúng tôi muốn zkEVM theo đơn đặt hàng L2 nói riêng sử dụng thiết lập nhiều khách hàng/nhà cung cấp để giảm nguy cơ xảy ra các lỗi lớn. Ngoài ra, việc chuẩn hóa việc triển khai các tính năng loại 2 "cổ điển" (ví dụ: Cây Merkle thưa thớt, hàm băm Poseidon thay vì keccak) có thể giúp nhiều người chứng minh sử dụng cùng một ứng dụng khách hoặc tương tự. Giảm số lượng khách hàng "geth" sẽ là một thắng lợi lớn cho hệ sinh thái! Một sáng kiến ​​tiêu chuẩn hóa có tên "RollCall" đã được đề xuất, cùng với một loạt Khuyến nghị tối ưu hóa tổng hợp (RIP), mặc dù vẫn chưa rõ sáng kiến ​​này sẽ phổ biến đến mức nào.

Thứ hai, các zkEVM này hầu hết đều là các trình tự sắp xếp đơn lẻ, điều này đặt ra thách thức đối với tính phân cấp và tính bảo mật của các bản tổng hợp này. Đặc biệt, lưu ý rằng hành vi của người chứng minh chỉ nhằm đảm bảo cầu L1-L2 được an toàn. Bất kỳ hệ thống bên ngoài nào dựa vào xác nhận trước L2 (như CEX) đều gặp rủi ro rất lớn vì chúng hoàn toàn dựa vào một trình sắp xếp chuỗi duy nhất - đối với nhiều L2 ngày nay, một vụ hack rất tai hại chỉ cần có. Điều này có thể được thực hiện bằng cách đánh cắp một trình sắp xếp chuỗi chìa khóa. Tuy nhiên, khi bạn phân cấp bộ phân loại, các thách thức khác nhau sẽ xuất hiện (như bạn có thể thấy trong nội dung Taiko ở trên!). Bạn có cần cung cấp bằng chứng zk cho L1 để chứng minh rằng đã đạt được sự đồng thuận L2 không? Còn vấn đề hoạt động thì sao? Còn MEV thì sao? Hầu hết các bản tổng hợp trình sắp xếp đơn lẻ hiện không sử dụng MEV vì lý do tin cậy về thương hiệu/danh tiếng/chuỗi, nhưng điều này có thể thay đổi trong tương lai.

Thứ ba, không có khuôn khổ tiêu chuẩn nào để đo lường hiệu suất và chi phí của zkEVM. Phần lớn bài viết này được dành để so sánh tác động tiềm ẩn về hiệu suất của các thiết kế zkEVM khác nhau, nhưng hiện tại rất ít nhóm zkEVM đã công bố bất kỳ thông số hoặc thử nghiệm hiệu suất thực tế nào. "Chi phí zkEVM" bao gồm các phần sau:

· Chi phí điện toán đám mây để tạo ra bằng chứng (bị ảnh hưởng bởi hiệu suất mạch)

· L1 chi phí cho bằng chứng xác minh

· Chi phí sẵn có của dữ liệu

· Chi phí gửi thông tin từ lớp này sang lớp khác

Tôi có thể tạo các bài kiểm tra tiêu chuẩn hóa cho các lĩnh vực này và put Các kết quả được lập bảng để giúp người xây dựng đưa ra quyết định sáng suốt hơn – điều mà hiện tại không thể thực hiện được. Sắc thái sau đây: một số cách triển khai bằng chứng sẽ tốt hơn những cách triển khai khác đối với một số loại giao dịch nhất định và một phần chi phí sẽ phụ thuộc vào mức sử dụng, do khả năng phân bổ chi phí giao dịch trên toàn bộ gói giao dịch. Cách trình bày những chi phí này cho người dùng cũng là một điều không chắc chắn lớn (ví dụ: zkEVM bất biến có kế hoạch thanh toán chi phí phát hành cho người dùng trong hầu hết các trường hợp, trong khi Scroll có thiết lập tính phí L1 + L2 phức tạp để đảm bảo rằng mọi giao dịch đều có lãi). Ngoài ra, nhiều zkEVM có thể gặp vấn đề về hiệu suất liên quan đến sự tăng trưởng trạng thái - việc mở rộng không gian khối Ethereum là không miễn phí! Tất cả những điều này sẽ đòi hỏi khả năng đo lường/so sánh cao hơn mức hiện có.

Thứ tư, đối với hầu hết các bản tổng hợp hợp đồng thông minh, cơ chế thoát vẫn chưa được hiểu và xác định rõ ràng. Tự lưu trữ được xác định rõ ràng trên một bản tổng hợp ứng dụng cụ thể (như Immutable X) - mọi nội dung bạn gửi vào cầu L1 đó đều có thể truy xuất được, ngay cả khi trình sắp xếp chuỗi hoàn toàn ngoại tuyến hoặc hoàn toàn độc hại. Đây thường được gọi là "cửa thoát hiểm". Nhưng điều này có ý nghĩa gì trong bối cảnh tổng hợp hợp đồng thông minh? Điều gì sẽ xảy ra nếu ETH của bạn được đặt cược vào một hợp đồng không nên có sẵn? Đây có phải là tất cả về khả năng chống kiểm duyệt (chúng ta có cần đảm bảo khả năng ép buộc giao dịch) không? Mức độ sẵn có của dữ liệu nào được chấp nhận đối với zkEVM được sử dụng cho các mục đích khác nhau (ví dụ: tài sản trò chơi so với DeFi)? Chúng tôi cần một khuôn khổ nhất quán để thông báo các điều kiện lỗi thực tế cho người dùng - L2 Beat là một khởi đầu tốt về mặt này!

Thứ năm, mối quan hệ giữa zkEVM và Ethereum L1 vẫn chưa rõ ràng. Khi viết bài này, tôi một lần nữa bị thu hút bởi một bài đăng trên blog do Buterin xuất bản phản ánh về "zkEVM được lưu giữ". Điểm đáng chú ý chính là lớp máy khách Ethereum có thể "lưu giữ" việc triển khai zk proof, có thể được sử dụng để xác minh việc thực thi các khối EVM do các nguồn khác gửi (chẳng hạn như L2). Điều này giúp tránh phải cập nhật tất cả các trình chứng minh L2 zkEVM (thắng lớn!) - họ có thể dựa vào công việc của các nhóm khác, bao gồm cả nhóm khách hàng Ethereum cốt lõi và Ethereum SNARKed hoàn toàn đã trở thành Hiện thực. Vì vậy, tôi có nên hiểu đề xuất “zkEVM được lưu giữ” là một sự khởi đầu từ lộ trình mở rộng quy mô lấy L2 làm trung tâm của Ethereum, mang lại giá trị mà L2 thu được không?

Không chính xác. L2 vẫn cần trình sắp xếp chuỗi riêng để cung cấp xác nhận nhanh chóng (quan trọng trong các lĩnh vực như trò chơi) và thiết kế do Buterin đề xuất chỉ hỗ trợ zkEVM với dữ liệu đầy đủ trên chuỗi. Hầu hết các L2 gần như muốn duy trì sự độc lập vì những lý do như kiếm tiền, đây là một sự đánh đổi quan trọng đối với hệ sinh thái Ethereum. L2 rất quan trọng đối với việc mở rộng không gian khối Ethereum, nhưng động lực của họ (và nhóm BD) có thể không phải lúc nào cũng phù hợp với Ethereum.

Cuối cùng, nhiều zkEVM sẽ tiếp tục phân tán người dùng và tính thanh khoản, dẫn đến trải nghiệm người dùng kém. Hôm nay, mỗi Ethereum L2 bổ sung sẽ tiếp tục phân cấp trạng thái và tính thanh khoản - nếu bạn có 2 ETH trên Arbitrum, việc truy cập ETH trên bất kỳ L2 nào khác sẽ khó khăn. Theo tôi, đây là lập luận tốt nhất cho chuỗi monome, nơi khả năng kết hợp được cải thiện đáng kể và người dùng không cần phải cân bằng giữa nhiều chuỗi. Với sự phổ biến hiện nay của "bộ công cụ L2" (ví dụ: Polygon CDK, Arbitrum Orbit, OP Stack), việc khởi chạy một chuỗi chưa bao giờ dễ dàng hơn thế nhưng phải trả giá bằng sự phân mảnh lớn hơn.

Để mô hình multi-L2 này thành công về lâu dài, trong hầu hết các trường hợp, chúng tôi cần loại bỏ các chuỗi và số dư riêng lẻ khỏi người dùng. Đây là một trong những lập luận mạnh mẽ hơn về bằng chứng xác thực so với bằng chứng gian lận – xác minh bằng chứng tức thời để kết nối nhanh giữa các chuỗi. Tuy nhiên, ngay cả với khung kết nối/khả năng tương tác mạnh mẽ, vẫn có rất nhiều vấn đề về trải nghiệm người dùng cần được giải quyết. Tại Immutable, kế hoạch của chúng tôi là giải quyết vấn đề này thông qua Hộ chiếu bất biến và tích hợp dọc ở lớp ví.

3, Kết luận

Dành cho zkEVM, 2023 Năm nay sẽ là một năm quan trọng cho cả tiến trình phát triển lẫn sự chuẩn bị cho việc áp dụng thực tế. Năm 2024 sẽ là năm đầu tiên zkEVM Loại 1 và Loại 2 thực sự sẵn sàng để sử dụng trong sản xuất, nhưng trên thực tế, chúng tôi sẽ không thể sử dụng chúng sớm nhất cho đến Quý 3/Q4 – có rất nhiều điều chúng tôi cần phải giải quyết để đạt được Hiệu suất đó vấn đề!

Tôi muốn nói rõ rằng vấn đề chính mà zkEVM sẽ giải quyết vào năm 2024 không phải là vấn đề kỹ thuật (mặc dù rõ ràng là chúng tôi vẫn còn một số vấn đề kỹ thuật cần giải quyết), nhưng Câu hỏi về giá trị – liệu chúng ta có thể tạo ra các ứng dụng thú vị cho người dùng trên L2 thế hệ tiếp theo không? Chúng tôi cần các nhà phát triển giao thức giỏi và các nhà phát triển ứng dụng giỏi!