Ethereumの2025年以降のロードマップの概観｜The Purge & The Splurge

2024年12月19日

この記事を簡単にまとめると（AI要約）

前提

本レポートでは、Ethereum（イーサリアム）の2025年以降のロードマップについて、Vitalik Buterin（ヴィタリック・ブテリン）が2024年10月頃に自身のブログで公開した「Possible futures of the Ethereum protocol」シリーズに沿って解説します。このシリーズは高度な専門用語を多く含んでいますが、本レポートではできる限りわかりやすく噛み砕いて説明します。

「Possible futures of the Ethereum protocol」シリーズは全6部構成であり、本レポートも3本に分けて公開しています。残りのレポートはこちらからご覧いただけます。

また、以前公開されたロードマップには、今回説明するThe Scourgeは入っていません。より詳しく違いを知りたい方は、2022年に発表された2023年以降のロードマップについての以下のレポートを参照してください。

Ethereumの2023年以降のロードマップの概観

Ethereumは、分散性やセキュリティを維持しつつ、システムのスケーラビリティ（拡張性）を高めることを目指しています。Ethereumのロードマップは、こうした目標達成に向けて解決すべき課題を段階的に分け、それぞれの課題に対するアップグレードを段階的に進めることで最終的なゴールを目指しています。

まずは、全体のロードマップの概要について説明します。

https://x.com/VitalikButerin/status/1741190491578810445

The Merge: 2022年9月に完了。EthereumはこのアップデートによってPoS（プルーフ・オブ・ステーク）への移行を達成し、エネルギー消費量を大幅に削減しました
The Surge: ロールアップやEIP-4844の導入を通じてスケーラビリティの向上に焦点を当て、秒間100,000件の取引処理を目指す段階です
The Scourge: 経済的な中央集権化のリスクを低減し、バリデータノードの管理やブロック検証プロセスの改善に取り組みます
The Verge: レイヤー1のガスリミットを増やすことなくブロック検証効率を高め、ネットワークのスケーラビリティをサポートすることを目的とします
The Purge: プロトコルを簡素化し、技術的負債を削減することで、ネットワークへの参加コストを抑える取り組みです
The Splurge: エコシステム全体の成長やEthereumユーザーコミュニティの拡大に重点を置き、より広範な開発の促進を図ります

本レポートでは、Ethereumが抱える履歴データやステート肥大化の問題を解決するための「The Purge」フェーズ、およびEVM改善やアカウントアブストラクション（AA）、先進的な暗号技術導入を目指す「The Splurge」フェーズについて紹介します。

「The Purge」を理解することで、Ethereumネットワークが不要な機能や冗長なデータを削減し、長期的なスケーラビリティを確保する手法を把握できます。

また「The Splurge」を理解することで、EVMの拡張性や高度なアカウント操作性、プライバシー保護技術など、これからのEthereumが提供し得る新たな価値や開発の可能性を見出せます。

これら両フェーズに関する理解は、ノード運営者、開発者、投資家、ユーザーなど多様な立場において、インフラコスト削減や技術的飛躍、ビジネスチャンス創出といった具体的なメリットをもたらします。

本レポートを通して、変革期にあるEthereumの全体像を俯瞰し、その進化がもたらす恩恵やリスクを冷静に評価する手掛かりを得られるでしょう。

The Purge

本セクションでは、Ethereumのトランザクション履歴やステートデータが時間とともに増大し、ノード運用に大きな負担をもたらす問題への対処法、および使用されなくなった古い機能を削除することでどのような影響が考えられるのかを説明します。

履歴データの課題

現在、フル同期されたEthereumノードには実行クライアントで約1.1TB、コンセンサスクライアントで数百GBのディスク容量が必要です。この大半を占める履歴データは、過去のブロック、取引、領収書などで構成されています。これらのデータは、ガスリミットの増加がないにもかかわらず、毎年数百GBずつ増加し続け、ネットワーク全体の永続性に影響を与えています。

部分的な履歴保持

履歴データの検証には、特定のアクター（誰でも）が提供するMerkle Proofをネットワーク全体で検証する仕組みが利用されます。このため、すべてのノードが全履歴を保持する必要はなく、一部のノードが選択的にデータを保存する形が可能です。この考え方は、P2Pネットワークの一例であるTorrentネットワークと同様の仕組みです。

現在、Ethereumでは履歴データの保存期間を限定する取り組みが進められています。たとえば、コンセンサス関連のブロックデータは約6か月間、L2ロールアップで必要なBlobデータは約18日間保存されています。また、EIP-4444では、履歴ブロックや領収書の保存期間を1年とする提案が進行中です。

最終的には、各ノードが短期間（例：18日程度）のみデータを保存し、その後は分散型ネットワークで履歴データを共有・保存する形を目指しています。このため、BlobデータとErasure codesを活用し、データの可用性と耐障害性を高める仕組みが検討されています。

BlobやErasure codesによる冗長化については以下のレポートを参照してください。

Ethereumの大型アップグレード、Pectraの概要投資家に与える影響は？

今後の展望

履歴データの分散保存に向けて、以下の2つの方法が考えられています：

既存のBittorrentライブラリの活用
BittorrentのP2Pネットワークを用いて履歴データを効率的に共有・保存する方法です。この仕組みでは、各ノードが全データを保持する必要がなく、ネットワーク全体で分散的にデータを管理できます。Bittorrentの成熟した技術を活用することで、導入の容易さと信頼性が期待されます。
Portal Networkの導入
Ethereum独自の分散型ソリューションとして、Portal Networkが開発されています。このアプローチでは、DHT（分散ハッシュテーブル）を活用してライトクライアントが履歴データや現在のチェーン情報にアクセス可能にします。Portal Networkは軽量なプロトコル設計で、ノード間で効率的に情報を交換できる仕組みを提供します。

参考：https://ethereum.org/ja/developers/docs/networking-layer/portal-network/

いずれの方法も、すべてのクライアントが同期的にソフトウェアを有効化することが不可欠です。これを行わない場合、ノードが他のノードから必要なデータを取得できず、システム全体の動作に支障をきたすリスクがあります。

古い履歴データの扱い

古い履歴データをどの程度利用可能にするかも重要な検討事項です。単純な方法としては、保存を停止し、既存のアーカイブノードや中央集権型プロバイダーに依存する方法があります。しかし、このアプローチではEthereumが「永久的な記録を保存する基盤」としての価値が損なわれる恐れがあります。

困難な実装となりますが、安全なアプローチは、まず履歴を分散型で保存するためのtorrentネットワークを構築・統合することです。この場合、ノードに対する「履歴保存の確認」に関して以下の2つのポイントが重要です。

どれだけ多くのノードが履歴データを保存していることを保証するか？： プルーフ・オブ・ステーク（PoS）バリデーターに対して、一定割合の履歴を保存する義務を課し、その保存状況を定期的に暗号学的にチェックするという方法。
プロトコルへの統合： Portal Networkなどを用い、履歴データを保存するアーカイブノードが不足している場合でも、ネットワークから履歴データを直接取得できる仕組みを整えます。これにより、他のアーカイブノードがオフラインの場合でも完全な同期が可能となります。

ステートを減らす

クライアントが履歴データを保存しなくなっても、ステート（アカウントの残高やnonce、コントラクトコード、ストレージなど）の増加により、クライアントのストレージ要件は依然として拡大します。ステートは年間約50GBのペースで増加すると見積もられており、この問題はEthereumの持続可能性にとって極めて重要です。

履歴データと同様に、ステートデータに有効期限を設けることは、難易度が高いと考えられます。EVMは、ステートオブジェクトが一度作成されると、どの取引でもアクセス可能であるという前提で設計されているので、ステートの増加を抑制しつつネットワークの整合性とユーザビリティを維持する新たなアプローチが求められています。

The Vergeで実現可能予定のステートレスクライアントが導入されれば、このステートに関する問題は気にする必要がない可能性もありますが、ステートレス性に頼りすぎるのは避けたいという議論もあります。

ステートの保存に関する解決策として、「部分的に有効期限を適用させる方法」と「アドレス期間という新たな仕組みを導入して解決する方法」の２つの手法について説明します。

ステート基本構造と課題

現在、ステートオブジェクトが作成される主な方法は以下の3つです：

ETHを新しいアカウントに送信する
新しいコードを持つアカウントを作成する
未使用のストレージスロットに値を設定する

これらのオブジェクトは作成後、永続的に保存され、いつでも読み取ることが可能です。この永続性がEthereumの利便性とセキュリティを支えてきましたが、同時にステート肥大化を招く要因でもあります。

ステート肥大化問題のための有効期限設定とその要件

ステート肥大化を防ぐためには、ステートオブジェクトに有効期限を設定し、期限切れのオブジェクトを自動的に削除する仕組みが必要です。この取り組みでは以下の3つの目標を重視します：

効率性： 有効期限の管理が過剰な計算コストを伴わないこと。
ユーザーフレンドリー： 長期間利用がなかったユーザーでも簡単に資産（ETH、ERC20、NFTなど）に再アクセスできること。
開発者フレンドリー： 開発者が既存の開発モデルを大きく変更せずに対応できること。

シンプルな解決策の限界

期限付きのステートオブジェクトを作成するシンプルな方法として、各ステートオブジェクトに期限切れの日付を持つカウンターを追加し、そのカウンターをETHをburnすることで延長したり、データの読み書き時に自動更新する仕組みがあります。また、期限切れのオブジェクトを削除するプロセスをループで実行する方法も考えられます。

しかし、この方法には課題が多くあります。まず、期限切れを検知するプロセスを維持するために膨大な計算リソースや追加ストレージが必要になる可能性があり、計算コストとストレージ要件の増加を招きます。また、ユーザーがステートの有効期限やタイマー管理を意識しなければならず、利便性が低下する点も問題です。さらに、開発者にとっては、ストレージのリセットが発生するケースを考慮した実装が求められ、技術的な負担が増加します。

タイマーをコントラクト全体で共通化すれば、技術的な実装は簡素化されますが、経済的負担が増加します。開発者としても、ガス代以外にストレージを維持するコストがユーザーに転嫁される仕組みを整える必要があり、実装のハードルが高くなります。

イーサリアムのコア開発者コミュニティは、これらの課題に対応するため、以下の2つの解決策に集約しました。「部分的なステート有効期限」と「アドレス期間に基づくステート有効期限」です。以下でこの２つの解決策について解説します。

部分的なステート有効期限

ステートデータをいくつかのチャンク（塊）に分割し、すべてのノードがどのチャンクが空で、どのチャンクが使用中かを記録します。各チャンクのデータは最近アクセスされた場合のみ保存され、アクセスがない場合は削除されます。ただし、削除されたデータは「復元可能な形」で記録されており、復元には以前のデータがどうであったかを証明する必要があります。これが「部分的」という言葉の意味であり、完全に削除するのではなく復元を前提とした仕組みです。

https://vitalik.eth.limo/general/2024/10/26/futures5.html

この方法を設計するには、「最近」はいつからなのかという基準や「チャンク」の定義を明確にする必要があります。例えば、EIP-7736では上図のようなVerkleツリーを基にした「stem-and-leaf」デザインを採用しています。このデザインでは、アカウントヘッダー、コード、ストレージスロットなどが一つのstemに格納され、6か月間アクセスがなければデータは削除され、32バイトのコミットメント（stub）のみが保存されます。このデータを利用する際には、stubを使ってデータを復元する必要があります。

しかし、このアプローチには攻撃リスクもあります。攻撃者が大容量データを1つのサブツリーに集中させ、定期的に取引を行うことで木の更新を強制し、ノードに過剰な負担をかける可能性があります。

このレポートは有料会員限定です。

HushHubリサーチの紹介 >

法人向けプラン >

※免責事項：本レポートは、いかなる種類の法的または財政的な助言とみなされるものではありません。