EIP-7706と最新のイーサリアムガスの仕組みを詳しく解説

中級6/5/2024, 2:33:32 PM
この記事では、EIP-7706 の原理と実装の詳細について詳しく説明します。この提案は、EIP-4844のブロブガス価格メカニズムを利用して、レイヤー2(L2)の運用コストをさらに削減します。これは、読者がイーサリアムガスメカニズムの最新の開発をすばやく理解するのに役立ちます。

紹介

2024 年 5 月 13 日、ヴィタリックは EIP-7706 を提案し、既存のガス モデルの補足計画を提案しました。この提案は、コールデータのガス計算を分離し、Blobガスと同様の基本料金の価格設定メカニズムをカスタマイズすることで、レイヤー2(L2)の運用コストをさらに削減します。関連する提案は、2022年2月に提案されたEIP-4844にさかのぼります。時間差が大きいため、本稿では関連資料をレビューし、イーサリアムガスの仕組みの最新動向を概観し、読者が最新情報をすぐに理解できるようにしています。

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

イーサリアムは当初の設計で、取引手数料の価格設定にシンプルなオークションメカニズムを採用しており、ユーザーはガス価格を設定して積極的に取引に入札する必要がありました。一般的に、ユーザーが支払う取引手数料はマイナーに支払われるため、マイナーは、マイナーの抽出可能価値(MEV)を考慮しないと仮定して、最高入札額に基づいて取引に優先順位を付けます。コア開発者は、このメカニズムに関する 4 つの主要な問題を特定しました。

取引手数料のボラティリティとコンセンサスコストのミスマッチ:アクティブなブロックチェーンでは、取引を含めることに対する需要が十分にあるため、ブロックを簡単に埋めることができます。ただし、これにより、手数料の変動も大きくなります。例えば、平均ガス価格が10Gweiの場合、ブロックに別のトランザクションを追加する限界費用は、平均Gas価格が1Gweiの場合の10倍であり、これは許容できません。

ユーザーにとっての不必要な遅延:ブロックあたりのハードガス制限と過去のトランザクション量の自然な変動により、トランザクションは多くの場合、数ブロックが組み込まれるのを待ちます。これは、ブロック間の需要の変化に対応するために、1つのブロックを大きくし、次のブロックを小さくする柔軟性メカニズムがないため、ネットワーク全体にとって非効率的です。

価格設定の非効率性:単純なオークションメカニズムは非効率的な価格発見につながり、ユーザーが妥当な価格を設定することを困難にします。これにより、ユーザーは取引手数料を過剰に支払うことになります。

ブロック報酬のないブロックチェーンの不安定性:マイニングによるブロック報酬が取り除かれ、純粋な手数料モデルが採用されると、取引手数料を盗む「アンクルブロック」が作成され、強力な利己的なマイニング攻撃のベクトルが増加するなど、不安定さにつながる可能性があります。

EIP-1559の導入と実装により、ガスモデルは最初の重要な反復を受けました。2019 年 4 月 13 日に Vitalik と他のコア開発者によって提案され、2021 年 8 月 5 日のロンドンのアップグレード中に採用されたこのメカニズムは、オークション モデルを放棄し、基本料金と優先料金で構成されるデュアル プライシング モデルを採用しました。基本料金は、フローティングおよび再帰的なガスターゲットに対する親ブロックのガス消費量に基づいて、所定の数学的モデルによって定量的に調整されます。

基本料金の計算と効果:前のブロックのガス使用量がガス目標を超えると、基本料金が増加します。目標ガスを下回ると、基本料金が下がります。この調整は、需要と供給のダイナミクスをよく反映し、合理的なガス予測の精度を向上させ、基本料金の計算がユーザー指定ではなくシステムによって決定されるため、誤操作による法外なガス価格を回避します。計算の具体的なコードは次のとおりです。

内容から、parent_gas_usedがparent_gas_targetよりも大きい場合、現在のブロックの基本料金は、前のブロックの基本料金と比較してオフセット値だけ増加すると推測できます。このオフセットは、parent_base_feeに前のブロックのガス ターゲットからの総ガス使用量の偏差を乗算し、ガス ターゲットの残りの部分と定数、およびこの剰余と 1 の間の最大値を取ることによって決定されます。逆に、parent_gas_usedがparent_gas_targetより小さい場合も、このロジックは同様に適用されます。

さらに、基本料金はマイナーへの報酬として分配されなくなり、代わりに燃やされます。これにより、ETHの経済モデルはデフレになり、その価値を安定させるのに役立っています。一方、ユーザーからマイナーへのチップのような優先料金は、自由に価格設定できるため、マイナーのソートアルゴリズムである程度再利用できます。

2021 年までに、ロールアップ開発は成熟した段階に入りました。OP RollupとZK Rollupはどちらも、L2データを圧縮し、データの可用性や直接オンチェーン検証のために、コールデータを介して証明データをチェーンにアップロードすることがわかっています。これにより、L2のファイナリティを維持するための多額のガスコストが発生し、最終的にはユーザーが負担するため、ほとんどのL2プロトコルで予想よりも高いコストが発生します。

同時に、イーサリアムはブロックスペースの競争という課題に直面しました。各ブロックにはガスリミットがあり、ブロック内のすべてのトランザクションのガス消費量の合計がこの制限を超えることはできません。現在のガスリミットを30,000,000に設定すると、理論的には、ブロックあたり1,875,000バイト(30,000,000 / 16)の制限があり、EVMによって処理されるcalldataバイトごとに16ユニットのガスが必要となり、ブロックあたりの最大データ容量は約1.79MBになります。L2シーケンサーによって生成されるロールアップ関連のデータは通常大きく、他のメインネットユーザーのトランザクションとの競争を引き起こし、1つのブロックに含めることができるトランザクションの数を減らし、メインネットのTPSに影響を与えます。

この問題に対処するために、コア開発者は 2022 年 2 月 5 日に EIP-4844 を提案し、2024 年第 2 四半期初頭の Dencun アップグレード後に実装されました。この提案では、BLOB トランザクションと呼ばれる新しいトランザクションの種類が導入されました。従来のトランザクションとは異なり、BLOB トランザクションには新しいデータ型である BLOB データが含まれており、calldata とは異なり、EVM から直接アクセスすることはできず、VersionedHash とも呼ばれるハッシュを介してのみアクセスできます。さらに、BLOB トランザクションは、通常のトランザクションと比較して GC サイクルが短いため、ブロック データが肥大化するのを防ぎます。また、BLOB データには、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 は定数ですが、excess_blob_gasは親ブロック内のブロブ ガス消費量の合計と一定のTARGET_BLOB_GAS_PER_BLOCKの差によって決定されます。ブロブガスの総消費量が目標値を超え、その差が正になると、e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)が1より大きくなり、base_fee_per_blob_gasが増加し、その逆も同様です。

このメカニズムにより、イーサリアムのコンセンサス機能を利用して大量のデータを公証し、トランザクションのパッケージ化容量を占有することなく可用性を確保するシナリオを低コストで実行することができます。たとえば、ロールアップ シーケンサーは BLOB トランザクションを使用して、主要な L2 情報を BLOB データにカプセル化し、EVM 内の VersionedHash によるオンチェーン検証を実現できます。

TARGET_BLOB_GAS_PER_BLOCKとMAX_BLOB_GAS_PER_BLOCKの現在の設定では、メインネットに制限が課せられており、ブロックあたり平均3ブロブ(0.375MB)、ブロックあたり最大6ブロブ(0.75MB)の処理を目標としています。これらの初期制限は、この EIP によって引き起こされるネットワーク負荷を最小限に抑えることを目的としており、ネットワークがより大きなブロック サイズで信頼性を示すにつれて、将来のアップグレードでこれらの制限を増やすことが期待されています。

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

現在のイーサリアムガスモデルを理解した上で、EIP-7706の提案の目標と実装の詳細を掘り下げてみましょう。2024 年 5 月 13 日に Vitalik によって提出されたこの提案は、以前の Blob データの変更と同様に、calldata と呼ばれる特定のデータ フィールドの Gas モデルを再定義することを目的としています。さらに、この提案により、対応するコードロジックが最適化されます。

基本的な概念

EIP-7706 のコールデータの基本料金計算ロジックは、EIP-4844 で指定されている BLOB データの基本料金計算を反映しています。どちらも指数関数を利用して、実際のガス消費量と親ブロックの目標値との偏差に基づいて基本料金を調整します。

この提案の注目すべき点は、新しいパラメータ設計 LIMIT_TARGET_RATIOS = [2, 2, 4] の導入です。内訳は次のとおりです。

LIMIT_TARGET_RATIOS[0]:約定動作ガスの目標比率。

LIMIT_TARGET_RATIOS[1]: ブロブデータガスの目標比率。

LIMIT_TARGET_RATIOS[2]:コールデータガスの目標比率。

これらの比率は、ガスリミットをそれぞれの比率で割ることにより、親ブロック内の 3 種類のガスのガス目標値を計算するために使用されます。

ガスリミットは次のように設定されています。

  • gas_limits[0] 既存の調整式に従います。

  • gas_limits[1]MAX_BLOB_GAS_PER_BLOCK等しい。

  • gas_limits[2]gas_limits[0] / CALLDATA_GAS_LIMIT_RATIO等しい。

電流 gas_limits[0] が 30,000,000 で、が CALLDATA_GAS_LIMIT_RATIO 4 にプリセットされているとすると、現在の calldata ガス目標は約次のようになります。

[ \frac{30,000,000}{4 \times 4} = 1,875,000 ]

現在の calldata ガス計算ロジックによると、次のようになります。

  • 0 以外の各バイトは 16 ガスを消費します。

  • 各 0 バイトは 4 ガスを消費します。

calldataセグメントに 0 以外のバイトと 0 のバイトが均等に分布していると仮定すると、バイトあたりの平均ガス消費量は 10 ガスです。したがって、現在の calldata ガス ターゲットは約 187,500 バイトの calldataに相当し、これは現在の平均使用量の約 2 倍です。

提案の利点

この調整により、ガスリミットに達する可能性 calldata が大幅に減少し、経済モデリングを通じて使用量を一貫したレベルに維持 calldata し、乱用を防止します。この設計の主な目的は、レイヤー 2 ソリューションの成長を促進し、BLOB データと共に使用する場合にシーケンサーのコストを削減することです。

結論として、EIP-7706は、データ関連のガス消費を制御および最適化することにより、Gasモデル calldata を洗練させるだけでなく、Ethereumをレイヤー2ソリューションの効率的なスケーリングに戦略的に位置付けます。

免責事項:

  1. この記事は【Web3Mario】からの転載ですが、すべての著作権は原作者【Web3Mario】に帰属します。この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
  2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
  3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。

EIP-7706と最新のイーサリアムガスの仕組みを詳しく解説

中級6/5/2024, 2:33:32 PM
この記事では、EIP-7706 の原理と実装の詳細について詳しく説明します。この提案は、EIP-4844のブロブガス価格メカニズムを利用して、レイヤー2(L2)の運用コストをさらに削減します。これは、読者がイーサリアムガスメカニズムの最新の開発をすばやく理解するのに役立ちます。

紹介

2024 年 5 月 13 日、ヴィタリックは EIP-7706 を提案し、既存のガス モデルの補足計画を提案しました。この提案は、コールデータのガス計算を分離し、Blobガスと同様の基本料金の価格設定メカニズムをカスタマイズすることで、レイヤー2(L2)の運用コストをさらに削減します。関連する提案は、2022年2月に提案されたEIP-4844にさかのぼります。時間差が大きいため、本稿では関連資料をレビューし、イーサリアムガスの仕組みの最新動向を概観し、読者が最新情報をすぐに理解できるようにしています。

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

イーサリアムは当初の設計で、取引手数料の価格設定にシンプルなオークションメカニズムを採用しており、ユーザーはガス価格を設定して積極的に取引に入札する必要がありました。一般的に、ユーザーが支払う取引手数料はマイナーに支払われるため、マイナーは、マイナーの抽出可能価値(MEV)を考慮しないと仮定して、最高入札額に基づいて取引に優先順位を付けます。コア開発者は、このメカニズムに関する 4 つの主要な問題を特定しました。

取引手数料のボラティリティとコンセンサスコストのミスマッチ:アクティブなブロックチェーンでは、取引を含めることに対する需要が十分にあるため、ブロックを簡単に埋めることができます。ただし、これにより、手数料の変動も大きくなります。例えば、平均ガス価格が10Gweiの場合、ブロックに別のトランザクションを追加する限界費用は、平均Gas価格が1Gweiの場合の10倍であり、これは許容できません。

ユーザーにとっての不必要な遅延:ブロックあたりのハードガス制限と過去のトランザクション量の自然な変動により、トランザクションは多くの場合、数ブロックが組み込まれるのを待ちます。これは、ブロック間の需要の変化に対応するために、1つのブロックを大きくし、次のブロックを小さくする柔軟性メカニズムがないため、ネットワーク全体にとって非効率的です。

価格設定の非効率性:単純なオークションメカニズムは非効率的な価格発見につながり、ユーザーが妥当な価格を設定することを困難にします。これにより、ユーザーは取引手数料を過剰に支払うことになります。

ブロック報酬のないブロックチェーンの不安定性:マイニングによるブロック報酬が取り除かれ、純粋な手数料モデルが採用されると、取引手数料を盗む「アンクルブロック」が作成され、強力な利己的なマイニング攻撃のベクトルが増加するなど、不安定さにつながる可能性があります。

EIP-1559の導入と実装により、ガスモデルは最初の重要な反復を受けました。2019 年 4 月 13 日に Vitalik と他のコア開発者によって提案され、2021 年 8 月 5 日のロンドンのアップグレード中に採用されたこのメカニズムは、オークション モデルを放棄し、基本料金と優先料金で構成されるデュアル プライシング モデルを採用しました。基本料金は、フローティングおよび再帰的なガスターゲットに対する親ブロックのガス消費量に基づいて、所定の数学的モデルによって定量的に調整されます。

基本料金の計算と効果:前のブロックのガス使用量がガス目標を超えると、基本料金が増加します。目標ガスを下回ると、基本料金が下がります。この調整は、需要と供給のダイナミクスをよく反映し、合理的なガス予測の精度を向上させ、基本料金の計算がユーザー指定ではなくシステムによって決定されるため、誤操作による法外なガス価格を回避します。計算の具体的なコードは次のとおりです。

内容から、parent_gas_usedがparent_gas_targetよりも大きい場合、現在のブロックの基本料金は、前のブロックの基本料金と比較してオフセット値だけ増加すると推測できます。このオフセットは、parent_base_feeに前のブロックのガス ターゲットからの総ガス使用量の偏差を乗算し、ガス ターゲットの残りの部分と定数、およびこの剰余と 1 の間の最大値を取ることによって決定されます。逆に、parent_gas_usedがparent_gas_targetより小さい場合も、このロジックは同様に適用されます。

さらに、基本料金はマイナーへの報酬として分配されなくなり、代わりに燃やされます。これにより、ETHの経済モデルはデフレになり、その価値を安定させるのに役立っています。一方、ユーザーからマイナーへのチップのような優先料金は、自由に価格設定できるため、マイナーのソートアルゴリズムである程度再利用できます。

2021 年までに、ロールアップ開発は成熟した段階に入りました。OP RollupとZK Rollupはどちらも、L2データを圧縮し、データの可用性や直接オンチェーン検証のために、コールデータを介して証明データをチェーンにアップロードすることがわかっています。これにより、L2のファイナリティを維持するための多額のガスコストが発生し、最終的にはユーザーが負担するため、ほとんどのL2プロトコルで予想よりも高いコストが発生します。

同時に、イーサリアムはブロックスペースの競争という課題に直面しました。各ブロックにはガスリミットがあり、ブロック内のすべてのトランザクションのガス消費量の合計がこの制限を超えることはできません。現在のガスリミットを30,000,000に設定すると、理論的には、ブロックあたり1,875,000バイト(30,000,000 / 16)の制限があり、EVMによって処理されるcalldataバイトごとに16ユニットのガスが必要となり、ブロックあたりの最大データ容量は約1.79MBになります。L2シーケンサーによって生成されるロールアップ関連のデータは通常大きく、他のメインネットユーザーのトランザクションとの競争を引き起こし、1つのブロックに含めることができるトランザクションの数を減らし、メインネットのTPSに影響を与えます。

この問題に対処するために、コア開発者は 2022 年 2 月 5 日に EIP-4844 を提案し、2024 年第 2 四半期初頭の Dencun アップグレード後に実装されました。この提案では、BLOB トランザクションと呼ばれる新しいトランザクションの種類が導入されました。従来のトランザクションとは異なり、BLOB トランザクションには新しいデータ型である BLOB データが含まれており、calldata とは異なり、EVM から直接アクセスすることはできず、VersionedHash とも呼ばれるハッシュを介してのみアクセスできます。さらに、BLOB トランザクションは、通常のトランザクションと比較して GC サイクルが短いため、ブロック データが肥大化するのを防ぎます。また、BLOB データには、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 は定数ですが、excess_blob_gasは親ブロック内のブロブ ガス消費量の合計と一定のTARGET_BLOB_GAS_PER_BLOCKの差によって決定されます。ブロブガスの総消費量が目標値を超え、その差が正になると、e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)が1より大きくなり、base_fee_per_blob_gasが増加し、その逆も同様です。

このメカニズムにより、イーサリアムのコンセンサス機能を利用して大量のデータを公証し、トランザクションのパッケージ化容量を占有することなく可用性を確保するシナリオを低コストで実行することができます。たとえば、ロールアップ シーケンサーは BLOB トランザクションを使用して、主要な L2 情報を BLOB データにカプセル化し、EVM 内の VersionedHash によるオンチェーン検証を実現できます。

TARGET_BLOB_GAS_PER_BLOCKとMAX_BLOB_GAS_PER_BLOCKの現在の設定では、メインネットに制限が課せられており、ブロックあたり平均3ブロブ(0.375MB)、ブロックあたり最大6ブロブ(0.75MB)の処理を目標としています。これらの初期制限は、この EIP によって引き起こされるネットワーク負荷を最小限に抑えることを目的としており、ネットワークがより大きなブロック サイズで信頼性を示すにつれて、将来のアップグレードでこれらの制限を増やすことが期待されています。

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

現在のイーサリアムガスモデルを理解した上で、EIP-7706の提案の目標と実装の詳細を掘り下げてみましょう。2024 年 5 月 13 日に Vitalik によって提出されたこの提案は、以前の Blob データの変更と同様に、calldata と呼ばれる特定のデータ フィールドの Gas モデルを再定義することを目的としています。さらに、この提案により、対応するコードロジックが最適化されます。

基本的な概念

EIP-7706 のコールデータの基本料金計算ロジックは、EIP-4844 で指定されている BLOB データの基本料金計算を反映しています。どちらも指数関数を利用して、実際のガス消費量と親ブロックの目標値との偏差に基づいて基本料金を調整します。

この提案の注目すべき点は、新しいパラメータ設計 LIMIT_TARGET_RATIOS = [2, 2, 4] の導入です。内訳は次のとおりです。

LIMIT_TARGET_RATIOS[0]:約定動作ガスの目標比率。

LIMIT_TARGET_RATIOS[1]: ブロブデータガスの目標比率。

LIMIT_TARGET_RATIOS[2]:コールデータガスの目標比率。

これらの比率は、ガスリミットをそれぞれの比率で割ることにより、親ブロック内の 3 種類のガスのガス目標値を計算するために使用されます。

ガスリミットは次のように設定されています。

  • gas_limits[0] 既存の調整式に従います。

  • gas_limits[1]MAX_BLOB_GAS_PER_BLOCK等しい。

  • gas_limits[2]gas_limits[0] / CALLDATA_GAS_LIMIT_RATIO等しい。

電流 gas_limits[0] が 30,000,000 で、が CALLDATA_GAS_LIMIT_RATIO 4 にプリセットされているとすると、現在の calldata ガス目標は約次のようになります。

[ \frac{30,000,000}{4 \times 4} = 1,875,000 ]

現在の calldata ガス計算ロジックによると、次のようになります。

  • 0 以外の各バイトは 16 ガスを消費します。

  • 各 0 バイトは 4 ガスを消費します。

calldataセグメントに 0 以外のバイトと 0 のバイトが均等に分布していると仮定すると、バイトあたりの平均ガス消費量は 10 ガスです。したがって、現在の calldata ガス ターゲットは約 187,500 バイトの calldataに相当し、これは現在の平均使用量の約 2 倍です。

提案の利点

この調整により、ガスリミットに達する可能性 calldata が大幅に減少し、経済モデリングを通じて使用量を一貫したレベルに維持 calldata し、乱用を防止します。この設計の主な目的は、レイヤー 2 ソリューションの成長を促進し、BLOB データと共に使用する場合にシーケンサーのコストを削減することです。

結論として、EIP-7706は、データ関連のガス消費を制御および最適化することにより、Gasモデル calldata を洗練させるだけでなく、Ethereumをレイヤー2ソリューションの効率的なスケーリングに戦略的に位置付けます。

免責事項:

  1. この記事は【Web3Mario】からの転載ですが、すべての著作権は原作者【Web3Mario】に帰属します。この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
  2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
  3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。
Lancez-vous
Inscrivez-vous et obtenez un bon de
100$
!
It seems that you are attempting to access our services from a Restricted Location where Gate is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Thailand, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.