原作者： @Web3マリオ
はじめに: Vitalik は、2024 年 5 月 13 日に EIP-7706 提案をリリースしました。これは、既存のガス モデルを補足し、通話データのガス計算を個別に分離し、Blob ガスと同様の基本料金価格設定メカニズムをカスタマイズして、L2 運用コストをさらに削減することを提案しています。関連する提案は 2022 年 2 月に提案された EIP-4844 まで遡る必要があり、かなり前のことです。そのため、関連情報を参照した上で、誰もがすぐに理解できるように最新のイーサリアム ガスのメカニズムの概要を作成したいと考えています。それ。
現在サポートされているイーサリアム ガス モデル - EIP-1559 および EIP-4844
初期の設計では、イーサリアムは取引手数料の価格設定に単純なオークションメカニズムを使用していました。これには、ユーザーが自分の取引に積極的に入札する必要がありました。つまり、通常、ユーザーが支払った取引手数料はマイナーに帰属します。したがって、マイナーは経済最適化の原則に基づいて入札価格に基づいてトランザクションのパッケージ化の順序を決定しますが、これは MEV を無視していることに注意してください。当時のコア開発者によると、このメカニズムには次の 4 つの問題があったとのことです。
トランザクション手数料レベルの変動性とトランザクションのコンセンサスコストの間の不一致: アクティブなブロックチェーンの場合、トランザクションのパッケージングに対する十分な需要があり、これはブロックを簡単に埋めることができることを意味しますが、これは多くの場合、全体のコストの変動性が高いことも意味します。たとえば、平均ガス価格が 10 Gwei の場合、ブロック内の別のトランザクションを受け入れることによってネットワークが負担する限界コストは、平均ガス価格が 1 Gwei の場合よりも 10 倍高くなり、これは許容できません。
ユーザーにとって不必要な遅延: 各ブロックのハード ガス制限と過去のトランザクション量の自然な変動により、トランザクションは通常、パッケージ化されるまでに数ブロック待機しますが、これはネットワーク全体に悪影響を及ぼします。ブロックごとの需要の違いを満たすために、あるブロックを大きくし、次のブロックを小さくする「緩和」メカニズムはありません。
非効率な価格設定：単純なオークション機構を使用しているため、適正価格発見の効率が低く、ユーザーが適正な価格を提示することが困難であり、多くの場合、ユーザーは高額な料金を支払うことになります。
ブロック報酬のないブロックチェーンは不安定になります。マイニングによってもたらされるブロック報酬が排除され、純粋な手数料モデルが採用されると、マイニングに取引手数料を盗むよう促す「姉妹ブロック」など、多くの不安定性が生じる可能性があります。より強力な利己的マイニング攻撃ベクトルなど。
EIP-1559 が提案され実装されるまで、Gas モデルは 2019 年 4 月 13 日に Vitalik などのコア開発者によって最初のイテレーションが行われ、2021 年 8 月 5 日にロンドンのアップグレードで採用されました。このメカニズムはオークションメカニズムを放棄し、代わりに基本料金と優先料金の二重価格モデルを採用します。このモデルでは、基本料金は親ブロックで生成されたガス消費量と変動および再帰的なガス目標に基づいて計算されます。確立された数学的モデルにより、前のブロックでのガス使用量が所定のガス目標を超えた場合、基本料金が増額され、それがガス目標を下回った場合、基本料金が減額されます。基本料金の計算はシステムによって自由に指定されるのではなく、システムによって直接決定されるため、需要と供給の関係をより適切に反映し、合理的なガスの予測をより正確にし、誤操作によるガス価格の高騰を防ぐことができます。ユーザー。具体的なコードは次のとおりです。
parent_gas_used がparent_gas_targetよりも大きい場合、現在のブロックの基本料金は、前のブロックの基本料金にオフセット値を加えたものと比較されることがわかります。オフセット値については、parent_base_feeに総ガスコストを乗算します。前のブロック ガス ターゲットに対するオフセット、およびガス ターゲットと定数の間の係数 1 の最大値。逆に、ロジックは似ています。
さらに、基本料金は報酬としてマイナーに分配されなくなり、直接破棄されるため、ETH の経済モデルはデフレ状態となり、価値の安定につながります。一方、優先料金はユーザーがマイナーに与える報酬に相当し、自由に価格を設定できるため、マイナーのソートアルゴリズムをある程度再利用できます。
2021 年に時間が進むにつれて、Rollup の開発は徐々に良い状況に入るでしょう。OP Rollup または ZK Rollup のいずれであっても、データを実現するには、L2 データの圧縮後の特定の証明データを calldata を通じてチェーンにアップロードする必要があることがわかります。可用性 (データが利用可能)、または検証のためにチェーンに直接送信されます。このため、これらのロールアップ ソリューションは L2 ファイナリティを維持する際に多額のガス コストに直面することになり、これらのコストは最終的にユーザーに転嫁されることになるため、当時のほとんどの L2 プロトコルの使用コストは想像されていたほど低くありませんでした。
同時に、イーサリアムはブロックスペースの競争というジレンマにも直面しています。これは、現在のブロック内のすべてのトランザクションの合計ガス消費量がこの値を超えることができないことを意味します。ガス制限は 30000000 として計算されます。理論的には、30,000,000 / 16 = 1,875,000 バイトの制限があります。ここで、16 は、EVM が各 calldata バイトを処理するために 16 ユニットの Gas を消費するという事実を指します。つまり、1 つのブロックが保持できる最大データ サイズは約 1.79 MB です。 L2 シーケンサーによって生成されるロールアップ関連データは通常サイズが大きいため、他のメイン チェーン ユーザーのトランザクション確認と競合し、その結果 1 つのブロックにパッケージ化できるトランザクション量が小さくなり、TPS に影響を与えます。メインチェーンの。
このジレンマを解決するために、コア開発者は 2022 年 2 月 5 日に EIP-4844 提案を提案し、2024 年第 2 四半期初めの Dencun アップグレード後に実装されました。この提案では、Blob トランザクションと呼ばれる新しいトランザクション タイプを提案しています。従来のタイプのトランザクションと比較して、Blob トランザクションの中心となるアイデアは、新しいデータ タイプ、つまり Blob データを追加することです。 calldata 型とは異なり、BLOB データは EVM から直接アクセスできませんが、そのハッシュ (VersionedHash とも呼ばれます) にのみアクセスできます。さらに、通常のトランザクションに比べて BLOB トランザクションの GC サイクルが短く、ブロック データが肥大化しないようにするための設計が 2 つあります。もう 1 つは、BLOB データがネイティブの Gas メカニズムを備えていることです。一般的に言えば、提示される効果は EIP-1559 と同様ですが、自然指数関数の傾きはこれは、現時点でのネットワーク トランザクションの規模がどのような状態であるかに関係なく、トランザクションの規模が急速に上昇すると、ブロブ ガスの基本料金がより完全に応答し、それによってトランザクション アクティビティが効果的に抑制されることを意味します。この関数には、横軸が 0 の場合、関数の値は 1 になるという重要な特徴もあります。
blob_gas あたりのbase_fee_gas = MIN_BASE_FEE_PER_BLOB_GAS * e**(超過blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)
このうち、MIN_BASE_FEE_PER_BLOB_GAS と BLOB_BASE_FEE_UPDATE_FRACTION は 2 つの定数で、excess_blob_gas は親ブロック内の総ブロブ ガス消費量と TARGET_BLOB_GAS_PER_BLOCK 定数の差によって決定され、総ブロブ ガス消費量が目標値を超えた場合、つまり差分が正になります。 . e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) が 1 より大きい場合、base_fee_per_blob_gas は大きくなり、それ以外の場合は小さくなります。
このようにして、イーサリアムのコンセンサス機能のみを使用して特定の大規模データを認証し、可用性を確保したい一部のシナリオは、ブロックのトランザクション パッケージ化機能をクラウドアウトすることなく、低コストで実行できます。ロールアップ シーケンサーを例にとると、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
イーサリアムの現在のGasモデルを明らかにした後、EIP-7706提案の目標と実装の詳細を見てみましょう。この提案は、2024 年 5 月 13 日に Vitalik によって提出されました。 Blob データと同様に、この提案では、特殊な特性を持つ別のデータ フィールド (calldata) に対応するガス モデルが削除されます。また、対応するコードの実装ロジックを最適化しました。
原則として、calldata の基本料金計算ロジックは、EIP-4844 の BLOB データの基本料金と同じであり、どちらも指数関数を使用し、親ブロック内の実際のガス消費量間の偏差に基づいて現在の基本料金を計算します。そして目標値。
新しいパラメーター設計 LIMIT_TARGET_RATIOS=[ 2, 2, 4 ] に注目してください。ここで、 LIMIT_TARGET_RATIOS[ 0 ] は、Gas オペレーション クラスのターゲット比率を表し、 LIMIT_TARGET_RATIOS[ 1 ] は、Blob データ クラス Gas、LIMIT_TARGET_RATIOS のターゲット比率を表します。 [ 2 ] は calldata クラス Gas のターゲット比率を表します。このベクトルは、親ブロック内の 3 種類のガスに対応するガスターゲット値を計算するために使用されます。計算ロジックは次のとおりです。つまり、LIMIT_TARGET_RATIOS を使用して整数除算を実行します。ガス制限に関する操作:
Gas_limits の設定ロジックは次のとおりです。
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 ガス目標が約 30000000 // 4 // 4 = 1875000 であることを意味します。また、現在の calldata ガス計算ロジックにより、それぞれ非ゼロ バイトは 16 ガスを消費し、ゼロ バイトは 4 ガスを消費します。呼び出しデータの特定のセグメントにおける非ゼロ バイトとゼロ バイトの分布がそれぞれ 50% を占めると仮定すると、1 バイトの処理には平均して 10 ガスが必要になります。通話データ。したがって、現在の calldata ガス目標は、現在の平均使用量の約 2 倍である 187500 バイトの calldata データに相当する必要があります。
この利点は、通話データがガス制限に達する可能性を大幅に低減し、経済モデルを通じて通話データの使用をより一貫した状態に維持し、通話データの悪用も排除できることです。この設計の理由は、L2 の開発に道を開くためであり、ブロブ データを使用すると、ソーターのコストをさらに削減できます。
