▼目次
前提
本レポートでは、暗号資産イーサリアム（ETH）をネイティブ通貨とするイーサリアムネットワークの2025年以降のロードマップについて、Vitalik Buterin（ヴィタリック・ブテリン）が2024年10月頃に自身のブログで公開した「Possible futures of the Ethereum protocol」シリーズに沿って解説します。このシリーズは高度な専門用語を多く含んでいますが、本レポートではできる限りわかりやすく噛み砕いて説明します。
「Possible futures of the Ethereum protocol」シリーズは全6部構成であり、本レポートも3本に分けて公開しています。
残りのレポートはこちらからご覧いただけます。
イーサリアム（ETH）の2025年以降ロードマップの概要｜わかりやすく解説
イーサリアム（ETH）の2025年以降のロードマップの概要｜スカージ（The Scourge）＆バージ（The Verge）
イーサリアムは、分散性やセキュリティを維持しつつ、システムのスケーラビリティ（拡張性）を高めることを目指しています。
イーサリアムのロードマップは、こうした目標達成に向けて解決すべき課題を段階的に分け、それぞれの課題に対するアップグレードを段階的に進めることで最終的なゴールを目指しています。
まずは、全体のロードマップの概要について説明します。
https://x.com/VitalikButerin/status/1741190491578810445
- マージ（The Merge）: 2022年9月に完了。イーサリアムはこのアップデートによってPoS（プルーフ・オブ・ステーク）への移行を達成し、エネルギー消費量を大幅に削減しました
- サージ（The Surge）: ロールアップやEIP-4844の導入を通じてスケーラビリティの向上に焦点を当て、秒間100,000件の取引処理を目指す段階です
- スカージ（The Scourge）: 経済的な中央集権化のリスクを低減し、バリデータノードの管理やブロック検証プロセスの改善に取り組みます
- バージ（The Verge）: レイヤー1のガスリミットを増やすことなくブロック検証効率を高め、ネットワークのスケーラビリティをサポートすることを目的とします
- パージ（The Purge）: プロトコルを簡素化し、技術的負債を削減することで、ネットワークへの参加コストを抑える取り組みです
- スプラージ（The Splurge）: エコシステム全体の成長やイーサリアムユーザーコミュニティの拡大に重点を置き、より広範な開発の促進を図ります
本レポートでは、イーサリアムが抱える履歴データやステート肥大化の問題を解決するためのイーサリアムのアップグレード「The Purge」フェーズ、およびEVM改善やアカウントアブストラクション（AA）、先進的な暗号技術導入を目指す「The Splurge」フェーズについて紹介します。
「The Purge」を理解することで、イーサリアムネットワークが不要な機能や冗長なデータを削減し、長期的なスケーラビリティを確保する手法を把握できます。
また「The Splurge」を理解することで、EVMの拡張性や高度なアカウント操作性、プライバシー保護技術など、これからのイーサリアムが提供し得る新たな価値や開発の可能性を見出せます。
これら両フェーズに関する理解は、ノード運営者、開発者、投資家、ユーザーなど多様な立場において、インフラコスト削減や技術的飛躍、ビジネスチャンス創出といった具体的なメリットをもたらします。
本レポートを通して、変革期にあるイーサリアムの全体像を俯瞰し、その進化がもたらす恩恵やリスクを冷静に評価する手掛かりを得られるでしょう。
イーサリアムのアップグレード・パージ（The Purge）
ここでは、イーサリアムのトランザクション履歴やステートデータが時間とともに増大し、ノード運用に大きな負担をもたらす問題への対処法、および使用されなくなった古い機能を削除することでどのような影響が考えられるのかを説明します。
履歴データの課題
現在、フル同期されたイーサリアムノードには実行クライアントで約1.1TB、コンセンサスクライアントで数百GBのディスク容量が必要です。
この大半を占める履歴データは、過去のブロック、取引、領収書などで構成されています。
これらのデータは、ガスリミットの増加がないにもかかわらず、毎年数百GBずつ増加し続け、ネットワーク全体の永続性に影響を与えています。
部分的な履歴保持
履歴データの検証には、特定のアクター（誰でも）が提供するMerkle Proofをネットワーク全体で検証する仕組みが利用されます。
このため、すべてのノードが全履歴を保持する必要はなく、一部のノードが選択的にデータを保存する形が可能です。
この考え方は、P2Pネットワークの一例であるTorrentネットワークと同様の仕組みです。
現在、イーサリアムでは履歴データの保存期間を限定する取り組みが進められています。
例えば、コンセンサス関連のブロックデータは約6か月間、L2ロールアップで必要なBlobデータは約18日間保存されています。
また、EIP-4444では、履歴ブロックや領収書の保存期間を1年とする提案が進行中です。
最終的には、各ノードが短期間（例：18日程度）のみデータを保存し、その後は分散型ネットワークで履歴データを共有・保存する形を目指しています。
このため、BlobデータとErasure codesを活用し、データの可用性と耐障害性を高める仕組みが検討されています。
今後の展望
履歴データの分散保存に向けて、以下の2つの方法が考えられています：
- 既存のBittorrent（ビットトレント）ライブラリの活用：BittorrentのP2Pネットワークを用いて履歴データを効率的に共有・保存する方法です。この仕組みでは、各ノードが全データを保持する必要がなく、ネットワーク全体で分散的にデータを管理できます。Bittorrentの成熟した技術を活用することで、導入の容易さと信頼性が期待されます。
- Portal Network（ポータルネットワーク）の導入：イーサリアム独自の分散型ソリューションとして、Portal Networkが開発されています。このアプローチでは、DHT（分散ハッシュテーブル）を活用してライトクライアントが履歴データや現在のチェーン情報にアクセス可能にします。Portal Networkは軽量なプロトコル設計で、ノード間で効率的に情報を交換できる仕組みを提供します。
参考：https://ethereum.org/ja/developers/docs/networking-layer/portal-network/
いずれの方法も、すべてのクライアントが同期的にソフトウェアを有効化することが不可欠です。
これを行わない場合、ノードが他のノードから必要なデータを取得できず、システム全体の動作に支障をきたすリスクがあります。
古い履歴データの扱い
古い履歴データをどの程度利用可能にするかも重要な検討事項です。
単純な方法としては、保存を停止し、既存のアーカイブノードや中央集権型プロバイダーに依存する方法があります。
しかし、このアプローチではイーサリアムが「永久的な記録を保存する基盤」としての価値が損なわれる恐れがあります。
困難な実装となりますが、安全なアプローチは、まず履歴を分散型で保存するためのtorrentネットワークを構築・統合することです。
この場合、ノードに対する「履歴保存の確認」に関して以下の2つのポイントが重要です。
- どれだけ多くのノードが履歴データを保存していることを保証するか？： プルーフ・オブ・ステーク（PoS）バリデーターに対して、一定割合の履歴を保存する義務を課し、その保存状況を定期的に暗号学的にチェックするという方法。
- プロトコルへの統合： Portal Networkなどを用い、履歴データを保存するアーカイブノードが不足している場合でも、ネットワークから履歴データを直接取得できる仕組みを整えます。これにより、他のアーカイブノードがオフラインの場合でも完全な同期が可能となります。
ステートを減らす
クライアントが履歴データを保存しなくなっても、ステート（アカウントの残高やnonce、コントラクトコード、ストレージなど）の増加により、クライアントのストレージ要件は依然として拡大します。
ステートは年間約50GBのペースで増加すると見積もられており、この問題はイーサリアムの持続可能性にとって極めて重要です。
履歴データと同様に、ステートデータに有効期限を設けることは、難易度が高いと考えられます。
EVMは、ステートオブジェクトが一度作成されると、どの取引でもアクセス可能であるという前提で設計されているので、ステートの増加を抑制しつつネットワークの整合性とユーザビリティを維持する新たなアプローチが求められています。
The Vergeで実現可能予定のステートレスクライアントが導入されれば、このステートに関する問題は気にする必要がない可能性もありますが、ステートレス性に頼りすぎるのは避けたいという議論もあります。
ステートの保存に関する解決策として、「部分的に有効期限を適用させる方法」と「アドレス期間という新たな仕組みを導入して解決する方法」の２つの手法について説明します。
ステート基本構造と課題
現在、ステートオブジェクトが作成される主な方法は以下の3つです：
- 暗号資産イーサリアム（ETH）を新しいアカウントに送信する
- 新しいコードを持つアカウントを作成する
- 未使用のストレージスロットに値を設定する
これらのオブジェクトは作成後、永続的に保存され、いつでも読み取ることが可能です。
この永続性がイーサリアムの利便性とセキュリティを支えてきましたが、同時にステート肥大化を招く要因でもあります。
ステート肥大化問題のための有効期限設定とその要件
ステート肥大化を防ぐためには、ステートオブジェクトに有効期限を設定し、期限切れのオブジェクトを自動的に削除する仕組みが必要です。
この取り組みでは以下の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つのサブツリーに集中させ、定期的に取引を行うことで木の更新を強制し、ノードに過剰な負担をかける可能性があります。
アドレス期間に基づくステート有効期限
さらに進んで、32バイトのstubすら保存しない形でステートの成長を抑える方法も検討されています。
このアプローチでは、ステートデータが完全に削除された場合の競合リスク（削除されたデータの場所に新しいデータが書き込まれる）が課題となります。
部分的なステート有効期限では、stubが競合を防ぎますが、完全な有効期限ではこれを保証する仕組みが必要です。
そこで、アドレス期間ベースの設計が提案されています。
この方法では、すべてのステートデータを保存するのではなく、期間ごとに新しいステートツリーを追加し、古いツリーは固定します。
フルノードは最新の2つのツリーだけを保存し、古いデータにアクセスする場合はMerkle証明を提供して復元します。
これにより、期限切れのステートデータが最新ツリーに移行され、成長を抑えられます。
アドレス期間とは、アドレスの一部に埋め込まれた期間番号を指します。
この設計では、アドレス期間Nのアドレスは期間N以降のステートツリーでしか使用できません。
新しいステートデータは、アドレス期間NまたはN-1のツリーに保存されますが、古いツリーにアクセスする場合は証明が必要です。
この仕組みは、既存のイーサリアム特性をほぼ維持しつつ、追加コストを抑える設計となっています。
しかし、この設計を実現するには、アドレス形式の変更が必要です。変更の種類も２種類提案されています。
● アドレス空間の拡張
32バイトのアドレスフォーマットを導入し、バージョン番号、アドレス期間番号、拡張されたハッシュを含む形式を採用します。
赤色部分がバージョン番号です。
オレンジ色の4つのゼロは空きスペースを意味し、将来的にはシャード番号が入る可能性があります。
緑色部分がアドレス期間番号です。
青色部分が26バイトのハッシュです。
ここでの主な課題は、後方互換性です。
既存のスマートコントラクトは、20バイトのアドレスを前提に設計されており、多くの場合、この仕様に基づいたバイトパッキング技術を活用しています。
バイトパッキングとは、イーサリアムのスマートコントラクトにおいて、データをストレージやメモリに効率的に格納する手法です。
ストレージは256ビット（32バイト）単位で扱われますが、このスロットに収まりきらないデータを格納すると、新たなスロットが使用されるため、ガスコストが増加します。
バイトパッキングは、複数の小さなデータを1つのスロットに詰め込むことで、ストレージ使用量を抑え、ガスコストを最適化する技術です。
アドレスが20バイトであることを前提として実装されているので、アドレスが32バイトになると実装が破綻してしまいます。
この課題に対処するための一つの提案として、変換マップの導入があります。
このアプローチでは、新しい形式の32バイトアドレスを使用する際に、旧形式の20バイトアドレスを変換して扱います。
具体的には、旧形式のコントラクトは、新しい形式のアドレスに対して20バイトのハッシュを参照することで互換性を維持します。
しかし、この方法には複雑性が伴います。
変換マップの管理や、安全性の確保、そしてコントラクト間での一貫性を維持する仕組みを設計する必要があり、これが実装上の大きな障壁となります。
● アドレス空間の収縮
逆に、アドレス空間を縮小するアプローチでは、特定のサブレンジ（例：特定のプレフィックスを持つアドレス）を禁止し、その範囲をアドレス期間とハッシュの短縮版に使用します。
このアプローチが犠牲にする主な点は、カウンターファクチュアルアドレス（Counterfactual Addresses）に対するセキュリティリスクです。
カウンターファクチュアルアドレスは、まだスマートコントラクトのコードがブロックチェーン上に展開されていないが、既に資産や権限を保持しているようなアドレスのことを指します。
このリスクは、誰かが（まだ公開されていない）コードを持つと主張するアドレスを作成し、そのアドレスにハッシュが一致する別の有効なコードを持つというものです。
このような衝突を計算するには、現在では2^80回のハッシュ計算が必要ですが、アドレス空間の収縮により、この数は2^56回のハッシュ計算にまで減少します。
機能の整理
イーサリアムプロトコルのシンプルさは、セキュリティやアクセシビリティ、中立性を支える重要な要素です。
しかし、時間の経過とともにプロトコルは複雑さを増し、バグのリスクや保守性の問題を引き起こします。
この複雑さを管理するため、次のような選択肢が考えられます：
- プロトコルの変更を停止し、固定化する
- 機能を削除して複雑さを削減する
- 変更を減らしつつ、複雑さも少しずつ減らしていく
ここでは、具体的な複雑性の削減や削除の対象となる機能について説明します。
SELFDESTRUCTオペコードの削除：成功例としての指針
例えば、すでにほぼ完了しており、他の問題をどのように扱うかの指針となる例として、SELFDESTRUCTオペコードの削除があります。
SELFDESTRUCTオペコードは、DoS攻撃への対策でクライアントに大きな負担を強いてきました。
本来の目的は、任意のステートをクリアし、ステートを削減することでしたが、実際にはほとんど使用されていません。
Dencunハードフォークでは、このオペコードが同一トランザクション内で作成されたアカウントのみに制限され、DoS問題が解消されました。
将来的には、SELFDESTRUCTの完全な削除が妥当と考えられています。
複雑さ削減のための具体的提案
プロトコルを簡素化するために削除可能だと考えられる例をいくつか紹介します。
- RLP → SSZ への移行： イーサリアムのオブジェクトは元々RLPというエンコーディングを使用してシリアライズされています。現在のRLPエンコーディングは型がなく複雑ですが、Beaconチェーンで使用されているSSZはシリアライズとハッシュ処理に優れています。最終的には、RLPを廃止してすべてのデータ型をSSZに移行することを目指します。
- 古いトランザクションタイプの削除：既存の多くのトランザクションタイプは不要とされています。これらを削除する代わりに、アカウントアブストラクションを導入し、スマートアカウントが旧型トランザクションを処理できるようにする方法も検討されています。
- LOGの改革：Bloomフィルタを使用した複雑なログ構造はクライアントであまり利用されておらず、削除が検討されています。代わりに、SNARKsを活用した分散型ログ読み取りツールに焦点を当てています。
- Beaconチェーン同期委員会の削除：ライトクライアント検証を目的とした同期委員会は複雑さを増していますが、SNARKsの活用により不要になる可能性があります。これにより、プロトコルが簡素化されます。
- データフォーマットの統一：実行ステート、コンセンサスステート、blobデータで異なるフォーマットを使用している点が非効率的です。これを統一することで、ステートレスクライアント向けの簡単な証明やシリアライズの標準化が実現します。
- Beaconチェーンの委員会の削除：もともとシャーディングのために導入されましたが、現在ではL2やblobを通じてシャーディングを行っているため、委員会は不要です。これも削除の候補です。
- エンディアンの統一：EVMはビッグエンディアン、コンセンサス層はリトルエンディアンを採用しており、これが非効率の原因となっています。統一が検討されています。
EVM（Ethereum Virtual Machine）内部での簡素化
- ガスメカニズムの簡素化: 現在のガスルールは複雑で、予測が困難です。例えば、ストレージの読み書きコストやメモリ充填ルールを単純な式に統一することが提案されています。例えば、EIP-4762でステートレスガス費用変更があり、これによりすべてのストレージ関連のコストを単純な式に統一できます。
- プレコンパイルの削除: プレコンパイルは複雑で、使用頻度も低いものが多くあります。これらを削除し、EVMコードに置き換えることが可能です。
- ガスの可視性の削除: EVM実行中の残りガス量の確認を廃止することで、プロトコルの簡素化が可能になります。これにより、いくつかのアプリケーション（特にスポンサー付きトランザクション）が破綻しますが、将来的にはより高度な多次元ガスのバージョンに向けてアップグレードを簡素化することができます
- 静的解析の改善: 動的ジャンプ命令を削除またはコストを引き上げることで、EVMコードの静的解析が容易になり、最適化が進みます。
トレードオフと方向性
機能の削除には、プロトコルの簡素化と後方互換性維持のバランスが求められます。
イーサリアムの価値は、アプリケーションを数年後も動作させる信頼性にありますが、これを過剰に追求すると不要な機能が残り続けるリスクがあります。
価値のない機能を守るためにリソースを浪費することは避けるべきです。
その機能がわずかな利用しかない場合、削除し、必要に応じて補償金を支払う選択肢も検討されます。
例えば、もしイーサリアム上で特定の機能を使っているアプリケーションが2つしかなく、そのうち1つは数年間ユーザーがゼロで、もう1つはほとんど使われておらず、合計で57ドルの価値しか守られていないのであれば、その機能は削除すべきであり、必要なら57ドルを補償金として支払うべきです。
現状、イーサリアムのプロトコル設計は依然としてパレートフロンティア（効率的な設計の最前線）から遠く、改善の余地が多く残されています。
このため、バランスを取りながらも、効率化を進める努力が必要とされています。
イーサリアムのアップグレード・スプラージ（The Splurge）
ここでは、EVMの改善やアカウントアブストラクション（AA）、Obfuscation（難読化）、one-shot signaturesなど、Ethereumの次世代技術に関連するトピックを扱います。
EVM（Ethereum Virtual Machine）のさらなる改善
EOF（EVM Object Format）の導入
現在のEVMには、静的解析の困難さや形式的検証の不足、拡張性の課題があります。
これらを解決するために次回のハードフォークで導入予定の「EVM Object Format（EOF）」は、コードとデータを分離し、デプロイ時のコード検証を行う仕組みを導入します。
この設計により、パフォーマンス向上や将来的な拡張が可能になります。
https://www.youtube.com/watch?v=NMRLOwVkh88 のスライド4ページ目
EVM-MAXとSIMDの活用
EVMのさらなる拡張として、「EVMモジュラー算術拡張（EVM-MAX）」が提案されています。
これは、mod演算（剰余計算）専用の演算を導入し、モンゴメリー乗算のような特定のアルゴリズムにおける計算効率を高めるものです。
また、新しい専用メモリ空間を設けることで、これらの操作を他の演算から分離します。
さらに、EVM-MAXに加えてSIMD（Single Instruction, Multiple Data）命令を採用する提案もあります。
SIMDは複数のデータを同時に処理できる技術で、ハッシュ関数やSTARKs、格子ベース暗号などの分野で効率を大幅に向上させることが可能です。
これらを組み合わせることで、EVMのパフォーマンスを大幅に向上させることが期待されています。
EVM（Ethereum Virtual Machine）改善のトレードオフ
EVMの改善には、L1の複雑さとインフラ全体の複雑さとの間でトレードオフがあります。
EOFの導入は、効率化や柔軟性をもたらす一方で、実装の複雑さや作業量の増加を伴います。
EOFを導入しない選択肢も理論上可能ですが、それにより将来的なEVMアップグレードが難しくなるリスクがあるため、現時点では実装が優先されています。
イーサリアムのAccount Abstraction
概要
アカウント抽象化（Account Abstraction, AA）は、従来のExternally Owned Account（EOA）とコントラクトアカウントの機能差を解消し、コントラクトアカウントからもトランザクションを発行できるようにする技術です。
この仕組みにより、ウォレットのセキュリティ向上やトランザクション処理の柔軟性が実現します。
EOAの主要な課題は、秘密鍵の流出による資産盗難リスクや、ECDSA署名の量子コンピュータへの耐性不足にあります。
AAはこれらの課題を克服し、アカウントの検証ロジックを任意のEVMコードに基づいて実装することで、以下の機能の実現を可能にします：
- 量子耐性暗号への切り替え
- 鍵の更新やセキュリティ対策
- マルチシグウォレットやソーシャルリカバリー
- 操作内容に応じた異なる鍵の使用
- リレイヤー不要のプライバシープロトコルの実現
アカウント抽象化は、単に検証を抽象化するだけでなく、あらゆるものを抽象化することを目指しています。
これには、認証（誰が操作を実行できるか）、権限付与（何をできるか）、再実行防止、ガス支払い、実行などが含まれます。
いくつかの課題、特に「利便性」に関連する問題は、MPC（多人数計算：Multi Party Computation）やEIP-7702といった技術を活用することで段階的に解決可能です。
しかし、アカウント抽象化の本質的な目標を達成するには、元々の問題に直接取り組む必要があります。
つまり、スマートコントラクトコードにトランザクション検証の制御を委ねる仕組みを作ることです。
これまでこのアプローチが採用されなかった主な理由は、安全に実装するのが難しいからです。
スマートコントラクトによる検証は強力ですが、設計を誤るとイーサリアム全体のセキュリティや効率性に重大なリスクをもたらします。このため、安全性と実装の難易度をバランスさせながら開発を進める必要があります。
ERC-4337による実現
長年の議論を経て、アカウント抽象化を安全に実現する解決策として登場したのがERC-4337です。
このERCは、以下の問題に対処します：
マルチ無効化問題
同一の検証ロジックを持つ複数のアカウントが、検証条件を満たすトランザクションをメモリプールに送信した場合、1つのトランザクションが条件を変更すると他のトランザクションが無効化される問題です。これにより、攻撃者はメモリプールをスパムしてネットワークリソースを消費させることが可能になります。
解決方法
ERC-4337は、トランザクションを「検証フェーズ」と「実行フェーズ」に分け、それぞれを独立して処理することでこの問題を回避します。検証フェーズでは、アカウント固有の条件のみをチェックし、実行フェーズでは他のアカウントや環境変数に依存しない形で処理が行われます。これにより、トランザクションの相互干渉を防止します。
さらに、Paymasters（他アカウントの手数料を代行して支払う仕組み）やAggregators（署名の効率的な集約）といった拡張機能が導入され、利便性が向上しています。
プロトコルへ組み込む
ERC-4337は、当初Ethereumクライアントの開発者がMergeに集中していたため、他の機能に取り組む余裕がなかったことから、プロトコル外の標準（ERC）として設計されました。
このため、 ERC-4337は通常の取引の代わりに「UserOperation」という独自のオブジェクトを使用しています。
しかし、最近になって、少なくともその一部をプロトコルに組み込む必要があることが認識されてきました。
その主な理由は次の2つです：
- 効率の改善： 現行のERC-4337はバンドルごとに高いガスオーバーヘッドが発生するため、直接的な組み込みが望まれています
- プロパティの引き継ぎ： イーサリアムのインクルージョン保証などの特性をアカウント抽象化に適用するためには、プロトコル内での統合が必要です
トレードオフと課題
残されている主な課題は、アカウント抽象化を完全にプロトコルに組み込むことです。
最近、注目されているアカウント抽象化のプロトコル内実装を示すEIPはEIP-7701で、これはEOFの上にアカウント抽象化を実現するものです。
このEIPでは、アカウントに検証用のコードセクションを別々に持たせることができ、そのコードセクションが設定されている場合、そのアカウントからの取引の検証ステップでそのコードが実行される仕組みとなります。
https://vitalik.eth.limo/general/2024/10/29/futures6.html
AAのプロトコル実装には、「早期の実装による普及」と「理想的な設計を追求するための時間確保」というトレードオフがあります。
例えば、特定のユースケースに早期に対応しつつ、他の用途には時間をかけて解決策を模索する「ハイブリッドアプローチ」が現実的な選択肢となります。
また、まずはL2で展開させる案も有望ですが、これにはL1や他のL2との互換性確保が前提となります。
これを実現するには、L1およびL2間でアカウント抽象化の共通基盤を構築する必要があります。
Obfuscation and one-shot signatures
神のプロトコルと現在地
ニック・サボが1997年に発表した有名なエッセイ「神のプロトコル（God protocols）」では、多くのマルチパーティーアプリケーションが、相互でのやり取りを管理するために「信頼された第三者」に依存していると指摘されています。
彼の見解では、暗号技術の役割は、特定の第三者への信頼を必要とせずに、同じ役割を果たす「シミュレートされた信頼された第三者」を作り出すことにあります。
https://nakamotoinstitute.org/library/the-god-protocols/
現在、ブロックチェーン技術はデータの改ざんや検閲を防ぎ、透明性を保つ仮想コンピュータを提供する形で、神のプロトコルの一部を実現しています。
しかし、現在の暗号技術はアプリケーションごとにプロトコルを設計する必要があり、全ての課題に対応できているわけではありません。
この限界を打破するために、プログラム可能な暗号技術が進化してきました。
zk-SNARKs、FHE、識別不可能な難読化（IO）、量子ワンショット署名
zk-SNARKs
ZK-SNARKs（Zero-Knowledge Succinct Non-Interactive Argument of Knowledge）は、特定の命題を証明しながらデータの内容を明かさずに検証を可能にする技術です。
これにより、データ所有者がプライバシーを保ちながら信頼性を証明できます。
ただし、ZK-SNARKsはデータ所有者がその内容を完全に知っている必要があり、データの操作には所有者の関与が必須となります。
この制限を克服する技術として次のプロトコルが登場しました。
完全準同型暗号（FHE）
FHE（Fully Homomorphic Encryption）は、暗号化されたデータに対して計算を実行し、その結果も暗号化された状態で得られる技術です。
これにより、データを復号せずに操作できるため、プライバシーを保ちながら計算が可能です。
例えば、投票システムではFHEを使うことで、ユーザーの秘密投票を守りつつ、正確な集計を行えます。
FHEはかつて非効率とされていましたが、技術の進展により、実用可能なレベルに達しつつあります。
それでも、復号鍵の管理や分散型のセットアップについての課題が残っています。
識別不可能な難読化（IO）
IO（Indistinguishability Obfuscation）は、プログラムの内部構造を完全に隠し、「暗号化されたプログラム」を作成することで、その機能を外部に提供する技術です。
例えば、秘密鍵を埋め込んだプログラムを配布し、特定の条件下でのみその鍵を使用できるようにすることが可能です。
この技術は、ZK-SNARKsやFHEをさらに強化し、ほぼ全ての暗号機能を統合的に実現する基盤となります。
量子ワンショット署名
難読化されたプログラムができないことは、ただ一つ、自己複製を防ぐことです。
しかし、この問題についても、さらに強力な解決策が待ち構えています。
それが「量子ワンショット署名」です。
量子コンピュータを利用したワンショット署名は、特定のメッセージに一度だけ署名を行う技術です。
この技術は、特定の操作を厳密に制限する目的で使用され、難読化されたプログラムやその他の暗号技術と組み合わせることで、強力なセキュリティ保証を提供します。
どのようにしてアプリケーションを実現させるか
暗号技術の各プリミティブ（ZK-SNARKs、FHE、IO、ワンショット署名など）は、新たな力をアプリケーションに提供します。
その例として、投票システムを見てみましょう。
投票システムは、多くのセキュリティ特性（プライバシー、検証可能性、強制耐性など）を満たす必要があるため、良い例となるでしょう。
まず、単純に投票をブロックチェーン上に公開することで、投票結果が誰でも検証可能になり、検閲耐性が確保されます。
ただし、この方法では投票者のプライバシーが保たれません。
次に、ZK-SNARKsを導入すると、各投票を匿名化し、認可された投票者のみが一度だけ投票できる仕組みが実現します。
これにより、プライバシーが確保され、投票者の情報が守られます。
さらに、MACI（Minimal Anti-Collusion Infrastructure）を組み合わせることで、投票内容を中央サーバーで暗号化し、結果の集計を行いながら、投票内容や重複を排除することが可能になります。
この結果はZK-SNARKsで証明されるため、サーバーの誠実さが保証され、ユーザーは自分の投票内容を第三者に証明することができなくなります。
これにより、賄賂や強制的に投票させるリスクが排除されます。
さらに、FHEを活用すれば、投票内容を暗号化したまま集計処理を実行できます。
その後、N/2-of-Nの復号計算で結果を復号することで、強制耐性がより向上します。
難読化されたプログラムを使用すると、集計の過程がブロックチェーンコンセンサスやProof of Workによって制御され、許可がない限り出力を返さない仕組みを構築できます。
この設計により、プライバシーとセキュリティの保証がさらに強化されます。
最後に、量子コンピュータを活用したワンショット署名を導入すれば、特定のメッセージに対して一度だけ署名が行われ、強制耐性が真に完全なものとなります。この技術の組み合わせにより、非常に強力で安全な投票システムが実現します。
他の応用例
難読化やワンショット署名は、投票以外の多くの分野にも応用可能です。
例えば、DAOやオンチェーンオークションなどの秘密状態を持つ分散型アプリケーション、暗号化されたトランザクションmempool、さらには量子マネー（量子通貨）の構築などが挙げられます。
ブロックチェーンなしで重複支出問題を解決できますが、より複雑なアプリケーションは依然としてブロックチェーンを必要とします。
これらの技術を効率的に実装できれば、イーサリアムやその他のブロックチェーンプラットフォームの能力を大幅に拡張することができます。
今後の課題
これらの技術の実現には、いくつかの課題があります。
特に、FHEやIO技術の効率性向上と、これらが意図通りに動作することを保証するための正確性の検証が必要です。
また、これらの技術を商業システムや分散型アプリケーションで普及させるための基盤整備も重要です。
これらの暗号技術は、イーサリアムのような分散型プラットフォームの可能性を飛躍的に広げる鍵となるでしょう。
総論
本レポートでは、「Possible futures of the Ethereum protocol」シリーズのPart 5およびPart 6に基づき、残された技術負債に関する課題や、イーサリアムの永続性に関する技術的な選択肢と、それぞれの課題について解説しました。
全ての内容を網羅的に解説することはできず、例えばEOFの利点、VDFについてなどは割愛しました。
詳細に興味のある方は、本レポートの参照元を参照してください。
これまで曖昧なまま見過ごされてきた履歴データの膨張やステート肥大化、さらには非効率な機能の存在といった問題が、イーサリアムのアップグレード「The Purge」フェーズによって次々と明確化されてきています。
特に、長年困難と見られていた履歴データの分散保存やステート有効期限設定といった技術的課題に対し、実現性のある解決策が示され始めている点は、非常に注目すべき進展といえます。
さらに、イーサリアムの「The Splurge」フェーズでは、EVM拡張やアカウントアブストラクション、洗練された暗号技術の導入により、開発者・ユーザー双方にとって想像以上の柔軟性や効率性をもたらす新たな可能性が拓かれつつあります。
これらの改革が本格的に実現すれば、イーサリアムは軽量かつ強固なインフラを獲得し、より多くのノードやユーザーが参加しやすい、真に分散化されたネットワークへと進化するでしょう。
こうした動きは、イーサリアムエコシステム全体を一層持続可能で魅力的なものへと変貌させる、大きな原動力となっていくことが期待されます。
「Possible futures of the Ethereum protocol」シリーズは全6部構成であり、本レポートも3本に分けて公開しています。
残りのレポートはこちらからご覧いただけます。
イーサリアム（ETH）の2025年以降ロードマップの概要｜わかりやすく解説
イーサリアム（ETH）の2025年以降のロードマップの概要｜スカージ（The Scourge）＆バージ（The Verge）
【ご注意事項】
本記事は執筆者の見解です。本記事の内容に関するお問い合わせは、株式会社HashHub（https://hashhub.tokyo/）までお願いいたします。また、HashHub Researchの各種レポート（https://hashhub-research.com/）もご参照ください。
提供：HashHub Research
執筆者：HashHub Research
