Bài đăng blog mới nhất của Vitalik: Thảo luận về Giá Gas đa chiều

Tác giả: Vitalik, người sáng lập Ethereum; Bản dịch: 0xjs@金财经

Trong Ethereum, cho đến gần đây, tài nguyên bị hạn chế và một loại nhiên liệu duy nhất gọi là "Gas" đã được sử dụng. Gas là thước đo "lượng tính toán" cần thiết để xử lý một giao dịch hoặc khối nhất định. Gas kết hợp một số loại "nỗ lực", đáng chú ý nhất là:

• Các phép tính cơ bản (chẳng hạn như ADD, MULTIPLY )

  < /li>

• Đọc và ghi bộ lưu trữ Ethereum (chẳng hạn như SSTORE, truyền SLOADETH)

• Băng thông dữ liệu

• < p>Chi phí tạo bằng chứng ZK-SNARK về một khối

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

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

Nhưng Cách tiếp cận này cũng có một vấn đề kém hiệu quả lớn: nó xử lý các tài nguyên khác nhau dưới dạng có thể chuyển đổi được cho nhau, trong khi mạng thực tế những hạn chế tiềm tàng của những gì có thể được xử lý là không. Một cách để hiểu vấn đề này là nhìn vào bức ảnh này:

Giới hạn gas thực thi các ràng buộc sau: x1*data+x2*computation<N. Các ràng buộc bảo mật cơ bản thực tế thường gần với max(x1*data, x2*computation)<N. Sự khác biệt này khiến giới hạn gas loại trừ các khối thực sự an toàn hoặc chấp nhận các khối thực sự không an toàn hoặc sự kết hợp nào đó của cả hai.

Nếu có ? tài nguyên với các ràng buộc bảo mật khác nhau thì khí một chiều có thể giảm thông lượng tới một hệ số ?. Vì vậy, đã có rất nhiều người quan tâm đến khái niệm Gas đa chiều trong một thời gian dài và với EIP-4844, chúng ta thực sự có Gas đa chiều chạy trên Ethereum ngày nay. Bài viết này khám phá những lợi ích của phương pháp này và triển vọng để nâng cao hơn nữa nó.

Blobs: Gas đa chiều ở Dencun

Vào đầu năm nay, kích thước khối trung bình của Ethereum là 150 kB. Một phần lớn của kích thước này là dữ liệu tổng hợp: Giao thức lớp 2 lưu trữ dữ liệu trên chuỗi để bảo mật. Dữ liệu này rất tốn kém: mặc dù chi phí của giao dịch Rollup thấp hơn khoảng 5-10 lần so với 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.

Tại sao không giảm chi phí gas của calldata (hiện tại là 16 Gas trên mỗi byte khác 0, 4 Gas trên mỗi byte 0) để làm cho Rollup rẻ hơn? Chúng tôi đã làm điều đó trước đây và chúng tôi có thể làm điều đó một lần nữa. Câu trả lời ở đây là: kích thước khối trong trường hợp xấu nhất là 30000000/16 = 1875000 byte khác 0 và mạng hầu như không thể xử lý các khối có kích thước đó. Nếu chi phí giảm thêm 4 lần nữa, dung lượng tối đa sẽ tăng lên 7,5 MB, điều này sẽ gây ra rủi ro bảo mật rất lớ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 thân thiện với việc tổng hợp riêng biệt (được gọi là "blob") trong mỗi khối. Hai tài nguyên này có mức giá khác nhau và giới hạn khác nhau: sau hard fork Dencun, một khối Ethereum có thể chứa tới (i) 30 triệu Gas và (ii) 6 đốm màu, mỗi đốm màu có thể chứa ~125 kB dữ liệu cuộc gọi. Cả hai tài nguyên đều có giá riêng, được điều chỉnh thông qua cơ chế định giá giống như EIP-1559 riêng biệt, nhắm mục tiêu mức sử dụng trung bình là 15 triệu Gas và 3 blob mỗi khối.

Kết quả là chi phí của các lần cuộn đã giảm 100 lần, khối lượng giao dịch trong các lần cuộn đã tăng hơn 3 lần, trong khi kích thước khối tối đa theo lý thuyết chỉ tăng nhẹ: từ khoảng 1,9 MB lên khoảng 2,6 MB .

< span style="font-size: 14px;">Phí giao dịch tổng hợp, do Growthepie.xyz cung cấp. Sự phân nhánh Dencun xảy ra vào ngày 13 tháng 3 năm 2024 và giới thiệu các đốm màu định giá đa chiều.

Khí đa chiều và khách hàng không quốc tịch

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

< span style="font-size: 14px;">Một khách hàng không có trạng thái nhận được một khối, cùng với bằng chứng về giá trị hiện tại của một phần cụ thể của trạng thái liên quan đến việc thực thi khối (ví dụ: số dư tài khoản, mã, bộ nhớ) . Điều này cho phép các nút xác thực các khối mà không cần bất kỳ bộ lưu trữ nào.

Một lần đọc lưu trữ tốn 2100-2600 Gas, tùy thuộc vào loại đọc, trong khi ghi vào lưu trữ đắt hơn. Trung bình, một khối sẽ thực hiện khoảng 1.000 lượt đọc và ghi lưu trữ (bao gồm kiểm tra số dư ETH, lệnh gọi SSTORE tới SLOAD, đọc mã hợp đồng, v.v.). Tuy nhiên, mức tối đa theo lý thuyết là 30000000/2100=14285 lượt đọc. Tải băng thông của máy khách không trạng thái tỷ lệ thuận với con số này.

Hôm nay, kế hoạch là hỗ trợ các khách hàng không quốc tịch bằng cách chuyển thiết kế cây trạng thái của Ethereum từ cây Merkle Patricia sang cây Verkle. Tuy nhiên, cây Verkle không có khả năng kháng lượng tử và không phải là lựa chọn tốt nhất 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ợ các khách hàng không quốc tịch thông qua cây Merkle nhị phân và STARK - hoặc bỏ qua Verkle hoàn toàn hoặc nâng cấp khi STARK trở nên trưởng thành hơn sau vài năm chuyển đổi sang Verkle.

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

Với những con số được dự đoán ngày hôm nay từ các hệ thống chứng minh siêu tối ưu hóa như Binius và Plonky3, cũng như các hàm băm chuyên dụng như Vision-Mark-32, có khả năng chúng ta sẽ ở vào vị trí như vậy có thể trong một thời gian. Phải mất ít hơn một giây để thực sự chứng minh trạng thái của 1.000 giá trị, chứ không phải 14.285 giá trị. Trung bình mỗi khối đều ổn, nhưng một khối trong trường hợp xấu nhất (có thể do kẻ tấn công xuất bản) sẽ phá vỡ mạng.

Cách xử lý tình huống này "mặc định" của chúng tôi là định giá lại: làm cho việc đọc bộ nhớ trở nên đắt hơn để giảm mức tối đa trên 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 đến mức nó sẽ trở nên quá tốn kém đối với quá nhiều ứng dụng nếu chúng tôi làm lại. Một cách tiếp cận tốt hơn là Gas đa chiều: giới hạn và tính phí truy cập bộ nhớ riêng, giữ mức sử dụng trung bình ở mức 1.000 quyền truy cập bộ nhớ trên mỗi khối, nhưng đặt giới hạn cho mỗi khối thành, nói, 2.000 lần.

Gas đa chiều tổng quát hơn

Một tài nguyên khác đáng xem xét là tăng trưởng kích thước trạng thái: để tăng kích thước trạng thái Ethereum, các nút đầy đủ sẽ cần phải giữ trạng thái đầy đủ. Điều độc đáo về sự tăng trưởng quy mô tiểu bang là lý do cơ bản để hạn chế sự tăng trưởng của tiểu bang hoàn toàn xuất phát từ việc sử dụng bền vững lâu dài chứ không phải đến mức đỉnh điểm. Do đó, việc thêm thứ nguyên Gas riêng cho các hoạt động tăng kích thước trạng thái (ví dụ: SSTORE từ 0 đến khác 0, tạo hợp đồng) có thể có giá trị, nhưng với một mục tiêu khác: chúng tôi có thể đặt giá thả nổi để nhắm mục tiêu 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 trong những đặc tính mạnh mẽ của Khí đa chiều: nó cho phép chúng ta đặt các câu hỏi sau một cách riêng biệt: (i) cho mỗi tài nguyên Mức sử dụng trung bình lý tưởng của là bao nhiêu và (ii) mức sử dụng tối đa an toàn trên mỗi khối là bao nhiêu. Thay vì đặt giá gas dựa trên giá trị tối đa trên mỗi khối, chúng tôi đặt giá gas dựa trên mức sử dụng trung bình, có 2 bậc tự do để đặt 2 tham số và điều chỉnh từng mục theo mức độ bảo mật của mạng.

Các trường hợp phức tạp hơn, chẳng hạn như hai tài nguyên có cân nhắc bảo mật bổ sung một phần, có thể được xử lý bằng cách làm cho mã opcode hoặc tài nguyên tiêu tốn một lượng gas nhất định thuộc nhiều loại (ví dụ: SSTORE từ 0 đến khác 0 có thể Chi phí 5000 gas cho bằng chứng khách hàng không quốc tịch và 20000 gas cho lạm phát lưu trữ).

Giá trị tối đa trên mỗi giao dịch: một cách yếu hơn nhưng đơn giản hơn để có được Gas đa chiều

Đặt x1 là chi phí Gas của dữ liệu và x2 là chi phí Gas được tính toán, vì vậy trong In trong hệ thống chiều Gas, chúng ta có thể viết chi phí Gas của một giao dịch gas=x1*data+x2*computation

Trong giải pháp mới, chúng ta xác định Gas cost của giao dịch là: gas=max(x1 * data, x2*computation)

Nói cách khác, một giao dịch không bị tính phí dựa trên dữ liệu cộng với tính toán mà dựa trên tài nguyên nào trong hai tài nguyên mà nó tiêu thụ nhiều hơn. Điều này có thể dễ dàng mở rộng để bao gồm nhiều thứ nguyên hơn (ví dụ: max(…,x3*storage_access)).

Có thể dễ dàng thấy điều này cải thiện thông lượng như thế nào trong khi vẫn duy trì tính bảo mật. Về mặt lý thuyết, lượng dữ liệu tối đa trong một khối vẫn là GASLIMIT/x1, hoàn toàn giống với sơ đồ Gas một chiều. Theo cách tương tự, lượng tính toán tối đa theo lý thuyết là GASLIMI/x2, lại giống hệt như sơ đồ Khí một chiều. Tuy nhiên, bất kỳ giao dịch nào sử dụng dữ liệu và tính toán sẽ giảm chi phí gas.

Đây gần như là phương pháp được thực hiện trong EIP-7623 được đề xuất 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á dữ liệu cuộc gọi hiện tại ở mức 16 Gas mỗi byte, nhưng thêm "giá sàn" là 48 Gas mỗi byte; giao dịch thanh toán ( 16 * byte + exec_gas) và (  48 * byte) tùy theo giá trị nào cao hơn. Do đó, EIP-7623 giảm dữ liệu cuộc gọi giao dịch tối đa theo lý thuyết trong một khối từ ~1,9 MB xuống ~0,6 MB trong khi vẫn 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 các sơ đồ khí một chiều hiện tại và do đó rất dễ thực hiện.

Nó 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 một lượng nhỏ tài nguyên đó, một giao dịch chiếm nhiều tài nguyên vẫn sẽ được tính phí lớn không cần thiết.

2. Nó khuyến khích các giao dịch sử dụng nhiều dữ liệu và tính toán chuyên sâu được hợp nhất thành một gói duy nhất để tiết kiệm chi phí.

Tôi nghĩ rằng các quy tắc kiểu EIP-7623, cho dù đối với dữ liệu cuộc gọi giao dịch hay các tài nguyên khác, đều có thể mang lại đủ lợi ích mà ngay cả với những thiếu sót này, nó vẫn đáng giá. Tuy nhiên, có một cách tiếp cận lý tưởng hơn nếu chúng ta sẵn sàng đầu tư công sức phát triển (cao hơn đáng kể).

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

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

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

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

Ở đây TARGET = 3. Nghĩa là, nếu một khối có nhiều đốm màu hơn mục tiêu, thì khối thừa sẽ tăng lên và nếu một khối có ít đốm màu hơn mục tiêu thì khối đó sẽ giảm. Sau đó, chúng tôi đặt blob_basefee = exp(excess_blobs / 25.47), trong đó exp là giá trị gần đúng của hàm mũ exp(x).

Nói cách khác, mỗi lần extra_blobs tăng khoảng 25 lần , chi phí cơ bản của blob sẽ tăng khoảng 2,7 lần. Nếu các đốm màu trở nên quá đắt, mức sử dụng trung bình sẽ giảm và sau đó các đốm màu dư thừa bắt đầu giảm, tự động giảm giá trở lại. Giá của các đốm màu được điều chỉnh liên tục để đảm bảo rằng, tính trung bình, các khối đã đầy một nửa - nghĩa là mỗi khối chứa trung bình 3 đốm màu.

Nếu lượng sử dụng tăng đột biến trong thời gian ngắn, giới hạn sẽ được áp dụng: mỗi khối chỉ có thể chứa tối đa 6 đốm màu, trong trường hợp đó, 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 những trường hợp thông thường, mỗi blob chỉ trả blob_basefee cộng thêm một chút phí ưu tiên như một động lực để được đưa vào.

Loại định giá gas này đã tồn tại trong Ethereum trong nhiều năm: vào năm 2020, EIP-1559 đã giới thiệu một cơ chế rất giống nhau. Với EIP-4844, hiện tại chúng tôi có hai mức giá thả nổi riêng biệt cho Gas và Blobs.

Chi phí gas cơ bản trong vòng một giờ vào ngày 8 tháng 5 năm 2024, tính bằng gwei. Nguồn: siêu âm.money

Về nguyên tắc, chúng tôi có thể thêm nhiều khoản phí thả nổi riêng biệt cho hoạt động đọc lưu trữ và các loại hoạt động khác, nhưng có một lưu ý mà tôi sẽ trình bày chi tiết trong phần tiếp theo minh họa .

Đối với người dùng, trải nghiệm này rất giống với ngày nay: thay vì trả một khoản phí cơ bản, bạn phải trả hai khoản phí cơ bản, nhưng ví của bạn có thể loại bỏ khoản phí đó khỏi bạn. Chỉ hiển thị cho bạn các khoản phí dự kiến ​​và mức tối đa mà bạn có thể mong đợi để trả tiền.

Đối với những người xây dựng khối, chiến lược tốt nhất hầu như luôn giống như ngày nay: bao gồm bất kỳ thứ gì hiệu quả. Hầu hết các khối đều không đầy - không có khí cũng như các đốm màu. Một tình huống đầy thách thức là khi có đủ khí hoặc đủ các đốm màu vượt quá giới hạn khối và các nhà xây dựng cần có khả năng 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 tồn tại một thuật toán gần đúng hợp lý, thì trong trường hợp này, mức tăng thu được bằng cách xây dựng thuật toán độc quyền để tối ưu hóa lợi nhuận sẽ nhỏ hơn nhiều so với mức tăng thu được khi thực hiện cùng một thao tác sử dụng MEV.

Thách thức chính đối với các nhà phát triển là nhu cầu thiết kế lại chức năng của EVM và cơ sở hạ tầng xung quanh, hiện được thiết kế theo một mức giá và một ràng buộc, để được thiết kế để phù hợp với nhiều mức giá và Thiết kế với nhiều mức giá. hạn chế. Một vấn đề mà các nhà phát triển ứng dụng gặp phải 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 thể nói một cách dứt khoát rằng A hiệu quả hơn B, bởi vì nếu A sử dụng nhiều calldata hơn và B sử dụng nhiều khả năng thực thi hơn, thì khi calldata rẻ hơn, khi calldata đắt tiền, nó đắ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 trong lịch sử dài hạn.

Định giá đa chiều, EVM và lệnh gọi phụ

Có một vấn đề không xuất hiện trong các đốm màu, cũng như trong EIP-7623, thậm chí không xuất hiện trong quá trình triển khai định giá đa chiều "Đầy đủ" của dữ liệu cuộc gọi, nhưng nếu chúng tôi cố gắng định giá quyền truy cập trạng thái hoặc bất kỳ tài nguyên nào khác một cách riêng biệt thì vấn đề này sẽ phát sinh: giới hạn gas trong các cuộc gọi phụ.

Giới hạn gas trong EVM tồn tại ở hai nơi. Đầu tiên, mỗi giao dịch được đặt giới hạn gas nhằm giới hạn tổng lượng gas có thể được sử dụng trong giao dịch đó. Thứ hai, khi một hợp đồng gọi một hợp đồng khác, lệnh gọi có thể đặt giới hạn gas của chính 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ọ vẫn còn gas sau cuộc gọi để thực hiện các tính toán khác.

Dấu vết của một giao dịch trừu tượng về tài khoản trong đó một tài khoản gọi đến một tài khoản khác và chỉ 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 được gọi hoặc tiêu thụ hết gas được phân bổ cho nó, các cuộc gọi bên ngoài có thể tiếp tục chạy.

Thách thức là: làm cho Gas trở nên đa chiều trên các loại thực thi khác nhau dường như yêu cầu các lệnh gọi phụ để cung cấp nhiều giới hạn cho từng loại Gas, điều này đòi hỏi phải có một cuộc đại tu thực sự đối với EVM Thay đổi sâu sắc và không tương thích với các ứng dụng hiện có.

Đây là một lý do tại sao các đề xuất khí đa chiều thường ở hai chiều: dữ liệu và thực thi. Dữ liệu (dù là dữ liệu cuộc gọi giao dịch hay blob) chỉ được phân bổ bên ngoài EVM, do đó, không cần thay đổi gì bên trong EVM để cho phép định giá dữ liệu cuộc gọi hoặc blob riêng lẻ.

Chúng ta có thể đưa ra "giải pháp kiểu EIP-7623" để giải quyết vấn đề này. Đây là cách triển khai đơn giản: hoạt động của cửa hàng được tính phí gấp 4 lần trong quá trình thực hiện; để đơn giản hóa việc phân tích, chúng tôi giả định 10.000 gas cho mỗi hoạt động của cửa hàng. Giao dịch kết thúc và số tiền hoàn lại là tối thiểu (7500 * storage_Operations,execution_gas). Kết quả là, sau khi khấu trừ số tiền hoàn lại, người dùng sẽ trả số tiền sau:

execution_gas + 10000 * storage_Operations - min(7500 * storage_Operations, execion_gas)

Số tiền này bằng:

max(execution_gas + 2500 * storage_Operations, 10000 * Storage_Operations)

Đ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 storage_Operation và Execution_gas trong thời gian thực và sạc 2500 hoặc 10000 gas tùy thuộc vào số lượng tăng lên khi opcode được gọi, max(execution_gas + 2500 * storage_Operations, 10000 * Storage_Operations). Điều này tránh các giao dịch cần phân bổ quá mức gas, vốn chủ yếu được thu hồi thông qua hoàn tiền.

Chúng tôi không nhận được quyền chi tiết đối với các cuộc gọi phụ: các cuộc gọi phụ có thể tiêu tốn toàn bộ "khoản trợ cấp" của giao dịch cho các hoạt động lưu trữ giá rẻ. Nhưng chúng tôi nhận được thứ gì đó đủ tốt để hợp đồng thực hiện cuộc gọi phụ có thể đặt giới hạn và đảm bảo rằng sau khi cuộc gọi phụ kết thúc việc thực thi, cuộc gọi chính vẫn còn đủ năng lượng để thực hiện bất kỳ quá trình xử lý hậu kỳ nào mà nó cần thực hiện.

"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 tôi coi giới hạn gas của cuộc gọi phụ theo tỷ lệ thuận. Nghĩa là, giả sử có

?các loại thực thi khác nhau, mỗi giao dịch đặt ra các hạn chế đa chiều?1…??. Giả sử rằng tại thời điểm thực hiện hiện tại, lượng khí còn lại

là?1…??. Giả sử CALL gọi một opcode có giới hạn gas cuộc gọi phụ S. Đặt s1=S, sau đó s2=s1/g1*g2, s3=s1/g1*g3, v.v.

Nghĩa là, chúng tôi xử lý loại gas đầu tiên (thực tế là việc thực thi máy ảo) như một "đơn vị tài khoản" đặc quyền và sau đó phân bổ các loại gas khác để các loại lệnh gọi phụ nhận được cùng một tỷ lệ gas có sẵn . Điều này hơi xấu một chút nhưng nó tối đa hóa khả năng tương thích ngược. Nếu chúng tôi muốn làm cho giải pháp trở nên "trung tính" hơn giữa các loại khí khác nhau, nhưng lại gây tổn hại đến khả năng tương thích ngược, chúng tôi chỉ cần làm cho tham số giới hạn khí cuộc gọi phụ đại diện cho một phần nhỏ của khí còn lại (ví dụ: [1... 63] /64).

Tuy nhiên, trong cả hai trường hợp, cần nhấn mạnh rằng một khi bạn bắt đầu giới thiệu khí thực thi đa chiều, độ xấu vốn có sẽ tăng lên , điều này có vẻ khó tránh khỏi.

Vì vậy, chúng tôi được giao nhiệm vụ thực hiện một sự đánh đổi phức tạp: liệu chúng tôi có chấp nhận thứ gì đó xấu hơn ở cấp độ EVM để mở khóa một cách an toàn những lợi ích đáng kể về khả năng mở rộng L1 hay không và nếu vậy thì lời khuyên cụ thể nào là tốt nhất cho kinh tế giao thức và nhà phát triển ứng dụng?

Rất có thể, đó không phải là những thứ tôi đã đề cập ở trên và vẫn còn chỗ để tìm ra thứ gì đó thanh lịch hơn và tốt hơn.

Đặc biệt cảm ơn Ansgar Dietrichs, Barnabe Monoton và Davide Crapis vì những phản hồi và đánh giá của họ.