V Shen Xinwen: Sau khi ETH Fang tích hợp ZK, Layer2 sẽ đi về đâu?

Sản xuất | Odaily

Biên dịch | Lục Nghiễm

Hôm nay, Vitalik Buterin đã xuất bản một bài báo mới trong cộng đồng ETH có tiêu đề “ZK-EVM tích hợp có thể trông như thế nào?”. Bài viết này khám phá cách ETH Workshop sẽ có ZK-EVM riêng được tích hợp vào các bản nâng cấp mạng trong tương lai.

Như chúng ta đã biết, trong bối cảnh ETH phát triển chậm chạp, hầu như tất cả các Layer 2 chính thống đều đã có ZK-EVM, nhưng khi mainnet workshop ETH gói gọn ZK-EVM của riêng nó, liệu có xung đột giữa định vị vai trò của mainnet và Layer 2 không?

Trong bài viết này, Vitalik Buterin nhấn mạnh tầm quan trọng của khả năng tương thích, tính sẵn có của dữ liệu và khả năng kiểm toán, đồng thời khám phá các khả năng triển khai các tùy viên hiệu quả và trạng thái. Ngoài ra, bài viết khám phá khả năng thực hiện các bằng chứng trạng thái về hiệu quả và thảo luận về vai trò của các dự án Lớp 2 trong việc cung cấp các chiến lược xác nhận trước và giảm thiểu MEV nhanh chóng. Bài viết này phản ánh sự cân bằng của việc thúc đẩy sự phát triển của mạng ETH thông qua ZK-EVM trong khi vẫn duy trì tính linh hoạt của nó.

Odaily Planet Daily đã tổng hợp bài viết gốc, và toàn văn bài viết như sau:

Rollups lạc quan và ZK rollups, như các giao thức EVM Lớp 2 trên ETH, cả hai đều dựa vào xác minh EVM. Tuy nhiên, điều này đòi hỏi họ phải tin tưởng vào một cơ sở mã lớn và nếu có lỗi trong cơ sở mã này, thì các máy ảo này có nguy cơ bị tấn công. Điều này cũng có nghĩa là ZK-EVM, ngay cả khi chúng muốn hoàn toàn tương đương với EVM L1, sẽ cần một số hình thức quản trị để sao chép các thay đổi EVM L1 vào việc triển khai EVM của riêng chúng.

Đây không phải là một tình huống lý tưởng. Bởi vì các dự án này đang sao chép chức năng đã tồn tại trong ETH Workshop Protocol cho chính chúng - ETH Governance đã chịu trách nhiệm nâng cấp và sửa lỗi, và những gì ZK-EVM về cơ bản làm là xác thực các khối ETH Lớp 1. Trong vài năm tới, chúng tôi hy vọng các máy khách nhẹ sẽ ngày càng trở nên mạnh mẽ hơn và sẽ sớm có thể sử dụng ZK-SNARK để xác thực đầy đủ các lệnh L1 EVM. Tại thời điểm đó, mạng ETH thực sự sẽ có ZK-EVM trong một gói. Vì vậy, câu hỏi đặt ra: tại sao không làm cho ZK-EVM này cũng có sẵn cho các bản tổng hợp?

Bài viết này sẽ mô tả một số phiên bản của “Encapsulated ZK-EVM”, phân tích sự đánh đổi, thách thức thiết kế và lý do không đi theo một số hướng nhất định. Lợi ích của việc triển khai chức năng của giao thức nên được so sánh với lợi ích của việc cho phép hệ sinh thái xử lý các giao dịch và giữ cho giao thức cơ bản đơn giản.

Chúng ta muốn nhận được những tính năng chính nào từ ZK-EVM được đóng gói?

Các thuộc tính chính mà chúng ta có thể mong đợi từ ZK-EVM được đóng gói là gì?

Chức năng cơ bản: Xác thực các khối ETH. Hàm giao thức (chưa được xác định liệu đó là opcode, precompilation hay một số cơ chế khác) sẽ có thể chấp nhận ít nhất một gốc tiền trạng thái, một khối và một gốc sau trạng thái làm đầu vào và xác minh rằng gốc sau trạng thái thực sự là kết quả của việc thực thi khối đó trên gốc tiền trạng thái. Tương thích với nhiều khách hàng của ETH Workshop. Điều này có nghĩa là chúng tôi muốn tránh một hệ thống chứng thực duy nhất được tích hợp sẵn và thay vào đó cho phép các máy khách khác nhau sử dụng các hệ thống chứng thực khác nhau.

Điều này cũng có nghĩa là một vài điều:

Yêu cầu về tính khả dụng của dữ liệu: Đối với bất kỳ thực thi EVM nào sử dụng bằng chứng ZK-EVM đóng gói, chúng tôi muốn đảm bảo rằng dữ liệu cơ bản có thể sử dụng được để người chứng minh sử dụng hệ thống chứng thực khác có thể chứng thực lại việc thực thi và khách hàng dựa vào hệ thống chứng thực đó có thể xác thực các bằng chứng mới được tạo đó.

Bằng chứng nằm bên ngoài cấu trúc dữ liệu EVM và khối: * Chức năng ZK-EVM không thực sự lấy SNARK làm đầu vào bên trong EVM, vì các máy khách khác nhau sẽ mong đợi các loại SNARK khác nhau. Thay vào đó, nó có thể tương tự như xác thực blob: một giao dịch có thể bao gồm các khiếu nại (trạng thái trước, nội dung khối, trạng thái sau) cần được chứng minh, nội dung có thể được truy cập bằng opcodes hoặc biên dịch trước và quy tắc đồng thuận phía máy khách kiểm tra tính khả dụng của dữ liệu và bằng chứng về các khiếu nại được thực hiện trong khối, tương ứng.

Khả năng kiểm toán: Nếu bất kỳ việc thực thi nào được chứng minh, chúng tôi muốn dữ liệu cơ bản có thể sử dụng được để nếu có sự cố, cả người dùng và nhà phát triển đều có thể kiểm tra nó. Trên thực tế, điều này bổ sung thêm một lý do tại sao các yêu cầu về tính khả dụng của dữ liệu lại quan trọng.

Khả năng nâng cấp: Nếu chúng tôi tìm thấy lỗi trong một giải pháp ZK-EVM cụ thể, chúng tôi muốn có thể sửa nó nhanh chóng. Điều này có nghĩa là không cần hard fork để khắc phục sự cố. Điều này thêm một lý do khác tại sao các bằng chứng bên ngoài EVM và cấu trúc dữ liệu khối là quan trọng.

Một trong những điểm thu hút của việc hỗ trợ “EVM gần đúng” :* * L2s là khả năng đổi mới ở lớp thực thi và mở rộng quy mô EVM. Nếu một máy ảo L2 chỉ khác một chút so với EVM, thì sẽ rất tuyệt nếu L2 có thể sử dụng ZK-EVM trong giao thức gốc cho các bộ phận tương tự như EVM và chỉ dựa vào mã riêng của chúng để xử lý các bộ phận khác nhau. Điều này có thể đạt được bằng cách thiết kế chức năng ZK-EVM cho phép người gọi chỉ định trường bit hoặc opcode hoặc danh sách địa chỉ, sẽ được xử lý bởi một biểu mẫu được cung cấp bên ngoài thay vì chính EVM. Chúng tôi cũng có thể làm cho chi phí gas có thể tùy chỉnh ở một mức độ nào đó.

Hệ thống đa khách hàng “mở” so với “đóng”

“Tâm lý đa khách hàng” có lẽ là yêu cầu gây tranh cãi nhất trong danh sách này. Một lựa chọn sẽ là từ bỏ multiclient và tập trung vào một sơ đồ ZK-SNARK, điều này sẽ đơn giản hóa thiết kế. Nhưng với cái giá phải trả là một “sự thay đổi triết học” lớn hơn tại Hội thảo ETH (vì điều này thực sự từ bỏ tâm lý đa khách hàng lâu đời của ETH Workshop) và mang lại rủi ro lớn hơn. Trong tương lai lâu dài, ví dụ, khi các kỹ thuật xác minh chính thức trở nên tốt hơn, có thể tốt hơn để đi theo con đường này, nhưng hiện tại nó có vẻ quá rủi ro.

Một tùy chọn khác là một hệ thống đa máy khách khép kín với một bộ hệ thống chứng thực cố định được biết đến trong giao thức. Ví dụ: chúng tôi có thể quyết định sử dụng ba ZK-EVM: PSE ZK-EVM, Polygon ZK-EVM và Kakarot. Một khối cần bằng chứng từ ít nhất hai trong số ba khối này để hợp lệ. Điều này tốt hơn so với một hệ thống bằng chứng đơn lẻ, nhưng nó làm cho hệ thống ít thích ứng hơn do thực tế là người dùng phải duy trì trình xác thực cho từng hệ thống bằng chứng tồn tại, sẽ có một quy trình quản trị không thể tránh khỏi để kết hợp các hệ thống bằng chứng mới, v.v.

Điều này thúc đẩy tôi thích một hệ thống đa khách hàng mở, nơi các bằng chứng được đặt “bên ngoài khối” và được xác minh riêng bởi các khách hàng. Người dùng cá nhân sẽ sử dụng bất kỳ máy khách nào họ muốn xác thực một khối và họ sẽ có thể làm như vậy miễn là ít nhất một người chứng minh tạo ra bằng chứng cho hệ thống chứng thực đó. Hệ thống chứng thực sẽ đạt được ảnh hưởng bằng cách thuyết phục người dùng chạy chúng, không phải bằng cách thuyết phục quá trình quản trị giao thức. Tuy nhiên, cách tiếp cận này có chi phí phức tạp hơn, như chúng ta sẽ thấy.

Chúng ta muốn những tính năng chính nào trong việc triển khai ZK-EVM?

Ngoài tính chính xác chức năng cơ bản và đảm bảo an toàn, thuộc tính quan trọng nhất là tốc độ. Mặc dù có thể thiết kế một giao thức không đồng bộ với chức năng ZK-EVM tích hợp trong đó mỗi yêu cầu chỉ trả về kết quả sau N khe cắm, vấn đề trở nên dễ dàng hơn nhiều nếu chúng ta có thể đảm bảo một cách đáng tin cậy rằng bằng chứng sẽ được tạo trong vài giây, để những gì xảy ra trong mỗi khối là tự cung tự cấp.

Mặc dù phải mất vài phút hoặc vài giờ để tạo ra bằng chứng cho một khối ETH ngày nay, chúng tôi biết rằng không có lý do lý thuyết nào để ngăn chặn song song hàng loạt: chúng tôi luôn có thể lắp ráp đủ GPU để chứng minh các phần khác nhau của việc thực thi khối một cách riêng biệt và sau đó sử dụng SNARK đệ quy để đặt các bằng chứng đó lại với nhau. Ngoài ra, quá trình chứng minh có thể được tối ưu hóa hơn nữa thông qua việc tăng tốc phần cứng của FPGA và ASIC. Tuy nhiên, thực sự đạt được điều đó là một thách thức kỹ thuật không nên đánh giá thấp.

Chính xác thì chức năng ZK-EVM trông như thế nào trong giao thức?

Tương tự như các giao dịch blob EIP-4844, chúng tôi giới thiệu một loại giao dịch mới bao gồm các tuyên bố ZK-EVM:

lớp ZKEVMClaimTransaction(Container):
pre_state_root: byte 32
post_state_root: byte 32
transaction_and_witness_blob_pointers: Danh sách[VersionedHash]
…

Như với EIP-4844, đối tượng được truyền trong mempool là phiên bản sửa đổi của giao dịch:

lớp ZKEvmClaimNetworkTransaction(Container):
pre_state_root: byte 32
post_state_root: byte 32
chứng: byte
transaction_and_witness_blobs: List[Bytes[FIELD_ELEMENTS_PER_BLOB * 31 ]]

Cái sau có thể được chuyển đổi thành cái trước, nhưng không phải là cách khác. Chúng tôi cũng đã mở rộng đối tượng sidecar khối (được giới thiệu trong EIP-4844) để bao gồm một danh sách các bằng chứng được khai báo trong một khối.

Lưu ý rằng trong thực tế, chúng tôi có thể muốn chia sidecar thành hai sidecar riêng biệt, một cho blob và một để chứng thực, và thiết lập một mạng con riêng cho từng loại bằng chứng (và một mạng con bổ sung cho blob).

Ở lớp đồng thuận, chúng tôi đã thêm quy tắc xác thực sẽ chỉ chấp nhận một khối nếu khách hàng thấy bằng chứng hợp lệ về từng khiếu nại trong khối. Bằng chứng phải là sự kết hợp của bằng chứng ZK-SNARK, được tuần tự hóa dưới dạng một cặp giao dịch \ _and \ _witness \ _blobs và trước \ _state \ _root hợp lệ với (i) và Nhân chứng (ii) xuất ra bài đăng chính xác \ _state \ _root. (Block, Witness) Có khả năng, khách hàng có thể chọn chờ M-of-N cho nhiều loại bằng chứng.

Một lưu ý ở đây là bản thân việc thực thi khối có thể được coi là một bộ ba cần được kiểm tra cùng với bộ ba được cung cấp trong đối tượng ZKEVMClaimTransaction (σpre, σpost, Proof).

Do đó, việc triển khai ZK-EVM của người dùng có thể thay thế máy khách thực thi của nó, vẫn sẽ được sử dụng bởi (i) người chứng minh và trình tạo khối và (ii) các nút quan tâm đến việc lập chỉ mục và lưu trữ dữ liệu để sử dụng cục bộ.

Xác nhận và xác nhận lại

Giả sử bạn có hai máy khách ETH, một trong số đó sử dụng PSE ZK-EVM và ứng dụng còn lại sử dụng Polygon ZK-EVM. Giả sử rằng tại thời điểm này, cả hai triển khai đã phát triển đến mức chúng có thể chứng minh việc thực thi một khối ETH trong vòng chưa đầy 5 giây và đối với mỗi hệ thống chứng minh, có đủ tình nguyện viên độc lập chạy phần cứng để tạo bằng chứng.

Thật không may, vì các hệ thống chứng thực độc lập không được tích hợp sẵn, chúng không thể được khuyến khích trong giao thức, tuy nhiên, chúng tôi dự đoán rằng chi phí chạy một prover thấp hơn so với chi phí R &D, vì vậy chúng tôi có thể chỉ cần sử dụng một cơ quan chung để tài trợ cho hàng hóa công cộng cho người chứng minh.

Giả sử ai đó phát hành ZKEvmClaimNetworkTransaction, nhưng họ chỉ phát hành phiên bản bằng chứng PSE ZK-EVM. Nút chứng minh của Polygon ZK-EVM nhìn thấy điều này và sử dụng chứng minh của Polygon ZK-EVM để tính toán và xuất bản lại đối tượng.

Điều này làm tăng tổng độ trễ tối đa giữa nút trung thực lâu đời nhất chấp nhận một khối và nút trung thực mới nhất chấp nhận cùng một khối δ: 2 δ + Tprove (giả sử Tprove<5 s).

Tuy nhiên, tin tốt là nếu chúng ta tính cuối cùng của vị trí, chúng ta gần như chắc chắn có thể “đường ống” độ trễ bổ sung này cùng với độ trễ đồng thuận nhiều vòng vốn có trong SSF. Ví dụ: trong đề xuất 4 vị trí, bước “bỏ phiếu đầu” có thể chỉ cần kiểm tra tính hợp lệ của khối cơ sở, nhưng sau đó bước “đóng băng và xác nhận” sẽ yêu cầu bằng chứng tồn tại.

Tiện ích mở rộng: Hỗ trợ “EVM gần đúng”

Mục tiêu lý tưởng cho tính năng ZK-EVM là hỗ trợ “EVM gần đúng”: nghĩa là EVM với một số chức năng bổ sung được tích hợp sẵn. Điều này có thể bao gồm biên dịch trước, opcode mới hoặc thậm chí các tùy chọn trong đó hợp đồng có thể được viết trong EVM hoặc một máy ảo hoàn toàn khác (ví dụ: như trong Arbitrum Stylus) hoặc thậm chí nhiều EVM song song với giao tiếp chéo đồng bộ.

Một số sửa đổi có thể được hỗ trợ một cách đơn giản: chúng ta có thể xác định ngôn ngữ cho phép ZKEVMClaimTransaction vượt qua mô tả đầy đủ về quy tắc EVM đã sửa đổi. Điều này có thể được thực hiện:

• Bảng gas tùy chỉnh (người dùng không thể giảm chi phí gas, nhưng có thể tăng chúng)
• Vô hiệu hóa một số opcodes nhất định
• Đặt số khối (điều này sẽ ngụ ý các quy tắc khác nhau tùy thuộc vào hard fork)
• Đặt cờ kích hoạt một tập hợp đầy đủ các thay đổi EVM đã được chuẩn hóa để sử dụng L2 thay vì sử dụng L1 hoặc các thay đổi đơn giản khác

Để cho phép người dùng thêm các tính năng mới theo cách cởi mở hơn, bằng cách giới thiệu một bản biên dịch trước (hoặc opcode) mới, chúng tôi có thể bao gồm bản ghi đầu vào / đầu ra được biên dịch trước trong blob của ZKEVMClaimNetworkTransaction:

lớp PrecompileInputOutputTran(Container):
used_precompile_addresses: Danh sách[Address]
đầu vào_commitments: Danh sách[VersionedHash]
đầu ra: Danh sách[Bytes]

Việc thực thi EVM sẽ được sửa đổi như sau. Khởi tạo một mảng đầu vào trống. Bất cứ khi nào địa chỉ trong used_precompile_addresses được gọi, chúng ta thêm một đối tượng InputsRecord(callee_address, gas, input_calldata) vào đầu vào và đặt RETURNDATA của cuộc gọi thành đầu ra[i]。 Cuối cùng, chúng tôi kiểm tra xem sử dụng \ _precompile \ _addresses đã được gọi là len (đầu ra) tổng số lần và đầu vào \ _commitments khớp với kết quả đã hứa bằng cách tuần tự hóa SSZ trên đầu vào. Mục đích của việc phơi bày đầu vào \ _commitments là giúp SNARK bên ngoài dễ dàng chứng minh mối quan hệ giữa đầu vào và đầu ra.

Lưu ý sự bất đối xứng giữa đầu vào và đầu ra, trong đó đầu vào được lưu trữ trong hàm băm và đầu ra được lưu trữ trong các byte phải được cung cấp. Điều này là do việc thực thi cần được thực hiện bởi một máy khách chỉ nhìn thấy đầu vào và hiểu EVM. Việc thực thi EVM đã tạo đầu vào cho chúng, vì vậy chúng chỉ cần kiểm tra xem đầu vào được tạo có khớp với đầu vào được yêu cầu hay không, điều này chỉ yêu cầu kiểm tra hàm băm. Tuy nhiên, đầu ra phải được cung cấp cho họ toàn bộ và do đó phải là dữ liệu có thể sử dụng được.

Một tính năng hữu ích khác có thể là cho phép “giao dịch đặc quyền” có thể được gọi từ bất kỳ tài khoản người gửi nào. Các giao dịch này có thể được chạy giữa hai giao dịch khác hoặc là một phần của giao dịch khác (và có thể là đặc quyền) khi biên dịch trước được gọi. Điều này có thể được sử dụng để cho phép các cơ chế không phải EVM được gọi trở lại EVM.

Thiết kế này có thể được sửa đổi để hỗ trợ opcode mới hoặc sửa đổi, ngoài các bản biên dịch trước mới hoặc sửa đổi. Ngay cả khi chỉ biên dịch trước, thiết kế này khá mạnh mẽ. Ví dụ:

• Bằng cách thiết lập used \ _precompile \ _addresses để bao gồm danh sách các địa chỉ tài khoản bình thường với các cờ nhất định trong tiểu bang và tạo SNARK để chứng minh rằng nó được xây dựng chính xác, bạn có thể hỗ trợ các tính năng kiểu Arbitrum Stylus nơi hợp đồng có thể được viết bằng EVM hoặc WASM (hoặc một máy ảo khác). Các giao dịch đặc quyền có thể được sử dụng để cho phép các tài khoản WASM được gọi lại vào EVM.
• Bằng cách thêm kiểm tra bên ngoài để đảm bảo rằng các bản ghi đầu vào / đầu ra và các giao dịch đặc quyền được thực hiện bởi nhiều EVM được khớp theo cách chính xác, bạn có thể chứng minh một hệ thống song song gồm nhiều EVM nói chuyện với nhau thông qua kênh đồng bộ hóa.
• ZK-EVM Loại 4 có thể được vận hành bằng cách triển khai nhiều triển khai: một triển khai trực tiếp chuyển đổi Solidity hoặc một ngôn ngữ cấp cao khác thành máy ảo thân thiện với SNARK và một triển khai khác biên dịch nó thành mã EVM và thực thi nó trong ZK-EVM tích hợp. Việc triển khai thứ hai (và chắc chắn chậm hơn) chỉ có thể chạy nếu người chứng minh lỗi gửi một giao dịch khẳng định rằng có lỗi và thu tiền thưởng nếu họ có thể cung cấp rằng cả hai xử lý các giao dịch khác nhau. Một máy ảo không đồng bộ thuần túy có thể đạt được bằng cách trả về 0 cho tất cả các cuộc gọi và ánh xạ các cuộc gọi đến các giao dịch đặc quyền được thêm vào cuối khối.

Tiện ích mở rộng: Hỗ trợ cho các chứng nhận trạng thái

Một trong những thách thức với thiết kế trên là nó hoàn toàn không có trạng thái, khiến nó không hiệu quả về dữ liệu. Trong trường hợp nén dữ liệu lý tưởng, ERC 20 gửi bằng cách sử dụng nén trạng thái có thể tiết kiệm không gian hơn tới 3 lần so với nén chỉ trạng thái.

Ngoài ra, EVM trạng thái không cần cung cấp dữ liệu nhân chứng. Trong cả hai trường hợp, nguyên tắc đều giống nhau: khi chúng ta đã biết rằng dữ liệu có thể sử dụng được vì nó đã được nhập hoặc tạo trong quá trình thực thi EVM trước đó, thì thật lãng phí khi yêu cầu dữ liệu có sẵn.

Nếu chúng ta muốn tính năng ZK-EVM có trạng thái, thì chúng ta có hai tùy chọn:

1. Yêu cầu σpre Hoặc nó trống, đó là danh sách dữ liệu có sẵn với các khóa và giá trị được khai báo hoặc nó được thực thi trước một thời điểm nhất định σPOST 。

2. Hướng tới ( σpre, σpost, Bằng chứng ) Ba lần để thêm biên lai được tạo cho khối R của các cam kết blob. Bất kỳ cam kết blob nào được tạo hoặc sử dụng trước đó, bao gồm cả những cam kết đại diện cho các khối, nhân chứng, biên lai hoặc thậm chí các giao dịch blob EIP-4844 đơn giản, có thể có một số hạn chế về thời gian có thể được tham chiếu trong ZKEVMClaimTransaction và được truy cập trong quá trình thực hiện chúng (có thể thông qua một loạt các hướng dẫn: "Sẽ được cam kết I Các byte của N… N + k-1 được chèn vào khối + dữ liệu nhân chứng J "）。

Tùy chọn 1 có nghĩa là thay vì tích hợp xác minh EVM không trạng thái, tốt hơn là nên tích hợp chuỗi con EVM. Tùy chọn hai về cơ bản tạo ra một thuật toán nén trạng thái tích hợp tối thiểu sử dụng blob được sử dụng hoặc tạo trước đó làm từ điển. Cả hai cách tiếp cận đều đặt gánh nặng lên nút prover, đây là cách duy nhất cần lưu trữ nhiều thông tin hơn và trong trường hợp hai, việc có giới hạn thời gian đối với gánh nặng này sẽ dễ dàng hơn trong trường hợp một.

Các thông số cho dữ liệu đa cerversers kín và off-chain

Một hệ thống đa chứng minh khép kín với số lượng chứng minh cố định trong cấu trúc M-of-N sẽ tránh được phần lớn sự phức tạp trên. Đặc biệt, một hệ thống đa prover khép kín không cần phải lo lắng về việc đảm bảo rằng dữ liệu nằm trên chuỗi. Ngoài ra, một hệ thống đa gắn khép kín sẽ cho phép các bằng chứng ZK-EVM được thực thi ngoài chuỗi, làm cho chúng tương thích với các giải pháp EVM Plasma.

Tuy nhiên, một hệ thống đa giáo sư khép kín làm tăng thêm sự phức tạp trong quản trị và loại bỏ khả năng kiểm toán, đó là những chi phí cao cần được cân nhắc với những lợi ích này.

Nếu chúng ta xây dựng ZK-EVM vào nó và biến nó thành một tính năng giao thức, vai trò của “dự án Lớp 2” sẽ là gì?

Các chức năng xác minh EVM hiện đang được thực hiện bởi chính các nhóm Lớp 2 sẽ được xử lý bởi giao thức, nhưng dự án Lớp 2 vẫn chịu trách nhiệm về một số tính năng quan trọng:

• Xác nhận trước nhanh chóng: Tính cuối cùng của một vị trí duy nhất có thể làm chậm các vị trí Lớp 1, trong khi các dự án Lớp 2 đã cung cấp cho người dùng của họ “xác nhận trước” được hỗ trợ bởi bảo mật của chính Lớp 2 với độ trễ thấp hơn nhiều so với một khe cắm duy nhất. Dịch vụ này sẽ tiếp tục hoàn toàn thuộc trách nhiệm của Lớp 2.
• Các chiến lược giảm thiểu MEV (Miner Extractable Value): Điều này có thể bao gồm các mempool được mã hóa, lựa chọn trình tự dựa trên danh tiếng và các tính năng khác mà Lớp 1 không muốn thực hiện.
• Tiện ích mở rộng cho EVM: Các dự án Lớp 2 có thể cung cấp các phần mở rộng đáng kể cho EVM cho người dùng của họ. Điều này bao gồm “EVM gần đúng” và các cách tiếp cận khác nhau về cơ bản như hỗ trợ WASM của Arbitrum Stylus và ngôn ngữ Cairo thân thiện với SNARK.
• Thuận tiện cho người dùng và nhà phát triển: Các nhóm Lớp 2 đã làm rất nhiều để thu hút người dùng và dự án vào hệ sinh thái của họ và khiến họ cảm thấy được chào đón; họ được bù đắp bằng cách nắm bắt MEV và phí tắc nghẽn trong mạng của họ. Mối quan hệ này là ở đây để ở lại.