著者: @Web3Mario

はじめに:Vitalikは2024年5月13日にEIP-7706の提案を発表し、既存のガスモデルを補完するスキームを提案し、コールデータのガス計算を廃止し、L2のランニングコストをさらに削減するためにBlob ガスに似た基本料金の価格設定メカニズムをカスタマイズしました。 関連する提案も、ロングタイム前の2022年2月に提案されたEIP-4844にまでさかのぼる必要があるため、関連資料をチェックして、誰もがすぐに理解できるように最新のイーサリアムガスメカニズムの概要を作成してください。

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

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

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

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

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

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

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

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

このジレンマに対処するために、コア開発者は2022年2月5日にEIP-4844の提案を提出し、2024年第2四半期の初めにデンクンのアップグレード後に実装されました。 この提案では、従来のトランザクション型と比較して、新しいデータ型である BLOB データで補完される BLOB トランザクションと呼ばれる新しいトランザクション タイプが提案されています。 calldata タイプとは異なり、EVM は BLOB データに直接アクセスできず、ハッシュ (VersionedHash とも呼ばれる) にのみアクセスします。 さらに、2つの付随する設計があり、1つは通常のトランザクションと比較して、ブロブトランザクションのGC期間が短く、ブロックデータが肥大化しすぎないようにすること、もう1つはブロブデータがネイティブのガスメカニズムを持っていることであり、全体的な効果は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_ガス は、1 つの TARGET_BLOB_GAS_PER_BLOCK 定数によって消費される親ブロック ガスの合計 BLOB の差によって決定されます。 消費量ガス目標値を超える場合、つまり、差が正の場合、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=[2,2,4] (LIMIT_TARGET_RATIOS[0][1]操作ガスの目標比率を示します (LIMIT_TARGET_RATIOS[2]BLOB データ クラス Gas のターゲット比率を示します (LIMIT_TARGET_RATIOSこのベクトルは、親ブロックのガスの3つのクラスに対応するガスターゲット値を計算するために使用され、計算ロジックは、LIMIT_TARGET_RATIOSを使用して、制限を除算してガスリミットを分割します。

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

ガス_limits[0]既存の調整式に従う必要があります

ガス_limits[1]MAX_BLOB_GAS_PER_BLOCK と等しくなければなりません。

ガス_limits[2][0]ガス_limits と等しい必要があります CALLDATA_GAS_LIMIT_RATIO

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

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