イーサリアムでは、リソースは最近まで限られており、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∗𝑑𝑎𝑡𝑎,𝑥2∗𝑐𝑜𝑚𝑝𝑢𝑡𝑎𝑡𝑖𝑜𝑛)<𝑁

. この不一致は、ガスリミットが実際に安全なブロックを不必要に除外するか、実際には危険なブロックを受け入れるか、あるいはその両方の混合物につながります。

もしあれば

𝑛

安全限界を持つリソースがあり、1次元ガスがスループットを最大で何倍も低下させる可能性がある

𝑛

この理由から、長い間、多次元ガスの概念に興味が持たれてきました。EIP-4844実際に、今日はイーサリアムでマルチディメンショナルなガスが動作しています。この投稿では、このアプローチの利点とさらなる増加の見通しについて探求します。

Blobs: 多次元のガスはDencun内にあります

今年の初めに、平均ブロックは150 kBのサイズそのサイズの大部分は、ロールアップデータです。レイヤー2プロトコルセキュリティのためにチェーン上にデータを保存する。このデータは高価だった：ロールアップ上の取引がイーサリアムL1上の対応する取引よりも約5-10倍安くなるにもかかわらず、そのコストさえも多くのユースケースにとって高すぎました。

なぜcalldataのガスコスト（現在はゼロでないバイトごとに16ガス、ゼロバイトごとに4ガス）を減らさないのでしょうか。ロールアップをより安くするために。以前にこれをしました、我々はもう一度やることができました。ここでの答えは：ブロックの最悪の場合のサイズは

30,000,00016=1,875,000

非ゼロバイトで、ネットワークは既にそのサイズのブロックをほとんど処理できない状況です。コストをさらに4倍削減すると、最大容量が7.5MBになり、安全上のリスクが大きくなります。

この問題は、各ブロックに「blob」として知られるロールアップフレンドリーデータの別のスペースを導入することで処理されることになりました。 これら2つのリソースには、それぞれ独自の価格と独自の制限があります：Dencunハードフォークの後、Ethereumブロックには最大で30百万ガスと6つのブロブ（それぞれ約125 kBのcalldataを含む）が含まれることができます。 どちらのリソースも、調整された独自の価格があります。EIP-1559のような価格メカニズムを分離する, 平均使用量を15百万ガスと1ブロックあたり3ブロブを目標としています。

その結果、ロールアップは100倍安くなり、ロールアップ上の取引量は3倍以上増加し、理論上の最大ブロックサイズはわずかに増加しました：約1.9 MBから約2.6 MBまで。

ロールアップの取引手数料、のおかげでgrowthepie.xyz. 多次元価格を導入したDencunフォークは、2024年3月13日に発生しました。

マルチ次元ガスと状態レスクライアント

近い将来、状態を保存するための証明に関して、statelessクライアントに関する類似した問題が発生するでしょう。Statelessクライアントは、ローカルにあまりデータを保存せずにチェーンを検証できる新しいタイプのクライアントです。Statelessクライアントは、そのブロック内のトランザクションが触れる必要のある特定のEthereum状態の証明を受け入れることでこれを行います。

ステートレスクライアントは、ブロックとともに、ブロック実行に触れる特定の状態の現在の値（例：アカウント残高、コード、ストレージ）を証明する証拠を受け取ります。これにより、ノードは、自身のストレージを持たずにブロックを検証することができます。

ストレージの読み取りには、読み取りの種類に応じて2100〜2600ガスかかります。書き込みはさらに費用がかかります。平均すると、1ブロックあたり約1000回のストレージ読み取りと書き込みが行われます（ETH残高の確認、SSTOREおよびSLOADの呼び出し、コントラクトコードの読み取りなどを含む）。ただし、理論上の最大値は、「Gate.io」です。

30,000,0002,100=14,285

読み取ります。 無状態のクライアントの帯域幅負荷は、この数に比例します。

今日の計画は、イーサリアムの状態ツリーデザインを移行して、ステートレスクライアントをサポートすることですマークル・パトリシア・ツリーtoVerkle treesただし、Verkleツリーは量子耐性ではなく、新しい波のSTARK証明システムに最適ではありません。その結果、多くの人々がバイナリMerkleツリーを通じたステートレスクライアントのサポートに興味を持っています。STARKs代わりに、Verkleを完全にスキップするか、Verkleの移行後数年してから、STARKsがより成熟するのを待ってからアップグレードすることもできます。

バイナリハッシュツリーブランチのSTARKプルーフには多くの利点がありますが、生成には時間がかかるという重要な弱点があります。Verkle treescan prove1秒あたり10万以上の値, ハッシュベースのSTARKは通常、1秒あたり数千のハッシュしか証明できず、各値を証明するには多くのハッシュを含む「枝」が必要です。

本日のハイパーオプティマイズされた証明システムから予測されている数字を考慮すると、BiniusそしてPlonky3そして専門のハッシュ値のようなVision-Mark-32, しばらくの間、1秒未満で1,000の値を証明することが実用的であるが、14,285の値を証明することは実用的でないと考えられるレジームにいる可能性が高いです。 平均ブロックは問題ありませんが、最悪のケースのブロックは、攻撃者によって公開される可能性があり、ネットワークを破壊する可能性があります。

「デフォルト」でこのようなシナリオを処理する方法は、再価格設定です: ストレージの読み取りをより高くして、ブロックあたりの最大値を安全なレベルに抑えます。しかし、私たちは既に完了これ多くの回, そして、これを再度行うと多くのアプリケーションが高額になりすぎる可能性があります。 より良いアプローチは、多次元のガス：ストレージアクセスの制限と料金を別々に設定し、平均使用量をブロックあたり1,000回のストレージアクセスに保ちつつ、例えばブロックあたり2,000回の制限を設定することです。

より一般的な多次元ガス

考慮に値するもう一つのリソースは状態サイズの増加です: イーサリアムの状態のサイズを増やす操作、それはフルノードがそれ以降保持する必要があります。状態サイズの増加のユニークな特性は、その制限の理由が長期的な持続的な使用から来ており、スパイクからではないことです。したがって、状態サイズを増加させる操作（例: ゼロから非ゼロのSSTORE、コントラクトの作成）には、異なる目標がありますが、それには別のガス次元を追加する価値があるかもしれません: 特定の平均使用を目標とするために浮動価格を設定できますが、ブロックごとの上限は設定しません。

これは多次元ガスの強力な特性の1つを示しています。それは、（i）理想的な平均使用量が何であり、（ii）各リソースに対するブロックごとの安全な最大使用量が何であるかという質問を別々に行うことを可能にします。ブロックごとの最大値に基づいてガス価格を設定し、平均使用量に従わせるのではなく、

2𝑛

自由度を設定する

2𝑛

パラメータを調整し、それぞれのネットワークに安全なものに基づいて調整します。

より複雑な状況、例えば、2つのリソースが部分的に加算される安全性の考慮事項を持つ場合、オペコードまたはリソースコストを複数タイプのガスの量として扱うことで対処できます（例：ゼロから非ゼロのSSTOREの場合、5000の状態レスクライアント証明ガスと20000のストレージ拡張ガスがかかることがあります）。

トランザクションごとの最大：多次元ガスを取得するための弱いが簡単な方法

Let

𝑥1

データのガスコストとなります

𝑥2

計算のガスコストは、一次元のガスシステムではトランザクションのガスコストを次のように書くことができます。

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

このスキームでは、代わりにトランザクションのガスコストを次のように定義します:

ガス=最大(×1∗データ,×2∗コンピュテーション)

つまり、データプラス計算に対して料金が請求される代わりに、トランザクションはどちらのリソースをより多く消費するかに基づいて料金が請求されます。これは簡単に他の次元に拡張できます（例えば、

max(…,x3*storage_access)

).

これにより、スループットが向上し、安全性が保たれる方法が簡単に見えるはずです。ブロック内の理論上のデータ量の最大値はまだ

ガスリミットx1

, exactly the same as in the one-dimensional ガス scheme. Similarly, the theoretical max amount of computation is

ガスリミットx2

, again exactly the same as in the one-dimensional ガス scheme. However, the ガス cost of any transaction that consumes both data and computation decreases.

これは提案されたスキームで使用されているものですEIP-7623, 最大ブロックサイズを減らしながらブロブ数をさらに増やすことで、EIP-7623の正確なメカニズムは少し複雑です：現在のcalldata価格を1バイトあたり16ガスに保ちますが、1バイトあたり48ガスの「底値価格」を追加します。トランザクションは(16 バイト+実行ガス）および（48バイト）。その結果、EIP-7623により、ブロック内の理論上の最大トランザクションコールデータが約1.9 MBから約0.6 MBに減少し、ほとんどのアプリケーションのコストは変わらずに残ります。このアプローチの利点は、現行の単一次元ガススキームからの非常に小さな変更であるため、実装が非常に簡単であることです。

欠点は2つあります：

1. 1つのリソースに負荷がかかっている取引は、その他の取引がそのリソースをほとんど使用していなくても、不必要に大量に請求されます。
2. データ重視および計算重視のトランザクションにインセンティブを創出し、コストを節約するために束ねられます。

EIP-7623のようなルールは、トランザクションのcalldataやその他のリソースにとって大きな利益をもたらす可能性があり、これらの欠点にもかかわらずそれに値すると主張できると思います。ただし、（かなり高い）開発の取り組みを行う覚悟ができている場合、より理想的なアプローチがあります。

多次元EIP-1559：より難しいが理想的な戦略

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

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

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

TARGET = 3 です。つまり、ブロックにはターゲットよりも多くのブロブが含まれている場合、excess_blobs が増加し、ターゲットよりも少ない場合は減少します。その後、blob_basefee = exp(excess_blobs / 25.47) とします。ここで、exp は指数関数の近似です。

𝑒𝑥𝑝(𝑥)=2.71828𝑥

.

すなわち、excess_blobs が約25増加するたびに、blob basefee は約2.7倍に増加します。blob が高価になりすぎると、平均使用量が減少し、excess_blobs が自動的に減少し、再び価格が下がります。blob の価格は常に調整され、平均してブロックが半分埋まるようになっています。つまり、平均して各ブロックには3つの blob が含まれています。

使用量が急増すると、制限がかかります: 各ブロックには最大6つのブロブしか含まれず、そのような状況では取引が優先手数料を上乗せして競合することができます。ただし、通常の場合、各ブロブはブロブベース手数料にわずかな追加の優先手数料を支払うだけで、すべてに含まれるようにインセンティブを得る必要があります。

この種の価格設定は、ガスのために数年間イーサリアムに存在していました: ほとんど同じメカニズムが導入されました @vbuterin/eip-1559-faq">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のスケーラビリティの利益を安全に解放するために、そしてその場合、どの具体的な提案がプロトコル経済とアプリケーション開発者にとって最も適しているか？おそらく、私が上記で言及したもののどちらもそうではない可能性が高く、まだより優雅でより良いものを考える余地があります。

免責事項：

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