多次元ガス価格設定

イーサリアムでは、リソースは最近まで限られており、1つのリソースである「ガス」を使用して価格が付けられていました。ガスは、特定のトランザクションやブロックを処理するために必要な「計算作業」の量を表すものです。ガスは、複数の種類の「作業」を組み合わせたもので、特に次のようなものがあります:

• 生の計算（例：ADD、MULTIPLY）- Ethereumのストレージへの読み書き（例：SSTORE、SLOAD、ETHの転送）- データ帯域幅- 生成コストZK-SNARKプルーフブロックの例えば、この取引私が送ったものは合計で47,085ガスかかりました。これは(i) 21000ガスの「基本コスト」、(ii) トランザクションの一部として含まれるcalldataのバイトに対する1556ガス、(iii) ストレージへの読み書きに16500ガス、(iv) 作成に対する2149ガスに分かれています。ログ, およびEVMの実行のための残りの部分。ユーザーが支払わなければならない取引手数料は、取引が消費するガスに比例しています。ブロックには最大で3000万ガスまで含めることができ、ガス価格は常に調整されています。@vbuterinEIP-1559のターゲティングメカニズムは、ブロックが平均して15百万ガスを含むようにします。

このアプローチには1つの主要な効率があります:すべてが1つの仮想リソースに統合されているため、非常にシンプルな市場設計につながります。コストを最小限に抑えるようにトランザクションを最適化することは簡単で、最高の手数料を集めるようにブロックを最適化することは比較的簡単です（含まれていませんMEV)、そして、他の取引とまとめて手数料を節約するためにいくつかの取引を促進するような奇妙なインセンティブはありません。

しかし、このアプローチには1つの主要な非効率性もあります: 実際のネットワークが処理できる限界が異なるリソースを相互に変換可能として扱うという点です。この問題を理解する方法の1つは、このダイアグラムを見ることです。

ガスリミットは制約を強制します

𝑥1∗𝑑𝑎𝑡𝑎+𝑥2∗𝑐𝑜𝑚𝑝𝑢𝑡𝑎𝑡𝑖𝑜𝑛- 1つのリソースに負荷がかかっている取引は、その他の取引がそのリソースをほとんど使用していなくても、不必要に大量に請求されます。- データ重視および計算重視のトランザクションにインセンティブを創出し、コストを節約するために束ねられます。EIP-7623のようなルールは、トランザクションのcalldataやその他のリソースにとって大きな利益をもたらす可能性があり、これらの欠点にもかかわらずそれに値すると主張できると思います。ただし、（かなり高い）開発の取り組みを行う覚悟ができている場合、より理想的なアプローチがあります。

多次元EIP-1559：より難しいが理想的な戦略まず、EIP-1559の「通常の」動作を振り返りましょう。数学的により優雅なため、EIP-4844でブロブ用に導入されたバージョンに焦点を当てます。

我々はパラメーター、excess_blobsを追跡します。各ブロック中に、我々は設定します：

excess_blobs EIP-1559 back in 2020. With EIP-4844, we now have two separately floating prices for ガス and for blobs.

2024-05-08の1時間ごとのガス基本手数料、gwei単位。出典: 超音波.money.

原則として、ストレージの読み取りやその他の種類の操作について、別途浮動する追加料金を設定することができますが、次のセクションで詳しく説明する注意点が1つあります。

ユーザーにとっては、1つの基本料金を支払う代わりに、2つの基本料金を支払うことになりますが、ウォレットはそれを抽象化し、予想される手数料と支払うことが予想される最大料金を表示するだけです。

ブロックビルダーにとって、最適な戦略はほとんどの場合、今日と同じです：有効なものはすべて含めます。ほとんどのブロックは満杯ではありません - どちらもガス中norin blobs. 1つの難しいケースは、ガスが十分にあるか、ブロブが十分にある場合で、ブロックの制限を超える可能性があるときであり、ビルダーは潜在的に解決する必要があります。多次元ナップザック問題その利益を最大化するために。しかし、そこでもかなり優れた近似アルゴリズムが存在し、この場合、利益を最適化するための独自のアルゴリズムを作成する利益は、MEVと同じことをする利益よりもはるかに小さいです。

開発者にとって、主な課題はEVMの機能を再設計し、現在1つの価格と1つの制限を中心として設計されている周辺インフラを、複数の価格と複数の制限を収容する設計に変更する必要があることです。アプリケーション開発者の1つの問題は、最適化がやや難しくなることです：いくつかの場合、AがBよりも効率的であると一意に言えなくなります。なぜなら、Aがより多くのcalldataを使用するがBがより多くの実行を使用する場合、calldataが安い場合はAが安く、calldataが高い場合はAが高くなる可能性があるからです。ただし、開発者は長期の平均価格に基づいて最適化することで、合理的に良い結果を得ることができます。

マルチディメンショナル価格設定、EVMおよびサブコールBlobには現れなかった1つの問題があり、EIP-7623や「完全な」コールデータの多次元価格実装でも現れませんが、状態アクセスやその他のリソースを別々に価格設定しようとすると現れます：サブコールのガス限界。

EVM内のガス制限は2つの場所に存在します。まず、各トランザクションはガス制限を設定し、そのトランザクションで使用できるガスの総量を制限します。次に、契約が別の契約を呼び出す場合、呼び出し側は独自のガス制限を設定できます。これにより、信頼していない契約を呼び出すことができ、その呼び出し後に他の計算を行うために残りのガスがあることを保証できます。

アカウント抽象化トランザクションの痕跡で、アカウントが別のアカウントを呼び出し、呼び出し先に制限されたガス量しか与えないことで、呼び出し元が割り当てられたガスを全て消費した場合でも、外部呼び出しが継続できるようにします。

課題は、異なる種類の実行間でガスを多次元にすることであり、それには各種類のガスに複数の制限を提供するためにサブコールが必要になるようです。これにはEVMへの非常に深い変更が必要であり、既存のアプリケーションと互換性があるわけではありません。

これは、多次元のガス提案がしばしばデータと実行の2つの次元で止まる理由の1つです。データ（トランザクションのcalldataまたはblobsであっても）はEVMの外部にのみ割り当てられるため、EVMの内部でcalldataまたはblobsが別々に価格設定されるためには何も変更する必要がありません。

この問題に対する「EIP-7623スタイルの解決策」を考えることができます。ここに1つの簡単な実装例があります：実行中に、ストレージ操作に対して4倍の料金を請求します。分析を単純化するために、ストレージ操作ごとに10000ガスとします。トランザクションの最後に、min(7500 * storage_operations, execution_gas)を返金します。その結果、返金額を差し引いた後、ユーザーに請求される金額は次のとおりです：

execution_gas + 10000 storage_operations - min(7500storage_operations、execution_gas)

それは等しい：

execution_gas + 2500最大値ストレージオペレーション、10000storage_operations)

これはEIP-7623の構造を反映しています。それを行う別の方法は、ストレージ操作と実行ガスをリアルタイムで追跡し、max(execution_gas + 2500に応じて2500または10000を請求することです。storage_operations、10000オペコードが呼び出されるタイミングで、ストレージ操作)の消費量が増加します。これにより、取引がリファンドを通じてほとんど戻ってくるガスを過剰に割り当てる必要がなくなります。

サブコールに対する細かい許可設定は得られません：サブコールは安価なストレージ操作のためのトランザクションの「許可」をすべて消費する可能性があります。しかし、サブコールを行う契約では、限度を設定し、サブコールの実行が終了した後も、主要なコールが必要なポスト処理を行うために十分なガスが残っていることを保証できます。

私が考える最も簡単な「完全な多次元価格設定ソリューション」は次の通りです: サブコールのガスリミットを比例と見なします。つまり、仮定してください

𝑘

異なる種類の実行があり、各トランザクションは多次元の制限を設定します

𝐿1…𝐿𝑘

. 現在の実行ポイントで、残りのガスがあるとします。

𝑔1…𝑔𝑘

CALLオペコードが呼び出され、サブコールのガス制限があるとします

𝑆

. Let

𝑠1=𝑆

、そして

𝑠2=𝑠1𝑔1∗ガス2

,

𝑠3=𝑠1𝑔1∗𝑔3

, など。

つまり、最初のタイプのガス（実際にはVM実行）を一種の特権的な「単位」として扱い、その後、他のタイプのガスを割り当てて、サブコールがそれぞれの種類ごとに利用可能なガスの同じ割合を得るようにします。これはやや不格好ですが、後方互換性を最大限に活用しています。異なる種類のガス間でスキームをより「中立的」にするために、後方互換性を犠牲にしても、単にサブコールのガス制限パラメータが現在のコンテキスト内の残りのガスの分数（例：[1…63] / 64）を表すようにすることができます。

どちらの場合でも、多次元実行ガスを導入し始めると、固有の醜さのレベルが増加し、これは避けがたいようです。したがって、私たちの仕事は複雑なトレードオフを行うことです。つまり、EVMレベルでやや醜さを受け入れて、重要なL1のスケーラビリティの利益を安全に解放するために、そしてその場合、どの具体的な提案がプロトコル経済とアプリケーション開発者にとって最も適しているか？おそらく、私が上記で言及したもののどちらもそうではない可能性が高く、まだより優雅でより良いものを考える余地があります。

免責事項：- この記事は[[ヴィタリック・ブテリン]]から転載されました。すべての著作権は元の著者に帰属しますヴィタリック・ブテリン]. If there are objections to this reprint, please contact the [ゲートラーン](https://www.Gate.com/questionnaire/3967チームが promptly に対処します。- 責任の免責事項: この記事で表現されている見解や意見は、著者個人のものであり、投資アドバイスを構成するものではありません。- この記事の翻訳はGate Learnチームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。