Tiêu đề gốc: "Một "ZK-EVM được lưu giữ" trông như thế nào?"

Tác giả gốc: Vitalik

Bản tổng hợp 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ười đồng sáng lập Ethereum, đã xuất bản một bài báo thảo luận về “ZK-EVM” chuyên sâu (Các hình thức triển khai có thể có của Máy ảo Ethereum không 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 do Vitalik đề xuất nhằm mục đích giảm việc triển khai lặp lại các chức năng giao thức Ethereum của các dự án Lớp 2 và cải thiện khả năng xác minh Lớp 1 Khu vực Ethereum hiệu quả về thời gian. Bài viết chỉ ra rằng các giao thức EVM Lớp 2 hiện tại (chẳng hạn như Optimistic Rollups và ZK Rollups) cần phải dựa vào cơ chế xác minh của EVM, nhưng điều này cũng có nghĩa là chúng phải tin tưởng vào một cơ sở mã khổng lồ. 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ũng đề cập đến việc hỗ trợ "gần như EVM", cho phép vẫn sử dụng máy ảo L2 với chỉ những khác biệt nhỏ so với ZK-EVM bên trong. giao thức cũng cung cấp tính linh hoạt cho việc tùy chỉnh một phần EVM.

Giao thức EVM lớp 2 trên Ethereum, bao gồm op rollup và ZK rollup, đề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ơ sở mã đó dễ bị tổn thương thì các máy ảo này có nguy cơ bị hack. Ngoài ra, ngay cả ZK-EVM muốn tương đương hoàn toàn với L1 EVM cũng sẽ yêu cầu một số hình thức quản trị để nhân rộng các thay đổi từ L1 EVM sang triển khai EVM của riêng chúng.

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 Ethereum và ban quản trị Ethereum đã 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 Ethereum L1! Ngoài ra, trong vài năm tới, chúng tôi hy vọng các khách hàng hạng nhẹ sẽ ngày càng trở nên mạnh mẽ hơn và sớm thực hiện L1 Ethereum có thể kiểm chứng đầy đủ bằng cách sử dụng ZK-SNARK. Tại thời điểm này, mạng Ethereum thực sự sẽ có ZK-EVM tích hợp sẵn. Vì vậy, câu hỏi đặt ra: tại sao không cung cấp bản địa hóa ZK-EVM này cho dự án tổng hợp?

Bài viết này sẽ mô tả một số phiên bản có thể có của "ZK-EVM được tiêu chuẩn hóa" và khám phá những đánh đổi và thách thức trong thiết kế, cũng như lý do không chọn một hướng đi cụ thể. Những ưu điểm này của việc triển khai các tính năng giao thức phải đượ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.

Chúng tôi mong đợi những thuộc tính chính nào từ ZK-EVM, được coi là tiêu chuẩn?

Chức năng cơ bản: Xác minh khối Ethereum. Tính năng giao thức này (vẫn chưa quyết định liệu đó là opcode, tiền biên dịch hay cơ chế khác) phải 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 thực sự là được thực thi trên đầu trạng thái gốc. Kết quả của khối.

Khả năng tương thích với khái niệm đa khách hàng của Ethereum. Điều này có nghĩa là chúng tôi muốn tránh cam kết với một hệ thống bằng chứng 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 bằng chứng khác nhau. Ngược lại, điều này có nghĩa là một số điểm chính:

· Yêu cầu về tính khả dụng của dữ liệu: Đối với mọi EVM sử dụng chứng nhận ZK-EVM được coi là làm tiêu chuẩn Để thực thi, chúng tôi muốn có thể đảm bảo rằng dữ liệu cơ bản luôn sẵn có để những 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 các lần thực thi và những 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 tồn tại bên ngoài EVM và cấu trúc dữ liệu 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ì khác nhau khách hàng mong đợi các loại SNARK khác nhau. Thay vào đó, nó có thể tương tự như xác minh blob: các giao dịch có thể chứa các câu lệnh cần được chứng minh (tiền trạng thái, nội dung khối, trạng thái sau), nội dung của các câu lệnh này có thể được truy cập bằng 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ừng phần về tính khả dụng của Dữ liệu và bằng chứng về sự tồn tại của các khiếu nại được đưa ra trong khối.

Khả năng 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 để 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 xảy ra. Trong thực tế, điều này bổ sung thêm một lý do khác 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 một lỗ hổng được phát hiện trong sơ đồ ZK-EVM cụ thể, chúng tôi muốn có thể khắc phục lỗ hổng đó một cách nhanh chóng. Điều này có nghĩa là không cần hard fork để sửa nó. Điều này bổ sung thêm một lý do khác cho tầm quan trọng của bằng chứng tồn tại bên ngoài EVM và chặn cấu trúc dữ liệu.

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

Hệ thống nhiều khách hàng "Mở" và "Đóng"

"Khái niệm đa khách hàng ” có lẽ là yêu cầu quyết đoán 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, giải pháp này sẽ đơn giản hóa thiết kế nhưng phải trả giá bằng một "sự thay đổi triết học" lớn hơn sang Ethereum (vì trên thực tế, đây sẽ là một thay đổi đáng kể sang Ethereum) Việc từ bỏ khái niệm nhiều khách hàng dài hạn) và đưa ra những rủi ro lớn hơn. Trong tương lai lâu dài, chẳng hạn nếu công nghệ xác minh chính thức trở nên tốt hơn thì có thể chọn con đường này sẽ tốt hơn, nhưng hiện tại, rủi ro có vẻ quá lớn.

Một tùy chọn khác là hệ thống nhiều khách hàng khép kín, trong đó một tập hợp các hệ thống chứng minh 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 có 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 một hệ thống bằng chứng duy nhất, nhưng nó làm cho hệ thống kém 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, nhất thiết 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 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 xác minh riêng biệt bởi khách hàng. Người dùng cá nhân có thể xác thực các khối bằng cách sử dụng bất kỳ ứng dụng khách nào họ muốn, 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 triển khai ZK-EVM của mình có những tính năng chính nào?

Bên cạnh những đảm bảo cơ bản về chức năng chính xác và bảo mật, 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 giao thức không đồng bộ và chỉ trả về câu trả lời cho mỗi xác nhận quyền sở hữu sau độ trễ N vị trí, nhưng 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 tạo ra trong vài giây, thì vấn đề của mọi thứ diễn ra trong mỗi khối khép kín sẽ trở nên dễ dàng hơn.

Mặc dù việc tạo bằng chứng về các khối Ethereum ngày nay mất nhiều phút hoặc nhiều giờ, nhưng chúng tôi biết không có 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ể kết hợp đủ số GPU để chứng minh riêng biệt các phần khác nhau của quá trình thực thi khối, 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, khả năng 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 bằng chứng. Tuy nhiên, thực sự đạt được điều này là một thách thức kỹ thuật quan trọng không nên đánh giá thấp.

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

Tương tự như giao dịch Blob EIP-4844, chúng tôi đã giới thiệu một loại giao dịch mới chứa các xác nhận quyền sở hữu ZK-EVM:

Tương tự như EIP-4844, đối tượng được chuyển trong nhóm bộ nhớ sẽ được Sửa đổi phiên bản giao dịch:

Phiên bản giao dịch 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 bằng chứng cho các tuyên bố được đưa ra trong khối.

Xin lưu ý rằng trong thực tế Trong quá trình hoạt động, 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 cho proof, đồng thời có một mạng con riêng cho từng loại proof (và một mạng con bổ sung cho blob).

Trên lớp đồng thuận, chúng tôi đã thêm quy tắc xác minh rằng chỉ sau khi khách hàng thấy bằng chứng hợp lệ cho từng khiếu nại trong khối thì khối đó mới được chấp nhận. Bằng chứng phải là bằng chứng ZK-SNARK tuyên bố rằng việc ghép các giao dịch_and_witness_blobs là một chuỗi các cặp (Khối, Nhân chứng) và khối thực thi sử dụng Nhân chứng trên pre_state_root (i) là hợp lệ và (ii) để xuất ra kết quả chính xác post_state_root. Có khả năng, khách hàng có thể chọn đợi M-of-N của nhiều loại chứng thực.

Một lưu ý triết học ở đây là bản thân việc thực thi khối có thể được coi là chỉ yêu cầu , σpost, Proof) được kiểm tra cùng với một trong các bộ ba . Do đó, việc triển khai ZK-EVM của người dùng có thể thay thế ứng dụng khách thực thi của nó; ứng dụng khách thực thi sẽ vẫn được sử dụng bởi (i) người kiểm chứng và người xây dựng khối, và (ii) những người liên quan đế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 nhận lại

Giả sử có hai máy khách Ethereum, một trong số đó sử dụng PSE ZK-EVM và loại còn lại sử dụng Polygon ZK-EVM. Người ta giả định rằng vào thời điểm này, cả hai cách triển khai đều đã 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 bằng chứng riêng lẻ chưa được thiết lập chính thức nên chúng không thể nhận được các ưu đãi trong giao thức, tuy nhiên, chúng tôi hy vọng 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ể tài trợ cho các nút bằng chứng chỉ đơn giản thông qua nguồn tài trợ chung của cơ quan 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. Nút chứng minh của Polygon ZK-EVM nhìn thấy điều này, tính toán và xuất bản lại đối tượng, cùng với bằng chứng của Polygon ZK-EVM.

Đây sẽ là lần sớm nhất trung thực Tổng độ trễ tối đa giữa một nú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ăng từ δ lên 2δ + Tprove (ở đây giả sử Tprove <5 giây).

Tuy nhiên, tin tốt là nếu chúng ta áp dụng thuyết xác định một khe, chúng ta gần như chắc chắn có thể kết hợp độ trễ bổ sung này với độ trễ đồng thuận nhiều vòng vốn có trong SSF xử lý đường ống". Ví dụ: trong đề xuất 4 ô con này, 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ơ bản, nhưng 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 "gần như EVM"

Mục tiêu mong muốn cho ZK-EVM chức năng Nó hỗ trợ "gần như EVM": EVM với một số tính 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ã hoạt động mới cho phép viết hợp đồng bằng EVM hoặc một VM hoàn toàn khác (ví dụ: trong Arbitrum Stylus) hoặc thậm chí nhiều EVM song song có giao tiếp chéo đồng bộ.

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ể được sử dụng cho:

· Bảng chi phí gas tùy chỉnh (người dùng không được 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 có nghĩa là 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 trình biên dịch trước (hoặc mã opcode) mới theo cách cởi mở hơn, chúng tôi có thể thêm trình biên dịch trước như một phần của blob của ZKEVMClaimNetworkTransaction input/ xuất ra nội dung được phiên âm:

EVM việc thực hiện sẽ được sửa đổi như sau. Các đầu vào mảng sẽ được khởi tạo thành trống. Mỗi khi 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 các cam kết blob thu được đối với việc tuần tự hóa SSZ của input hay không. Mục đích của việc hiển thị input_commitments là tạo điều kiện cho 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. Các lần thực thi EVM đã có đầu vào được tạo sẵn 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 đã khai báo 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 cho họ ở dạng hoàn chỉnh và do đó 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 đượ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 trong một 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 mã hoạt động 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 rất mạnh mẽ. Ví dụ:

· Bằng cách đặt used_precompile_addresses, hãy bao gồm danh sách các địa chỉ tài khoản thông thường ở trạng thái có một số cờ nhất định được đặt trong đối tượng tài khoản của chúng và tạo SNARK để chứng minh điều đó Được xây dựng chính xác, bạn có thể hỗ trợ chức năng kiểu Arbitrum Stylus, trong đó mã của hợp đồng có thể được viết bằng EVM hoặc WASM (hoặc VM khác). 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 EVM.

· Bằng cách thêm một kiểm tra bên ngoài để đảm bảo rằng 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 khớp chính xác, bạn có thể chứng minh rằng nhiều hệ thống EVM song song.

· 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 trực tiếp Solidity hoặc các ngôn ngữ cấp cao khác thành thân thiện với SNARK VM và cái còn lại biên dịch nó thành mã EVM và thực thi nó trong ZK-EVM, được coi là một tiêu chuẩn. Việc triển khai thứ hai (chắc chắn là chậm hơn) chỉ hoạt động trong trường hợp người kiểm tra lỗi gửi giao dịch xác nhận lỗi và có thể nhận được phần thưởng nếu họ có thể cung cấp giao dịch được cả hai xử lý khác nhau.

· Có thể triển khai một VM hoàn toàn không đồng bộ 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.

Tiện ích mở rộng: hỗ trợ cho những người chứng minh có trạng thái

Một thách thức của thiết kế trên là nó Nó hoàn toàn không có trạng thái, khiến việc sử dụng dữ liệu kém hiệu quả hơn. Bằng cách hỗ trợ nén có trạng thái, sử dụng tính năng nén dữ liệu lý tưởng, việc gửi ERC20 có thể tiết kiệm không gian hơn so với việc chỉ sử dụng tính năng nén không trạng thái, tiết kiệm không gian gấp 3 lần.

Ngoài ra, trạng thái The EVM 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: yêu cầu phải có sẵn dữ liệu là một sự lãng phí vì chúng tôi đã biết rằng dữ liệu có sẵn vì dữ liệu đó được nhập vào hoặc được tạo ra bởi quá trình thực thi EVM trước đó.

Nếu muốn làm cho hàm ZK-EVM có trạng thái, thì chúng ta có hai lựa chọn:

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

2. Thêm lời hứa blob về biên nhận R do khối tạo ra vào bộ dữ liệu (σ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 lai hoặc thậm chí các giao dịch blob EIP-4844 thông thường, có thể với một số hạn chế về thời gian, đều có thể được tham chiếu trong ZKEVMClaimTransaction và được sử dụng trong quá trình thực thi nó được truy cập (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 tại vị trí j của khối + dữ liệu chứng kiến").

(1) Về cơ bản có thể 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 tích hợp sẵn 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 điều này đều tạo thêm gánh nặng cho nút chứng minh, chỉ là nút chứng minh, để lưu trữ nhiều thông tin hơn; trong trường hợp (2) việc giới hạn gánh nặng này trong một thời gian nhất định sẽ dễ dàng hơn so với trường hợp (1).

Tranh cãi giữa hệ thống nhiều bằng chứng đóng và dữ liệu ngoài chuỗi

Hệ thống nhiều bằng chứng đóng sửa chữa một số hệ thống chứng minh nhất định trong cấu trúc M-of-N, tránh được nhiều sự phức tạp nêu trên. Đặc biệt, một 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, hệ thống đa chuẩn khép kín sẽ cho phép thực thi bằng chứng ZK-EVM ngoài chuỗi; khiến nó tương thích với các giải pháp EVM Plasma.

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

Nếu chúng ta thiết lập ZK-EVM như một tính năng giao thức, thì "Dự án L2" sẽ có vai trò gì?

Giao thức sẽ xử lý các chức năng xác minh EVM hiện do chính nhóm L2 triển khai, nhưng dự án L2 vẫn sẽ chịu trách nhiệm về nhiều chức năng quan trọng:

Xác nhận trước nhanh chóng: Tính hữu hạn của một vị trí có thể làm chậm các vị trí L1 và dự án L2 đã cung cấp cho người dùng "xác nhận trước" được hỗ trợ bởi bảo mật riêng của L2, độ 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 thuần túy của L2.

Chiến lược giảm thiểu MEV: Điều này có thể bao gồm nhóm bộ nhớ được mã hóa, lựa chọn đơn hàng dựa trên danh tiếng và các tính năng khác mà L1 không muốn triển khai .

Phần 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 để mang lại 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 hoàn toàn khác nhau như hỗ trợ WASM của Arbitrum Stylus và ngôn ngữ Cairo thân thiện với SNARK.

Sự thuận tiện cho người dùng và nhà phát triển: Nhóm L2 rất giỏi trong việc thu hút người dùng và dự án vào hệ sinh thái của mình và khiến họ cảm thấy được chào đón rất nhiều hoàn thành công việc; họ được đền bù bằng cách thu phí 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.

「Liên kết gốc‖

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