EIP-7706の詳細と最新のイーサリアムガスの仕組みを整理する

原作者: @Web3 Mario

はじめに:2024年5月13日、ヴィタリックはEIP-7706提案を発表し、既存のガスモデルを補完するソリューションを提案し、コールデータのガス計算を分離し、ブロブガスに似た基本料金価格メカニズムをカスタマイズして、L2のランニングコストをさらにドロップしました。 また、関連する提案は、ロングタイム前の2022年2月に提案されたEIP-4844にまでさかのぼる必要があるため、関連資料をチェックして、最新のイーサリアムガスの仕組みの概要を説明し、すぐに理解できるようにしてください。

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

元の設計では、イーサリアムは単純なオークションメカニズムを使用して取引手数料の価格設定を行いますが、これはユーザーが自分の取引に積極的に入札する、つまりガス価格を設定する必要があります、通常、ユーザーが支払う取引手数料はマイナーよりも権利確定されるため、マイナーは入札レベルに応じて経済的最適性の原則に従ってトランザクションパッケージの注文を決定します、これはMEVを無視する場合であることに注意してください。 当時のコア開発者の目には、このメカニズムは次の4つの問題に直面していました。

*取引手数料のレベルと取引のコンセンサスコストの変動:アクティブなブロックチェーンでは、トランザクションパッケージングに対する十分な需要があり、ブロックを簡単に埋めることができますが、これは多くの場合、全体的な手数料の変動が非常に大きいことも意味します。 たとえば、平均ガス価格が10Gweiの場合、ブロックでもう1つのトランザクションを受け入れるためのネットワークの限界費用は、平均ガス価格の1Gweiの10倍であり、これは許容できません。 *ユーザーにとって不要なレイテンシー:各ブロックのハードガスリミットと過去の出来高の自然な変動により、トランザクションは通常、いくつかのブロックがパッケージ化されるのを待ちますが、これはネットワーク全体にとって非効率的です。 つまり、ケースバイケースでブロックのニーズの違いを満たすために、1つのブロックを大きくし、次のブロックを小さくする「スラック」メカニズムはありません。 *非効率的な価格設定:単純なオークションメカニズムの使用は、非効率的な公正な価格発見につながり、ユーザーが合理的な価格を提供することが困難になることを意味し、非常にロングの場合、ユーザーは高い料金を支払うことを意味します。 *ブロック報酬フリーブロックチェーンが不安定になる:マイニングがもたらすブロック報酬が取り除かれ、純粋な料金モデルが採用されると、「姉妹ブロック」を盗むマイニング取引手数料インセンティブを与えたり、より強力な利己的マイニング 攻撃ベクトルを開いたりするなど、非常にロング不安定になる可能性があります。

EIP-1559が提案され、実装されるまで、2019年4月13日にVitalikなどのコア開発者によって提案され、2021年8月5日のロンドンのアップグレードで採用されたガスモデルの最初の反復があり、オークションメカニズムを放棄して、基本料金が親ブロックですでに生成されたガスに基づいて基本料金と優先料金の二重価格設定モデルを採用しました 消費量と浮遊および再帰的なガス目標との関係は、確立された数学的モデルによって定量的に計算され、直感的な効果は、前のブロックでのガスの使用量が所定のガス目標を超えると基本料金が増加し、ガス目標を下回ると基本料金が引き下げられ、需要と供給の関係をよりよく反映できるだけでなく、合理的なガスの予測をより正確にすることができます。 基本料金の計算はユーザーが自由に指定するのではなく、システムによって直接決定されるため、誤操作によるガス価格の高騰はありません。 具体的なコードは次のとおりです。

parent\ガス_used が parent_ガス_target より大きい場合、現在のブロックの基本料金は、前のブロックの基本料金にオフセット値を加えたものと比較され、オフセット値は、親_base_feeに、ターゲットに対する前のブロック ガスの合計使用量のオフセットを掛けたものガス、ターゲットと定数を含む残りの 1 の最大値を掛けたものと見なされガス。 逆のロジックも同様です。

さらに、基本手数料は報酬としてマイナーにロング分配されるのではなく、直接燃やされるため、ETHの経済モデルはデフレ状態になり、価値の安定に役立ちます。 一方、プライオリティフィーはユーザーのマイナーへのチップと同等で、価格は自由に設定できるため、マイナーのソートアルゴリズムをある程度再利用することができます。

ロールアップの開発が徐々により良い状態に入る2021年に向けて時間が進むにつれて、OPロールアップとZKロールアップの両方が、L2データの圧縮後のプルーフデータをコールデータを介してオンチェーンにアップロードしてデータの可用性を実現するか、検証のためにオンチェーンに直接渡す必要があることを知っています。 その結果、これらのロールアップ ソリューションは、L2 ファイナリティを維持するときに多額のガス コストに直面し、これらのコストは最終的にユーザーに転嫁されるため、ほとんどの L2 プロトコルの使用コストは想像ほど低くありません。

同時に、イーサリアムブロック ショート間の競争のジレンマにも直面しており、各ブロックにはガスリミットがあることがわかっているので、現在のブロックのすべてのトランザクションのガス消費量の合計は、現在のガスリミット300000000に基づいてこの値を超えることはできません、理論上の制限は30, 000, 000 / 16 = 1, 875, 000バイトで、16はEVMによって処理されたcalldataバイトあたり16の消費量を指します つまり、1 つのブロックでデータを伝送できる最大ロングは約 1.79 MB です。 L2シーケンサーによって生成されるロールアップ関連のデータは通常大規模であるため、他のメインチェーンユーザーのトランザクション確認と競合するため、1つのブロックにパックできる出来高が小さくなり、メインチェーンのTPSに影響を与えます。

このジレンマに対処するために、コア開発者は2022年2月5日にEIP-4844を提案し、2024年第2四半期の初めにデンクンのアップグレード後に実装されました。 この提案では、従来のトランザクション型と比較して、新しいデータ型である BLOB データに基づく BLOB トランザクションと呼ばれる新しいタイプのトランザクションを提案しています。 calldata タイプとは異なり、EVM は BLOB データに直接アクセスできず、ハッシュ (VersionedHash とも呼ばれる) にのみアクセスします。 さらに、2つの付随する設計があり、1つは通常のトランザクションと比較して、ブロックデータが肥大化しすぎないようにするためにBLOBトランザクションのGC期間が短くなることであり、もう1つは、BLOBデータがネイティブガスメカニズムを持っていることであり、これは一般的にEIP-1559と同様の効果を示しますが、数学モデルで自然な指数関数を選択し、自然な指数関数の傾きも自然な指数関数であるため、トランザクションサイズの変動を処理する際の安定性が向上します。 これは、この時点でネットワークトランザクションサイズがどのような状態であっても、トランザクションサイズが急激に急増すると、ブロブガスの基本料金がより完全に応答し、それによってトランザクションアクティビティを効果的に抑制し、関数にも重要な機能があり、横軸が0の場合、関数値は1です。

ベース_fee_per_blob_ガス = MIN_BASE_FEE_PER_BLOB_GAS * e**(過剰_blob_ガス / BLOB_BASE_FEE_UPDATE_FRACTION)

ここで、MIN_BASE_FEE_PER_BLOB_GAS と BLOB_BASE_FEE_UPDATE_FRACTION は 2 つの定数ですが、超過_blob_ガス は、親ブロック ガス内の BLOB の合計数と TARGET_BLOB_GAS_PER_BLOCK 定数の差によって決定されガス 消費量が目標値を超える場合、つまり差が正の場合、e**(excess_blob_ガス / BLOB_BASE_FEE_UPDATE_FRACTION) が 1 より大きい場合、base_fee_per_blob_ガス は大きくなり、その逆も同様です。

このように、可用性を確保するために大規模なデータを格納するイーサリアムのコンセンサス機能のみを使用したい一部のシナリオでは、ブロックのトランザクションパッケージ容量を混雑させることなく低コストで実行できます。 ロールアップ・シーケンサを例にとると、L2 の鍵となる情報を BLOB トランザクションを通じて BLOB データにカプセル化し、EVM の巧妙な設計により versionedHash を使用してオンチェーン検証のロジックを実装できます。

現在の TARGET_BLOB_GAS_PER_BLOCK と MAX_BLOB_GAS_PER_BLOCK の設定メインネットでは、ブロックあたり 3 つの BLOB (0.375 MB)、ロングあたり最大 6 つの BLOB (0.75 MB) の制限が導入されています。 これらの初期制限は、この EIP によるネットワークへの負担を最小限に抑えるように設計されており、ネットワークがより大きなブロックで信頼性を示すにつれて、将来のアップグレードで増加すると予想されます。

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

現在のイーサリアム ガスモデルが明確になったところで、EIP-7706提案の目標と実装の詳細を見てみましょう。 この提案は、2024 年 5 月 13 日に Vitalik によって提示されました。 ブロブデータと同様に、この提案では、別の特別なデータフィールドであるcalldataのガスモデルを取り除きます。 また、対応するコード実装ロジックが最適化されています。

原則として、コールデータの基本料金の計算ロジックは、指数関数を使用し、親ブロックの実際のガス消費量の目標値からの偏差値に基づいて現在の基本料金のスケーリングを計算するEIP-4844のBLOBデータの基本料金と同じです。

ここで、LIMIT_TARGET_RATIOS[ 0 ] は操作クラス Gas のターゲット比率、LIMIT_TARGET_RATIOS[ 1 ] は BLOB データ クラス Gas のターゲット比率、LIMIT_TARGET_RATIOS [ 2 ] は呼び出しデータを表す、新しいパラメーター設計 LIMIT_TARGET_RATIOS=[ 2, 2, 4 ] は注目に値します クラスGasのターゲット比は、このベクトルを使用して、親ブロックのガスの3つのクラスに対応するガスターゲット値を計算し、計算ロジック_RATIOS_TARGETガスリミットは次のとおりです。

ガス_limits のロジックは次のとおりです。

ガス_limits[ 0 ] は既存の調整式に従わなければなりません

ガス_limits[ 1 ] は MAX_BLOB_GAS_PER\ と等しくなければなりません_BLOCK

ガス_limits[ 2 ] は ガス_limits[ 0 ] と等しくなければなりません // CALLDATA_GAS_LIMIT_RATIO

現在の ガス_limits[ 0 ] は 30000000 であり、CALLDATA_GAS_LIMIT_RATIO は 4 にプリセットされており、これは現在の calldata ガスターゲットが約 300000000 // 4 // 4 = 1875000 であることを意味し、現在の calldata ガス計算ロジックによると、ゼロ以外の各バイトは 16 ガスを消費し、0 バイトは 4 ガスを消費します。 コールデータの特定のセグメント内のゼロ以外のバイトとゼロのバイトの分布がそれぞれ50%を占めると仮定すると、1バイトのコールデータを処理するには平均10ガスが必要です。 したがって、現在のコールデータ ガス ターゲットは、現在の平均使用量の約 2 倍である 187500 バイトのコールデータ データを処理する必要があります。

これの利点は、コールデータがガスリミットに到達する確率が大幅に減少し、経済モデリングによってコールデータの使用がより一貫した状態に保たれ、コールデータの悪用も排除されることです。 この設計の理由は、L2の開発に道を開くためであり、ブロブデータを使用すると、シーケンサーのコストがさらに低下します。