紹介：2024年5月13日、VitalikはEIP-7706を提案しました。この提案は、既存のガスモデルを補完し、calldataのガス計算を別々に削除し、Blob gasに類似したベース料金設定メカニズムをカスタマイズして、レイヤー2の運用コストをさらに削減します。関連提案には、2022年2月に提案されたEIP-4844にさかのぼる必要があります。それは長い時間が経っています。したがって、関連資料を確認し、最新のEthereum Gasメカニズムの概要を提供し、皆さんの迅速な理解を促進したいと考えています。

現在サポートされているイーサリアムガスモデル - EIP-1559およびEIP-4844

初期設計では、Ethereumは取引手数料を価格設定するために簡単なオークションメカニズムを採用し、ユーザーに取引を積極的に入札させること、つまりガス価格を設定させることを要求しました。一般的に、ユーザーが支払う取引手数料はマイナーに支払われるため、マイナーは経済的最適性の原則に基づいて取引のパッケージング順序を決定し、入札価格に従って、MEVの状況を無視します。当時のコア開発者の見解では、このメカニズムは4つの問題に直面していました。

トランザクション手数料レベルの変動は、トランザクションの合意コストに一致しません：アクティブな状態のブロックチェーンでは、トランザクションのパッケージングに十分な需要があり、これはブロックを簡単に埋めることができますが、これはしばしば全体の手数料の大幅な変動につながります。例えば、平均Gas Priceが10 Gweiの場合、ブロック内の別のトランザクションを受け入れるための限界コストは、平均Gas Priceが1 Gweiの場合よりも10倍高くなります。このような状況は受け入れられません。

ユーザーにとって不要な遅延：各ブロックのガスリミットのハードリミットと、履歴的な取引量の自然な変動との組み合わせにより、取引はしばしば数ブロック待機する必要があり、全体的なネットワークにとって非効率です。ブロックごとに大きさが異なることでブロック間の需要の違いを満たすために、1つのブロックを大きくし、次のブロックを小さくする「緩和」メカニズムはありません。

非効率な価格設定：単純なオークションメカニズムの採用により、公正な価格決定の効率が低下し、ユーザーが合理的な価格を提示することが困難であり、ユーザーが過剰な手数料を支払うケースが多いことを意味します。

ブロック報酬なしのブロックチェーンは不安定になる可能性があります。マイニングによってもたらされるブロック報酬を取り消し、純粋な手数料モデルを採用すると、マイニングの「姉妹ブロック」に対する報酬が増え、より強力な自己中心的なマイニング攻撃経路が開かれるなど、多くの不安定要素が生じる可能性があります。

EIP-1559の提案と実装まで、ガスモデルの最初のイテレーションがありました。EIP-1559は、2019年4月13日にVitalikと他の主要な開発者によって提案され、2021年8月5日のロンドンアップグレードで採用されました。このメカニズムは、オークションメカニズムを放棄し、代わりにベース料金と優先料金のデュアルプライシングモデルを採用しています。ベース料金は、親ブロックでのガス消費と浮動および再帰的なガスターゲットの関係に基づいて定量的に計算されます。これは、前のブロックでのガス使用量が予め定められたガスターゲットを超えると、ベース料金が増加し、それ以下の場合は、ベース料金が減少する直感的な効果があります。これにより、需要と供給をよりよく反映し、適切なガスの予測をより正確に行うことができ、ユーザーによって自由に指定されるのではなく、ベース料金の計算が直接システムによって決定されるため、誤操作による法外なガス料金を防ぐことができます。具体的なコードは以下の通りです:

parent_gas_used が parent_gas_target より大きい場合、現在のブロックのベース料金が前のブロックのベース料金にオフセット値を加算したものと比較されます。オフセット値は、前のブロックの総ガス使用量のオフセットに parent_base_fee を乗じてガスターゲットと定数で剰余を取り、その結果と 1 の最大値を取ることで計算されます。このロジックは逆にも同様です。

さらに、ベース料金はもはやマイナーに報酬として割り当てられるのではなく、直接燃やされるようになりました。これにより、イーサリアムの経済モデルは収縮的な状態になり、価値の安定に貢献しています。一方、優先料金は、ユーザーからマイナーへのチップのようなものであり、自由に価格設定されることができます。これにより、ある程度、マイナーのシーケンスアルゴリズムが再利用される可能性があります。

2021年に入ると、ロールアップの開発は徐々にピークに達しました。OPロールアップであろうとZKロールアップであろうと、L2データの圧縮されたある証拠データをチェーンに calldata 経由でアップロードする必要があることはチェーン上でデータの可用性を達成するためであり、または直接チェーン上で検証される必要があることを意味します。これにより、L2 の最終的な確定性を維持するために著しいガスコストが発生し、最終的にユーザーに転嫁されます。したがって、ほとんどの L2 プロトコルを使用するコストは当時想像されていたほど低くはなかったのです。

同時に、イーサリアムはブロックスペース競争のジレンマに直面しています。各ブロックにはガスリミットがあり、現在のブロック内のすべてのトランザクションのガス消費量がこの値を超えてはなりません。現在のGas Limitが30,000,000であることを基に計算すると、理論上、1,875,000バイトの制限があります。ここで16はEVMによって処理されるcalldataバイトごとに消費されるガスを示します。これは、単一のブロックに収容できる最大データサイズが約1.79 MBであることを意味します。しかし、L2シーケンサーによって生成されるRollup関連のデータは通常、より大きなデータサイズを持ち、他のメインチェーンユーザーによるトランザクションの確認と競合し、単一のブロックにパックされることができるトランザクション数を減らし、それによってメインチェーンのTPSに影響を与えています。

このジレンマに対処するために、コア開発者は2022年2月5日にEIP-4844を提案し、2024年第2四半期のデンクンアップグレード後に実装されました。この提案では、BLOB トランザクションと呼ばれる新しいトランザクションの種類が導入されています。従来のトランザクション型とは対照的に、BLOB トランザクションの中心的な考え方は、新しいデータ型、つまり BLOB データを補完するものです。calldataタイプとは異なり、BLOBデータはEVMから直接アクセスすることはできませんが、そのハッシュ(VersionedHashとも呼ばれます)にのみアクセスできます。さらに、2つの付随するデザインが紹介されています。まず、通常のトランザクションと比較して、BLOBトランザクションのGCサイクルが短く、ブロックデータが肥大化しすぎないようにします。第 2 に、BLOB データにはネイティブの Gas メカニズムがあります。全体として、提示された効果はEIP-1559と似ていますが、数学的モデルは自然な指数関数を選択し、トランザクション量の変動を処理する際の安定性が向上します。これは、自然指数関数の傾きが自然指数関数でもあるため、ネットワークの取引量の状態に関係なく、取引量が急激に増加すると、ブロブガスの基本料金がより完全に反映され、取引活動を効果的に抑制するためです。さらに、この関数には、横軸が 0 のときに関数値が 1 になるという重要な特性があります。

base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS e*(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)

MIN_BASE_FEE_PER_BLOB_GAS および BLOB_BASE_FEE_UPDATE_FRACTION は 2 つの定数であり、excess_blob_gas は、親ブロックの総 blob ガス消費量と定数 TARGET_BLOB_GAS_PER_BLOCK の差によって決定されます。 総 blob ガス消費量が目標値を超える場合、すなわち、差が正である場合、e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) は 1 より大きくなり、base_fee_per_blob_gas が増加します。 それ以外の場合は減少します。

これにより、イーサリアムのコンセンサス機能のみが必要で、大規模データの可用性を確保するためにブロックのトランザクションパッキング能力を独占せずに、低コストで実行できるシナリオが可能になります。Rollupシーケンサーを例に取ると、L2の重要情報はブロブトランザクションを通じてブロブデータにカプセル化され、オンチェーン検証のためのロジックは、versionedHashを使用した洗練されたデザインを通じてEVMで実装できます。

TARGET_BLOB_GAS_PER_BLOCKおよびMAX_BLOB_GAS_PER_BLOCKの現在の設定により、メインネットには、1ブロックあたり平均3つのブロブ（0.375 MB）を処理する目標と、1ブロックあたり最大6つのブロブ（0.75 MB）の制限が設定されていることに注意する必要があります。これらの初期制限は、EIPがネットワークに与える圧力を最小限に抑えることを目的としており、将来のアップグレードではネットワークがより大きなブロックでも信頼性を示すために増加することが期待されています。

実行環境のガス消費モデルの改良 - EIP-7706

イーサリアムの現在のGasモデルを明確にした後、EIP-7706提案の目標と実装の詳細を見てみましょう。この提案は2024年5月13日にVitalikによって導入されました。Blobデータに似て、この提案は別の特別なデータフィールド、すなわちcalldataのGasモデルを分離し、対応するコード実装ロジックを最適化します。

基本的に、calldataのベース料金計算ロジックは、EIP-4844のblobデータのベース料金と同じであり、両者とも親ブロック内の実際のガス消費値と目標値の偏差に基づいて現在のベース料金のスケーリングファクターを計算するために指数関数を使用しています。

新しいパラメータデザイン、LIMIT_TARGET_RATIOS=[2,2,4]に注目する価値があります。LIMIT_TARGET_RATIOS[0]は実行操作のガスのターゲット比率を表し、LIMIT_TARGET_RATIOS[1]はBlobデータのガスのターゲット比率を表し、LIMIT_TARGET_RATIOS[2]はcalldataのガスのターゲット比率を表します。このベクトルは、親ブロック内の3種類のガスのためのガスターゲット値を計算するために使用され、ガスリミットで整数除算を行うためにLIMIT_TARGET_RATIOSを使用します。

ガス制限の設定ロジックは次のとおりです:

gas_limits[0]は既存の調整式に従う必要があります。

gas_limits[1]はMAX_BLOB_GAS_PER_BLOCKに等しくなければなりません。

gas_limits[2]はgas_limits[0]と等しくなければなりません // CALLDATA_GAS_LIMIT_RATIO.

現在のgas_limits[0]が30000000であること、CALLDATA_GAS_LIMIT_RATIOが4に設定されていることを知っています。これは、現在のcalldata gasターゲットが約30000000 // 4 // 4 = 1875000であることを意味します。したがって、現在のcalldata gasの計算ロジックによると、各非ゼロバイトは16 Gasを消費し、ゼロバイトは4 Gasを消費します。calldataのセグメント内の非ゼロバイトとゼロバイトの分布が50%と仮定した場合、1バイトのcalldataの平均処理には10 Gasが必要です。したがって、現在のcalldata gasターゲットは、calldataデータが187500バイトに対応するはずであり、現在の平均使用量の約2倍です。

このアプローチの利点は、カルデータがガスリミットに達する可能性を大幅に減らし、経済モデルを通じてカルデータの使用量を比較的一定のレベルに保ち、カルデータの濫用を防ぐことです。この設計の理由は、L2の開発のための道筋をつけ、ブロブデータと組み合わせて、シーケンサーのコストをさらに削減することです。

免責事項：

1. この記事は[から転載されていますTechFlow]. すべての著作権は元の著者に帰属します [Web3Mario]. If there are objections to this reprint, please contact the Gate Learnチームがすぐに対応します。
2. 責任の免責事項：この記事で表現されている意見や見解は、著者個人のものであり、いかなる投資アドバイスも構成しません。
3. 他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に断りがない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。