Trong Ethereum, tài nguyên cho đến gần đây vẫn bị giới hạn và định giá bằng cách sử dụng một loại tài nguyên duy nhất gọi là “gas”. Gas là một đơn vị đo lường 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ể. Gas kết hợp cùng nhau nhiều loại “nỗ lực”, đáng chú ý nhất là:

• Tính toán thô (ví dụ: CỘNG, NHÂN)
• Đọc và ghi vào bộ nhớ lưu trữ Ethereum (ví dụ: SSTORE, SLOAD, chuyển ETH)
• Băng thông dữ liệu
• Chi phí tạo ra một Chứng minh ZK-SNARKcủa khối

Ví dụ, giao dịch nàyTôi đã gửi đã tốn tổng cộng 47,085 gas. Điều này được chia thành (i) một “chi phí cơ sở” của 21000 gas, (ii) 1556 gas cho byte trong calldata được bao gồm là một phần của giao dịch (iii) 16500 gas cho việc đọc và ghi vào bộ nhớ, (iv) gas 2149 để thực hiện một 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 mà giao dịch tiêu thụ. 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 qua @vbuterin/eip-1559-faq">EIP-1559 cơ chế nhắm mục tiêu, đảm bảo rằng trung bình, các khối chứa 15 triệu khí.

Cách tiếp cận này có một hiệu suất chính lớn: vì mọi thứ được hợp nhất thành một tài nguyên ảo duy nhất, nó dẫn đến một 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í là dễ dàng, tối ưu hóa một khối để thu thập phí cao nhất có thể là tương đối dễ dàng (không bao gồm MEV) và không có cơ hội kỳ lạ nào khuyến khích một số giao dịch gói chung với các giao dịch khác để tiết kiệm phí.

Nhưng phương pháp này cũng có một hiệu suất chính không tốt: nó xem xét các nguồn lực khác nhau như là có thể chuyển đổi lẫn nhau, khi sự giới hạn cơ bản thực sự về những gì mạng có thể xử lý không phải như vậy. Một cách để hiểu vấn đề này là nhìn vào sơ đồ này:

Giới hạn gas áp đặt một ràng buộc của

𝑥1∗𝑑𝑎𝑡𝑎+𝑥2∗𝑐𝑜𝑚𝑝𝑢𝑡𝑎𝑡𝑖𝑜𝑛<𝑁

. Ràng buộc an toàn cơ bản thực tế thường gần hơn với

𝑚𝑎𝑥(𝑥1∗𝑑𝑎𝑡𝑎,𝑥2∗𝑐𝑜𝑚𝑝𝑢𝑡𝑎𝑡𝑖𝑜𝑛)<𝑁

. Sự không nhất quán này dẫn đến việc giới hạn gas một cách không cần thiết loại bỏ 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 một sự kết hợp của cả hai.

Nếu có

𝑛

tài nguyên có giới hạn an toàn riêng, sau đó khí một chiều có thể giảm lưu lượng điều khiển lên đến một hệ số

𝑛

Vì lý do này, đã có sự quan tâm lớn đối với khái niệm khí đa chiều, và với EIP-4844Chúng tôi thực sự đã có gas đa chiều hoạt động trên Ethereum ngày hôm nay. Bài đăng này khám phá các lợi ích của phương pháp này và triển vọng để tăng cường nó thêm nữa.

Blobs: khí đa chiều trong Dencun

Vào đầu năm nay, khối trung bình là 150 kB in kích thước. Một phần lớn trong kích thước đó là dữ liệu rollup: giao thức tầng 2lưu trữ dữ liệu trên chuỗi cho mục đích bảo mật. Dữ liệu này tốn kém: ngay cả khi giao dịch trên rollups chỉ tốn khoảng ~5-10 lần ít hơn so với các giao dịch tương ứng trên Ethereum L1, thì chi phí đó 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 mỗi byte khác không và 4 gas mỗi byte bằng không), để giảm giá rollups?đã làm điều này trước đây, chúng ta có thể làm lại. Câu trả lời ở đây là: kích thước tệ nhất của một khối là

30,000,00016=1,875,000

các byte không bằng không, và mạng đã gần như không thể xử lý các khối có kích thước đó. Giảm chi phí thêm 4 lần sẽ nâng cấp tối đa lên 7,5 MB, điều này sẽ là một rủi ro lớn đối với an toàn.

Vấn đề này đã được giải quyết bằng cách giới thiệu một không gian riêng biệt của dữ liệu thân thiện với rollup, được biết đến với tên gọi là "blobs", vào mỗi khối. Hai tài nguyên này có giá cả và giới hạn riêng biệt: sau cuộc hard fork Dencun, một khối Ethereum có thể chứa tối đa (i) 30 triệu gas và (ii) 6 blobs, mỗi blobs có thể chứa ~125 kB dữ liệu gọi hàm mỗi cái. Cả hai tài nguyên này có giá cả riêng biệt, được điều chỉnh bởicác cơ chế giá giống như EIP-1559 được tách biệt, với mục tiêu sử dụng trung bình là 15 triệu gas và 3 blobs mỗi khối.

Kết quả là, rollups đã trở nên rẻ hơn 100 lần, khối lượng giao dịch trên rollups tăng hơn 3 lần, và kích thước khối tối đa lý thuyết chỉ tăng một chút: từ ~1.9 MB lên ~2.6 MB.

Phí giao dịch trên rollups, nhờ sự hỗ trợ của growthepie.xyz. Cuộc chia tách Dencun, giới thiệu các phần tử với giá cả đa chiều, diễn ra vào ngày 13 tháng 3 năm 2024.

Khách hàng đa chiều gas và stateless

Trong tương lai gần, một vấn đề tương tự sẽ nảy sinh liên quan đến bằng chứng lưu trữ cho các khách hàng không trạng thái. Khách hàng không trạng thái 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ữ nhiều hoặc bất kỳ dữ liệu nào ở cấp độ cục bộ. Khách hàng không trạng thái thực hiện điều này bằng cách chấp nhận các 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 tiếp xúc.

Một khách hàng không có trạng thái nhận một khối, cùng với bằng chứng chứng minh các giá trị hiện tại trong các phần cụ thể của trạng thái (vd. số dư tài khoản, mã, lưu trữ) mà việc thực thi khối đó chạm đến. Điều này cho phép một 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ữ tốn khoảng 2100-2600 gas tùy thuộc vào loại đọc, và việc ghi lưu trữ tốn nhiều hơn. Trung bình, một khối thực hiện khoảng 1000 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, giới hạn lý thuyết là

30,000,0002,100=14,285

đọc. Tải băng thông của một khách hàng không có trạng thái tỉ lệ thuận trực tiếp với con số này.

Hôm nay, kế hoạch là hỗ trợ các khách hàng vô trạng thái bằng cách di chuyển thiết kế cây trạng thái của Ethereum từcây Merkle PatriciađếnCây Verkle. Tuy nhiên, cây Verkle không phải là cường độ 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. Do đó, nhiều người quan tâm đến việc hỗ trợ các khách hàng không trạng thái thông qua cây Merkle nhị phân và STARKsthay vì - hoặc là bỏ qua Verkle hoàn toàn, hoặc nâng cấp vài năm sau khi chuyển đổi Verkle một khi STARKs trở nên trưởng thành hơn.

STARK proofs of binary hash tree branches có nhiều ưu điểm, nhưng họ có điểm yếu chính là việc chứng minh mất nhiều thời gian để tạo ra: trong khi Cây Verklecó thể chứng minhhơn một trăm nghìn giá trị mỗi giây, STARKs dựa trên hash thường chỉ có thể chứng minh khoảng vài ngàn hash mỗi giây, và việc chứng minh mỗi giá trị đòi hỏi một “nhánh” chứa nhiều hash.

Với những con số được dự đoán từ hệ thống chứng minh siêu tối ưu như hôm nay từ BiniusvàPlonky3và các băm chuyên biệt như Vision-Mark-32Có vẻ như chúng ta sẽ trong một thời kỳ trong đó việc chứng minh 1.000 giá trị trong thời gian dưới 1 giây là khả thi, nhưng không phải 14.285 giá trị. Các khối trung bình sẽ ổn, nhưng các khối trong trường hợp xấu nhất, có thể được xuất bởi một kẻ tấn công, sẽ làm hỏng mạng.

Cách chúng tôi đã xử lý một cách “mặc định” trong tình huống như vậy là tái giá: làm cho việc đọc lưu trữ đắt hơn để giảm thiểu tối đa mỗi khối xuống mức an toàn hơn. Tuy nhiên, chúng tôi đã đãhoàn thànhđiều nàynhiềuthời gian, và điều này sẽ làm cho quá nhiều ứng dụng trở nên quá đắt đỏ để thực hiện điều này lần nữa. Một cách tiếp cận tốt hơn sẽ là gas đa chiều: giới hạn và tính phí cho việc truy cập bộ nhớ lưu trữ một cách riêng biệt, giữ cho việc sử dụng trung bình ở mức 1.000 lần truy cập bộ nhớ lưu trữ mỗi block nhưng đặt một giới hạn trên mỗi block là ví dụ 2.000.

Khí đa chiều nhiều hơn nói chung

Một tài nguyên khác đáng xem xét là sự phát triển kích thước trạng thái: các hoạt động tăng kích thước trạng thái Ethereum, mà các nút đầy đủ sẽ cần giữ từ đó trở đi. Đặc tính duy nhất của sự phát triển kích thước trạng thái là lý do giới hạn nó đến hoàn toàn từ việc sử dụng bền vững trong dài hạn, chứ không phải từ những đợt tăng đột ngột. Do đó, có thể có giá trị trong 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ụ: từ không đến không SSTORE, tạo hợp đồng), nhưng với một mục tiêu khác: chúng ta có thể đặt giá linh hoạt để nhắm vào một lượng sử dụng trung bình cụ thể, nhưng không thiết lập bất kỳ giới hạn nào trên mỗi khối.

Điều này cho thấy một trong những tính chất mạnh mẽ của khí đa chiều: nó cho phép chúng ta riêng biệt đặt câu hỏi về (i) sử dụng trung bình lý tưởng là gì, và (ii) sử dụng tối đa an toàn mỗi khối, cho mỗi tài nguyên. Thay vì đặt giá gas dựa trên sử dụng tối đa mỗi khối, và để sử dụng trung bình theo sau, chúng ta có

2𝑛

độ tự do để thiết lập

2𝑛

các tham số, điều chỉnh từng tham số dựa trên điều gì an toàn cho mạng.

Các tình huống phức tạp hơn, như khi hai tài nguyên có xem xét về an toàn một cách một phần có thể được xử lý bằng cách làm cho một opcode hoặc chi phí tài nguyên mất một lượng gas của nhiều loại (ví dụ, một SSTORE từ không đến không thể cost 5000 gas chứng minh từ máy khách không có trạng thái và 20000 gas mở rộng bộ nhớ).

Tối đa mỗi giao dịch: cách dễ dàng hơn nhưng yếu hơn để có được gas đa chiều

Let

𝑥1

là chi phí gas của dữ liệu và

𝑥2

là chi phí gas của việc 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 giao dịch:

gas=𝑥1∗𝑑𝑎𝑡𝑎+𝑥2∗𝑐𝑜𝑚𝑝𝑢𝑡𝑎𝑡𝑖𝑜𝑛

Trong kế hoạch này, chúng tôi thay vì xác định chi phí gas của một giao dịch như sau:

gas=max(x1*đata,x2*computation)

Đó là, thay vì một giao dịch bị tính phí cho dữ liệu cộng với việc tính toán, giao dịch sẽ được tính phí dựa trên tài nguyên nào nó tiêu thụ nhiều hơn. Điều này có thể dễ dàng được mở rộng để bao gồm nhiều chiều hơn (ví dụ,

max(…,x3*storage_access)

).

Nên dễ dàng nhận thấy cách mà điều này cải thiện công suất truyền tải trong khi vẫn bảo đảm an toàn. Số lượng dữ liệu tối đa lý thuyết trong một khối vẫn là

𝐺𝐴𝑆𝐿𝐼𝑀𝐼𝑇𝑥1

, hoàn toàn giống 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à

𝐺𝐴𝑆𝐿𝐼𝑀𝐼𝑇𝑥2

, lại chính xác như trong kế hoạch khí một chiều. Tuy nhiên, chi phí gas của bất kỳ giao dịch nào tiêu thụ cả dữ liệu và tính toán đều giảm.

Đây là khoảng cách sử dụng trong đề xuấtEIP-7623, để giảm kích thước khối tối đa trong khi tăng số lượng blob thêm. 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 thêm một “giá tối thiểu” là 48 gas mỗi byte; giao dịch phải trả giá cao nhất là (16 bytes + execution_gas) và (48 bytes). Do đó, EIP-7623 giảm sức chứa giao dịch tối đa 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í của hầu hết các ứng dụng. Lợi ích của cách tiếp cận này là nó chỉ là một thay đổi rất nhỏ so với hệ thống gas hiện tại theo chiều đơn vị, vì vậy nó rất dễ triển khai.

Có hai điểm hạn chế:

1. Các giao dịch mà tốn nhiều tài nguyên vẫn bị tính một lượng lớn một cách không cần thiết, ngay cả khi tất cả các giao dịch khác trong khối sử dụng ít tài nguyên đó.
2. Nó tạo động lực cho các giao dịch nặng về dữ liệu và tính toán hợp nhất lại với nhau thành một gói để tiết kiệm chi phí.

Tôi sẽ cho rằng một quy tắc kiểu EIP-7623, cả về dữ liệu giao dịch và về các nguồn lực khác, có thể mang lại các lợi ích đủ lớn để đáng giá ngay cả khi có những hạn chế này. Tuy nhiên, nếu và khi chúng ta sẵn lòng đầu tư vào nỗ lực phát triển (đáng kể cao hơn), có một cách tiếp cận lý tưởng hơn.

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

Hãy đầu tiên tổng kết cách hoạt động của EIP-1559 “thường”. Chúng tôi sẽ tập trung vào phiên bản được giới thiệu trong EIP-4844 cho các đoạn văn, vì nó toán học tinh tế hơn.

Chúng tôi theo dõi một tham số, excess_blobs. Trong mỗi khối, chúng tôi thiết lập:

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

Nơi MỤC TIÊU = 3. Điều này có nghĩa là, nếu một khối có nhiều hơn mức tiêu, excess_blobs tăng lên, và nếu một khối có ít hơn mức tiêu, nó giảm. Sau đó, chúng ta đặt blob_basefee = exp(excess_blobs / 25.47), ở đó exp là một xấp xỉ của hàm mũ.

𝑒𝑥𝑝(𝑥)=2.71828𝑥

.

Điều đó có nghĩa là, mỗi khi excess_blobs tăng khoảng ~25, phí cơ sở của blob tăng theo hệ số ~2.7. Nếu các blob 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á trở lại. Giá của một blob điều chỉnh liên tục để đảm bảo rằng trên trung bình, các khối chỉ đầy một nửa - tức là, chúng chứa trung bình 3 blob mỗi khối.

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

Loại cách định giá này đã tồn tại trong Ethereum cho gas trong nhiều năm: một cơ chế rất tương tự đã được giới thiệu với @vbuterin/eip-1559-faq">EIP-1559 trở lại vào năm 2020. Với EIP-4844, chúng ta hiện có hai mức giá riêng biệt cho gas và cho blobs.

Phí cơ sở gas trong vòng một giờ vào ngày 08-05-2024, tính bằng gwei. Nguồn: ultrasound.money.

Về nguyên tắc, chúng tôi có thể thêm nhiều khoản phí riêng lẻ cho việc đọc lưu trữ và các loại hoạt động khác, tuy nhiên với một điều cần lưu ý mà tôi sẽ mở rộng trong phần tiếp theo.

Đối với người dùng, trải nghiệm rất giống với hiện tại: thay vì thanh toán một khoản phí cơ sở, bạn sẽ thanh toán hai khoản phí cơ sở, nhưng ví của bạn có thể trừ trừ điều đó và chỉ hiển thị cho bạn khoản phí dự kiến và khoản phí tối đa mà bạn có thể mong đợi phải thanh toán.

Đối với những người xây dựng khối, hầu hết thời gian chiến lược tối ưu là giống như ngày hôm nay: bao gồm bất cứ điều gì hợp lệ. Hầu hết các khối không đầy - không phảitrong khínortrong các đám. Trường hợp thách thức duy nhất là khi có đủ khí hoặc đủ blobs để vượt quá giới hạn khối, và người xây dựng cần có thể giải quyết một Vấn đề ba lô đa chiềuđể tối đa hóa lợi nhuận của nó. Tuy nhiên, ngay cả khi có các thuật toán xấp xỉ khá tốt, và lợi ích từ việc tạo ra các thuật toán độc quyền để tối ưu hóa lợi nhuận trong trường hợp này cũng nhỏ hơn nhiều so với lợi ích từ việc làm điều tương tự với MEV.

Đố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 các tính năng của EVM và hệ thống xung quanh của nó, được thiết kế xung quanh một giá và một giới hạn ngày nay thành một thiết kế có thể chứa nhiều giá và nhiều giới hạn. Một vấn đề đối với các nhà phát triển ứng dụng là tối ưu hóa trở nên khó khăn hơn: trong một số trường hợp, bạn không còn 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 nhưng B sử dụng nhiều thực thi hơn, thì A có thể rẻ hơn khi calldata rẻ, và đắt hơn khi calldata đắt. Tuy nhiên, các nhà phát triển vẫn có thể đạt được kết quả tương đối tốt bằng cách tối ưu hóa dựa trên giá trị trung bình lịch sử dài hạn.

Giá đa chiều, EVM và cuộc gọi phụ

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

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, 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ể đặt giới hạn gas riêng của mình. Điều này cho phép 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ọ sẽ còn gas để thực hiện các phép tính khác sau cuộc gọi đó.

Một dấu vết của một giao dịch trừu tượng tài khoản, nơi 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 cuộc gọi bên ngoài vẫn có thể tiếp tục chạy ngay cả khi người được gọi tiêu thụ toàn bộ gas được gán cho nó.

Thách thức là: làm cho khí đa chiều giữa các loại thực thi khác nhau dường như sẽ đòi hỏi các cuộc gọi con để cung cấp nhiều giới hạn cho mỗi loại khí, điều này sẽ đòi hỏi một sự thay đổi sâu rộng đối với EVM và sẽ không tương thích với các ứng dụng hiện có.

Điều này là một lý do tại sao các đề xuất khí đa chiều thường dừng lại ở hai chiều: dữ liệu và thực hiện. Dữ liệu (dù là calldata giao dịch hoặc blobs) chỉ được gán bên ngoài EVM, vì vậy không cần thay đổi bất cứ điều gì bên trong EVM để làm cho calldata hoặc blobs có giá riêng biệt.

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

execution_gas + 10000storage_operations - min(7500lưu trữ thao tác, thực hiện gas)

Tương đương:

tối đa (execution_gas + 2500 hoạt động lưu trữ, 10000storage_operations)

Điều này phản ánh cấu trúc của EIP-7623. Một cách khác để thực hiện nó là theo dõi storage_operations và execution_gas trong thời gian thực, và thu phí là 2500 hoặc 10000 tùy thuộc vào việc max(execution_gas + 2500thao_tác_lưu_trữ, 10000Khi lệnh được gọi, lượng gas được sử dụng trong storage_operations) tăng lên. Điều này giúp tránh việc giao dịch phải cấp phát quá nhiều gas mà họ sẽ nhận lại chủ yếu thông qua hoàn trả.

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

Giải pháp giá cả đa chiều đầy đủ dễ nhất mà tôi nghĩ đến là: chúng ta xem xét giới hạn gas của cuộc gọi con là tỷ lệ thuận. Đó là, giả sử rằng có

𝑘

các loại thực thi khác nhau, và mỗi giao dịch đặt một giới hạn đa chiều

𝐿1…𝐿𝑘

. Giả sử rằng, tại điểm hiện tại trong quá trình thực hiện, khí gas còn lại là

𝑔1…𝑔𝑘

. Giả sử một mã lệnh GỌI được gọi, với giới hạn gas gọi con

𝑆

. Let

𝑠1=𝑆

và sau đó

𝑠2=𝑠1𝑔1∗gas2

,

s3=s1g1∗g3

, và cetera.

Nghĩa là, chúng tôi xem xử lý gas loại đầu tiên (hiện thực hóa VM) là một loại “đơn vị tính toán” đặc quyền nào đó, sau đó gán các loại gas khác sao cho cuộc gọi con nhận cùng phần trăm gas khả dụng trên mỗi loại. Điều này hơi xấu, nhưng nó tối đa hóa tính tương thích ngược. Nếu chúng ta muốn làm cho cơ chế trở nên “trung lập” hơn giữa các loại gas khác nhau, với chi phí hy sinh tính tương thích ngược, chúng ta có thể đơn giản làm cho tham số giới hạn gas cuộc gọi con đại diện cho một phần (ví dụ [1…63] / 64) của gas còn lại trong ngữ cảnh hiện tại).

Trong cả hai trường hợp, tuy nhiên, đáng lưu ý rằng khi bạn bắt đầu giới thiệu gas thực thi đa chiều, mức độ xấu xa cố hữu tăng lên và điều này dường như khó tránh khỏi. Do đó, nhiệm vụ của chúng tôi là thực hiện một sự cân nhắc phức tạp: liệu chúng ta có chấp nhận một chút xấu xí hơn ở mức 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 hoạt động tốt nhất cho kinh tế giao thức và các nhà phát triển ứng dụng? Khá có khả năng, chúng không phải là những gì tôi đề cập ở trên, và vẫn còn chỗ để đưa ra một cái gì đó tinh tế và tốt hơn.

Disclaimer：

1. Bài viết này được sao chép từ [[Vitalik Buterin]], Tất cả bản quyền thuộc về tác giả gốc [Vitalik Buterin]. Nếu có ý kiến phản đối về việc tái in này, vui lòng liên hệ Cổng Họcđội của họ và họ sẽ xử lý nhanh chóng.
2. Tất cả các quan điểm và ý kiến được thể hiện trong bài viết này đều là quan điểm cá nhân của tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được nêu, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.