ヴィタリックの最新ブログ記事：多次元ガス価格設定の探求

著者：Vitalik、イーサの創設者、翻訳者：0xjs@GoldenFinance

イーサでは最近まで、リソースは有限であり、「ガス」と呼ばれる単一のリソースを使用して価格が決められていました。 ガスとは、与えられた取引やブロックを処理するのに必要な「計算」の量を示す指標です。

• Raw computation (e.g. ADD、 MULTIPLY)

• 。

  イーサリアムのストレージへの読み書き（SSTORE、SLOADETH転送など）

• データ帯域幅

• ブロックのZK-SNARK証明を生成するコスト

例えば、私が送ったこのトランザクション（https://etherscan.io/tx/0xc5195b64cc333b8098d71fbd0f032e05d4545917e3b0be8d123ab06e1ad7998e)合計47,085'ガスのコストがかかります。この内訳は、(i)「基本コスト」の21,000ガス、(ii)トランザクションの一部を含むコール・データ・バイトを作成するための1556ガス、(iii)ストレージへの読み書き用の16,500ガス、(iv)ログ生成用の2149ガス、(v)ストレージへの書き込み用の16,500ガス、(vi)ストレージへの書き込み用の16,000ガス、(vii)ストレージへの書き込み用の16,000ガス、(viii)ストレージへの読み書き用の16,500ガス、(ix)ストレージへの読み書き用の16,500ガスである。2149ガスはログ生成用、残りはEVM実行用。 ユーザーが支払わなければならないトランザクション料金は、トランザクションによって消費されるガスに比例する。ブロックには最大3000万ガスが含まれ、ガスの価格はEIP-1559ターゲティングメカニズムによって常に調整されるため、ブロックには平均1500万ガスが含まれます。すべてが1つの仮想資源に統合されるため、非常にシンプルな市場設計につながります。コストを最小化するためにトランザクションを最適化するのは簡単で、（MEVを除いて）可能な限り高い手数料を請求するためにブロックを最適化するのは比較的簡単です。

しかし、このアプローチには大きな非効率性もあります。それは、ネットワークが処理できる実際の潜在的な限界はそうではないのに、異種のリソースを交換可能なものとして扱うことです。この問題を理解する1つの方法は、このグラフを見ることです。

ガス制限は次の制約を強制します：x1*データ+x2*計算<N. 実際の基礎となるセキュリティ制約は、通常max(x1*データ, x2*計算)<Nに近いです。この違いは、Gas制約が不必要に実際には安全なブロックを除外したり、実際には安全でないブロックを受け入れたり、あるいはその2つの混合を引き起こします。

異なるセキュリティ制約を持つ?リソースがある場合、1次元のガスはスループットを1?この記事では、このアプローチの利点と、さらなる機能拡張の見通しについて説明します。

Blobs: Dencunにおける多次元ガス

今年の初め、Etherの平均ブロックサイズは150キロバイトでした。このデータは非常に高価です。ロールアップトランザクションのコストはイーサL1上の対応するトランザクションの約5-10倍ですが、多くのユースケースにとってはまだ高すぎます。

なぜcalldataのGasコスト（現在、非ゼロバイトあたり16  Gas、ゼロバイトあたり4  Gas）を減らして、Rollupを安くしないのでしょうか？以前にもやったことがある。最悪の場合のブロックサイズは30,000,000/16 = 1,875,000非ゼロバイトであり、ネットワークはすでにそのサイズのブロックを処理するのがやっとである。もしコストがさらに4分の1になれば、最大容量は7.5MBに増え、これは大きなセキュリティリスクをもたらす。

この問題は最終的に、各ブロックに独立したロールアップフレンドリーなデータ空間（「ブロブ」と呼ばれる）を導入することで解決されました。Dencunハードフォーク後、イーサブロックは(i)3000万ガス、(ii)6ブロブを含むことができ、各ブロブは約125キロバイトのコールデータを含むことができます。

その結果、ロールアップのコストは100分の1に減少し、ロールアップのトランザクション量は3分の1以上に増加しましたが、理論上の最大ブロックサイズはわずかに増加しただけでした：

Growthepie.xyzによるロールアップ取引手数料。

多次元ガスとステートレスクライアント

近い将来、同様の問題がステートレスクライアントのストレージ証明でも発生するでしょう。ステートレスクライアントは新しいタイプのクライアントで、大量のデータをローカルに保存することなく、ブロックチェーンを検証できるようになります。ステートレスクライアントは、そのブロックのトランザクションが触れる必要のあるイーサの特定の部分の証明を受け入れることによってこれを行います。

ステートレスクライアントは、ブロックの実行に関係するステート固有の部分（アカウント残高、コード、ストレージなど）の現在値の証明とともに、ブロックを受け取ります。これによってノードは、ストレージそのものなしでブロックを検証することができます。

ストレージの読み込みには、読み込みの種類によって2100～2600 Gasのコストがかかりますが、ストレージの書き込みにはそれ以上のコストがかかります。平均して、ブロックは約1000のストレージの読み取りと書き込みを実行します（ETH残高チェック、SLOADへのSSTORE呼び出し、コントラクトコードの読み取り、その他の操作を含む）。ただし、理論上の最大値は30,000,000/2100 = 14,285回の読み取りである。ステートレスクライアントの帯域幅負荷はこの数に比例する。

今日の計画では、イーサネットのステートツリー設計をMerkle PatriciaツリーからVerkleツリーに移行することで、ステートレスクライアントをサポートする予定です。しかし、バークルツリーは量子耐性がなく、新しいSTARK証明システムには最適ではありません。その結果、バイナリのMerkleツリーとSTARKを介してステートレスクライアントをサポートすることに多くの関心が集まっています。Verkleを完全にスキップするか、Verkleの移行から数年後にSTARKがより成熟したらアップグレードするかのどちらかです。

バイナリハッシュツリーブランチに対するSTARK証明には多くの強みがありますが、証明の生成に時間がかかるという重要な弱点があります。ブランチ "が必要です。

超最適化された証明システム（BiniusやPlonky3など）や特殊化されたハッシュ（Vision-Mark-32など）から今日予測される数値を考慮すると、1,000の値を1秒未満で証明することは実際に可能ですが、14,285の値を証明することはできない状態がしばらく続くと思われます。各ブロックは平均的には問題ありませんが、最悪のブロック（攻撃者によって解放される可能性がある）はネットワークを破壊するでしょう。

この状況に対処する私たちの「デフォルト」の方法は、再プライシングです。ストレージの読み取りをより高価にして、ブロックあたりの最大値をより安全なレベルまで下げます。しかし、私たちはこれを何度も行ってきたため、再びこれを行うと、あまりにも多くのアプリケーションが高価になりすぎてしまいます。より良いアプローチは、多次元ガスです。ストレージ アクセスを個別に制限して課金し、平均使用量をブロックごとに 1,000 ストレージ アクセスに維持しますが、ブロックごとの制限をたとえば 2,000 に設定します。

より一般的な多次元ガス

検討する価値のあるもう1つのリソースは、状態のサイズ拡大です。状態サイズの成長についてユニークな点は、状態の成長を制限する正当な理由が、ピークではなく、長期的な持続的使用から来ることです。したがって、ステートサイズの増加操作（たとえば、ゼロから非ゼロのSSTORE、コントラクトの作成）に別のガス次元を追加することは価値があるかもしれませんが、目的は異なります。i）各リソースの理想的な平均使用量はいくらか、（ii）ブロックごとの安全な最大使用量はいくらか、です。ブロックごとの最大使用量に基づいてガス価格を設定するのではなく、平均使用量に基づいて設定します。2つのパラメータを設定し、ネットワークにとって安全なものに基づいて各パラメータを調整する自由度は2つです。

部分的に累積的なセキュリティの考慮がある2つのリソースのような、より複雑なケースは、オペコードまたはリソースに一定量の複数の種類のガスをコストさせることで処理できます（たとえば、ゼロからゼロでないSSTOREは、5,000のステートレスクライアント証明のガスと20,000のストレージ拡張のガスをコストさせるかもしれません）。

トランザクションごとの最大化：多次元Gasを得るための、より弱いが単純な方法

x1をデータのGasコスト、x2を計算のGasコストとすると、1次元Gasシステムでは、トランザクションのGasコストをgas=x1*data+x2*computationと書くことができます。gas=max(x1*data,x2*computation)

としてトランザクションのGasコストを定義する

つまり、データ＋計算に基づいてトランザクションを課金する代わりに、トランザクションは2つのリソースのどちらをより多く消費するかに基づいて課金される。これはより多くの次元をカバーするために簡単に拡張できます（例えばmax(...,x3*storage_access)）。

セキュリティを維持しながらスループットを向上させる方法は、容易に理解できるはずです。ブロック内の理論的な最大データ量は、やはりGASLIMIT/x1であり、1次元Gasスキームと全く同じです。同様に、理論上の最大計算量はGASLIMI/x2であり、これも一次元Gasスキームとまったく同じである。しかし、データと計算を消費するトランザクションのガスコストは削減されます。

これは、提案されているEIP-7623で使用されているスキームとほぼ同じです。 EIP-7623の正確なメカニズムは少し複雑で、1バイトあたり16ガスの現在のcalldata価格を維持しますが、1バイトあたり48ガスの「フロア」価格を追加します。48 * バイト）で同じ価格を支払う。その結果、EIP-7623は、ほとんどのアプリケーションのコストを一定に保ちながら、ブロック内の理論上の最大トランザクション・コール・データを約1.9MBから約0.6MBに削減する。このアプローチの利点は、現在の1次元GASスキームと比較してほとんど変更がないため、実装が非常に簡単であることです。

これには2つの欠点があります:

1.1つのリソースを大量に使用するトランザクションは、ブロック内の他のすべてのトランザクションがそのリソースをほとんど使用していないにもかかわらず、不必要に大量の金額を請求されます。

2.コストを節約するために、データ集約型トランザクションと計算集約型トランザクションを1つのバンドルにまとめるインセンティブが働きます。

私は、EIP-7623スタイルのルールは、データとその他のリソースを呼び出すトランザクションの両方に対して、これらの欠点があっても、十分に有益であると思います。しかし、（著しく高い）開発努力を惜しまないのであれば、より望ましいアプローチがあります。

多次元EIP-1559: より困難だが理想的な戦略

まず、「通常の」EIP-1559がどのように機能するかを復習することから始めましょう。EIP-4844でブロブ用に導入されたバージョンに焦点を当てますが、これは数学的によりエレガントだからです。

1つのパラメータであるexcess_blobsを追跡する。各ブロックの間に、

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

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

です。つまり、access_blobが25倍増加するごとに、ブロブの基本コストは2.7倍増加する。BLOBが高価になりすぎると、平均使用率が下がり、access_blobsが下がり始め、自動的に価格が再び下がる。

使用量が短期的に急増する場合、制限があります：各ブロックは最大6つのブロブを含むことができ、その場合、取引は優先料金を上げることで互いに競争することができます。しかし、通常の場合、各blobはblob_basefeeに加え、含まれるインセンティブとして少し余分に優先料金を支払うだけです。

このようなガス価格設定は、イーサでは何年も前から存在していました。2020年にさかのぼると、EIP-1559が非常に似たメカニズムを導入しました。EIP-4844では、GasとBlobに2つの別々の変動価格が設定されました。

<

2024年5月8日の1時間あたりのガス基本料金（gwei）。しかし、次のセクションで詳述する注意点があります。

ブロックビルダーにとって、ほとんどの場合、最善の戦略は現在と同じです。困難な状況とは、ブロックの限界を超えるほどのガスや塊がある場合で、ビルダーは利益を最大化するために多次元ナップザック問題を解く必要があります。しかし、合理的に良い近似が存在するとしても、この場合に独自のアルゴリズムを開発して利益を最適化することによる利益は、MEVを使用して同じ操作を実行することによる利益よりもはるかに小さくなります。

開発者にとっての主な課題は、現在1つの価格と1つのリミットを中心に設計されているEVMとその周辺のインフラの機能を、複数の価格と複数のリミットに対応する設計に再設計する必要があることです。アプリケーション開発者にとっての問題のひとつは、最適化が若干難しくなることである。Aはより多くのcalldataを使用し、Bはより多くの実行を使用する場合、calldataが安いときは安く、calldataが高いときは高くなるからである。しかし、開発者は長期的な過去の平均価格に対して最適化することで、かなり良い結果を得ることができます。

多次元プライシング、EVM、およびサブコール

blobにも、EIP-7623にも、calldataの「完全な」多次元プライシング実装にも現れない問題が1つあります。状態アクセスや他のリソースを単独でプライシングしようとすると、サブコールのガス制限という問題が発生します。

EVMにおけるガスリミットは、2つの場所に存在します。まず、各トランザクションは、そのトランザクションで使用できるガスの総量を制限するガスリミットを設定します。第二に、コントラクトが他のコントラクトを呼び出すとき、その呼び出しは独自のガスリミットを設定することができます。これにより、コントラクトは信頼できない他のコントラクトを呼び出しても、呼び出し後に他の計算を実行するためにガスが残っていることを保証することができます。

<

アカウントはトランザクションの痕跡を抽象化し、一方のアカウントが他方のアカウントを呼び出し、着呼側に限られた量のガスしか提供しないようにします。コールは、たとえ着呼側が割り当てられたガスをすべて消費したとしても、実行し続けることができる。

課題はこれです: 異なるタイプの実行間でガスを多次元にすることは、各タイプのガスに複数の制限を提供するサブコールを必要とするように思われます。

これは、多次元ガス提案が通常、データと実行の2つの次元にとどまる理由の1つです。データ(トランザクションのcalldataであれblobであれ)はEVMの外側でのみ割り当てられるので、calldataやblobを個別に価格設定するためにEVMの内側を変更する必要はありません。

私たちは、この問題に対する「EIP-7623スタイルのソリューション」を考え出すことができます。分析を簡単にするために、ストレージ操作ごとに10,000のガスを想定してみましょう。トランザクションの終了時に、min(7500 * storage_operations, execution_gas)を払い戻します。その結果、払い戻しを差し引いた後、ユーザーは次のように支払います:

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

これは次のように等しくなります:

。max(execution_gas + 2500 * storage_operations, 10000 * storage_operations)

これはEIP-7623の構造を反映しています。別のアプローチは、リアルタイムでstorage_operationsとexecution_gasを追跡し、オペコードが呼び出されたときにどれだけ上がるかに応じて、多かれ少なかれmax(execution_gas + 2500 * storage_operations, 10000 * storage_operations)を請求することです。2500または10000ガス。これは、ガスの日数を過剰に割り当てる必要があるトランザクションを回避します。

私たちは、サブコールのためのきめ細かいライセンスを得ることはできません：サブコールは、安価なストレージ操作を実行するために、トランザクションのすべての「許容量」を消費するかもしれません。しかし、サブコールを作成するコントラクトが制限を設定し、サブコールが実行を終了した後、メインコールが実行する必要のある後処理を実行するのに十分なガスをまだ持っていることを保証できるような、十分なものを得ることができます。

私が思いつく最も単純な「完全な多次元価格ソリューション」は、サブコールのガス制限を比例として扱うことです。つまり、

?それぞれ多次元的な制限を持つ、異なるタイプの実行があるとします。現在の実行時点で、残りのガス

が

「1...?s1=Sとし、s2=s1/g1*g2,s3=s1/g1*g3、とする。

つまり、最初のタイプのガス(これは実際にはVMの実行です)を特権的な「アカウント単位」として扱い、サブコールがビルドの各タイプで利用可能なガスの同じ割合を得るように、他のタイプのガスを割り当てます。互換性。後方互換性を犠牲にしてでも、異なるタイプのガス間でスキームをより「中立的」にしたい場合は、単純にサブコールのガス上限パラメーターを残りのガスのわずかな割合にすることができます（例えば、[1.）.63] / 64).

ただし、いずれの場合でも、ガスの多次元実行を導入し始めると、固有の醜さが増すことを強調する価値があります。

したがって、私たちの課題は、複雑なトレードオフを行うことです。L1の大幅なスケーラビリティの利得を安全に引き出すために、EVMレベルでより醜いものを受け入れるのか、もしそうなら、どの具体的な提案がプロトコル経済学とアプリケーション開発者に最も適しているのか。

可能性としては、上に挙げたもののどれでもなく、よりエレガントで優れたものを考え出す余地はまだあります。

フィードバックとレビューをしてくれたAnsgar Dietrichs、Barnabe Monoton and Davide Crapisに感謝します。