Vitalik's công việc mới: Đây là gì về giá xăng đa chiều?

Tác giả: Vitalik Buterin

Dịch bởi: Karen, Foresight News

Trong Ethereum, tài nguyên đã bị hạn chế cho đến gần đây và được định giá bằng một tài nguyên duy nhất gọi là "Gas." Gas là một đơn vị đo lường cho "nỗ lực tính toán" cần thiết để xử lý các giao dịch hoặc khối cụ thể. Gas kết hợp các loại "nỗ lực tính toán" khác nhau, trong đó những loại quan trọng nhất là:

1. Tính toán thô (ví dụ: CỘNG, NHÂN);

2. Đọc và ghi vào bộ nhớ lưu trữ Ethereum (ví dụ: SSTORE, SLOAD, chuyển ETH);

3. Băng thông dữ liệu;

4. Chi phí tạo ra các chứng minh ZK-SNARK cho các khối.

Ví dụ, giao dịch mà tôi gửi đã tiêu thụ tổng cộng 47.085 Gas. Điều này bao gồm: (i) chi phí cơ bản là 21.000 Gas, (ii) số byte calldata được bao gồm trong giao dịch tiêu thụ 1556 Gas, (iii) đọc/ghi vào bộ nhớ tiêu thụ 16.500 Gas, (iv) ghi nhật ký tiêu thụ 2149 Gas, phần còn lại được sử dụng cho thực thi EVM. Phí giao dịch mà người dùng phải trả tỷ lệ thuận trực tiếp với Gas tiêu thụ của giao dịch. Một khối có thể chứa tối đa 30 triệu Gas, và giá Gas được điều chỉnh liên tục thông qua cơ chế định mục tiêu EIP-1559 để đảm bảo trung bình 15 triệu Gas mỗi khối.

Phương pháp này có một ưu điểm lớn: vì tất cả nội dung được hợp nhất vào một tài nguyên ảo, thiết kế thị trường rất đơn giản. Tối ưu hóa giao dịch để giảm chi phí là dễ dàng, tối ưu hóa các khối để thu thập phí cao nhất có thể tương đối dễ dàng (ngoại trừ MEV), và không có cơ chế khuyến khích kỳ lạ nào khuyến khích việc gói một số giao dịch với nhau để tiết kiệm chi phí.

Tuy nhiên, phương pháp này cũng có hiệu suất không cao: nó xem xét các tài nguyên khác nhau như có thể thay thế khi các ràng buộc cơ bản thực sự khác nhau. Để hiểu vấn đề này, bạn có thể xem biểu đồ sau đây trước:

Giới hạn Gas áp đặt một ràng buộc:

Các ràng buộc bảo mật cơ bản thực sự thường gần với:

Sự khác biệt này khiến cho giới hạn Gas có thể loại trừ một cách không công bằng các khối thực sự an toàn, chấp nhận các khối thực sự không an toàn, hoặc cả hai.

Nếu có n tài nguyên với các ràng buộc bảo mật khác nhau, Gas một chiều có thể làm giảm hiệu suất lên đến n lần. Do đó, mọi người đã lâu đã quan tâm đến khái niệm Gas đa chiều, và thông qua EIP-4844, chúng tôi đã thực sự triển khai Gas đa chiều trên Ethereum. Bài viết này khám phá những ưu điểm của phương pháp này và triển vọng cho những cải tiến tiếp theo.

Blob: Gas Đa chiều trong Dencun

Đầu năm nay, kích thước trung bình của khối là 150 kB. Một phần lớn trong đó là dữ liệu Rollup: các giao thức Layer2 lưu trữ dữ liệu trên chuỗi. Dữ liệu này rất đắt đỏ: mặc dù chi phí của các giao dịch trên Rollup chỉ tăng 5-10 lần so với các giao dịch tương ứng trên Ethereum L1, nhưng chi phí này vẫn quá cao đối với nhiều trường hợp sử dụng.

Vậy tại sao không giảm chi phí Gas của calldata (hiện tại là 16 Gas cho byte khác không, 4 Gas cho byte không) để làm cho Rollup rẻ hơn? Chúng tôi đã làm điều này trước đây, và chúng ta có thể làm lại bây giờ. Nhưng câu trả lời ở đây là: kích thước khối tối đa là 30.000.000/16=1.875.000 byte khác không, và mạng gần như không thể xử lý hoặc gần như không thể xử lý các khối có kích thước như vậy. Giảm chi phí 4 lần sẽ tăng kích thước tối đa lên 7,5 MB, điều này sẽ tạo ra một rủi ro lớn đối với bảo mật.

Vấn đề này cuối cùng được giải quyết bằng cách giới thiệu một không gian dữ liệu riêng, thân thiện với Rollup (được gọi là blob) trong mỗi khối.

Hai tài nguyên này có giá và giới hạn khác nhau: sau cú đảo hard fork Dencun, một khối Ethereum có thể chứa (i) 30 triệu Gas và (ii) 6 blobs, mỗi blobs có thể chứa một

Khoảng 125 kB dữ liệu cuộc gọi. Hai nguồn tài nguyên này có giá riêng và được điều chỉnh thông qua cơ chế định giá tương tự như EIP-1559, với mục tiêu trung bình 15 triệu Gas và 3 blobs mỗi khối.

Do đó, chi phí của Rollup đã giảm đi 100 lần, khối lượng giao dịch trên Rollup đã tăng hơn 3 lần, và kích thước khối tối đa lý thuyết chỉ tăng ít: từ khoảng 1,9 MB lên khoảng 2,6 MB.

Lưu ý: Phí giao dịch Rollup được cung cấp bởi Growthepie.xyz. Sự phân nhánh Dencun đã xảy ra vào ngày 13 tháng 3 năm 2024, giới thiệu việc định giá đa chiều cho blobs.

Gas Đa chiều và Khách hàng Stateless

Trong tương lai gần, chứng minh lưu trữ cho khách hàng Stateless cũng sẽ phải đối mặt với các vấn đề tương tự. Stateless clients là một loại khách hàng mới sẽ có khả năng xác minh chuỗi mà không cần lưu trữ một lượng lớn hoặc bất kỳ dữ liệu nào cục bộ. Stateless clients đạt được điều này bằng cách chấp nhận chứng minh về các phần cụ thể của trạng thái Ethereum mà các giao dịch trong khối đó cần truy cập.

Biểu đồ cho thấy một khách hàng Stateless nhận một khối và chứng minh về các giá trị hiện tại của các phần cụ thể của trạng thái mà khối thực thi (ví dụ: số dư tài khoản, mã, lưu trữ), cho phép các nút xác minh một khối mà không cần lưu trữ nào.

Việc đọc lưu trữ tốn 2100-2600 Gas, tùy thuộc vào loại đọc, với chi phí ghi lưu trữ cao hơn. Trung bình, một khối sẽ thực hiện khoảng 1000 hoạt động đọc/ghi lưu trữ (bao gồm kiểm tra số dư ETH, cuộc gọi SSTORE và SLOAD, đọc mã hợp đồng và các hoạt động khác). Tuy nhiên, kích thước khối tối đa lý thuyết là 30.000.000/2.100=14.285 lần đọc. Tải băng thông của khách hàng Stateless tỉ lệ với số này.

<pkế hoạch hiện tại là hỗ trợ khách hàng stateless bằng cách chuyển thiết kế cây trạng thái của ethereum từ merkle patricia sang verkle. tuy nhiên, verkle không có bảo mật sau lượng tử và phải lựa chọn tối ưu cho các hệ thống chứng minh stark mới. do đó, nhiều người quan tâm đến việc thông qua nhị phân starks, hoặc hoàn toàn bỏ nâng cấp lên starks vài năm đổi verkle, khi trở nên chín chắn hơn.< p>

Các chứng minh STARK dựa trên các nhánh cây băm nhị phân có nhiều lợi ích, nhưng điểm yếu chính của chúng là thời gian lâu để tạo ra chứng minh: cây Verkle có thể chứng minh hơn 100.000 giá trị mỗi giây, trong khi STARKs dựa trên băm thường chỉ chứng minh vài nghìn băm mỗi giây, và việc chứng minh mỗi giá trị yêu cầu nhiều nhánh băm.

Xét đến dự đoán ngày nay từ các hệ thống chứng minh tối ưu như Binius và Plonky3, cũng như các băm dành riêng như Vision-Mark-32, có vẻ như việc chứng minh 1000 giá trị mỗi giây là khả thi trong một thời gian, nhưng việc chứng minh 14.285 giá trị thì không. Một khối trung bình sẽ ổn, nhưng các khối trường hợp xấu nhất tiềm năng (được phát hành bởi kẻ tấn công) sẽ làm gián đoạn mạng.

Phương pháp mặc định của chúng tôi để xử lý các tình huống như vậy là định giá lại: tăng chi phí đọc lưu trữ để giảm tối đa mỗi khối xuống một mức an toàn hơn. Tuy nhiên, chúng tôi đã làm điều này nhiều lần rồi, và nếu làm lại, nó sẽ làm cho quá nhiều ứng dụng trở nên quá đắt đỏ. Một phương pháp tốt hơn là Gas đa chiều: giới hạn và tính phí cho việc truy cập lưu trữ một cách riêng biệt, giữ cho việc sử dụng trung bình ở mức 1000 lần truy cập lưu trữ mỗi khối, nhưng đặt một giới hạn tối đa mỗi khối, ví dụ, 2000 lần truy cập.

Tính Phổ cập của Gas Đa chiều

Một nguồn tài nguyên khác đáng xem xét là sự tăng trưởng của kích thước trạng thái: các hoạt động tăng kích thước trạng thái Ethereum, sau đó yêu cầu các nút đầy đủ lưu trữ. Điểm độc đáo của sự tăng trưởng kích thước trạng thái là giới hạn của nó đến hoàn toàn từ việc sử dụng bền vững dài hạn, không phải từ việc sử dụng cao điểm.

Do đó, việc thêm một chiều Gas riêng cho các hoạt động tăng kích thước trạng thái (ví dụ: SSTORE từ không đến khác không, tạo hợp đồng) có thể có giá trị, nhưng với một mục tiêu khác: chúng ta có thể đặt một floa

Đặt giá Gas theo mục tiêu sử dụng trung bình cụ thể, mà không đặt bất kỳ giới hạn nào cho mỗi khối.

Điều này thể hiện một đặc tính mạnh mẽ của Gas đa chiều: nó cho phép chúng ta tách biệt hỏi mỗi tài nguyên: (i) sử dụng trung bình lý tưởng là bao nhiêu? (ii) sử dụng tối đa an toàn mỗi khối là bao nhiêu? Không giống như việc đặt giá Gas dựa trên tối đa mỗi khối và để sử dụng trung bình đi theo, chúng ta có 2n độ tự do để đặt 2n tham số, điều chỉnh mỗi tham số dựa trên xem xét về bảo mật mạng.

Trong các tình huống phức tạp hơn, như khi xem xét về bảo mật cho hai tài nguyên trùng lắp một phần, điều này có thể được xử lý bằng cách làm cho một opcode hoặc tài nguyên tiêu thụ một lượng Gas nhất định của nhiều loại (ví dụ, tiêu thụ nhiều loại Gas cho một hoạt động từ không sang không).

ERO SSTORE có thể tiêu thụ 5000 Gas chứng minh khách hàng không trạng thái và 20000 Gas mở rộng lưu trữ).

Tối đa mỗi giao dịch (chọn cái tiêu thụ nhiều dữ liệu hoặc tính toán hơn)

Đặt 𝑥1 là chi phí Gas của dữ liệu, 𝑥2 là chi phí Gas của tính toán, vì vậy trong một hệ thống Gas một chiều, chúng ta có thể viết chi phí Gas của một giao dịch:

Trong kế hoạch này, chúng ta xác định chi phí Gas của một giao dịch là:

Nghĩa là, các giao dịch được tính phí không dựa trên dữ liệu cộng tính toán, mà dựa trên tài nguyên nào trong hai tài nguyên nó tiêu thụ nhiều hơn. Điều này dễ dàng mở rộng để bao phủ nhiều chiều hơn (ví dụ, 𝑚𝑎𝑥(...,𝑥3∗𝑠𝑡𝑜𝑟𝑎𝑔𝑒_𝑎𝑐𝑐𝑒𝑠𝑠)).

Có thể thấy cách này tăng hiệu suất trong khi đảm bảo bảo mật. Lý thuyết, khối lượng dữ liệu tối đa trong một khối vẫn là GasLIMIT/𝑥1, giống như trong kế hoạch Gas một chiều. Tương tự, khối lượng tính toán tối đa lý thuyết là GasLIMIT/𝑥2, cũng giống như trong kế hoạch Gas một chiều. Tuy nhiên, chi phí Gas của bất kỳ giao dịch nào tiêu thụ dữ liệu và tính toán sẽ giảm.

Đây có lẽ là phương pháp được áp dụng trong EIP-7623 đề xuất để giảm kích thước khối tối đa trong khi tiếp tục tăng số lượng blob. Cơ chế chính xác trong EIP-7623 phức tạp hơn một chút: giữ giá calldata hiện tại ở 16 Gas mỗi byte nhưng thêm một giá tối thiểu là 48 Gas mỗi byte; các giao dịch trả phí cao hơn giữa (16 * byte + execution_Gas) và (48 * byte). Do đó, EIP-7623 giảm giá trị calldata giao dịch tối đa lý thuyết trong một khối từ khoảng 1.9 MB xuống khoảng 0.6 MB trong khi giữ nguyên chi phí cho hầu hết các ứng dụng. Lợi ích của phương pháp này là nó thay đổi rất ít so với kế hoạch Gas một chiều hiện tại, làm cho việc triển khai rất dễ dàng.

Tuy nhiên, phương pháp này có hai điểm hạn chế:

1. Ngay cả khi tất cả các giao dịch khác trong khối sử dụng rất ít tài nguyên đó, các giao dịch tiêu thụ mạnh một tài nguyên vẫn sẽ phải chịu phí cao không cần thiết;

2. Nó khuyến khích việc gói gọn các giao dịch tiêu thụ dữ liệu và tính toán cùng nhau để tiết kiệm chi phí.

Tôi tin rằng các quy tắc như EIP-7623, cho calldata giao dịch hoặc các tài nguyên khác, có thể mang lại lợi ích đáng kể, ngay cả với những hạn chế này.

Tuy nhiên, nếu chúng ta sẵn lòng đầu tư (rất nhiều) công sức phát triển, một phương pháp lý tưởng hơn sẽ xuất hiện.

EIP-1559 Đa chiều: Một Chiến lược Khó Khăn nhưng Lý tưởng Hơn

Hãy xem xét cách EIP-1559 thông thường hoạt động trước tiên. Chúng ta sẽ tập trung vào phiên bản được giới thiệu trong EIP-4844 nhắm vào các blob vì nó đẹp toán học hơn.

Chúng ta theo dõi một tham số excess_blobs. Trong mỗi khoảng thời gian khối, chúng ta đặt:

excess_blobs <-- max(excess_blobs + len(block.blobs) - TARGET, 0)

nơi TARGET = 3. Điều này có nghĩa nếu một khối có nhiều blob hơn mục tiêu, excess_blobs tăng, và nếu một khối có ít blob hơn mục tiêu, excess_blobs giảm. Sau đó, chúng ta đặt blob_basefee = exp(excess_blobs / 25.47), nơi exp là giá trị xấp xỉ của số mũ.

Hàm 𝑒𝑥𝑝(𝑥)=2.71828^𝑥.

Điều này có nghĩa là mỗi khi excess_blobs tăng khoảng 25, phí cơ sở của blobs tăng khoảng 2.7 lần. Nếu blobs trở nên quá đắt, việc sử dụng trung bình giảm, và excess_blobs bắt đầu giảm, tự động giảm giá lại. Giá của blobs được điều chỉnh liên tục để đảm bảo trên trung bình, các block chỉ đầy một nửa, có nghĩa là mỗi block chứa trung bình 3 blobs.

Nếu có một đỉnh tạm thời trong việc sử dụng, có một giới hạn: mỗi block chỉ có thể chứa tối đa 6 blobs, trong trường hợp đó, các giao dịch có thể cạnh tranh bằng cách tăng phí ưu tiên. Tuy nhiên, trong các hoàn cảnh bình thường, mỗi blob chỉ cần trả phí cơ sở của blob cộng với một khoản phí ưu tiên nhỏ để được bao gồm như một động lực.

Loại hình định giá Gas này đã tồn tại trong Ethereum từ nhiều năm: ngay từ năm 2020, EIP-1559 đã giới thiệu một cơ chế rất tương tự. Thông qua EIP-4844, chúng ta thiết lập hai mức giá độc lập cho Gas và Blobs.

Lưu ý: Phí cơ sở Gas trong gwei trong một giờ vào ngày 8 tháng 5 năm 2024. Nguồn: ultrasound.money

Về nguyên tắc, chúng ta có thể thêm nhiều phí độc lập khác nhau cho việc đọc lưu trữ và các loại hoạt động khác, nhưng tôi sẽ trình bày một vấn đề cần lưu ý trong phần tiếp theo.

Đối với người dùng, trải nghiệm này rất giống với hiện tại: bạn không còn trả một khoản phí cơ sở nữa, mà là hai khoản phí cơ sở, mà ví của bạn có thể trừ trực tiếp từ bạn, chỉ hiển thị phí dự kiến và phí tối đa mà bạn có thể mong đợi phải trả.

Đối với người xây dựng block, chiến lược tối ưu hóa phần lớn thời gian là giống như hiện tại: bao gồm bất kỳ nội dung hợp lệ nào. Hầu hết các block không đầy—dù là về Gas hay Blobs. Một tình huống khó khăn nảy sinh khi có đủ Gas hoặc đủ Blobs để vượt quá giới hạn block, và người xây dựng có thể cần giải quyết một bài toán ba lô đa chiều để tối đa hóa lợi nhuận của họ. Tuy nhiên, ngay cả với các thuật toán xấp xỉ khá tốt, lợi ích từ việc tối ưu hóa lợi nhuận thông qua các thuật toán độc quyền trong tình huống này nhỏ hơn nhiều so với việc sử dụng MEV cho các hoạt động tương tự.

Đối với nhà phát triển, thách thức chính là cần phải thiết kế lại EVM và các chức năng cơ sở hạ tầng liên quan của nó, hiện đang được thiết kế dựa trên một giá và giới hạn duy nhất và bây giờ cần phải được tái cấu trúc để chứa nhiều giá và giới hạn.

Một vấn đề mà nhà phát triển ứng dụng phải đối mặt là việc tối ưu hóa trở nên khó khăn hơn một chút: trong một số trường hợp, bạn không còn có thể nói rõ ràng rằng A hiệu quả hơn B vì nếu A sử dụng nhiều calldata hơn và B sử dụng nhiều thực thi hơn, A có thể rẻ hơn khi calldata rẻ và đắt hơn khi calldata đắt.

Tuy nhiên, nhà phát triển vẫn có thể đạt được kết quả khá tốt bằng cách tối ưu hóa dựa trên giá trung bình lịch sử dài hạn.

Định giá đa chiều, EVM, và Sub-calls

Một vấn đề không nảy ra trong blobs, và cũng sẽ không nảy ra trong một triển khai định giá đa chiều đầy đủ nhắm vào calldata như EIP-7623 hoặc thậm chí cho việc định giá riêng lẻ truy cập trạng thái hoặc bất kỳ tài nguyên nào khác, đó là giới hạn Gas trong các sub-calls.

Giới hạn Gas trong EVM tồn tại ở hai nơi. Đầu tiên, mỗi giao dịch đặt một giới hạn Gas, hạn chế tổng lượng Gas có thể sử dụng trong giao dịch đó. Thứ hai, khi một hợp đồng gọi một hợp đồng khác, cuộc gọi đó có thể đặt giới hạn Gas riêng của mình. Điều này cho phép các hợp đồng gọi các hợp đồng khác mà họ không tin tưởng và vẫn đảm bảo họ còn Gas còn lại để thực thi các tính toán khác sau cuộc gọi.

Lưu ý: Dấu vết của một tài khoản trừu tượng một giao dịch, nơi một tài khoản gọi một tài khoản khác và cung cấp một lượng Gas giới hạn cho người được gọi để đảm bảo rằng ngay cả khi người được gọi tiêu hết toàn bộ Gas được cấp cho mình, cuộc gọi bên ngoài vẫn có thể tiếp tục chạy.

Thách thức là việc đạt được Gas đa chiều giữa các cuộc gọi con khác nhau.Có vẻ như các loại thực thi khác nhau đòi hỏi cuộc gọi con để cung cấp nhiều giới hạn cho mỗi loại Gas, điều này sẽ đòi hỏi những thay đổi rất sâu đối với EVM và không tương thích với các ứng dụng hiện có. Đây là một trong những lý do tại sao các đề xuất Gas đa chiều thường giữ ở hai chiều: dữ liệu và thực thi. Dữ liệu (dù là calldata giao dịch hoặc blob) được phân bổ bên ngoài cho EVM, vì vậy không cần thay đổi nội bộ của EVM để định giá calldata hoặc blob một cách riêng lẻ. Chúng ta có thể đưa ra một "giải pháp theo kiểu EIP-7623" để giải quyết vấn đề này. Đây là một cách triển khai đơn giản: tính 4 lần phí cho các thao tác lưu trữ trong quá trình thực thi; để đơn giản hóa phân tích Giả sử mỗi thao tác lưu trữ tốn 10,000 gas. Cuối giao dịch, sẽ được hoàn lại một khoản tiền là min(7500 * thao_tác_lưu_trữ, Gas_thực_thi). Do đó, sau khi trừ đi khoản hoàn lại, người dùng cần trả các khoản phí sau: Gas_thực_thi + 10,000 * thao_tác_lưu_trữ - min(7500 * thao_tác_lưu_trữ, Gas_thực_thi) Điều này bằng: max(Gas_thực_thi + 2,500 * thao_tác_lưu_trữ, 10,000 * thao_tác_lưu_trữ) Điều này phản ánh cấu trúc của EIP-7623. Một cách tiếp cận khác là theo dõi thao_tác_lưu_trữ và Gas_thực_thi theo thời gian thực và tính 2,500 hoặc 10,000 dựa trên việc max(Gas_thực_thi + 2,500 * thao_tác_lưu_trữ, 10,000 * thao_tác_lưu_trữ) tăng lên bao nhiêu khi mã opcode được gọi. Điều này tránh cần phải cấp phát gas quá mức, chủ yếu được hoàn lại thông qua các khoản hoàn lại. Chúng ta không có quyền chi tiết cho các cuộc gọi con: các cuộc gọi con có thể tiêu tốn toàn bộ phần phép cho phép giao dịch cho các thao tác lưu trữ rẻ tiền. Tuy nhiên, chúng ta có một điều khá tốt, đó là hợp đồng thực hiện cuộc gọi con có thể đặt một giới hạn và đảm bảo rằng sau khi cuộc gọi con hoàn tất, cuộc gọi chính vẫn còn đủ gas cho việc xử lý sau cần thiết. Giải pháp "giá định giá đa chiều hoàn chỉnh" đơn giản nhất mà tôi nghĩ đến là: chúng ta xem xét giới hạn gas cho cuộc gọi con là tỷ lệ. Nghĩa là, giả sử có 𝑘 loại thực thi khác nhau, và mỗi giao dịch đặt giới hạn đa chiều 𝐿1...𝐿𝑘. Giả sử tại điểm thực thi hiện tại, gas còn lại là 𝑔1...𝑔𝑘. Khi gọi mã CALL và sử dụng giới hạn gas cho cuộc gọi con 𝑆, hãy để 𝑠1=𝑆, sau đó 𝑠2=𝑠1/𝑔1*𝑔2, 𝑠3=𝑠1/𝑔1*𝑔3, và cứ thế. Nói cách khác, chúng ta xem xét gas cho loại đầu tiên (thực sự là thực thi VM) như một "đơn vị tài khoản" đặc biệt và sau đó phân bổ gas cho các loại khác sao cho cuộc gọi con nhận cùng một phần trăm gas có sẵn trong mỗi loại. Phương pháp này có vẻ hơi xấu xí nhưng tối đa hóa tính tương thích ngược. Nếu chúng ta muốn làm cho giải pháp này trở nên "trung lập" hơn giữa các loại gas khác nhau mà không hy sinh tính tương thích ngược, chúng ta có thể đơn giản biểu diễn tham số giới hạn gas cho cuộc gọi con như một phần của gas còn lại trong ngữ cảnh hiện tại (ví dụ, [1...63]/64). Tuy nhiên, trong mọi trường hợp, đáng lưu ý rằng một khi chúng ta bắt đầu giới thiệu gas thực thi đa chiều, độ phức tạp bẩm sinh sẽ tăng lên, điều này dường như khó tránh khỏi. Do đó, nhiệm vụ của chúng ta là thực hiện một sự cân nhắc phức tạp: chúng ta có chấp nhận một mức độ tăng độ phức tạp (xấu xí) tại cấp độ EVM để an toàn mở khóa những lợi ích đáng kể về khả năng mở rộng L1, và nếu có, đề xuất cụ thể nào là hiệu quả nhất cho kinh tế giao thức và các nhà phát triển ứng dụng? Rất có khả năng rằng không phải cách tiếp cận nào trong hai cách tiếp cận mà tôi đề cập ở trên là tốt nhất, nhưng vẫn còn không gian để đề xuất những giải pháp tinh tế và tốt hơn. Lời cảm ơn đặc biệt đến Ansgar Dietrichs, Barnabe Monnot và Davide Crapis vì phản hồi và xem xét của họ.

</pkế>