Bài viết mới của Vitalik: Tương lai và thách thức của ZK-EVM

Tiêu đề ban đầu: “ZK-EVM được lưu giữ có thể trông như thế nào?”

Tác giả gốc: Vitalik

Biên dịch gốc: Luccy, BlockBeats

*Ghi chú của biên tập viên: Vào ngày 13 tháng 12, Vitalik Buterin, đồng sáng lập ETH Place, đã xuất bản một bài báo đi sâu vào việc triển khai “ZK-EVM” (Máy ảo Ethereum không có kiến thức) và thảo luận về thiết kế của các phiên bản khác nhau của ZK-EVM. *

• Khái niệm ZK-EVM của Vitalik nhằm mục đích giảm sự trùng lặp các tính năng giao thức Ethereum của các dự án Lớp 2 và cải thiện hiệu quả của chúng trong việc xác thực các khối Ethereum Lớp 1. Bài báo chỉ ra rằng các giao thức EVM Lớp 2 hiện tại (như Optimistic Rollups và ZK Rollups) dựa vào các cơ chế xác minh EVM, nhưng điều này cũng có nghĩa là họ phải tin tưởng vào một cơ sở mã lớn. Một khi có lỗ hổng trong cơ sở mã, các máy ảo này có thể có nguy cơ bị tấn công. *

• Ngoài ra, ông đã đề cập đến hỗ trợ cho “gần như EVM”, cho phép các máy ảo L2 sử dụng ZK-EVM trong giao thức chỉ với những khác biệt nhỏ so với EVM, đồng thời cung cấp sự linh hoạt cho một số tùy chỉnh của EVM. *

Các giao thức EVM lớp 2 trên ETH, bao gồm op rollups và ZK rollups, dựa trên xác thực 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 kho mã đó nằm trong lỗ hổng, các máy ảo này có nguy cơ bị tấn công. Ngoài ra, ngay cả ZK-EVM, muốn hoàn toàn tương đương với L1 EVM, cũng cần một số hình thức quản trị để sao chép các thay đổi từ L1 EVM sang triển khai EVM của riêng họ.

Tình huống này không lý tưởng, vì các dự án này đang sao chép chức năng đã tồn tại trong giao thức ETH Fang và quản trị ETH Fang đã chịu trách nhiệm nâng cấp và sửa lỗi: ZK-EVM về cơ bản thực hiện công việc tương tự như xác thực các khối ETH L1! Ngoài ra, 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ớm xác thực đầy đủ việc thực thi L1 ETH Fang bằng ZK-SNARK. Tại thời điểm này, mạng ETH sẽ có ZK-EVM tích hợp hiệu quả. Vì vậy, câu hỏi đặt ra: tại sao không làm cho bản địa hóa ZK-EVM này có sẵn cho dự án rollup?

Bài viết này sẽ mô tả một số phiên bản có thể có của “ZK-EVM được tôn vinh” và khám phá sự đánh đổi và thách thức thiết kế, cũng như lý do không chọn một hướng cụ thể. Những lợi thế của việc triển khai các tính năng giao thức nên được cân nhắc với những lợi ích còn lại cho hệ sinh thái và lợi ích của việc giữ cho giao thức cơ bản đơn giản.

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

Chức năng cơ bản: Xác thực các khối ETH. Tính năng giao thức (vẫn chưa chắc chắn liệu đó là opcode, precompilation hay một số cơ chế khác) ít nhất nên chấp nhận root pre-state, block và post-state root làm đầu vào và xác minh rằng post-state root thực sự là kết quả của việc thực thi một block trên đầu gốc pre-state.

Khả năng tương thích với ETH khái niệm nhiều khách hàng. Điều này có nghĩa là chúng tôi muốn tránh theo đuổi một hệ thống chứng thực 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 thực khác nhau. Điều này, đến lượt nó, có nghĩa là một vài điểm:

· 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 được lưu giữ, chúng tôi muốn có thể đả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 này.

· Bằng chứng tồn tại bên ngoài cấu trúc dữ liệu EVM và khối: Tính năng ZK-EVM không trực tiếp sử dụng SNARK làm đầu vào trong EVM, vì các máy khách khác nhau 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ể chứa các câu lệnh cần được chứng minh (trạng thái trước, nội dung khối, trạng thái sau), nội dung có thể được truy cập bằng opcodes hoặc biên dịch trước và các quy tắc đồng thuận phía máy khách sẽ kiểm tra tính khả dụng của dữ liệu và sự tồn tại của bằng chứng cho mỗi khiếu nại được đưa ra trong khối, tương ứng.

Khả năng kiểm toán. Nếu bất kỳ 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 để trong trường hợp có sự cố, người dùng và nhà phát triển có thể kiểm tra nó. Trong thực tế, điều này thêm một lý do khác cho tầm quan trọng của các yêu cầu về tính khả dụng của dữ liệu.

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

Các mạng hỗ trợ gần như EVM. Một trong những điểm thu hút của L2 là khả năng đổi mới lớp thực thi và mở rộng EVM. Nếu máy ảo (VM) của một L2 nhất định chỉ khác một chút so với EVM, sẽ thật tuyệt nếu L2 vẫn có thể sử dụng cùng một ZK-EVM trong giao thức gốc như EVM, chỉ dựa vào mã riêng của nó cho cùng một phần của EVM và mã riêng của chúng cho các bộ phận khác nhau. Điều này có thể đạt được bằng cách thiết kế tính năng ZK-EVM cho phép người gọi chỉ định một số opcode, địa chỉ hoặc bitfield đượ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ể làm cho chi phí gas mở để tùy chỉnh ở một mức độ hạn chế.

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

“Khái niệm nhiều khách hàng” có lẽ là yêu cầu được khẳng định nhiều nhất trong danh sách này. Có tùy chọn từ bỏ ý tưởng này và tập trung vào giải pháp ZK-SNARK, điều này sẽ đơn giản hóa thiết kế, nhưng với chi phí của một “sự thay đổi triết học” lớn hơn trên ETH Workshop (vì đây thực sự sẽ là một sự khởi đầu từ triết lý đa khách hàng dài hạn của ETH Workshop) và đưa ra những rủi ro lớn hơn. Ví dụ, trong tương lai dài hạn, nếu 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 là chọn con đường này, nhưng hiện tại, rủi ro dường như quá lớn.

Một tùy chọn khác là một hệ thống đa máy khách khép kín, nơi một tập hợp các 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 phải mang theo bằng chứng của hai trong số ba điều này để được coi là hợp lệ. Điều này tốt hơn so với 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 đã biết, chắc chắn sẽ có một quy trình quản trị chính trị để 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 mở, đa khách hàng, nơi các bằng chứng được đặt “bên ngoài các khối” và được xác minh riêng bởi khách hàng. Người dùng cá nhân có thể xác thực các khối với máy khách mà họ muốn, miễn là có ít nhất một người chứng minh tạo ra bằng chứng của hệ thống. 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 mà chúng ta sẽ thấy.

Các tính năng chính mà chúng tôi muốn triển khai ZK-EVM có là gì?

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

Mặc dù ngày nay phải mất nhiều phút hoặc hàng giờ để tạo ra bằng chứng về các khối ETH, 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ể kết hợ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, tăng tốc phần cứng thông qua FPGA và ASIC có thể giúp tối ưu hóa hơn nữa các bằng chứng. Tuy nhiên, thực sự đi đến thời điểm này là một thách thức kỹ thuật đáng kể không nên đánh giá thấp.

Các tính năng ZK-EVM trong giao thức có thể trông như thế nào?

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:

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

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 thực hiện trong một 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, và thiết lập một mạng con riêng cho mỗi loại bằng chứng (và một mạng con bổ sung cho blob).

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

Có một lưu ý triết học ở đây rằng bản thân việc thực thi khối có thể được coi là thứ chỉ cần được kiểm tra cùng với một trong các bộ ba (σpre, σpost, Proof) đượ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ó, 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 minh và chứng thực 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 đến 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 ETH thực thi khối trong vòng chưa đầy 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 bằng chứng.

Thật không may, vì các hệ thống chứng thực riêng lẻ không được chính thức hóa, 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 nút bằng chứng sẽ thấp hơn so với chi phí nghiên cứu và phát triển, vì vậy chúng tôi có thể chỉ cần tài trợ cho các nút bằng chứng thông qua tài trợ chung cho hàng hóa công cộng.

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

Đ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 từ δ lên 2 δ + Tprove (giả sử Tprove < 5 giây ở đây).

Tuy nhiên, tin tốt là nếu chúng ta thực hiện chủ nghĩa xác định một vị trí, chúng ta gần như chắc chắn có thể “đường ống” độ trễ thêm 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 vị trí này, bước “bỏ phiếu đầu” có thể chỉ cần kiểm tra tính hợp lệ của khối cơ bản, nhưng bước “đóng băng và xác nhận” sẽ yêu cầu sự tồn tại của bằng chứng.

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

Một mục tiêu mong muốn của tính năng ZK-EVM là hỗ trợ “gần như EVM”: EVM với một vài tính năng bổ sung. Điều này có thể bao gồm biên dịch trước mới, opcode mới, cho phép các hợp đồng được viết trong EVM hoặc các máy ảo hoàn toàn khác nhau (ví dụ: 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ề các quy tắc EVM đã sửa đổi. Điều này có thể được sử dụng để:

· Bảng chi phí gas tùy chỉnh (người dùng không được phép 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 có nghĩa là sẽ có các quy tắc khác nhau tùy thuộc vào hard fork)

· Đặt cờ kích hoạt toàn bộ 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 chức năng mới bằng cách giới thiệu các bản biên dịch sẵn (hoặc opcodes) mới theo cách cởi mở hơn, chúng tôi có thể thêm nội dung chứa các bản ghi đầu vào / đầu ra được biên dịch sẵn vào một phần của blob của ZKEVMClaimNetworkTransaction:

Việc thực thi EVM sẽ được sửa đổi như sau. Đầu vào mảng sẽ được khởi tạo dưới dạng trống. Mỗi khi địa chỉ trong used_precompile_addresses được gọi, chúng ta nối thêm đối tượng InputsRecord(callee_address, gas, input_calldata) vào đầu vào và đặt RETURNDATA của lệnh 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ả tuần tự hóa SSZ của các cam kết blob được tạo với đầu vào. Mục đích của việc phơi bày đầu vào \ _commitments là tạo điều kiện cho các SNARK bên ngoài 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. Thực thi EVM đã tạo đầu vào cho chúng, vì vậy chúng chỉ cần kiểm tra xem các đầu vào được tạo có khớp với đầu vào được khai báo 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ọ ở dạng đầy đủ, vì vậy nó phải có sẵn dữ liệu.

Một tính năng hữu ích khác có thể là cho phép “giao dịch đặc quyền”, tức là các giao dịch bắt đầu cuộ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ể chạy giữa hai giao dịch khác hoặc khi gọi biên dịch trước trong một giao dịch khác (và có thể là đặ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 EVM.

Thiết kế này có thể được sửa đổi để hỗ trợ opcode mới hoặc sửa đổi, ngoài việc 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 rất 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 thông thường với các cờ nhất định được đặt trong các đối tượng tài khoản của chúng trong trạng thái 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 trong đó mã cho hợp đồng có thể được viết bằng EVM hoặc WASM (hoặc các 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 trở lại EVM.

· Bằng cách thêm kiểm tra bên ngoài để đảm bảo rằng các phiên âm đầ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 chính xác, bạn có thể chứng minh một hệ thống song song gồm nhiều EVM giao tiếp với nhau qua kênh đồng bộ hóa.

· Loại ZK-EVM thứ tư có thể hoạt động bằng cách có nhiều triển khai: một loại chuyển đổi Solidity hoặc các ngôn ngữ cấp cao khác trực tiếp thành các máy ảo thân thiện với SNARK và một loại khác biên dịch nó thành mã EVM và thực thi nó trong ZK-EVM được lưu giữ. Việc triển khai thứ hai (và chắc chắn chậm hơn) chỉ chạy nếu người chứng minh lỗi gửi một giao dịch nói rằng có lỗi và nếu họ có thể cung cấp một giao dịch được xử lý khác nhau bởi cả hai, họ có thể được thưởng.

· Một máy ảo hoàn toàn không đồng bộ có thể đạt được 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 đến các giao dịch đặc quyền được thêm vào cuối khối.

Phần mở rộng: Hỗ trợ cho các đính kèm 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, điều này làm cho nó kém hiệu quả hơn về mặt sử dụng dữ liệu. Bằng cách hỗ trợ nén trạng thái, gửi ERC 20 có thể tiết kiệm dung lượng gấp 3 lần so với khi chỉ sử dụng nén không trạng thái, sử dụng nén dữ liệu lý tưởng.

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: thật lãng phí khi yêu cầu dữ liệu có sẵn, bởi vì 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 ra bởi việc thực thi EVM trước đó.

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

1. Yêu cầu σpre phải trống hoặc danh sách dữ liệu có sẵn cho cặp khóa-giá trị được khai báo trước hoặc một số σpost đã được thực thi trước đó.

2. Thêm cam kết blob của biên lai R được tạo khối vào bộ dữ liệu (σpre, σpost, Bằng chứng). Bất kỳ lời hứa blob nào được tạo hoặc sử dụng trước đó, bao gồm cả những lời hứa đạ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 thông thường, có thể có giới hạn thời gian, có thể được tham chiếu trong ZKEVMClaimTransaction và được truy cập trong quá trình thực hiện (có thể thông qua một loạt các hướng dẫn: "Chèn byte N của cam kết i tại vị trí j của khối + dữ liệu nhân chứng… N+k− 1 」)。

(1) Về cơ bản nói: thay vì củng cố xác minh EVM không trạng thái, chúng tôi sẽ củng cố chuỗi con EVM. (2) Về cơ bản tạo ra một thuật toán nén trạng thái tối thiểu được tích hợp sẵn sử dụng blob được sử dụng hoặc tạo trước đó làm từ điển. Cả hai đều thêm gánh nặng lưu trữ nhiều thông tin hơn vào nút chứng minh, chỉ là nút chứng minh và trong trường hợp (2), việc giới hạn gánh nặng này trong một khoảng thời gian nhất định sẽ dễ dàng hơn trong trường hợp (1).

Cuộc tranh luận giữa các hệ thống đa bằng chứng khép kín và dữ liệu ngoài chuỗi

Một hệ thống đa prover khép kín tránh được nhiều phức tạp ở trên bằng cách sửa một số lượng chứng minh nhất định trong cấu trúc M-of-N. Đặc biệt, các 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 plasma EVM.

Tuy nhiên, các hệ thống đa prover khép kín làm tăng độ phức tạp của quản trị và giảm khả năng kiểm toán, đây là sự đánh đổi giữa chi phí cao và những lợi ích này.

Nếu chúng ta thiết lập ZK-EVM như một tính năng giao thức, vai trò liên tục của “dự án L2” sẽ là gì?

Giao thức sẽ xử lý các tính năng xác minh EVM mà các nhóm L2 hiện đang tự triển khai, nhưng dự án L2 vẫn sẽ 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 khe cắm có thể làm chậm các vị trí L1 và các dự án L2 đã 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 L2, với độ trễ thấp hơn nhiều so với một khe. Dịch vụ này sẽ tiếp tục là trách nhiệm pháp lý thuần túy của L2.

Các chiến lược giảm thiểu MEV: Điều này có thể bao gồm các mempool được mã hóa, lựa chọn tuần tự dựa trên danh tiếng và các tính năng khác mà L1 không muốn thực hiện.

Tiện ích mở rộng cho EVM: Các dự án L2 có thể kết hợp các phần mở rộng đáng kể cho EVM để cung cấp giá trị đáng kể cho người dùng của họ. Điều này bao gồm cả “gần như EVM” 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 của SNARK.

Thuận tiện cho người dùng và nhà phát triển: Các nhóm L2 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, và họ được bù đắp bằng cách mua MEV và phí tắc nghẽn trong mạng của họ. Mối quan hệ này là ở đây để ở lại.

Liên kết đến bài viết gốc