EIP-7706の詳細と最新のイーサリアムのGasメカニズムの整理

by@Web3Mario

はじめに:

。Vitalikは2024年5月13日に提案書EIP-7706を発表しました。この提案書では、L2のランニングコストをさらに削減するために、calldataのガス計算を別に分離し、Blobガスのような基本料金の価格メカニズムをカスタマイズすることで、既存のガスモデルを補完するソリューションを提案しています。これに関連する提案も、2022年2月に提案されたEIP-4844まで遡る必要があり、だいぶ時間が離れているので、関連情報を確認し、最新のEthereum Gasの仕組みの概要をざっくりと理解しやすいようにできればと思います。

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

当初の設計では、イーサリアムは取引手数料の値付けに単純なオークションメカニズムを使用しており、ユーザーが積極的に取引に入札すること、つまりガス価格を設定する必要がありました。 通常、ユーザーが支払った取引手数料はマイナーに帰属するため、マイナーは入札のレベルに応じて経済最適性の原則に基づいて取引を決定します。梱包順序、これはMEVを無視していることに注意。

• 取引手数料の水準がコンセンサスに対して変動する。コンセンサスとコストの不一致：アクティブな状態にあるブロックチェーンの場合、トランザクションのパッキングに対する十分な需要があるため、ブロックは簡単に埋まりますが、これはまた、全体的な手数料が非常に不安定であることを意味することがよくあります。例えば、平均ガス価格が10Gweiのとき、ブロック内で別のトランザクションを受け入れるネットワークにとっての限界コストは、平均ガス価格が1Gweiのときよりも10倍高くなり、これは容認できない。

• ユーザーにとって不要な待ち時間:ブロックごとのガス価格のハードリミット、および過去の取引量の自然な変動により、取引は通常、パッケージ化されるまでに数ブロック待ちますが、これはネットワークにとって非効率です。つまり、ブロックごとの需要の違いに対応するために、あるブロックは大きく、次のブロックは小さくできる「スラック」メカニズムがないのです。

• 価格設定非効率：単純なオークションの使用による公正な価格発見の非効率性は、ユーザーが妥当な価格をつけるのが難しいことを意味します。

• ブロック報酬のないブロックチェーンは不安定になる：マイニングからブロック報酬を取り除き、純粋に手数料ベースのモデルを採用する場合、ブロックチェーンは不安定になります。これは、取引手数料を盗む「姉妹ブロック」のマイニングを奨励したり、利己的なマイニングにより強力な攻撃ベクトルを開くなど、多くの不安定性につながる可能性があります。

2019年4月13日にVitalik氏と他のコア開発者によって提案され、2021年8月5日のロンドンアップデートで採用されたEIP-1559の提案と実装まで、Gasモデルの最初の反復がありました。採用されたメカニズムでは、オークション・メカニズムが廃止され、基本料金（Base fee）と優先料金（Priority fee）の二重価格設定モデルが採用されました。基本料金は、親ブロックの発生ガスの消費量と、浮動的かつ再帰的なガス・ターゲットとの関係に基づく確立された数学的モデルによって定量的に計算されます。直前のブロックのガス消費量が所定のガス目標値を上回れば、基本料金は上方修正され、下回れば、基本料金は下方修正される。これは、需給関係をよりよく反映するだけでなく、適正ガスの予測をより正確にし、基本料金がシステムによって計算される一方で、基本料金がシステムによって直接決定されるため、ガス料金の誤用によるガス料金の高騰の発生を防ぐことができる。基本料金の計算は、ユーザーが指定するのではなく、システムによって直接決定されます。

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

さらに、Base feeは報酬として採掘者に分配されなくなり、破棄されるため、ETHの経済モデルは価値の安定に資するデフレ状態になります。一方、Priority feeはマイナーに対するユーザーの報酬に相当し、自由に価格を設定できるため、マイナーのソートアルゴリズムをある程度再利用できる。

2021年まで時間が進むと、ロールアップの私たちは、OP RollupとZK Rollupの両方が、L2データを圧縮し、Data Availableを達成するためにcalldataを介して特定の証明データをチェーンにアップロードするか、検証のためにチェーンに直接アップロードする必要性を示唆していることを知っています。このため、これらのロールアップ・ソリューションは、L2の最終性を維持するためのガスという点で、かなりのコストがかかります。

イーサリアムがブロックスペースの競争というジレンマに直面しているのと同時に、各ブロックにはガスの上限があり、現在のブロック内のすべてのトランザクションのガス消費量がその値を超えてはならないことが分かっています。現在のGas Limitの30,000,000に従って計算すると、理論的には30,000,000 / 16 = 1,875,000バイトの制限があります。ここで16は、EVMが各calldataバイトを処理するために16単位のGasを消費する必要があることを意味し、1つのブロックが運ぶことができるデータの最大サイズは約1.79MBであることを意味します。

このジレンマを解決するために、コア開発者は2022年2月5日にEIP-4844案を提案し、Dencunのアップグレード後の2024年第2四半期の初めに、EIP-4844案を提案しました。四半期に提案された。この提案は、Blobトランザクションと呼ばれる新しいトランザクションタイプを提案し、従来のトランザクションタイプと比較して、Blobトランザクションのコアアイデアは、新しいデータ型、すなわちBlobデータを補完することです。さらに、2つの付随する設計があります。1つは、ブロブ・トランザクションのGCサイクルが通常のトランザクションよりも短いことで、ブロック・データが過度に肥大化しないことを保証します。もう1つは、ブロブ・データがネイティブのGasメカニズムを持っていることで、これはEIP-1559のものと似ていますが、数学的モデルはEIP-1559のものとは異なります。類似しているが、数学的モデルでは、自然指数関数が選択されており、トランザクションサイズの変動に対処する際に、その安定性がより優れている。自然指数関数の傾きも自然指数関数であるため、現時点でネットワークのトランザクションサイズがどのような状態であっても、トランザクションサイズが急激に高騰している場合、ブロブガスの基本料金はトランザクション活動を抑制するためにより適切に反応する。また、この関数には重要な特徴があり、トランザクションサイズが急激に高騰している場合、ブロブデータの期間が短くなるため、ブロックデータが肥大化しすぎることがない。

ベース_フィー_パー_ブロブ_ガス = 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つの定数であり、超過分_blob_gasは以下のように決定される。blob_gasは、親ブロックの総blobガス消費量とTARGET_BLOB_GAS_PER_BLOCK定数との差によって決定され、総blobガス消費量が目標値を超えるとき、すなわち差が正のとき、e**(EXCESS_BLOB_GAS / BLOB_BASE_FEE_UPDATE_FRACTION) は1より大きい。FRACTION)が1より大きい場合、base_fee_per_blob_gasは大きくなり、その逆も同様です。

これは、イーサリアムのコンセンサス機能を活用して、ブロックのトランザクションパック機能を混雑させることなく、可用性を確保するために特定の大きなデータサイズに対してのみ入金を行いたいシナリオのための低コストの実装です。Rollupシーケンサーを例にとると、L2のキー情報はblobトランザクションを通してblobデータにカプセル化することができ、オンチェーン検証のロジックはversionedHashを使った繊細な設計によってEVMに実装することができます。

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

Refinement of the Execution Environment Gas Consumption Model - EIP-7706

実行環境の現在のガス消費モデルを明確にする上で、EIP-7706

は良いアイデアです。">現在のイーサリアムのGasモデルが明確になったところで、EIP-7706提案の目標と実装の詳細を見てみましょう。この提案はVitalik氏によって2024年5月13日に行われました。Blobデータと同様に、この提案はGasモデルからもう1つの特別なデータフィールドであるcalldataを取り除き、コードの実装ロジックを最適化します。

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

注目すべきは、新しいパラメータ設計であるLIMIT_TARGET_RATIOSです。TARGET_RATIOS=[2,2,4]、ここでLIMIT_TARGET_RATIOS[0]はExecuteオペレーションクラスGasの目標比率を示し、LIMIT_TARGET_RATIOS[1]はBlobデータクラスGasの目標比率を示し、LIMIT_TARGET_RATIOS[2]はLIMIT_TARGET_RATIOS[2]はcalldataクラスの気体の目標比率を表し、このベクトルは親ブロックの3種類の気体の対応する気体の目標値を計算するために使用され、計算ロジックは次のとおりです、すなわち、LIMIT_TARGET_RATIOSはそれぞれ気体の限界値の整数除算演算を行うために使用されます：

gas_limits設定のロジックは以下の通りです:

gas_limits[0]は、既存のgas_limits[0]に従わなければなりません。limits[0] は既存の調整式に従わなければなりません

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

gas_limits[2] はMAX_BLOB_GAS_PER_BLOCKに等しくなければなりません。LIMITS[2]はGAS_LIMITS[0] // CALLDATA_GAS_LIMIT_RATIOに等しくなければならない

現在のGAS_LIMITS[0]は30,000,000であり、CALLDATA_GAS_LIMIT現在の Calldata ガスの目標値は約 30000000 // 4 // 4 = 1875000 であり、現在の Calldata ガス計算ロジックによると、非ゼロバイトは 16 ガスを消費し、ゼロバイトは 4 ガスを消費する。ある calldata のセグメントにおける非ゼロバイトとゼロバイトの分布が 50% であると仮定すると、平均して 1 Bytes の calldata を処理するのに10 Gas を消費することになります。

この利点は、calldataがガスリミットに達する確率を大幅に減らし、経済的なモデリングによってcalldataの使用量をより一貫した状態に保ち、calldataの誤用をなくすことです。このような設計にした理由は、やはりブロブデータを使ったL2の開発に道を開き、シーケンサーのコストをさらに下げるためです。