Vitalik tác phẩm mới nhanh đọc: Định giá Gas đa chiều

?

• tác giả: Vitalik Buterin*

• biên dịch: Karen, Foreisght News *

Trong Ethereum, tài nguyên cho đến gần đây vẫn còn hạn chế và được định giá thông qua một tài nguyên duy nhất gọi là "Gas". Gas là đơn vị đo lường lượng "công sức tính toán" (computational effort) cần thiết để xử lý một giao dịch hoặc khối cụ thể. Gas kết hợp nhiều loại "công sức tính toán", trong đó quan trọng nhất bao gồm:

1. Tính toán thô (Raw computation, ví dụ như ADD, MULTIPLY);

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

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

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

Ví dụ, giao dịch mà tôi gửi đã tiêu tốn tổng cộng 47,085 Gas. Trong đó bao gồm: (i) chi phí cơ bản là 21000 Gas, (ii) số byte calldata bao gồm trong giao dịch tiêu tốn 1556 Gas, (iii) đọc và ghi bộ nhớ tiêu tốn 16500 Gas, (iv) tạo nhật ký (log) tiêu tốn 2149 Gas, phần còn lại được sử dụng cho việc thực thi EVM. Phí giao dịch mà người dùng phải trả tỷ lệ thuận với Gas mà giao dịch tiêu tốn. 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 mục tiêu EIP-1559, đảm bảo mỗi khối trung bình chứa 15 triệu Gas.

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

Tuy nhiên, phương pháp này cũng có sự kém hiệu quả: nó coi các tài nguyên khác nhau là có thể chuyển đổi lẫn nhau, trong khi các hạn chế cơ bản thực tế thì không giống nhau. Để hiểu vấn đề này, bạn có thể xem biểu đồ dưới đây:

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

Các ràng buộc an toàn cơ bản thực tế thường gần hơn với:

Sự khác biệt này dẫn đến việc giới hạn Gas hoặc là vô lý loại trừ các khối an toàn thực tế, hoặc chấp nhận các khối thực tế không an toàn, hoặc cả hai.

Nếu có n loại tài nguyên với các hạn chế an toàn khác nhau, thì Gas một chiều có thể làm giảm thông lượng tối đa đến n lần. Do đó, trong một thời gian dài, mọi người đã quan tâm đến khái niệm Gas đa chiều, và thông qua EIP-4844, chúng ta hiện đã thực sự triển khai Gas đa chiều trên Ethereum. Bài viết này khám phá những lợi ích của phương pháp này, cũng như triển vọng để tăng cường thêm.

Blob: Gas đa chiều trong Dencun

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

Vậy tại sao không giảm chi phí Gas cho calldata (hiện tại byte không bằng 0 là 16 Gas, byte bằng 0 là 4 Gas) để làm cho Rollup rẻ hơn? Chúng tôi đã làm điều đó trước đây và bây giờ có thể làm lại. Nhưng câu trả lời ở đây là: kích thước tối đa của khối là 30,000,000/16=1,875,000 byte không bằng 0, và mạng chỉ vừa đủ hoặc gần như không thể xử lý khối có kích thước như vậy. Giảm chi phí thêm 4 lần sẽ làm tăng giới hạn lên 7.5 MB, điều này sẽ mang lại rủi ro lớn cho an toàn.

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 độc lập, thân thiện với Rollup (gọi là blob) trong mỗi khối.

Hai loại tài nguyên này có giá cả và giới hạn khác nhau: sau khi hard fork Dencun, một khối Ethereum có thể chứa tối đa (i) 30 triệu Gas và (ii) 6 blob, mỗi blob có thể chứa khoảng 125 kB calldata. Cả hai loại tài nguyên này đều có giá riêng biệt và được điều chỉnh thông qua cơ chế định giá riêng biệt tương tự như EIP-1559, với mục tiêu sử dụng trung bình 15 triệu Gas và 3 blob mỗi khối.

Kết quả là, chi phí Rollup giảm 100 lần, khối lượng giao dịch trên Rollup tăng hơn 3 lần, trong khi kích thước tối đa lý thuyết của khối chỉ tăng nhẹ: từ khoảng 1.9 MB lên khoảng 2.6 MB.

• Chú thích: Phí giao dịch Rollup, do Growthepie.xyz cung cấp. Hard fork Dencun diễn ra vào ngày 13 tháng 3 năm 2024, giới thiệu định giá đa chiều cho blob. *

Gas đa chiều và khách hàng không trạng thái

Trong tương lai gần, chứng minh lưu trữ của khách hàng không trạng thái (stateless clients) cũng sẽ gặp phải vấn đề tương tự. Khách hàng không trạng thái là một loại khách hàng mới có thể 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 tại địa phương. Khách hàng không trạng thái đạ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à giao dịch trong khối đó cần truy cập.

Hình trên cho thấy một khách hàng không trạng thái nhận một khối, cũng như chứng minh giá trị hiện tại của các phần trạng thái cụ thể mà khối đó tác động đến (ví dụ, số dư tài khoản, mã, lưu trữ), cho phép nút xác minh một khối mà không cần bất kỳ lưu trữ nào.

Một lần đọc lưu trữ cần tiêu tốn 2100-2600 Gas, tùy thuộc vào loại đọc, trong khi chi phí ghi vào lưu trữ cao hơn. Trung bình, một khối sẽ thực hiện khoảng 1000 lần đọc và ghi lưu trữ (bao gồm kiểm tra số dư ETH, gọi SSTORE và SLOAD, đọc mã hợp đồng và các hoạt động khác). Tuy nhiên, giá trị 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 không trạng thái tỷ lệ thuận với con số này.

Kế hoạch hiện tại là hỗ trợ khách hàng không trạng thái bằng cách chuyển thiết kế cây trạng thái của Ethereum từ Merkle Patricia trees sang Verkle trees. Tuy nhiên, Verkle trees không có khả năng chống lại lượng tử và không phải là lựa chọn tối ưu cho các hệ thống chứng minh STARK mới hơn. Do đó, nhiều người quan tâm đến việc hỗ trợ khách hàng không trạng thái thông qua các cây Merkle nhị phân và STARK, hoặc hoàn toàn bỏ qua Verkle, hoặc nâng cấp sau vài năm chuyển tiếp Verkle, khi STARK trở nên trưởng thành hơn.

Chứng minh STARK dựa trên 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 nó là thời gian tạo chứng minh rất lâu: Verkle trees có thể chứng minh hơn 100,000 giá trị mỗi giây, trong khi STARK dựa trên băm thường chỉ có thể chứng minh vài nghìn băm mỗi giây, và chứng minh mỗi giá trị cần bao gồm nhiều "nhánh" (branch) băm.

Xét đến các con số dự đoán từ các hệ thống chứng minh tối ưu hóa cao như Binius và Plonky3, cũng như băm chuyên dụng như Vision-Mark-32, chúng ta dường như sẽ ở trong một phạm vi thực tiễn trong một thời gian, tức là chứng minh 1000 giá trị mỗi giây là khả thi, nhưng chứng minh 14,285 giá trị thì không khả thi. Khối trung bình sẽ không gặp vấn đề gì, nhưng khối trong trường hợp xấu nhất tiềm năng (do kẻ tấn công phát hành) sẽ phá hủy 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 giá trị tối đa mỗi khối xuống mức an toàn hơn. Tuy nhiên, chúng tôi đã làm điều này nhiều lần, và nếu làm lại, sẽ khiến 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í truy cập lưu trữ riêng biệt, giữ mứ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 giới hạn tối đa cho mỗi khối, chẳng hạn như 2000 lần.

Tính phổ quát của Gas đa chiều

Một tài nguyên khác đáng xem xét là sự gia tăng kích thước trạng thái: tức là các hoạt động làm tăng kích thước trạng thái Ethereum, mà sau đó cần các nút đầy đủ để lưu trữ. Điều đặc biệt về sự gia tăng kích thước trạng thái là lý do hạn chế nó hoàn toàn đến từ việc sử dụng liên tục lâu dài, chứ không phải từ đỉnh điểm.

Do đó, việc thêm một chiều Gas riêng biệt cho các hoạt động làm tăng kích thước trạng thái (ví dụ, SSTORE từ không đến không) có thể có giá trị, nhưng mục tiêu khác nhau: chúng ta có thể đặt một mức giá dao động để nhắm vào mức sử dụng trung bình cụ thể, nhưng hoàn toàn không đặt giới hạn cho mỗi khối.

Điều này cho thấy một thuộc tính mạnh mẽ của Gas đa chiều: nó cho phép chúng ta hỏi riêng biệt cho mỗi tài nguyên, (i) mức sử dụng trung bình lý tưởng là gì? (ii) mức sử dụng tối đa an toàn cho mỗi khối là gì? Khác với việc đặt giá Gas dựa trên giá trị tối đa cho mỗi khối và để mức sử dụng trung bình theo sau, chúng ta có 2n bậc tự do để đặt 2n tham số, điều chỉnh từng tham số dựa trên các cân nhắc về an toàn mạng.

Các trường hợp phức tạp hơn, chẳng hạn như khi các cân nhắc an toàn của hai loại tài nguyên cộng lại một phần, có thể được xử lý bằng cách làm cho một mã thao tác hoặc tài nguyên tiêu tốn một số lượng Gas của nhiều loại (ví dụ, một SSTORE từ không đến không có thể tiêu tốn 5000 Gas chứng minh khách hàng không trạng thái và 20000 Gas mở rộng lưu trữ).

Chi phí giao dịch Max (chọn loại dữ liệu hoặc tính toán tiêu tốn nhiều hơn)

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

Trong kịch bản này, chúng ta định nghĩa chi phí Gas cho giao dịch là:

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

Nên dễ dàng thấy điều này làm thế nào để tăng thông lượng trong khi đảm bảo an toàn. Về lý thuyết, lượng dữ liệu tối đa trong một khối vẫn là Gas LIMIT /𝑥1, giống hệt như trong kế hoạch Gas một chiều. Tương tự, lượng tính toán tối đa lý thuyết là Gas LIMIT /𝑥2, cũng giống hệt như trong kế hoạch Gas một chiều. Tuy nhiên, chi phí Gas cho bất kỳ giao dịch nào tiêu tốn dữ liệu và tính toán sẽ giảm.

Đây có lẽ là kế hoạch được đề xuất trong EIP-7623, nhằm giảm kích thước khối tối đa trong khi tăng thêm số lượng blob. Cơ chế chính xác trong EIP-7623 phức tạp hơn một chút: nó giữ giá calldata hiện tại là 16 Gas mỗi byte, nhưng tăng giá sàn lên 48 Gas mỗi byte; giao dịch trả phí (16 * bytes + execution_Gas) và (48 * bytes) cao hơn. Do đó, EIP-7623 giảm lượng dữ liệu gọi giao dịch tối đa lý thuyết trong khối từ khoảng 1.9 MB xuống khoảng 0.6 MB, trong khi giữ chi phí của hầu hết các ứng dụng không thay đổi. 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, do đó rất dễ thực hiện.

Tuy nhiên, phương pháp này có hai nhược điểm:

1. Ngay cả khi tất cả các giao dịch khác trong khối chỉ sử dụng rất ít tài nguyên đó, giao dịch chiếm nhiều tài nguyên vẫn sẽ bị tính phí quá nhiều;

2. Nó khuyến khích các giao dịch tập trung vào dữ liệu và tính toán được gộp lại thành một gói để tiết kiệm chi phí.

Tôi cho rằng, các quy tắc như EIP-7623, cho dù là đối với calldata giao dịch hay các tài nguyên khác, đều có thể mang lại lợi ích đủ lớn, ngay cả khi có những nhược điểm này, vẫn đáng giá.

Tuy nhiên, nếu chúng ta sẵn sàng đầu tư (nỗ lực phát triển cao hơn đáng kể), sẽ xuất hiện một phương pháp lý tưởng hơn.

EIP-1559 đa chiều: chiến lược khó khăn nhưng lý tưởng

Hãy cùng xem lại cách hoạt động của EIP-1559 thông thường. Chúng ta sẽ tập trung vào phiên bản được giới thiệu cho blob trong EIP-4844, vì nó về mặt toán học thanh lịch hơn.

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

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

Trong đó TARGET = 3. Nói cách khác, nếu số lượng blob trong một khối vượt quá mục tiêu, thì excessblobs sẽ tăng lên, nếu số lượng blob trong một khối ít hơn mục tiêu, thì excessblobs sẽ giảm xuống. Sau đó, chúng ta đặt blobbasefee = exp(excessblobs / 25.47), trong đó exp là hàm số mũ 𝑒𝑥𝑝(𝑥)=2.71828^𝑥.

Nói cách khác, mỗi khi excessblobs tăng khoảng 25, phí cơ bản cho blob sẽ tăng khoảng 2.7 lần. Nếu blob trở nên quá đắt, mức sử dụng trung bình sẽ giảm và excessblobs bắt đầu giảm, từ đó tự động giảm giá trở lại. Giá của Blob được điều chỉnh liên tục để đảm bảo trung bình, khối là nửa đầy, tức là mỗi khối trung bình chứa 3 Blob.

Nếu mức sử dụng có đỉnh điểm ngắn hạn, sẽ có giới hạn: mỗi khối chỉ có thể chứa tối đa 6 blob, trong trường hợp này, các giao dịch có thể cạnh tranh với nhau bằng cách tăng phí ưu tiên. Tuy nhiên, trong điều kiện bình thường, mỗi blob chỉ cần trả phí blob_basefee cộng với một khoản phí ưu tiên nhỏ để được đưa vào.

Cách định giá Gas này đã tồn tại trong Ethereum nhiều năm: 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á dao động độc lập cho Gas và Blobs.

• Chú thích: Phí cơ bản Gas trong một giờ vào ngày 8 tháng 5 năm 2024, đơn vị là gwei. Nguồn: ultrasound.money *

Về nguyên tắc, chúng ta có thể thêm nhiều khoản phí dao động độc lập hơn cho việc đọc lưu trữ và các loại hoạt động khác, tuy nhiên tôi sẽ đề cập đến 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 ngày hôm nay: bạn không còn trả một khoản phí cơ bản (basefee) nữa, mà thay vào đó là hai khoản phí cơ bản, nhưng ví của bạn có thể trừu tượng hóa điều này từ tay bạn, chỉ hiển thị cho bạn phí dự kiến và phí tối đa mà bạn có thể phải trả.

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

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

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

Tuy nhiên, các 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 mức giá trung bình lịch sử lâu dài.

Định giá đa chiều, EVM và các cuộc gọi con

Có một vấn đề không xuất hiện trong các blob, cũng như không xuất hiện trong EIP-7623 hoặc thậm chí là trong việc thực hiện định giá đa chiều đầy đủ cho calldata, nhưng nếu chúng ta cố gắng định giá riêng cho truy cập trạng thái hoặc bất kỳ tài nguyên nào khác, thì vấn đề này sẽ xuất hiện: đó là giới hạn Gas trong các cuộc gọi con (sub-calls).

Giới hạn Gas trong EVM tồn tại ở hai nơi. Đầu tiên, mỗi giao dịch sẽ thiết lập một giới hạn Gas (Gas Limit), giới hạn 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ể thiết lập giới hạn Gas riêng của nó. Đ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 rằng họ có đủ Gas còn lại để thực hiện các tính toán khác sau cuộc gọi.

Chú thích: Dấu vết của giao dịch trừu tượng tài khoản, trong đó một tài khoản gọi một tài khoản khác và chỉ cung cấp cho người được gọi một lượng Gas hạn chế, để đảm bảo rằng ngay cả khi người được gọi tiêu tốn toàn bộ Gas được phân bổ cho nó, 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 thực hiện Gas đa chiều giữa các loại thực thi khác nhau dường như yêu cầu các 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ẽ cần thay đổi rất sâu sắc đố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 mà các đề xuất Gas đa chiều thường chỉ dừng lại ở hai chiều: dữ liệu và thực thi. Dữ liệu (dù là calldata giao dịch hay blob) chỉ được phân bổ bên ngoài EVM, do đó bên trong EVM không cần thay đổi gì để có thể định giá riêng cho calldata hoặc blob.

Chúng ta có thể nghĩ ra một "giải pháp kiểu EIP-7623" để giải quyết vấn đề này. Đây là một cách thực hiện đơn giản: trong quá trình thực thi, tính phí gấp 4 lần cho các thao tác lưu trữ; để đơn giản hóa phân tích, giả sử mỗi thao tác lưu trữ có 10000 Gas. Cuối giao dịch, hoàn lại min(7500 * storageoperations, executionGas). Kết quả là, sau khi trừ hoàn lại, người dùng cần phải trả các khoản phí sau:

executionGas + 10000 * storageoperations - min(7500 * storageoperations, executionGas)

Điều này tương đương với:

max(executionGas + 2500 * storageoperations, 10000 * storage_operations)

Điều này phản ánh cấu trúc của EIP-7623. Một phương pháp khác là theo dõi thời gian thực các storageoperations và executionGas, và tính phí 2500 hoặc 10000 dựa trên mức tăng của max(executionGas + 2500 * storageoperations, 10000 * storage_operations) khi mã thao tác được gọi. Điều này tránh việc giao dịch cần phân bổ quá nhiều Gas, mà chủ yếu được hoàn lại thông qua hoàn lại.

Chúng ta không có sự cho phép 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ộ khoản phân bổ của giao dịch để thực hiện các thao tác lưu trữ rẻ.

Nhưng chúng ta thực sự có được một số thứ đủ tốt, tức là các hợp đồng thực hiện cuộc gọi con có thể thiết lập một giới hạn và đảm bảo rằng một khi cuộc gọi con hoàn tất, cuộc gọi chính vẫn có đủ Gas để thực hiện các xử lý cần thiết (post-processing).

Giải pháp "định giá đa chiều hoàn chỉnh" đơn giản nhất mà tôi có thể nghĩ đến là: chúng ta sẽ xem giới hạn Gas của các cuộc gọi con như là tỷ lệ. Nói cách khác, giả sử có 𝑘 loại thực thi khác nhau và mỗi giao dịch thiết lập 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…𝑔𝑘. Giả sử gọi mã CALL và sử dụng giới hạn Gas cho cuộc gọi con 𝑆. Đặt 𝑠1=𝑆, sau đó 𝑠2=𝑠1/𝑔1∗𝑔2, 𝑠3=𝑠1/𝑔1∗𝑔3, và cứ như vậy.

Nói cách khác, chúng ta sẽ xem loại Gas đầu tiên (thực tế là thực thi VM) như là một "đơn vị tài khoản" đặc biệt, sau đó phân bổ các loại Gas khác để các cuộc gọi con có được tỷ lệ Gas khả dụng giống nhau trong mỗi loại Gas. Phương pháp này có chút khó nhìn (ugly), nhưng tối đa hóa khả năng tương thích ngược.

Nếu chúng ta muốn làm cho kế hoạch này trở nên "trung lập" hơn giữa các loại Gas mà không hy sinh khả năng 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 của các cuộc gọi con như là 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 bất kỳ trường hợp nào, điều đáng nhấn mạnh là, một khi bắt đầu đưa Gas thực thi đa chiều vào, độ phức tạp vốn có (ugliness) 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ự đánh đổi phức tạp: liệu chúng ta có chấp nhận một mức độ phức tạp (ugliness) nào đó ở cấp độ EVM để mở khóa một cách an toàn những lợi ích mở rộng L1 đáng kể hay không, và nếu có, đề xuất cụ thể nào sẽ hiệu quả nhất đối với kinh tế giao thức và các nhà phát triển ứng dụng? Rất có thể, hai kế hoạch mà tôi đã đề cập ở trên không phải là tốt nhất, nhưng vẫn còn không gian để đề xuất các kế hoạch thanh lịch và tốt hơn hơn.

Cảm ơn đặc biệt Ansgar Dietrichs, Barnabe Monnot và Davide Crapis đã phản hồi và xem xét.