EIP-7623: イーサリアムトランザクションのコールデータ価格を再設定する提案

ブロックチェーンのトランザクションは、伝播、ノード間で実行、保存されるときに、CPU、メモリ、ストレージなどのリソースを消費します。したがって、ネットワークの悪用を防ぎ、リソースを効率的に利用するには、トランザクションの適切な価格設定が不可欠です。

しかし、取引の適切な価格を決定することは、ブロックチェーン プロトコルの設計において長年の課題でした。Ethereum の創設者である Vitalik Buterin は、古い研究文書でこの問題について触れています。

ブロックチェーンプロトコルの設計における最も難しい問題の1つは、チェーンに含まれるトランザクションの送信を制限し、価格を設定することです。」— Vitalik Buterin

EIP -7623は、コールデータの価格を変更して最大ブロック サイズを制限することを目的とした Ethereum 改善提案 (EIP) です。コールデータのコストを単に増加させた以前の提案とは異なり、EIP-7623 は、効率的なリソース利用を実現しながら、日常のユーザー トランザクションへの影響を最小限に抑えることに重点を置いています。

この記事では、イーサリアム レイヤー 1 (L1) のトランザクションで使用されるコールデータを再価格設定する理由と、ブロック サイズとネットワーク パフォーマンスへの影響について説明します。また、ブロックチェーン リソースの効率的な価格設定の問題に関する長年の研究に基づいて、イーサリアムのトランザクション手数料メカニズムへの提案された変更の背景を説明します。

さあ、始めましょう！

舞台設定: 取引価格を適切に設定することがなぜ難しいのか?

ブロックチェーン トランザクションの価格設定は、各トランザクションが消費する各リソースの正確な量を見積もることが本質的に複雑であるため困難です。現在、Ethereum では、すべてのリソースは「ガス」および「ブロブ ガス」と呼ばれる統一された単位で表されます ( EIP-4844で導入)。

トランザクション リソースの消費をガスに変換する定義済みのルールがあり、これらのルールは定期的に更新されます。これらのルールの例は次のとおりです。

• 主に署名検証のために少なくとも21,000ガスの固定オーバーヘッドが発生するトランザクション

• 各EVMオペコードに事前定義されたガス消費量

  
  

さらに、コールデータのガス消費はこれらのルールの不可欠な部分であり、あまり知られていませんが非常に重要です。コールデータの価格は、最大ブロック サイズに直接影響するため重要です。さらに、スマート コントラクトを使用するすべてのトランザクションに影響し、特に、 データの可用性のために BLOB ではなくコールデータ スペースに依存するロールアップ トランザクションのコストに影響します。

ブロックサイズが重要な理由

Ethereum は 12 秒のスロットで動作し、その間にすべてのバリデータ ノードはブロックと BLOB を伝播し、トランザクションを実行および検証し、新しいブロックを証明する必要があります。具体的には、Ethereum クライアント実装では、正直なノードがスロットの最初の 4 秒以内にブロックを受信して検証する必要があります。ノードはスロットの 4 秒後に証明するため、4 秒後に到着するブロックは証明されないと予想され、次のプロポーザーによって再編成される可能性があります。

Ethereum ノード間の分割ビューを最小限に抑えるには、ブロック実行時間と伝播時間を制限することが必要です。Ethereum は最大ガス使用量を設定することでブロック実行時間を制限します。現在、上限は 3000 万、目標は 1500 万です。つまり、Ethereum ブロックは平均で約 1500 万ガスを使用し、アクティビティが活発なときには 3000 万ガスを消費する能力が拡張されます。

また、各 EVM オペコードには、リソース消費量に基づいて事前に決定されたガス コストがあります。たとえば、 SSTORE オペコードは、状態トライへのアクセスと変更を伴うため、より単純な操作 (算術加算 (ADD) など) よりもコストがかかります。EVM オペコードのこの差別化された価格設定と合計ガス制限は、合計実行時間を制限することを目的としています。

ブロックのガス制限はブロック実行時間をある程度制限できますが、ブロックの伝播時間は明示的に制限されません。ブロック サイズは、パブリック ブロックチェーンの伝播時間に影響を与える主な要因です。たとえば、ブロック サイズが大きいほど、ネットワーク負荷と帯域幅要件が増加します。ブロック サイズがほとんどのノードの帯域幅を大幅に超える場合、ノードがブロックを完全に伝播して受信するのに時間がかかり、ブロックの欠落や再編成のリスクが高まります。(これが、ビットコイン プロトコル ( Segwit以前) で、フォーク率の増加を防ぎ、ブロックチェーンのセキュリティと低いノード要件を確保するために、ブロック サイズの上限が 1 MB に設定された理由です。)

現在、Ethereum にはブロック サイズの制限が明示的に設定されていません。ただし、ガス制限、コールデータ コスト、圧縮率などを考慮すると、理論上の最大ブロック サイズを推定できます。Ethereum の現在のブロック サイズは約 2.78 MB (BLOB を除く) ですが、現在のコールデータ料金では最大 7.15 MB の EL ペイロードが許可されており、平均サイズはそれよりはるかに小さく、約 100 KB です。

このような大きなペイロードが 10 分間にわたって継続的に伝播された場合、そのサイズは約 42.9 MB に達し、これは他のブロックチェーン ネットワークの一般的なブロック サイズよりも大幅に大きくなります。

これにより、Ethereum ネットワークが過負荷になり、7.15 MB のペイロードがしばらく続く DoS 攻撃シナリオで、ノードが短期間異なるビューを持つ可能性があります。

実際には、現在の Ethereum の平均ブロック サイズは約 125 KB であり、最大ブロック サイズとの差が大きくなっています。これにより、リソース利用の非効率性に関する別の懸念が生じます。たとえば、ネットワークが 1 MB のブロックを連続して十分に処理できる場合、平均ブロック サイズと 1 MB の間に大きな差があると、Ethereum にはデータ可用性 (DA) 機能の容量が十分にあるものの、それを効果的に活用していないことが示唆されます。

最大ブロック サイズを制限し、平均ブロック サイズをこの最大値に近づけることで、Ethereum はコンセンサス リスクを軽減しながら、より効率的なリソース利用を実現できます。このため、EIP-7623 は、コールデータ価格設定に大きく影響される最大ブロック サイズの可能性に重点を置いています。

Ethereum の Calldata とは何ですか?

Calldata はトランザクション内のフィールドで、通常、呼び出す関数と渡すパラメータを伝えるために使用されます。たとえば、NFT をミントする場合は、calldata フィールドに「mint」メソッドと NFT の特定の特性を含めます。次の例は、2017 年の CryptoPunk の最初のミント トランザクションを示しています。

calldata（図では「入力データ」と呼ばれています）には、0xc81d1d5b で表されるgetPunk関数名と、0x00001eb0（16 進数で 7856）で表される NFT インデックスが含まれています。ETH のみを転送し、スマート コントラクトとやり取りしない場合は、calldata フィールドは null（ 0x ）になります。

calldata は、スマート コントラクトにパラメータを渡すという主な目的のほかに、簡単なメモを記録したり、トランザクション データを格納するロールアップにも使用されます。つまり、calldata は必ずしもスマート コントラクトとやり取りしたり、厳密なルールに従う必要はなく、任意の値を含めることができます。

この柔軟性を活用することで、Optimism や Arbitrum などの楽観的ロールアップ、一部の ZK (有効性) ロールアップ、圧縮後のロールアップ トランザクション データ、およびそれらのシーケンス トランザクションの calldata フィールドの更新された状態が実現します。EIP-4844 では、calldata ではなくblobによるデータの可用性が有効になっていますが、単一のバッチに 128 KB の blob 全体を必要としない小さなロールアップでは、依然として calldata が好まれます。

コールデータは、 EVM に大容量データを投稿するためのガス消費が最も少ない方法であるため、DA 機能によく使用されます。最大ブロック サイズがコールデータの価格によって制限されるのは、このためです。最悪のシナリオは、ガス消費量が少ないがデータ サイズが大きい DA 目的のトランザクションでブロックがいっぱいになったときに発生します。

現在、コールデータのコストは、ゼロバイトあたり 4 GAS、非ゼロバイトあたり 16 GAS です。コールデータは、スナップ圧縮 ( EIP-706 ) を使用して圧縮でき、トランザクション サイズは 125 KB を超えることはできません。圧縮率のさまざまな性質により、最大ブロック サイズの正確な計算は複雑ですが、ブロックは最大で約 2.78 MB まで増加する可能性があることがわかっています。

何らかの理由（スパム攻撃など）で 2.78 MB のブロックが連続して続くと、ネットワークが過負荷になり、伝播速度が遅いためにノードのビューが分割される可能性があります。より多くのノードが異なるブロックを正規チェーンとして証明する可能性があり、コンセンサスに達しないリスクが高まります。これを防ぐには、コールデータのコストを増やすという簡単な解決策があります。たとえば、コールデータのコストを 0 バイトあたり 8 ガス、非ゼロ バイトあたり 32 ガスに倍増すると、最大ブロック サイズをほぼ半分に減らすことができます。

ただし、このアプローチは、通常のユーザー トランザクションに悪影響を与える可能性があります。最悪のシナリオを防ぐためだけに calldata コストを増やすと、平均ブロック サイズが現在 125 KB に過ぎず、大きな問題にはならないことを考えると、利益よりも損失の方が大きくなる可能性があります。

EIP-7623 の目的は何ですか?

EIP-7623 は、コールデータのコストを単純に引き上げる他の提案とは少し異なります。コールデータの価格を全面的に調整するのではなく、EIP-7623 は、 データ可用性(DA) の目的に役立つと思われるトランザクションのガス コストを特に引き上げることに重点を置いています。

これは何を意味するのでしょうか? トランザクションで使用されるガスがロードされるデータの合計サイズに比べて不十分な場合、DA 目的のトランザクションとみなされ、calldata に対して大幅に高い料金が請求されます。逆に、トランザクションがデータ サイズに対して十分なガスを消費する場合、非 DA トランザクションとみなされ、現在と同じ料金が請求されます。

イーサリアムのコールデータと現実世界のビニール袋の間には、役に立つ類推ができます。商品や食料品を購入すると、通常は非常に安価、あるいは無料で、ビニール袋をもらって持ち運ぶことがよくあります。しかし、個人が無制限にビニール袋を購入できるとしたら、環境に悪影響を及ぼします。

考えられる解決策としては、十分な量の商品を購入する顧客や、1袋あたり1ドルなどの高い価格を請求する顧客にのみビニール袋の提供を制限することが挙げられます。これは、ピグー税の一種として機能するEIP-7623アプローチに似ています。大量のコールデータを使用するがガスが不十分なトランザクションに高いコストを課すことで、より効率的なリソースの使用を促進します。データと実行のバランスの取れた組み合わせではなく、主にデータの可用性のためにコールデータを使用するトランザクションに、より積極的なコストを適用することで、プロトコルはネットワークリソースのより効率的で持続可能な利用を確保することを目指しています。

なぜ Ethereum で DA トランザクションをターゲットにするのか?

データの可用性のために Ethereum を利用するトランザクションに、本質的に問題があるわけではありません。EIP-7623 は、Ethereum がデータ可用性レイヤーとして機能することを推奨していません。むしろ、トランザクション データの保存を目的とした calldata の使用を推奨せず、代わりに DA 用の BLOB の使用を間接的に推奨しています。この提案は、実行レイヤーをデータ可用性レイヤーから分離し、各レイヤーが需要を効率的に管理し、極端なケースをより適切に予測できるようにすることを目的としています。

そうすることで、EIP-7623 は、DoS サーフェスを制限しながら、Ethereum のリソース管理の効率と予測可能性を高めることを目指しています。この分離により、各レイヤーが特定の機能をより効率的に処理できるようになり、最終的にはより堅牢でスケーラブルな Ethereum ネットワークの実現に貢献します。

EIP-7623 仕様の概要

トランザクションの現在のガス計算は次のとおりです。

上記の仕様の21,000は、あらゆるトランザクションに課される最小ガスです。また、 STANDARD_TOKEN_COST tokens_in_calldata 、EIP-7623 が主に修正しようとしている calldata に使用されるガスを表します。ここで、 tokens_in_calldata 、ゼロバイトと非ゼロバイトの単純な重み付けの組み合わせであり、 tokens_in_calldata = zero_bytes_in_calldata + 4 * nonzero_bytes_in_calldataで計算されます。

STANDARD_TOKEN_COSTは現在 4 に設定されているため、 zero_bytes_in_calldataのガス コストは 4、 nonzero_bytes_in_calldataは 16 です。

evm_gas_usedトランザクションの実行に使用されるガスであり、主にスマート コントラクトとのやり取りをカバーします。DA 目的以外のトランザクションには通常、大きなevm_gas_usedコンポーネントがあります。

トランザクションが新しい契約を作成すると、 isContractCreation項は 1 になります。これは、新しい契約を作成して保存するために追加のガスが発生することを意味します。ここでは契約の作成に焦点を当てていないため、この項を 0 に設定します。

EIP-7623 では、総ガス計算に対して次の調整を提案しています。

新しい計算では、 max(blue box, red box)現在の方法で計算されたガス(青いボックス)と、 TOTAL_COST_FLOOR_PER_TOKEN calldata(赤いボックス)を比較します。青いボックスは、現在のガス計算方法とまったく同じです。EIP-7623で新しく追加された赤いボックスは、トランザクションがDA目的であるかどうかを判断する値を表します。2025年1月1日現在、 TOTAL_COST_FLOOR_PER_TOKENは10に提案されており、これはSTANDARD_TOKEN_COSTの4よりもはるかに高い値です。

つまり、トランザクションが十分なevm_gas_used消費しない場合、赤いボックスの値は青いボックスの値よりも高くなる可能性が高く、DA 目的のトランザクションとしてマークされます。その結果、トランザクションはTOTAL_COST_FLOOR_PER_TOKENレートで課金され、実質的に calldata に対して 3 倍弱多く支払うことになります。逆に、ほとんどの汎用トランザクションは十分なevm_gas_used消費するため、max(青いボックス、赤いボックス) はデフォルトで青いボックスの値になり、現在のガスコスト方式が維持されます。

EIP-7623 の影響を受けるトランザクションの種類は何ですか?

EIP-7623 の影響を受けるトランザクションを特定するには、赤いボックス (新しいガス計算) が青いボックス (現在のガス計算) よりも高い状態を特定する必要があります。

契約作成期間を無視し、パラメータに値を代入することで、次の条件が導き出されます。EVM 実行に消費されるガスが calldata 内のトークンの 6 倍未満の場合、トランザクションにはより高いガス コストが発生します。

これをより直感的にするために、両辺を 4 tokens_in_calldataで割ります。6 tokens_in_calldata 、トランザクションで calldata に支払われるガスであることを覚えておいてください。

この最後の式は、EVM 実行に使用されるガスが calldata に使用されるガスの 2 倍未満の場合、トランザクションでは calldata に対してより高い手数料が発生することを示しています。

EIP-7623 後、Calldata のコストはどのくらい増加しますか?

トランザクションの最小ガスが 21,000、EVM 実行に使用されるガスが k、calldata に使用されるガスが kx であると仮定します。トランザクションの合計コストは次のように表すことができます。

現在の計算（EIP-7623 なし）では、コストは 21,000+k+kx になります。したがって、EIP-7623 を使用した場合の増加率は次のようになります。

kの関数としての増加率は以下のようにプロットされます。

実際の影響を理解するために、ほとんどのユーザーに馴染みのある一般的な関数メソッドに焦点を当てて、ガス使用量の統計を調べてみましょう。

分散型取引所のさまざまなスワップ関数の中で、 swap(string, address, uint256, bytes)が最も広く使用されています。

中央値では、 calldata に 5,152、EVM に 175,742 が使用され、これは 34 倍の大きな値を占めています。ERC20 トークンの転送に使用されるtransfer(address, uint256)関数は、EVM 実行に約 24,501 GAS を消費します。これは、calldata に使用される 620 GAS の約 40 倍です。

これらの関数と同様に、ほとんどの日常的なユーザートランザクションでは、calldata と EVM 実行に使用されるガスに大きな違いがあるため、EIP-7623 の影響を受ける可能性は低いと考えられます。

Ethereum 研究者のToni Wahrstätter氏の分析によると、EIP-7623 が適用されると、最近の Ethereum トランザクションの 3.02% が影響を受けるとのことです。また、同氏の分析では、影響を受ける関数メソッドを特定し、それらのメソッドのコスト増加を推定しています。Wahrstätter 氏のさらなる分析によると、Ethereum の最近のトランザクションでは、EIP-7623 が適用されると 3.02% のトランザクションが影響を受けるとのことです。

彼のサイトでは、実際に影響を受ける関数メソッドと、それらのメソッドの価格がどの程度増加するかについても示されています。

EIP-7623 の影響を受ける関数の中で最も頻繁に使用されるのはaddSequencerL2BatchFromOrigin()で、これは Ethereum のロールアップ トランザクションの順序付けによく使用されます。影響を受けるもう 1 つのメソッドはcommitBatches()で、これはロールアップ トランザクションで頻繁に使用されます。これらの 2 つの関数はコストが最も大幅に増加すると予想され、これらのメソッドを使用するとガス コストの合計が 150% 増加すると推定されます。

ただし、ロールアップはデータの投稿に BLOB を利用することができ、Arbitrum One や Base などの多くのロールアップではすでにそれが行われています。したがって、データの投稿に BLOB を使用するロールアップは、EIP-7623 によって課せられるコストの増加の影響を大きく受ける可能性は低いと考えられます。

EIP-7623 がブロック サイズに与える影響の分析

EIP-7623 は、大量のコールデータを使用するトランザクションのガスコストを引き上げます。つまり、コールデータに大きく依存するスパム攻撃には約 3 倍のガスコストが必要となり、最大ブロック サイズが 2.54 MB から約 0.72 MB に減少します。その結果、Ethereum ネットワークは、大きなブロックが継続的に伝播する最悪のシナリオに対処しやすくなります。

最大ブロック サイズが縮小されたことで、ブロックあたりに含まれる BLOB の数を増やす機会が生まれました。現在、BLOB の最大数は 6 個で、各サイズは 128 KiB です。EIP-7623 が採用され、同じ最大ブロック サイズが維持されれば、BLOB の最大数を約 18 個に増やすことが可能になり、ロールアップの最大 TPS (1 秒あたりのトランザクション数) が 3 倍に増加することになります。

この計算には、BLOB とブロックの伝播方法が異なるため、多少の単純化が含まれています。ただし、主な利点は、実行レイヤーとデータ可用性レイヤー間の分離が強化されることです。BLOB ガスと実行ガスには別々の手数料市場があるため、一方の市場での混乱が他方に直接影響を与えることはありません。

この分離により、Ethereum ネットワークが 1 つのブロック内で処理できるターゲットと最大リソースを制御しやすくなるため、資本効率の達成が簡単になります。

EIP-7623 の実装に関連するその他の考慮事項は何ですか?

EIP-7623 には大きな利点がありますが、コールデータの代わりに BLOB を使用する必要があるため、小規模なロールアップに影響を及ぼす可能性があります。需要の少ないロールアップの場合、128 KiB という大きな BLOB サイズでは、BLOB 全体がいっぱいになるまで待機時間が長くなる可能性があります。この状況では、 BLOB 共有プロトコルの必要性が高まり、複数のロールアップで大きな BLOB スペースを共有してコスト効率を高めることができます。

ブロブの基本料金は現在非常に低く (ブロブは安価な DA スペースになっています)、需要が急増すると、これらのロールアップに大きな負担がかかる可能性があります。ブロックあたりのブロブ数を同時に増やさなければ、DA の総容量が全体的に減少しているため、EIP-7623 によって DA トランザクションを送信するロールアップの競争力が高まる可能性があります。この変化に対応するために、ブロブ数を同時に増やす必要があるかどうかを評価する必要があります。

もう 1 つの考慮事項は、この更新によって影響を受けるトランザクションのしきい値の基準を決定することです。ブロック サイズとユーザー エクスペリエンスの間にはトレードオフがあります。たとえば、しきい値をあまりに積極的に設定すると、最大ブロック サイズが大幅に削減される可能性がありますが、多くのトランザクションが calldata に対してより多くのガスを支払う必要がある可能性があります。

最大ブロック サイズの変更は明確かつ鮮明ですが、DA 目的のトランザクションに高いガス コストを要求することで Ethereum がどの程度影響を受けるかを推定および定量化することは困難です。このしきい値は社会的にのみ設定できます。

さらに、基準は、EVM 操作またはガス制限によって設定される他のパラメータに大きく依存します。たとえば、将来的に Ethereum がブロック ガス制限を 3 億に増やす場合、最大ブロック サイズを維持するために EIP-7623 のしきい値も変更する必要があります。

結論

EIP-7623 は、特に DA 目的のトランザクションを対象に、コールデータ コストを調整することで最大ブロック サイズを削減することを目的とした Ethereum の改善提案です。この調整により、非 BLOB DA トランザクションのコストが最大 300% 増加する可能性がありますが、ほとんどの日常的なユーザー トランザクションには影響がありません。

この投稿では、提案の背後にある動機、その影響、影響を受けるトランザクションの種類、発生する可能性のある懸念について検討しました。この記事が、この最新の提案について理解を深め、その内容に関する詳細な洞察を提供するのに役立つことを願っています。興味があり、詳細を知りたい場合は、 Toni Wahrstätter の分析と説明をフォローし、Ethereum Magicians フォーラムの公開ディスカッションに参加してください。