Ethereum ネットワークが EIP-4844 アップグレードを通じて BLOB を導入してから 8 か月が経ちました。予想どおり、ロールアップはバッチ投稿料金が大幅に削減されたことで恩恵を受けており、コスト効率の高い BLOB オプションを介してより多くのトランザクションを Ethereum に送信できるようになりました。
しかし、BLOB の使用量は予想どおり低く、BLOB を活用するロールアップや分散型アプリケーション (DApps) はまだ十分ではありません。
その結果、ブロブガスの基本料金は、わずか 1 wei という最低価格のままです。ブロブの需要が高かった期間が 4 回あったにもかかわらず、全体的なコストは例外的に低いままです。これにより、Ethereum はロールアップにとって魅力的なデータ可用性 (DA) レイヤーになりますが、ロールアップがメインネットに十分貢献しているかどうかについてコミュニティ内で懸念も生じています。さらに、Ethereum はブロブの採用以来、発行インフレを経験しており、その影響についての議論が巻き起こっています。
ブロブによって Ethereum の拡張が可能になり、最終的にはより多くのロールアップ サービスがネットワークに移行すると主張する人もいます。一方で、現時点ではロールアップは Ethereum にほとんど貢献していない、あるいはまったく貢献していないと主張する人もいます。
価格効果以外にも、ブロブのより広範な影響に関する議論が浮上しています。主要なトピックの 1 つは、EIP-7762 で提案されているように、ブロブの最小基本料金を調整すべきかどうかです。この提案の結果は不透明です。EIP-7691 に記録されている別の議論は、ブロブの数を増やすべきかどうかを中心にしており、支持者は、これによってコンセンサス セキュリティが損なわれることはないと主張しています。両方の提案は、今後のPectra ハード フォークで検討されています。
この記事では、各提案の詳細を掘り下げ、背景、提案内容の詳細、潜在的な利点と欠点を探ります。
BLOB に馴染みのない方のために、まずは基本について説明します。EIP-4844 と BLOB についてすでに知識があり、提案に特に興味がある場合は、EIP-7762 の議論に進んでください。
まず、データ可用性の正確な概念を詳しく説明し、EIP-4844 が DA レイヤーとして Ethereum をどのように強化するかを説明します。
データの可用性とは、特にブロックチェーン ネットワークで新しいブロックを検証する目的で、特定のデータに特定の時点でアクセスできることを保証するプロパティです。新しいブロックを検証し、合意に達するために必要なリアルタイム アクセスに重点を置いています。現在のブロックの検証に必要なデータがすべての参加ノードで利用可能であることを保証し、ブロックをチェーンに追加する前にトランザクションを検証できるようにします。
DA は、履歴データにアクセスする機能を指すデータ取得可能性と混同されることがよくあります。取得可能性とは、通常、新しいノードの同期やトランザクション履歴の確認などの目的で、古いブロックの情報などの過去のデータを取得することです。ただし、取得可能性は、ブロック作成に必要なリアルタイム検証には影響しません。
たとえば、イーサリアム ブロックチェーンは、ブロックが提案された時点でブロック検証に必要なデータをノードが利用できるようにすることで DA を保証します。イーサリアム ノードが同期ノードにすべての履歴データを提供しないケースもありますが、コンセンサス メカニズムにより、 検証中に必要なデータが利用可能であることが保証されます。その時点でデータが利用できなかった場合、ブロックはブロックチェーンに追加されませんでした。
また、DA はバイナリ プロパティではないことにも留意する必要があります。つまり、単に「利用可能」または「利用不可」を意味するのではなく、連続したスペクトル上に存在します。Ethereum のような安全で分散化されたブロックチェーンは強力な DA を提供しますが、コンセンサス メカニズムや分散化のレベルなどの要因に基づいて、可用性の程度にばらつきが生じる可能性があります。
データ可用性 (DA) はロールアップにとって重要です。これは、トランザクション データにアクセスして状態の更新を確認し、ロールアップの現在の状態を再構築できることを保証するためです。楽観的ロールアップの場合、DA は不正の証明を作成するために不可欠です。誤った状態遷移が投稿された場合、ユーザーは DA レイヤーに保存されているトランザクション データに依存して遷移を検証し、不正を証明できます。DA がなければ、ユーザーはロールアップ オペレーターを完全に信頼する必要があり、オペレーターが悪意を持って行動したりデータを隠したりした場合にリスクにさらされる可能性があります。
ZK ロールアップの場合、DA はすべてのトランザクション データを投稿する必要なく、状態遷移を検証するための暗号証明の存在を保証します。ただし、実際には、多くの ZK ロールアップは、透明性を高め、ユーザーによる検証を容易にするために、依然としてトランザクション データを DA レイヤーに投稿しています。
Ethereum の強力な DA 保証が、ロールアップがそれを DA レイヤーとして使用する理由です。EIP-4844 より前は、ロールアップは DA に Ethereum の calldata フィールドを活用していました。現在は、BLOB と calldata の両方を利用できるため、ロールアップ実装のスケーラビリティと効率が向上しています。
EIP-4844 では、BLOB と呼ばれる新しいデータ構造が導入されています。これは、 calldataとは異なり、削除されるまで約 18 日間コンセンサス レイヤーに一時的に保存されます。Ethereum バリデータは、一時的な BLOB ストレージに約 50 GB を割り当てます。BLOB は、Ethereum 仮想マシン (EVM) からアクセスできない点で calldata とは異なります。BLOB コミットメントのみがアクセス可能で、DA を確保しながらデータ フットプリントを削減します。BLOB は、ロールアップに必要な基本的な機能のみを提供することで効率的な DA を提供し、トランザクション手数料の大幅な削減に貢献します。
各 BLOB は約 128 KiB で、ブロックには最大 6 個の BLOB を含めることができ、ブロックあたり合計約 0.784 MiB になります。BLOB は、BLOB トランザクションと呼ばれる新しいトランザクション タイプを通じて追加されます。このトランザクション タイプは、従来のトランザクションと同様に、少なくとも 21,000 ガスを使用し、1 ~ 6 個の BLOB を含めることができます。
BLOB は、 BLOB ガスと呼ばれる新しい単位を使用して価格設定され、各 BLOB は 217 = 131,072 BLOB ガス単位を消費します。Ethereum のEIP-1559 ガス料金メカニズムと同様に、BLOB ガス料金は、最近のブロックの BLOB 輻輳に基づいて動的に調整されます。次のブロックk + 1の BLOB ガス基本料金Bblobgas,k+1は、次のように計算されます。
ブロックが最大 6 つの BLOB で満たされると、次のブロックで BLOB ガス基本料金が約 12.5% 増加する可能性があります。現在、最小 BLOB 基本料金は 1 wei に設定されており、BLOB あたりの最小料金は 131,072 wei になります。各 BLOB トランザクションには、ガス価格に乗じた 21,000 ガスの標準実行料金も含まれます。最小基本料金 1 wei については活発な議論が行われており、EIP-7762 ではコストとデータ可用性のニーズのバランスをとるために料金の引き上げが提案されています。
EIP-7762 は、価格発見を高速化するために、BLOB ガスの基本料金 (中心部にかなり近いホテルを予約する) を上げることを提案しています。変更しようとしているのは、 MIN_BLOB_BASE_FEE
という 1 つのパラメータのみです。これを 1 wei から 225 wei に変更することを提案しています。しかし、この提案の背後にある理由は何でしょうか?
問題は、ロールアップがメインネットのトランザクションにほとんど貢献していない、または手数料が少なすぎるということではありません。それどころか、Ethereum の目標は、特に EIP-4844 では、スケーラブルで低コストのロールアップ トランザクションをサポートすることです。Blob ガスの基本料金は、EIP-4844 がアクティブ化されて以来、一貫して 1 wei のままであり、Blob 需要が急増したときに数回の短い急上昇があっただけです。理想的には、基本料金が無期限に 1 wei のままであれば、これは問題になりません。重要なのは、突然の需要の急増時に、Blob 基本料金の開始点が低いため、価格発見が困難になることです。
こうした需要急増時には、ブロブガスの基本料金が 1 ウェイから段階的に調整されるため、実際の需要に追いつくまでに時間がかかる可能性があります。架空のシナリオを考えてみましょう。ETH Bangkok 2024に参加し、食料品がほぼ無料で手に入る遠隔地のホテルに宿泊するとします。日々のニーズには理想的です。しかし、カンファレンス センターでのイベントに参加する必要がある場合、通常の状況では会場に到着するまでに 6 時間かかります。渋滞や直通ルートの欠如が加わると、移動時間は 14 時間にまで延びる可能性があります。
同様に、最小の BLOB ガス基本料金が 1 wei に設定されている場合、需要が低いときにロールアップは安価な BLOB の恩恵を受けます。しかし、需要が急増すると、BLOB ガス基本料金の上方調整は遅くなり、公正な市場レートに達するまでに価格発見期間が長くなります。
さらに、適切な価格に達するための理論上の最短時間は、実際には当てはまらない可能性があります。バリデーターまたはブロックビルダーがブロックから BLOB トランザクションを省略した場合、この検出期間はさらに長くなる可能性があります。たとえば ( dataalways の投稿より)、6 月 20 日の LayerZero エアドロップ中に、BLOB 基本料金は 1 wei から 7471 Gwei に上昇しました。理論的には、これには約 252 ブロック、つまり 51 分かかるはずでした (次のように計算されます)。
log1.125 (7.471 x 1012) = 251.66
しかし、実際の時間は約 6 時間で、予想の 5 ~ 6 倍近くも長くなりました。価格発見期間が長くなると、基本料金が BLOB の需要を正確に反映できなくなります。この不一致により、ロールアップと BLOB ユーザーは優先料金を通じて積極的に入札するようになり、予測不可能で競争の激しい料金市場につながる可能性があります。要約すると、基本料金の設定が低すぎると価格発見が遅れ、料金がリアルタイムの需要とずれてしまいます。
EIP-7762 が提案するのは、コンベンション センターに近いホテルに泊まるようなものです。近くの食料品の代金は高くなるかもしれませんが、近い方が、必要なときにカンファレンス センターに行くのが早くて便利になります。
最低 BLOB 基本料金が上がると、ロールアップは確かに BLOB トランザクションの送信に対してより高い料金を負担することになります。ただし、最低 BLOB 基本料金を 1 wei から 225 wei に上げることは、ロールアップが BLOB トランザクションに対して現在の料金の 225 倍を支払うことを意味するものではありません。これは、BLOB トランザクションが BLOB ガス料金を支払うだけでなく、BLOB トランザクションの実行料金も支払うためです。非 BLOB トランザクションと同様に、BLOB トランザクションは少なくとも 21,000 ガスを支払います。コールデータを投稿すると、実行料金はさらに上がります。
基本ガス料金が 5 Gwei であると仮定すると、BLOB トランザクションの実行料金は (少なくとも) およそ21,000 x 109 = 2.1 x 1013
wei になります。比較すると、1 つの BLOB の最小料金は131,072 = 1.3 x 105 wei
であるため、BLOB 基本料金は取るに足らないものになります。実行料金の約1.6 x 108 = 160,000
倍安くなります。直感的に、最小 BLOB 基本料金のわずかな増加は、BLOB トランザクションの総コストに大きな影響を与えません。
たとえば、EIP-7762 で提案された最小 BLOB 基本手数料 225 wei の場合、BLOB 手数料は225 x 1.3 x 105 = 4.3 x 1012
wei になります。したがって、合計コスト (実行手数料 + BLOB 手数料) は2.1 x 1013 + 4.3 x 1012 = 2.5 x 1013
になります。
これは、現在の 1 wei の最小 BLOB 基本料金から約 20% の増加に相当します。ブロックが最大 6 個の BLOB で満たされる場合、増加率は約 120% に達する可能性があります。
EIP-7762 による実際のコスト増加は、各ロールアップのトランザクション戦略によっても異なります。ロールアップは BLOB 送信戦略が異なります。トランザクションごとに異なる BLOB カウントを使用し、さまざまな量のコールデータを投稿するため、発生する実行手数料も異なります。コールデータでより複雑な証明を投稿するロールアップは、より高い実行手数料を支払うことになります。つまり、提案されている BLOB 基本料金の増加は、全体的なトランザクション コストにそれほど大きな影響を与えません。
dataalwaysによる過去のシミュレーションのデータによると、Base、Optimism、Blast などの OP Stack ベースのロールアップでは、BLOB 基本料金が 225 wei の場合、コストが最大 16% 増加する可能性があります。ただし、他のロールアップでは 2% 未満の増加が見られ、BLOB トランザクションの総コストへの影響は最小限であることが示唆されています。
MIN_BLOB_BASE_FEE
の調整に加えて、超過 BLOB ガスの計算方法にも小さな変更が加えられました。以前は、 excess_blob_gas
の計算によって、BLOB 基本料金が望ましくないほど急上昇する可能性がありました。これを防ぐために、EIP では、フォークの高さで超過 BLOB ガスをリセットする変更が導入されています。この調整により、フォーク イベント周辺の移行がよりスムーズになります。
EIP-7762 の提案以来、かなりの議論が巻き起こっています。研究者は、この提案の背後にある動機と価格発見の問題に対処する必要性についてはおおむね同意していますが、いくつかの懸念は残っています。主な問題の 1 つは、頻繁なプロトコル調整が Ethereum の安定性に及ぼす潜在的な影響です。定期的な微調整により、予期しない複雑さとリスクが生じる可能性があります。
もう 1 つの懸念は、適切な最低 BLOB 基本料金を決定することです。225 wei という恣意的な選択には確固とした実証的根拠がないため、この値がプロトコルの長期目標をサポートすることを確認するためにさらなる調査が求められています。この基本料金の確固たる根拠を確立することは、潜在的な不安定性や意図しない市場の歪みを回避するために不可欠です。
EIP-7691 は、ブロックあたりの最大 BLOB 数を増やすという単純な変更を提案しています。現在、上限はブロックあたり 6 BLOB で、目標は 3 です。EIP-7691 は、この制限 (現時点では正確な数値はありません) を上げることで、ロールアップは Ethereum のコンセンサス安定性を損なうことなく、より高いスケーラビリティを実現できると示唆しています。
ブロックあたりの BLOB 数を増やすと、Ethereum ピアツーピア (p2p) ネットワークで送信されるデータの合計サイズが増加し、コンセンサスに達するまでに遅延が生じる可能性があります。各 BLOB には 128 KiB のデータが含まれるため、6 つの BLOB を合わせると 784 KiB になります。Ethereum の最大ブロック サイズは約 2 MB であるため、BLOB を含め、スロットごとに送信されるデータの合計は約 2.78 MB に達する可能性があります。
ブロブ数が増えるとデータ サイズも大きくなり、ブロックとブロブがノード間で伝播するのに必要な時間が長くなります。この遅延は、バリデーターが各スロットが終了する前の 4 秒以内に証明を提出する必要があるため、Ethereum のコンセンサス プロセスに問題を引き起こす可能性があります。したがって、コンセンサスの安定性を確保するには、これらの伝播時間を慎重に管理する必要があります。
各 BLOB は個別のチャネルを介して伝播されるため、BLOB 数の増加はコンセンサスに大きな影響を与えないと主張する人もいるかもしれません。ただし、ノードはすべての BLOB とブロック データが到着するまで待機する必要があるため、BLOB 数が増えると待機時間が長くなる可能性があります。
EIP-4844 に続く実証分析 ( 投稿 1 、 投稿 2を参照) によると、フォーク率は実装後に増加しており、ブロックあたりの BLOB 数とともに上昇しています。以下のグラフは、2024 年 4 月 6 日から 6 月 6 日までの BLOB 数別の再編成率を示しています。最大 6 個の BLOB を含むブロックは、4 個未満の BLOB を含むブロックよりも大幅に高い再編成率を示しており、EIP-4844 が Ethereum のコンセンサス セキュリティに与える影響について懸念が生じています。
再編成はさまざまな理由で発生する可能性がありますが、P2P ネットワーク全体のデータ負荷が高いことは、1 つの要因にすぎません。クライアントの実装が最適でないことも、再編成率に影響する可能性があります。 私の最初の分析では、データ可用性 (DA) 時間、つまりノードが最後の BLOB が到着するまで待機する時間は最小限で、平均 20 ミリ秒未満で、0 個の BLOB を含むブロックと 6 個の BLOB を含むブロックの差は 5 ミリ秒未満であることが示されています。ノードがアテステーションを送信する前に約 4000 ミリ秒待機することを考えると、この遅延は無視できるほど小さく、コンセンサスに重大な影響を与える可能性は低いようです。下のグラフは、ブロックに含まれる BLOB の数が異なる場合に推定される DA 時間を示しています。
さらに、 Toni の分析によると、EIP-4844 の実装以来、全体的な再編成率は低下しています。以前のデータでは、6 月まで再編成率と BLOB 数の間に強い相関関係が見られましたが、過去 3 か月間の最新のデータでは、BLOB 数が異なるブロック間での再編成率の差は最小限であることが明らかになっています。これらの結果は、Ethereum クライアントのパフォーマンスが継続的に改善されていることによるもので、BLOB 制限を引き上げてもコンセンサスの安定性に大きなリスクは生じないことを示唆しています。
最近、Vitalik は「PectraA に EIP-7623 を追加し、小さなブロブ数の増加 (例: ターゲット 3 -> 4、最大 6 -> 8) を検討する必要があると思います」と提案しました。EIP-7623 がこの増加をどのように促進できるかを理解するために、まずその中核となる提案を検討してみましょう。(EIP-7623 の詳細な説明については、 こちらを参照してください)
EIP-7623 では、主にデータ可用性 (DA) を目的とするトランザクションについて、コールデータのガス コストを調整することを提案しています。基本的に、コールデータのサイズに比べて実行ガスが少ないトランザクションでは、コールデータの使用に対して、より高いガス コスト (最大 3 倍) が発生します。したがって、大きなコールデータを含みながら EVM 実行が最小限のトランザクションではコストが高くなり、DA 関連の機能ではコールデータよりも BLOB の使用が推奨されます。
この調整の背後にある理論的根拠は、DA フレームワークを最適化しながら、毎日の非 DA ユーザー トランザクションへの影響を最小限に抑えることです。DA 固有のトランザクションのコールデータ コストを増やすことで、EIP-7623 は、データ量の多い操作をコールデータから BLOB に移行させ、ネットワークのストレージと DA の効率を最適化します。さらに、この提案は、最悪のケースのブロック サイズを 2.78 MB から約 1.2 MB に削減することを目指しており、Ethereum の平均ブロック サイズである約 125 KB が、潜在的にはるかに大きな制限に達する可能性がある現在のギャップに対処します。
EIP-7623 が最大ブロック サイズを効果的に削減すると、より大きな BLOB 数のための余地が生まれ、EIP-7691 の目標をサポートします。DA の calldata への依存度が減るため、BLOB の数が増えても、最悪の状況でも合計データ サイズは管理可能なままです。EIP-7623 と EIP-7691 のこの調整により、最大ブロック サイズを持続可能な制限を超えて増やすことなく、より大きな BLOB スループットを実現できます。
この記事では、Ethereum の BLOB 機能の強化に重点を置いた最近の EIP を紹介しました。EIP-7762 は、需要の急増時に価格発見を高速化し、全体的な BLOB トランザクション コストへの影響を最小限に抑えるために、最小 BLOB 基本料金を引き上げることを提案しています。EIP-7691 は、ブロックあたりの BLOB 数を増やして、Ethereum のデータ可用性 (DA) レイヤーをさらに拡張することを目指しています。BLOB 数が増えると、需要のピーク時に BLOB 基本料金の増加がより制御され、よりスムーズな価格調整が可能になります。
これらの提案された変更については、詳細な議論が行われています。たとえば、ターゲット BLOB 数を 4 に設定し、最大 BLOB 数を 6 に設定することや、基本料金の更新ルールを対称にするか非対称にするかを決定することなどが議論されています。追加の考慮事項には、余剰 BLOB ガスの正規化と、 BLOB 基本料金の更新率の調整が含まれます。
Blob は Ethereum のエコシステムに最近追加されたもので、アプリケーション層とコンセンサス セキュリティの両方に影響を与えるため、Blob に関連するすべての変更には注意が必要です。とはいえ、Ethereum は急速に進歩しており、研究コミュニティは開発を推進し、ネットワークが成長し進化し続けるように熱心に取り組んでいます。
著者注: この記事のバージョンは元々こちらで公開されました。