Bài viết mới của V God: Sau khi Ethereum tích hợp ZK, Lớp 2 sẽ đi về đâu?
Sản xuất bởi - Odaily
Biên soạn - Loopy Lu
Hôm nay, Vitalik Buterin đã xuất bản một bài viết trên cộng đồng Ethereum với tiêu đề “ZK-EVM tích hợp có thể trông như thế nào?” 》Bài viết mới. Bài viết này tìm hiểu cách Ethereum sẽ tích hợp ZK-EVM của riêng mình 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 Ethereum phát triển chậm, hầu như tất cả Lớp 2 chính thống hiện nay đều có ZK-EVM, khi mạng chính Ethereum đóng gói ZK-EVM của riêng nó, liệu mạng chính và Lớp 2 có định vị vai trò không? ? Làm thế nào Lớp 1 và Lớp 2 có thể phân chia và hợp tác hiệu quả?
Trong bài viết này, Vitalik Buterin nhấn mạnh tầm quan trọng của tính tương thích, tính sẵn có của dữ liệu và khả năng kiểm tra, đồng thời khám phá khả năng triển khai các bộ chứng minh hiệu quả và có trạng thái. Ngoài ra, bài viết khám phá khả năng triển khai các bộ chứng minh trạng thái để tăng 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 giảm thiểu MEV và xác nhận trước nhanh chóng. Bài viết này phản ánh sự cân bằng trong việc duy trì tính linh hoạt của mạng Ethereum đồng thời thúc đẩy sự phát triển của nó thông qua ZK-EVM.
Odaily biên soạn văn bản gốc như sau:
Vì các giao thức EVM lớp 2 dựa trên Ethereum, các bản tổng hợp lạc quan và các bản tổng hợp ZK đề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ị hack. Điều này cũng có nghĩa là ZK-EVM, ngay cả khi họ hy vọng vẫn hoàn toàn tương đương với L1 EVM, sẽ cần một số hình thức quản trị để sao chép các thay đổi của L1 EVM vào quá trình triển khai EVM của riêng họ.
Đâ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 giao thức Ethereum vào chính chúng - ban quản trị Ethereum đã chịu trách nhiệm thực hiện nâng cấp và sửa lỗi và về cơ bản ZK-EVM thực hiện công việc xác thực các khối Ethereum Lớp 1. Trong vài năm tới, chúng tôi hy vọng các máy khách hạng nhẹ sẽ ngày càng trở nên mạnh mẽ và sớm có thể sử dụng ZK-SNARK để xác thực hoàn toàn các hoạt động thực thi L1 EVM. Vào thời điểm đó, mạng Ethereum sẽ thực sự có ZK-EVM được đóng gói. Vì vậy, câu hỏi đặt ra: tại sao không cung cấp sẵn ZK-EVM này 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 “ZK-EVM trong một gói” và phân tích những đánh đổi, thách thức trong thiết kế và lý do không đi theo những hướng nhất định của chúng. Lợi ích của việc triển khai chức năng 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.
Các tính năng chính mà chúng tôi muốn có từ ZK-EVM được đóng gói là gì?
Chức năng cơ bản: Xác minh khối Ethereum. Hàm giao thức (chưa được xác định liệu đó là opcode, tiền biên dịch hay cơ chế khác) phải có khả năng chấp nhận ít nhất một gốc trước 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 đó. gốc trạng thái thực sự nằm trên gốc trạng thái trước. Kết quả của việc thực thi khối này. Tương thích với nhiều khách hàng của Ethereum. Điều này có nghĩa là chúng tôi muốn tránh việc tích hợp sẵn một hệ thống chứng minh duy nhất và thay vào đó cho phép các khách hàng khác nhau sử dụng các hệ thống chứng minh 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 sẵn có của dữ liệu:Đối với bất kỳ quá trình thực thi EVM nào sử dụng bằng chứng ZK-EVM được đóng gói, chúng tôi muốn đảm bảo rằng dữ liệu cơ bản luôn sẵn có để người chứng minh sử dụng các hệ thống chứng minh khác nhau có thể chứng nhận lại việc thực thi và các khách hàng dựa vào hệ thống chứng minh đó có thể xác minh những bằng chứng mới được tạo này. .
Bằng chứng nằm ngoài EVM và chặn cấu trúc dữ liệu：Chức năng ZK-EVM thực tế không chấp nhận 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: các giao dịch có thể bao gồm các xác nhận quyền sở hữu cần được chứng minh (tiền trạng thái, nội dung khối, trạng thái hậu), nội dung của các xác nhận quyền sở hữu này có thể được truy cập bằng mã opcode hoặc tiền biên dịch và các quy tắc đồng thuận của khách hàng sẽ kiểm tra tính sẵn có của dữ liệu và bằng chứng về các khiếu nại được đưa ra trong khối.
Kiểm toán:Nếu bất kỳ hoạt động thực thi nào được chứng minh, chúng tôi muốn có sẵn dữ liệu cơ bản để cả người dùng và nhà phát triển có thể kiểm tra nếu có bất kỳ vấn đề nào phát sinh. 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 sẵn có của dữ liệu lại quan trọng.
Khả năng nâng cấp:Nếu phát hiện thấy lỗi trong giải pháp ZK-EVM cụ thể, chúng tôi muốn có thể khắc phục lỗi đó một cách 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 bổ sung 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ại quan trọng.
Hỗ trợ cho EVM gần đúng:Một trong những điểm hấp dẫn của L2 là khả năng đổi mới ở lớp thực thi và mở rộng EVM. Nếu VM của L2 nhất định chỉ khác một chút so với EVM, thì sẽ thật tuyệt nếu L2 có thể sử dụng ZK-EVM trong giao thức gốc cho các phần giống như EVM và chỉ dựa vào mã riêng của nó để xử lý các phần khác nhau. Điều này có thể được thực hiện bằng cách thiết kế chức năng ZK-EVM để người gọi có thể chỉ định trường bit hoặc mã opcode hoặc danh sách địa chỉ, sẽ được xử lý bởi một bảng được cung cấp bên ngoài thay vì bởi chính EVM. Chúng tôi cũng có thể tùy chỉnh chi phí gas ở một mức độ nhất định.
Hệ thống nhiều khách hàng Mở và Đóng
“Ý tưởng nhiều 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 là từ bỏ nhiều máy khách và tập trung vào sơ đồ ZK-SNARK, điều này sẽ đơn giản hóa thiết kế. Nhưng cái giá phải trả là một “sự thay đổi triết lý” lớn hơn đối với Ethereum (vì điều này thực sự đang từ bỏ tư duy đa khách hàng lâu đời của Ethereum) và tạo ra những rủi ro lớn hơn. Trong tương lai lâu dài, chẳng hạn như khi công nghệ xác minh chính thức trở nên tốt hơn, có thể sẽ tốt hơn nếu đ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à hệ thống nhiều khách hàng khép kín, trong đó có 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 yêu cầu bằng chứng từ ít nhất hai trong số ba điều này là hợp lệ. Điều này tốt hơn một hệ thống bằng chứng duy nhất, nhưng nó làm cho hệ thống ít thích ứng hơn vì người dùng phải duy trì trình xác thực cho mọi hệ thống bằng chứng đang 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 khiến tôi thích một hệ thống nhiều khách hàng mở, trong đó các bằng chứng được đặt bên ngoài khối và được các khách hàng xác minh riêng lẻ. Người dùng cá nhân sẽ sử dụng bất kỳ ứng dụng khách nào họ muốn để xác thực các khối và họ có thể thực hiện việc này miễn là có ít nhất một người chứng minh tạo ra bằng chứng cho hệ thống bằng chứng đó. Các hệ thống bằng chứng sẽ đạt được ảnh hưởng bằng cách thuyết phục người dùng chạy chúng chứ không phải bằng cách thuyết phục quy 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 tôi muốn có những tính năng chính nào khi triển khai ZK-EVM?
Bên cạnh tính đúng đắn về chức năng cơ bản và đảm bảo an ninh, 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 và mỗi câu lệnh chỉ trả về kết quả sau N vị trí, vấn đề sẽ trở nên dễ dàng hơn nếu chúng ta có thể đảm bảo một cách đáng tin cậy rằng bằng chứng có thể được tạo ra trong vài giây. Nhiều lắm, đến nỗi những gì xảy ra trong mỗi khối đều là tự cung tự cấp.
Mặc dù việc tạo bằng chứng cho một khối Ethereum ngày nay mất vài phút hoặc vài giờ, nhưng chúng tôi không biết lý do lý thuyết nào để ngăn chặn sự song song hóa lớn: chúng tôi luôn có thể tập hợp đủ GPU để chứng minh việc thực thi khối riêng lẻ, các phần khác nhau và sau đó sử dụng SNARK đệ quy để kết hợp các bằng chứng này lại với nhau . Ngoài ra, quy trình chứng minh có thể được tối ưu hóa hơn nữa thông qua khả năng tăng tốc phần cứng thông qua FPGA và ASIC. Tuy nhiên, thực sự đạt được điều này 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 trong giao thức trông như thế nào?
Tương tự như giao dịch blob EIP-4844, chúng tôi đã giới thiệu loại giao dịch mới chứa các xác nhận quyền sở hữu ZK-EVM:
class ZKEVMClaimTransaction(Container):
pre_state_root: bytes 32
post_state_root: bytes 32
transaction_and_witness_blob_pointers: List[VersionedHash]
...
Giống như EIP-4844, đối tượng được chuyển trong mempool là phiên bản sửa đổi của giao dịch:
class ZKEvmClaimNetworkTransaction(Container):
pre_state_root: bytes 32
post_state_root: bytes 32
proof: bytes
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 thể ngược lại. 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 danh sách các bằng chứng được khai báo trong khối.
Lưu ý rằng trong thực tế, chúng ta có thể muốn chia sidecar thành hai sidecar riêng biệt, một cho blob và một cho bằng chứng, đồng thời có một mạng con riêng cho từng loại bằng chứng (và một cho mạng con bổ sung blob).
Ở lớp đồng thuận, chúng tôi đã thêm quy tắc xác thực rằng khách hàng sẽ chỉ chấp nhận một khối nếu họ thấy bằng chứng hợp lệ cho từng yêu cầu trong khối. Bằng chứng phải là sự kết hợp của các bằng chứng ZK-SNARK, một cặp giao dịch_and_witness_blobs được tuần tự hóa và pre_state_root sử dụng (i) hợp lệ và Witness (ii) xuất ra post_state_root chính xác. (Chặn, Nhân chứng) Có thể, khách hàng có thể chọn đợi nhiều M-of-N của các bằng chứng loại.
Một lưu ý ở đây là bản thân việc thực thi khối có thể được xem đơn giản dưới dạng bộ ba (σpre,σpost,Proof) cần được kiểm tra cùng với bộ ba được cung cấp trong đối tượng ZKEVMClaimTransaction.
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ó; máy khách thực thi vẫn sẽ được sử dụng bởi (i) người chuẩn bị và người xây dựng khối cũng như (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 minh và xác minh lại
Giả sử có hai máy khách Ethereum, một máy sử dụng PSE ZK-EVM và máy kia sử dụng Polygon ZK-EVM. Giả sử rằng tại thời điểm này, cả hai cách triển khai đã phát triển đến mức chúng có thể chứng minh việc thực thi khối Ethereum trong 5 giây và đối với mỗi hệ thống bằng chứng, có đủ tình nguyện viên độc lập chạy phần cứng để tạo ra bằng chứng.
Thật không may, vì các hệ thống chứng minh độc lập không được tích hợp sẵn nên chúng không thể được khuyến khích trong giao thức; tuy nhiên, chúng tôi kỳ vọng rằng chi phí chạy một trình chứng minh sẽ thấp so với chi phí RD, vì vậy chúng ta có thể chỉ cần sử dụng thẩm quyền chung cho chứng minh đó Cung cấp vốn cho hàng hóa công cộng.
Giả sử ai đó phát hành ZKEvmClaimNetworkTransaction nhưng họ chỉ phát hành một 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 bằng chứng 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 sớm 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 tôi áp dụng tính chất cuối cùng một khe, chúng tôi gần như chắc chắn có thể xây dựng độ trễ bổ sung này cùng với độ trễ đồng thuận nhiều vòng vốn có của SSF. Ví dụ: trong đề xuất 4 ô con, bước bỏ phiếu trực tiếp có thể chỉ yêu cầu 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ợ cho EVM gần đúng
Mục tiêu lý tưởng của các tính năng ZK-EVM là hỗ trợ gần EVM: EVM được tích hợp sẵn một số chức năng bổ sung. Điều này có thể bao gồm các phần biên dịch trước mới, các mã opcode mới hoặc thậm chí tùy chọn mà các hợp đồng có thể được viết bằng 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 bản song song với EVM giao tiếp chéo được đồng bộ hóa.
Một số sửa đổi có thể được hỗ trợ theo cách đơn giản: chúng tôi có thể xác định ngôn ngữ cho phép ZKEVMClaimTransaction chuyển mô tả đầy đủ về quy tắc EVM đã sửa đổi. Điều này có thể thực hiện được:
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 nó)
Vô hiệu hóa một số opcode nhất định
Đặt số khối (điều này sẽ hàm ý 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 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 tính năng biên dịch trước (hoặc opcode) mới, chúng tôi có thể thêm bản ghi đầu vào/đầu ra được biên dịch trước vào blob của ZKEVMClaimNetworkTransaction:
class PrecompileInputOutputTranscript(Container):
used_precompile_addresses: List[Address]
inputs_commitments: List[VersionedHash]
outputs: List[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 một địa chỉ trong used_precompile_addresses được gọi, chúng tôi sẽ 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 used_precompile_addresses đã được gọi tổng số lần len(outputs) chưa và input_commitments có khớp với kết quả tuần tự hóa SSZ của các đầu vào tạo ra các cam kết blob hay không. Mục đích của việc hiển thị input_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 hơn.
Lưu ý sự bất đối xứng giữa đầu vào và đầu ra, đầ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 họ nên họ chỉ cần kiểm tra xem đầu vào được tạo có khớp với đầu vào được xác nhận hay không, việc 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 toàn bộ cho họ 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 khi quá trình biên dịch trước được gọi, như một phần của giao dịch khác (cũng có thể có đặc quyền). Điều này có thể được sử dụng để cho phép các cơ chế không phải EVM gọi lại vào EVM.
Thiết kế này có thể được sửa đổi để hỗ trợ các opcode mới hoặc được sửa đổi bên cạnh các phần biên dịch trước mới hoặc được sửa đổi. Ngay cả khi chỉ biên dịch trước, thiết kế này vẫn khá mạnh mẽ. Ví dụ:
Bằng cách đặt used_precompile_addresses để bao gồm danh sách các địa chỉ tài khoản thông thường với một số cờ nhất định trong trạng thái và tạo SNARK để chứng minh nó được xây dựng chính xác, bạn có thể hỗ trợ chức năng kiểu Arbitrum Stylus, trong đó hợp đồng có thể được viết bằng EVM hoặc WASM (hoặc loại khác một máy ảo). Các giao dịch đặc quyền có thể được sử dụng để cho phép tài khoản WASM gọi lại vào EVM.
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 các kênh được đồng bộ hóa 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 khớp với nhau theo cách chính xác.
ZK-EVM loại 4 có thể được vận hành bằng cách có nhiều triển khai: một triển khai chuyển đổi trực tiếp Solidity hoặc một ngôn ngữ cấp cao khác thành VM thân thiện với SNARK và một ngôn ngữ khác biên dịch nó thành mã EVM và xây dựng nó thành triển khai ZK-EVM. Quá trình triển khai thứ hai (chắc chắn là chậm hơn) chỉ có thể chạy nếu người kiểm tra lỗi gửi giao dịch xác nhận lỗi và thu tiền thưởng nếu họ có thể cung cấp cả hai cách xử lý giao dịch theo cách khác nhau.
Một VM hoàn toàn không đồng bộ có thể được triển khai bằng cách làm cho tất cả các cuộc gọi trả về 0 và ánh xạ các cuộc gọi tới 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 trình chứng minh trạng thái
Một 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 dữ liệu không hiệu quả. Trong điều kiện nén dữ liệu lý tưởng, việc gửi ERC 20 với tính năng nén trạng thái có thể tiết kiệm không gian gấp 3 lần so với chỉ nén trạng thái.
Ngoài ra, EVM có trạng thái không yêu cầu 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: yêu cầu dữ liệu phải có sẵn khi chúng ta đã biết nó có sẵn vì nó đã được nhập hoặc tạo trong lần thực thi EVM trước đó là một sự lãng phí.
Nếu chúng tôi muốn các tính năng ZK-EVM ở trạng thái ổn định thì chúng tôi có hai tùy chọn:
1) Yêu cầu σpre trống, danh sách dữ liệu có sẵn với các khóa và giá trị được khai báo hoặc σpost được thực thi trước đó.
2) Thêm cam kết blob cho biên nhận được tạo khối R vào bộ ba (σpre, σpost, Proof). Bất kỳ cam kết blob nào được tạo hoặc sử dụng trước đó, bao gồm những cam kết đại diện cho khối, nhân chứng, biên nhận hoặc thậm chí các giao dịch blob đơn giản EIP-4844, có thể có giới hạn thời gian nhất định và có thể được tham chiếu trong ZKEVMClaimTransaction và được truy cập trong quá trình thực thi nó (có thể thông qua một loạt hướng dẫn: Chèn byte N...N+k-1 của cam kết i vào vị trí j của khối + dữ liệu chứng kiến).
Tùy chọn một có nghĩa là: thay vì xác minh EVM không trạng thái tích hợp sẵn, hãy xây dựng các chuỗi con EVM. Tùy chọn hai về cơ bản là tạo ra một thuật toán nén trạng thái tích hợp sẵn tối thiểu sử dụng các đốm màu được tạo hoặc sử dụng trước đó làm từ điển. Cả hai phương pháp sẽ đặt gánh nặng lên nút người chứng minh, chỉ có nút người chứng minh cần lưu trữ nhiều thông tin hơn; trong trường hợp hai, việc giới hạn thời gian này sẽ dễ dàng hơn so với trường hợp một.
Các tham số cho nhiều bộ chứng minh đóng và dữ liệu ngoài chuỗi
Một hệ thống nhiều bộ chuẩn khép kín, trong đó có một số lượng bộ chuẩn cố định trong cấu trúc M-of-N, sẽ tránh được nhiều sự phức tạp nêu trên. Đặc biệt, các hệ thống đa chứng nhận khép kín không cần phải lo lắng về việc đảm bảo dữ liệu nằm trên chuỗi. Ngoài ra, một hệ thống đa chuẩn khép kín sẽ cho phép các bằng chứng ZK-EVM được thực hiện ngoài chuỗi; làm cho nó tương thích với các giải pháp EVM Plasma.
Tuy nhiên, hệ thống đa chứng nhận khép kín làm tăng độ phức tạp trong quản trị và loại bỏ khả năng kiểm toán, vốn là chi phí cao cần được cân nhắc so với những lợi ích này.
Nếu chúng tôi xây dựng ZK-EVM và biến nó thành một tính năng giao thức, vai trò của Dự án lớp 2 là gì?
Chức năng xác minh EVM hiện do chính nhóm Lớp 2 triển khai sẽ do giao thức xử lý, nhưng dự án Lớp 2 vẫn chịu trách nhiệm về nhiều chức năng quan trọng:
Xác nhận trước nhanh: Tính hữu hạn của một vị trí có thể làm chậm các vị trí Lớp 1 và 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 trong một vị trí. Dịch vụ này sẽ tiếp tục được quản lý hoàn toàn bởi Lớp 2.
Chiến lược giảm thiểu MEV (giá trị có thể trích xuất của thợ mỏ): Điều này có thể bao gồm các nhóm được mã hóa, lựa chọn đơn đặt hàng dựa trên danh tiếng và các tính năng khác mà Lớp 1 không muốn triển khai.
Tiện ích mở rộng cho EVM: Các dự án Lớp 2 có thể cung cấp cho người dùng của họ các tiện ích mở rộng đáng kể cho EVM. Đ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: Nhóm Lớp 2 thực hiện rất nhiều công việc để 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 đền bù bằng cách thu được MEV và phí tắc nghẽn trong mạng của họ. Mối quan hệ này sẽ tiếp tục tồn tại.
