ヴィタリックの新しいタイトル:最長のガス価格とは何ですか?

著者: ビタリックブテリン

コンパイラ: Karen, Foreisght News

イーサリアムでは、リソースは最近まで限られており、「ガス」と呼ばれる単一のリソースを通じて価格が設定されていました。 ガスは、特定のトランザクションまたはブロックを処理するために必要な「計算労力」を測定する測定単位です。 ガスは、最も長いタイプの「計算」をまとめたもので、その中で最も重要なものは次のとおりです。

1.生の計算(例:ADD、MULTIPLY)。

2. イーサリアムストレージ(SSTORE、SLOAD、ETH転送など)への読み取り、書き込み、書き込み。

3.データ帯域幅;

4. ブロックのZK-SNARKプルーフを生成するためのコスト。

たとえば、私が送信したこのトランザクションは、合計 47,085 ガスを消費しました。 これらには、(i)21,000ガスの基本コスト、(ii)トランザクションの一部として含まれるコールデータバイト用の1,556ガス、(iii)読み取りおよび書き込みストレージ用の16,500ガス、(iv)ログ生成用の2,149ガス、残りはEVM実行用が含まれます。 ユーザーが支払わなければならない取引手数料は、取引によって消費されるガスに比例します。 ブロックには最大3,000万ガス ロングを含めることができ、ガス価格はEIP-1559ターゲティングメカニズムによって継続的に調整され、各ブロックに平均1,500万ガスが含まれるようにします。

このアプローチには、すべてが 1 つの仮想リソースに結合されるため、マーケットプレースの設計が非常にシンプルになるという大きな利点があります。 コストを最小限に抑えるためにトランザクションを最適化するのは簡単で、可能な限り高い手数料(MEVを除く)を請求するようにブロックを最適化するのは比較的簡単で、手数料を節約するために一部のトランザクションを他のトランザクションとバンドルすることを奨励する奇妙なインセンティブはありません。

ただし、このアプローチには非効率性があり、実際の基礎となる制約が同じでない場合に、異なるリソースを相互に変換可能であるかのように扱います。 これを理解するには、まず次のグラフを見てください。

ガスリミットには制約があります。

実際の基になるセキュリティ制約は、多くの場合、次のようになります。

この違いにより、ガス制限は、実際に安全なブロックを不当に除外するか、実際に安全でないブロックを受け入れるか、またはその両方を行います。

セキュリティ制限の異なるリソースが n 個ある場合、1 次元ガスではスループットが最大 n 倍ロング ドロップになる可能性があります。 その結果、憧れのガスという概念への関心ロング、EIP-4844とともに、実際に憧れガスイーサリアムに実装するようになりました。 この記事では、このアプローチの利点と、さらなる機能強化の見通しについて説明します。

ブロブ:デンクンで最も長いガス

今年の初めには、平均ブロックサイズは150kBでした。 その大部分はロールアップ データであり、レイヤー2 プロトコルデータ オンチェーンを格納します。 このデータは非常に高価です:ロールアップの取引コストはイーサリアムL1の対応するトランザクションの5〜10倍にすぎませんが、そのようなコストでさえロングユースケースには高すぎます。

では、コールデータのガスコスト(現在、ゼロ以外のバイトの場合は16ガス、ゼロバイトの場合は4ガス)をドロップして、ロールアップを安くしてみませんか? これは以前にもやったことがあり、今またやることができます。 しかし、ここでの答えは、ブロックの最大サイズは30,000,000/16=1,875,000の非ゼロバイトであり、ネットワークはこのサイズのブロックをかろうじて、またはかろうじて処理できるということです。 コストをさらに 4 倍に減らすと、最大容量が 7.5 MB に増加し、セキュリティに重大なリスクをもたらします。

この問題は、最終的に、各ブロックに個別のロールアップに適したデータ ショート (blob と呼ばれる) を導入することで解決されます。

これら 2 つのリソースには異なる価格と制限があり、Dencun ハードフォーク後、イーサリアム ブロック最大ロングには (i) 3,000 万ガスと (ii) 6 つの BLOB を含めることができ、それぞれに約 125 kB のコールデータを含めることができます。 両方のリソースには個別の価格があり、EIP-1559 と同様の個別の価格メカニズムによって調整され、ブロックあたり平均 1,500 万ガスと 3 つのブロブを使用することを目標としています。

その結果、ロールアップのコストは 100 倍に低下し、ロールアップの出来高は 3 倍以上増加し、理論上の最大ブロック サイズは約 1.9 MB から約 2.6 MB にわずかに増加しました。

注: ロールアップ 取引手数料は、Growthepie.xyz によって提供されます。 デンクンフォークは2024年3月13日に発生し、最長の価格ブロブが導入されました。

最長ガスおよびステートレスクライアント

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

上の図は、ブロックと、そのブロックの実行によって触れられた状態の特定の部分(口座残高、コード、ストレージなど)の現在の値の証明を受け取るステートレスクライアントを示しており、これによりノードはストレージなしでブロックを検証できます。

ストレージの読み取りには、読み取りタイプに応じて 2100 から 2600 ガスのコストがかかり、ストレージの書き込みはより高価になります。 平均して、ブロックは約 1,000 回のストレージの読み取りと書き込み (ETH バランス チェック、SSTORE および SLOAD 呼び出し、コントラクト コードの読み取り、およびその他の操作を含む) を実行します。 ただし、理論上の最大値は 30,000,000/2,100=14,285 読み取りです。 ステートレス クライアントの帯域幅負荷は、その数に比例します。

現在の計画は、イーサリアムのステートツリーデザインをマークルパトリシアツリーからバークルツリーに変換することで、ステートレスクライアントをサポートすることです。 しかし、バークル木は耐量子性がなく、新しいSTARKプルーフ系には最適ではありません。 その結果、長期の人々は、バイナリマークルツリーとSTARKでステートレスクライアントをサポートすることに関心があり、Verkleを完全にスキップするか、STARKがより成熟したときにVerkleの移行から数年後にアップグレードします。

バイナリーハッシュツリーブランチに基づくSTARKプルーフには多くの利点ロングがありますが、その主な弱点は、プルーフの生成にかかる時間がロングことです:Verkleツリーは毎秒100,000以上の値を証明できますが、ハッシュベースのSTARKは通常、毎秒数千 ハッシュしか証明できず、各値にはロング ハッシュ「ブランチ」が含まれている必要があります。

BiniusやPlonky3のような高度に最適化された証明システムや、Vision-Mark-32のような独自のハッシュから現在予測されている数値を考えると、毎秒1000値の証明は可能だが、14,285値の証明は不可能という実用的な範囲にしばらくいるように思われます。 平均的なブロックは問題ありませんが、潜在的に最悪のケースのブロック(攻撃者によって公開される)ネットワークを混乱させます。

このようなケースを処理するためのデフォルトのアプローチは、価格を再設定することです:読み取りの保存コストを増やして、ブロックあたりの最大値をより安全なレベルに引き下げます。 ただし、このロングタイムを実行したため、もう一度実行すると、ロングアプリのコストが高すぎます。 より良いアプローチガスは、ストレージアクセスを個別に制限して課金し、平均使用量をブロックあたり 1,000 ストレージ アクセスに維持し、ブロックごとに上限 (2,000 など) を設定することです。

最長ガスの遍在性

検討する価値のある別のリソースは、状態サイズの増加です:イーサリアムの状態サイズを大きくする操作は、フルノードで保存する必要があります。 状態サイズの上昇は、それを制限する理論的根拠がピークではなくロングの持続的な使用のみに由来するという点で独特です。

したがって、状態のサイズを大きくする操作(たとえば、ゼロから非ゼロのSSTORE、コントラクトの作成)に別のガスディメンションを追加することは価値があるかもしれませんが、目標は異なります:特定の平均使用量で長い芯のローソクに変動価格を設定できますが、ブロックごとの制限はまったく設定しません。

これは、ロング次元ガスの強力な特性を示しています:それは私たちが各資源を別々に長い芯のローソクを尋ね、(i)理想的な平均使用量ロングはどれくらい少ないかを尋ねることを可能にします。 (ii)小ブロック ロングあたりの最大安全使用量はどれくらいですか? 各ブロックの最大値に基づいてガス価格を設定し、平均使用量を従わせる代わりに、2nの自由度で2n個のパラメータを設定し、ネットワークセキュリティの考慮事項に従って各パラメータを調整します。

2 つのリソースのセキュリティ上の考慮事項が部分的に合計される場合など、より複雑なケースは、オペレーションコードまたはリソースに一定量のロング種類のガスを消費させることで処理できます (たとえば、0 から 0 以外の SSTORE では、5,000 のステートレス クライアント 認証 ガスと 20,000 のストレージ拡張ガスが消費される可能性があります)。

トランザクションあたりの最大数 (より多くのデータまたは計算を消費するトランザクション)

x1 をデータのガスコスト、x2 を計算されたガスコストとすると、1 次元ガスシステムでは、トランザクションのガスコストを記述できます。

このシナリオでは、トランザクションのガスコストを次のように定義します。

つまり、トランザクションは、データと計算に基づいて課金されるのではなく、2 つのリソースのどちらを最も長く消費するかに基づいて課金されます。 これは、よりロングディメンション (e.g. max(…,x3∗storage_access)) をカバーするように簡単に拡張できます。

これにより、セキュリティを維持しながらスループットを向上させる方法は簡単に理解できるはずです。 理論的には、ブロック内の最大データ量は依然としてGasLIMIT / x1であり、これは1次元ガススキームとまったく同じです。 同様に、理論上の最大計算量はGasLIMIT/x2であり、これは1次元ガススキームとまったく同じです。 ただし、データと計算を消費するトランザクションのガスコストは低下します。

これはおそらく、提案されたEIP-7623で採用されたスキームであり、ブロブ数をさらに増やしながら最大ブロックサイズを縮小します。 EIP-7623の正確なメカニズムはもう少し複雑です:現在のコールデータ価格をバイトあたり16ガスに維持しますが、バイトあたり48ガスの最低価格を追加します。 トランザクションの支払い (16 * バイト + ution_Gas) と (48 * バイト) の大きい方。 その結果、EIP-7623 は、ブロック内の理論上の最大トランザクション呼び出しデータを約 1.9 MB から約 0.6 MB に削減し、最長のアプリケーションのコストを変更せずに維持します。 このアプローチの利点は、現在の1次元ガススキームと比較してほとんど変更されず、実装が非常に簡単になることです。

ただし、このアプローチには 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 です。 つまり、ブロック内のブロブの数がターゲットよりもロング場合は過剰_blobsが増加し、ブロック内のブロブの数がターゲットより少ない場合は過剰_blobs減少します。 次に、blob_basefee = exp(excess_blobs / 25.47) を設定します (exp は指数関数 exp(x)=2.71828^x の近似値です)。

つまり、超過_blobsが約 25 増加すると、ブロブの基本電荷は約 2.7 倍に増加します。 BLOB のコストが高くなりすぎると、平均使用量が下がり、_blobs超過分が減少し始め、自動的に価格が再びドロップされます。 ブロブの価格は、平均してブロックが半分になるように、つまり、各ブロックに平均3つのブロブが含まれるように常に調整されます。

ショート期的に使用量が急増した場合、各ブロックには最大ロングで 6 つの BLOB しか含めることができず、その場合、トランザクションは優先料金を増やすことで互いに競合する可能性があります。 ただし、通常の状況では、各 BLOB は BLOB_basefee と、含めるインセンティブとして少額の追加の優先料金を支払うだけです。

このガスの価格設定はイーサリアムで最も古くから存在しており、2020年にEIP-1559は非常によく似たメカニズムを導入しました。 EIP-4844では、ガスとブロブに2つの別々の変動価格を設定しました。

注:2024年5月8日にgweiで1時間の基本ガス充電。 ソース: ultrasound.money

原則として、ストレージ読み取りやその他の種類の操作に対してロング独立したフローティング料金を追加することもできますが、次のセクションで1つの問題について詳しく説明します。

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

ブロックビルダーは、最も長い時間、最善の戦略は今日と同じです:機能するものは何でも含めます。 最も長いブロックは満杯ではありません-ガスまたはブロブ。 困難な状況は、ブロック制限を超えるのに十分なガスまたは十分なブロブがある場合、ビルダーは利益を最大化するために最長のナップザック問題を潜在的に解決する必要があることです。 ただし、かなり優れた近似アルゴリズムがあったとしても、この場合、独自のアルゴリズムを定式化して利益を最適化することによる利益は、MEVで同じことを行うことによる利益よりもロング小さくなります。

開発者にとっての主な課題は、EVM とその関連インフラストラクチャの機能を再設計する必要があることです。これらは現在、単一の価格と単一の制限に基づいて設計されており、最長の価格と最長の制限に対応するために後付けする必要があります。

アプリケーション開発者が直面する問題の1つは、最適化が少し難しくなることです:場合によっては、Aがよりロングなcalldataを使用し、Bがよりロング実行を使用する場合、calldataが安価な場合、calldataが高価な場合、より高価であるため、AがBよりも効率的であると明示的にロング言えないことがあります。

アプリ開発者が直面する問題の1つは、最適化が少し難しくなることです:Aがよりロングなcalldataを使用し、Bがよりロングな実行を使用する場合、CallDataが安い場合はAが安くなり、calldataが高い場合はAがより高価になる可能性があるため、AがBよりも効率的であると決定的に言えない場合があります。

ただし、開発者は、ロング期間の過去の平均価格に基づいて最適化することで、かなり良い結果を得ることができます。

最長価格、EVM、サブコール

blob には現れない問題があり、EIP-7623 にも、calldata の ロング 芯 ろうそくの最長料金の実装にも現れませんが、状態アクセスやその他のリソースに個別に価格を設定しようとすると、サブ呼び出しのガスリミットという問題が発生します。

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

注: あるアカウントが別のアカウントを呼び出し、限られた量のガスのみが呼び出し先に提供され、呼び出し先が割り当てられたすべてのガスを消費した場合でも外部呼び出しが引き続き実行されることを保証する、アカウントの抽象化トランザクションのトレース。

課題は、異なるタイプの実行間で最長のガスを取得するには、各タイプのガスに最長の制限値を提供するサブコールが必要であり、EVMに非常に大幅な変更が必要であり、既存のアプリケーションと互換性がないことです。

これが、最長のガス提案が通常、データと実行の2次元にとどまる理由の1つです。 データは、トランザクション・コールデータかBLOBかにかかわらず、EVMの外部にのみ分散されるため、コールデータまたはBLOBの価格を個別に設定するために、EVM内で何も変更する必要はありません。

この問題を解決するための「EIP-7623スタイルのソリューション」を考え出すことができます。 これは単純な実装で、実行中、ストレージ操作には料金の 4 倍が課金されます。 分析を簡略化するために、貯蔵操作ごとに 10,000 個のガスがあると仮定します。 トランザクションの終了時に、min(7500 * storage_operations, ution_Gas) が払い戻されます。 その結果、払い戻しを差し引いた後、ユーザーは次の料金を支払う必要があります。

ution_Gas + 10000 * ストレージ_operations - min(7500 * storage_operations, ution_Gas)

これは、次のようになります。

max(ution_Gas + 2500 * ストレージ_operations, 10000 * ストレージ_operations)

これは EIP-7623 の構造を反映しています。 もう 1 つのアプローチは、ストレージ_operationsと ution_Gas をリアルタイムで追跡し、ポンプ ロング時の最大値 (ution_Gas + 2500 * storage_operations, 10000 * storage_operations) に応じて 2500 または 10000 を少なく課金することです。 オペレーションコードが呼び出されます。 これにより、トランザクションがガスを過剰に割り当てる必要がなくなり、ほとんどの場合、払い戻しによって回収されます。

サブコールのきめ細かなライセンスはありません:サブコールは、安価なストレージ操作のためにトランザクションの許容量をすべて消費する可能性があります。

しかし、サブコールを行うコントラクトが制限を設定し、サブコールが実行されると、メインコールに必要な後処理に十分なガスがあることを確認できるほど、十分な結果が得られます。

私が考えることができる最も単純な「完全な最長価格設定ソリューション」はこれです:サブコールガスリミットを比例として扱います。 つまり、千の異なる実行タイプがあり、各トランザクションが最長制限L1で設定されているとします… Lk。 現在の実行ポイントで、残りのガスがg1であるとします… Gk。 CALL オペレーションコードを呼び出し、サブ呼び出し Gas を使用して S を制限するとします。 s1=S、s2=s1/g1∗g2、s3=s1/g1∗g3 などとします。

つまり、最初の種類のガス (実際には VM の実行) を特別な “アカウント ユニット” として扱い、サブ呼び出しが各種類のガスで使用可能なガスの同じ割合を取得するように、他の種類のガスを割り当てます。 このアプローチは少し見苦しく、下位互換性を最大化します。

下位互換性を犠牲にすることなく、異なるタイプのガス間でスキームをより「中立」にしたい場合は、子呼び出しのガスリミットパラメータを現在のコンテキストの残りのガスの一部として表すだけです(たとえば、[1…63]/64)。

ただし、いずれの場合も、最長の実行ガスを導入し始めると、固有の複雑さ(醜さ)が増し、避けるのが難しいように思われることを強調する価値があります。

したがって、私たちのタスクは、複雑なトレードオフを行うことです:L1のスケーラビリティを大幅に向上させるために、EVMレベルである程度の醜さの増加を受け入れるかどうか、もしそうなら、プロトコルの経済性とアプリケーション開発者にとって最も効果的な特定の提案はどれですか? おそらく、上記の2つの選択肢はどちらも最善ではありませんが、よりエレガントでより良い解決策を考え出すための短編はまだあります。

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