Tiêu đề mới của Vitalik: Giá xăng dài nhất là bao nhiêu?

Tác giả: Vitalik Buterin

Trình biên dịch: Karen, Foreisght News

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

1. Tính toán thô (ví dụ: THÊM, NHÂN);

2. Đọc, ghi và ghi vào kho lưu trữ Ethereum (chẳng hạn như SSTORE, SLOAD, ETH chuyển);

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

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

Ví dụ, giao dịch này tôi gửi đã tiêu thụ tổng cộng 47.085 Gas. Chúng bao gồm: (i) chi phí cơ bản là 21.000 Gas, (ii) 1.556 Gas cho các byte calldata được bao gồm như một phần của giao dịch, (iii) 16.500 Gas để lưu trữ đọc và ghi, (iv) 2.149 Gas để tạo nhật ký và phần còn lại để thực hiện EVM. Các Rửa tiền mà người dùng phải trả tỷ lệ thuận với gas tiêu thụ của giao dịch. Một Khối có thể chứa tới 30 triệu gas long và giá gas liên tục được điều chỉnh thông qua cơ chế nhắm mục tiêu EIP-1559 để đảm bảo rằng mỗi Khối chứa trung bình 15 triệu gas.

Cách tiếp cận này có một lợi thế lớn: bởi vì mọi thứ được kết hợp thành một tài nguyên ảo duy nhấ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ó ưu đãi kỳ lạ nào để khuyến khích một số giao dịch kết hợp với các giao dịch khác để tiết kiệm phí.

Tuy nhiên, có sự thiếu hiệu quả với cách tiếp cận này: nó xử lý các tài nguyên khác nhau như thể chúng có thể chuyển đổi sang nhau, khi các ràng buộc cơ bản thực tế không giống nhau. Để hiểu điều này, trước tiên bạn có thể xem biểu đồ sau:

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 tế thường gần gũi hơn:

Sự khác biệt này gây ra gas giới hạn để loại trừ một cách vô lý 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 giới hạn bảo mật khác nhau, thì gas một chiều có thể làm cho thông lượng lên đến long Thả n lần. Kết quả là, long có sự quan tâm đến khái niệm khao khát gas, và với EIP-4844, bây giờ chúng tôi đã thực sự thực hiện gas khao khát trên Ethereum. Bài viết này khám phá những lợi thế của phương pháp này, cũng như triển vọng cải tiến hơn nữa.

Blob: gas dài nhất ở Dencun

Vào đầu năm nay, kích thước khối trung bình là 150 kB. Một phần lớn của điều này là dữ liệu tổng hợp: Layer 2 giao thức lưu trữ dữ liệu on-chain. 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 so với giao dịch tương ứng trên Ethereum L1, nhưng ngay cả chi phí như vậy cũng quá cao đối với trường hợp sử dụng long.

Vậy tại sao không Thả chi phí gas cho calldata (hiện tại là 16 gas cho các byte không phải 0 và 4 gas cho 0 byte) để làm cho rollups rẻ hơn? Chúng tôi đã làm điều này trước đây, và chúng tôi có thể làm lại bây giờ. Nhưng câu trả lời ở đây là kích thước tối đa của một khối là 30.000.000/16 = 1.875.000 byte khác 0 và mạng hầu như không thể xử lý một khối có kích thước này. Giảm chi phí thêm 4 lần nữa sẽ tăng tối đa lên 7,5 MB, điều này gây ra rủi ro đáng kể cho 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 dữ liệu riêng biệt, thân thiện với rollup ngắn hơn (được gọi là blob) trong mỗi khối.

Có nhiều mức giá và giới hạn khác nhau cho hai tài nguyên này: sau Hard Fork Dencun, long tối đa Ethereum Khối có thể chứa (i) 30 triệu gas và (ii) 6 blob, mỗi đốm có thể chứa khoảng 125 kB calldata. Cả hai tài nguyên đều có giá riêng biệt và được điều chỉnh thông qua cơ chế định giá riêng 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í của Bản tổng hợp đã giảm 100 lần, khối lượng trên Bản tổng hợp tăng hơn 3 lần và 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.

Lưu ý: Bản tổng hợp Rửa tiền, do Growthepie.xyz cung cấp. Cuộc fork Dencun diễn ra vào ngày 13 tháng 3 năm 2024, giới thiệu các đốm giá dài nhất.

Khách hàng gas và không quốc tịch lâu nhất

Trong tương lai gần, một vấn đề tương tự sẽ phát sinh với các bằng chứng được lưu trữ cho các khách hàng không quốc tịch. Máy khách không trạng thái là một loại máy khách mới có thể xác thực chuỗi mà không cần phải lưu trữ một lượng lớn hoặc bất kỳ dữ liệu nào cục bộ. Khách hàng không trạng thái làm đ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 trạng thái Ethereum mà các giao dịch trong khối đó cần truy cập.

Sơ đồ trên cho thấy một máy khách không trạng thái nhận được Khối và 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 (ví dụ: số dư tài khoản, mã, lưu trữ) được chạm vào khi thực thi Khối đó, cho phép Nút xác thực Khối mà không cần lưu trữ.

Một lần đọc lưu trữ có giá 2100-2600 gas, tùy thuộc vào loại đọc và ghi lưu trữ đắt hơn. Trung bình, một khối thực hiện khoảng 1.000 lần đọc và 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, mức tối đa trên lý thuyết là 30.000.000/2.100=14.285 lượt đọc. Tải băng thông của một máy khách không trạng thái tỷ lệ thuận với số đó.

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

Chứng minh STARK dựa trên các nhánh cây Hàm băm nhị phân long có nhiều ưu điểm, nhưng điểm yếu chính của chúng là long thời gian cần thiết để tạo ra bằng chứng: Cây Verkle có thể chứng minh hơn 100.000 giá trị mỗi giây, trong khi STARK dựa trên Hàm băm thường chỉ chứng minh vài k Hàm băm mỗi giây và mỗi giá trị cần chứa một “nhánh” long Hàm băm.

Xem xét các con số được dự đoán ngày hôm nay từ các hệ thống bằng chứng siêu tối ưu hóa như Binius và Plonky3, cũng như các hàm băm độc quyền như Vision-Mark-32, có vẻ như chúng ta sẽ ở trong một phạm vi thực tế trong một thời gian mà việc 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ối trung bình sẽ ổn, nhưng Khối có khả năng xấu nhất (được xuất bản bởi kẻ tấn công) sẽ làm gián đoạn mạng.

Cách tiếp cận mặc định của chúng tôi để xử lý các trường hợp như vậy là định giá lại: tăng chi phí lưu trữ các lần đọc để giảm mức tối đa cho 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 long lần và nếu chúng tôi làm lại, nó sẽ khiến quá long ứng dụng trở nên quá đắt. Một cách tiếp cận tốt hơn là khao khát gas: 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 1.000 lượt truy cập bộ nhớ trên mỗi khối, nhưng đặt giới hạn trên cho mỗi khối, chẳng hạn như 2000.

Sự phổ biến của gas dài nhất

Một tài nguyên khác đáng xem xét là tăng kích thước trạng thái: các hoạt động làm tăng kích thước trạng thái của Ethereum, sau đó cần được lưu bởi một nút đầy đủ. Kích thước nhà nước tăng là duy nhất ở chỗ lý do để hạn chế nó chỉ đến từ việc sử dụng bền vững long hạn, không phải là đỉnh.

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

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

Giả sử 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 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 trường hợp này, chúng tôi xác định chi phí gas của giao dịch là:

Đó là, 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ụ lâu nhất. Điều này có thể dễ dàng mở rộng để bao gồm nhiều kích thước long hơn (e.g. max (…, x3 ∗ lưu trữ \ _access)).

Sẽ dễ dàng để xem làm thế nào điều này có thể tăng thông lượng trong khi duy trì 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 như trong sơ đồ gas một chiều. Tương tự, lượng tính toán tối đa theo lý thuyết là GasLIMIT / x2, hoàn toàn giống như trong sơ đồ 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à sơ đồ được áp dụng trong EIP-7623 được đề xuất để 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 ở mức 16 gas mỗi byte, nhưng thêm giá sàn là 48 gas mỗi byte; Thanh toán giao dịch lớn hơn (16 * byte + ution_Gas) và (48 * byte). Do đó, EIP-7623 làm 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ừ khoảng 1,9 MB xuống còn khoảng 0,6 MB, trong khi vẫn giữ nguyên chi phí cho các ứng dụng dài nhất. Lợi ích của phương pháp này là nó thay đổi rất ít so với sơ đồ gas một chiều hiện tại, làm cho nó rất dễ thực hiện.

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

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 đó, các giao dịch chiếm một lượng lớn một tài nguyên vẫn sẽ tính một khoản 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 để hợp nhất thành một gói duy nhất để tiết kiệm chi phí.

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

Tuy nhiên, nếu chúng ta sẵn sàng đưa vào các nỗ lực phát triển (cao hơn đáng kể), một cách tiếp cận mong muốn hơn sẽ xuất hiện.

Thời EIP-1559 dài nhất: Một chiến lược khó khăn hơn nhưng đáng mơ ước hơn

Hãy bắt đầu bằng cách xem xét 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 bởi nến bóng dài blob vào năm EIP-4844 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ố, dư thừa \ _blobs. Trong mỗi khối, chúng tôi đặt:

dư thừa \ _blobs < - tối đa (dư thừa \ _blobs + len (khối.blobs) - MỤC TIÊU, 0)

trong đó TARGET = 3. Nghĩa là, nếu số lượng đốm màu trong một Khối long hơn mục tiêu, _blobs dư thừa sẽ tăng lên và nếu số lượng đốm màu trong một Khối nhỏ hơn mục tiêu, _blobs dư thừa sẽ giảm. Sau đó, chúng ta đặt blob_basefee = exp(excess_blobs / 25,47), trong đó exp là xấp xỉ của hàm mũ exp(x)=2,71828^x.

Nghĩa là, bất cứ khi nào dư thừa \ _blobs tăng khoảng 25, điện tích cơ bản blob tăng khoảng 2,7 lần. Nếu blob trở nên quá đắt, mức sử dụng trung bình giảm và dư thừa \ _blobs bắt đầu giảm, tự động Thả giá trở lại. Giá của các đốm màu liên tục được điều chỉnh để đảm bảo rằng, trung bình, Khối đầy một nửa, nghĩa là mỗi Khối chứa trung bình 3 blob.

Nếu có mức sử dụng tăng đột biến trong short hạn, có một giới hạn: mỗi Khối chỉ có thể chứa 6 blob ở mức tối đa long, 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 bình thường, mỗi blob chỉ trả blob \ _basefee cộng với một khoản phí ưu tiên bổ sung nhỏ như một động lực để được đưa vào.

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

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

Về nguyên tắc, chúng ta có thể thêm nhiều long phí thả nổi độc lập để đọc lưu trữ và các loại hoạt động khác, nhưng tôi sẽ giải thích chi tiết về một vấn đề trong phần tiếp theo.

Đối với người dùng, trải nghiệm rất giống với ngày nay: thay vì trả một 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ể trừu tượng hóa nó ra khỏi tay bạn, chỉ hiển thị cho bạn các khoản phí dự kiến và tối đa bạn có thể phải trả.

Khối các nhà xây dựng, lâu nhất, chiến lược tốt nhất cũng giống như ngày nay: bao gồm bất cứ thứ gì hoạt động. Các khối dài nhất không đầy đủ - khí hoặc đốm màu. Một tình huống đầy thách thức là khi có đủ gas hoặc đủ blob để vượt quá giới hạn khối, các nhà xây dựng cần có khả năng giải quyết vấn đề ba lô dài nhất để 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 xấp xỉ khá tốt, trong trường hợp này, lợi nhuận từ việc tối ưu hóa lợi nhuận bằng cách xây dựng Thuật toán độc quyền nhỏ hơn long so với lợi nhuận từ việc làm tương tự với 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 liên quan của nó, hiện đang được thiết kế dựa trên một mức giá duy nhất và một giới hạn duy nhất, và bây giờ cần phải được trang bị thêm để phù hợp với giá dài nhất và giới hạn dài nhất.

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 khó khăn hơn một chút: trong một số trường hợp, bạn không thể người theo lệnh long nói rõ ràng rằng A hiệu quả hơn B, bởi vì nếu A sử dụng calldata long hơn và B sử dụng thực thi long hơn, thì khi calldata rẻ hơn, sẽ đắt hơn khi calldata đắt.

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 khó khăn hơn một chút: trong một số trường hợp, bạn không thể nói chắc chắn rằng A hiệu quả hơn B, bởi vì nếu A sử dụng calldata long hơn và B sử dụng thực thi long hơn, thì A có thể rẻ hơn khi calldata rẻ và A có thể đắt hơn khi calldata đắt.

Tuy nhiên, các nhà phát triển vẫn có thể nhận đượ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ử long hạn.

Giá cả, EVM và cuộc gọi phụ dài nhất

Có một vấn đề không xuất hiện trong blob, cũng không xuất hiện trong EIP-7623 hoặc thậm chí là triển khai định giá dài nhất đầy đủ của nến long tim cho calldata, nhưng nếu chúng ta 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 khí đốt 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, giới hạn tổng số 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, cuộc gọi đó có thể đặt giới hạn gas của riêng 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 để thực hiện các tính toán khác sau cuộc gọi.

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

Thách thức là việc gas dài nhất giữa các loại thực thi khác nhau dường như yêu cầu các lệnh gọi con cung cấp giới hạn dài nhất cho từng loại gas, điều này sẽ đòi hỏi những thay đổi rất sâu đối với EVM và sẽ 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 dài nhất thường ở hai chiều: dữ liệu và thực thi. Dữ liệu, cho dù là calldata giao dịch hay blob, chỉ được phân phối bên ngoài EVM, vì vậy không có gì cần phải thay đổi bên trong EVM để calldata hoặc blob được định giá riêng.

Chúng ta có thể đưa ra một “giải pháp kiểu EIP-7623” để giải quyết vấn đề này. Đây là một triển khai đơn giản: trong quá trình thực hiện, hoạt động lưu trữ được tính phí gấp 4 lần; Để đơn giản hóa việc phân tích, giả sử 10.000 khí cho mỗi hoạt động lưu trữ. Khi kết thúc giao dịch, min(7500 * storage_operations, ution_Gas) được hoàn trả. Do đó, sau khi trừ tiền hoàn lại, người dùng phải trả các khoản phí sau:

ution_Gas + 10000 * storage_operations - min(7500 * storage_operations, ution_Gas)

Điều này bằng:

tối đa (ution \ _Gas + 2500 * lưu trữ \ _operations, 10000 * lưu trữ \ _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 lưu trữ \ _operations và ution \ _Gas trong thời gian thực và tính phí ít hơn 2500 hoặc 10000 tùy thuộc vào mức tối đa (ution \ _Gas + 2500 * lưu trữ \ _operations, 10000 * lưu trữ \ _operations) pump long thời điểm đó. Các Mã thao tác được gọi là. Điều này tránh sự cần thiết của các giao dịch để phân bổ quá mức gas, chủ yếu được thu hồi thông qua hoàn lại tiền.

Chúng tôi không có giấy phép chi tiết cho các cuộc gọi phụ: các cuộc gọi con có thể tiêu tốn tất cả các khoản phụ 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 một cái 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 một khi lệnh gọi phụ được thực hiện, cuộc gọi chính vẫn có đủ gas để xử lý hậu kỳ cần thiết.

“Giải pháp định giá dài nhất 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 cuộc gọi phụ là tỷ lệ thuận. Nghĩa là, giả sử có k loại khớp lệnh khác nhau và mỗi giao dịch được đặt với giới hạn dài nhất L1… Lk. Giả sử tại điểm khớp lệnh hiện tại, gas còn lại là g1… Gk. Giả sử bạn gọi CALL Mã thao tác và sử dụng lệnh gọi phụ Gas để giới hạn S. Cho s1=S, sau đó s2=s1/g1∗g2, s3=s1/g1∗g3, v.v.

Nghĩa là, chúng tôi coi loại gas đầu tiên (thực sự là VM thực thi) như một “đơn vị tài khoản” đặc biệt và sau đó phân bổ các loại gas khác để lệnh gọi con nhận được cùng một tỷ lệ phần trăm gas có sẵn trong mỗi loại gas. Cách tiếp cận này hơi xấu xí và tối đa hóa khả năng tương thích ngược.

Nếu chúng ta muốn làm cho sơ đồ trở nên “trung lập” hơn giữa các loại gas khác nhau mà không phải hy sinh khả năng tương thích ngược, chúng ta có thể chỉ cần biểu diễn tham số giới hạn gas của 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 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 gas thực thi dài nhất, sự phức tạp vốn có (xấu xí) sẽ tăng lên, điều này dường như khó tránh.

Vì vậy, nhiệm vụ của chúng tôi là thực hiện một sự đánh đổi phức tạp: chúng tôi có chấp nhận một số mức độ xấu xí tăng lên ở cấp độ EVM để mở khóa một cách an toàn các lợi ích khả năng mở rộng L1 đáng kể và nếu có, đề xuất cụ thể nào sẽ hiệu quả nhất cho các nhà phát triển kinh tế và ứng dụng giao thức? Rất có thể, cả hai lựa chọn tôi đã đề cập ở trên đều không phải là tốt nhất, nhưng vẫn có những chiếc quần short để đưa ra các giải pháp thanh lịch hơn và tốt hơn.

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