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

2024年11月19日

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

前提

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

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

また、以前公開されたロードマップとの違いを知りたい方は、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ユーザーコミュニティの拡大に重点を置き、より広範な開発の促進を図ります

現在、PoSへの移行は完了し、The Mergeは成功裏に実施されました。しかし、The Merge完了後の2022年頃から現在にかけて、Ethereumのロードマップは進化を続け、細かい部分でいくつかの変更が加えられています。ただし、年を追うごとにその変更差分は小さくなってきているため、現時点のロードマップを明確に理解することが、Ethereumの将来的な方向性を把握する助けとなります。

Ethereumのロードマップを理解することで、Ethereum自体への投資判断はもちろん、他のブロックチェーンが同様の課題に対処する際の参考としても役立てることができます。

The Merge

ここでは、EthereumがPoSへの移行を達成した「The Merge」について、その変更点や運用を経て明らかになった改善点と解決策を紹介します。

The Mergeによる変更点

The MergeはEthereumにとって重要な転換点であり、これによってネットワークのコンセンサスアルゴリズムがProof of Work（PoW）からProof of Stake（PoS）に大きく変更されました。この変更により、従来のPoW方式で必要だった膨大な計算資源を使うマイニングが終了し、代わりにバリデーターと呼ばれる参加者がETHを「ステーキング」することでブロックが生成されるようになりました。この移行の結果、Ethereumのネットワーク全体のエネルギー消費が劇的に削減され、従来と比べて約99.95%のエネルギー節約が達成され、環境への負荷が大幅に軽減されました。

参考：https://ethereum.org/ja/roadmap/merge/

また、The MergeはEthereumのセキュリティモデルにも大きな変革をもたらしました。PoS方式では、バリデーターがネットワークに参加する際に、自らのETHを担保としてステーキングします。不正が発生すると、ステーキングしたETHが没収される（スラッシュされる）ため、バリデーターには誠実にブロック生成を行う強いインセンティブがあります。この仕組みが導入されたことで、ネットワーク全体のセキュリティが向上し、Ethereumの信頼性がより高まりました。

The Mergeは単なるコンセンサスアルゴリズムの変更にとどまらず、持続可能なEthereumの未来に向けた重要な一歩といえます。さらに、今後計画されるシャーディングの導入準備としての役割も果たしており、Ethereumのさらなる発展の土台となるアップデートとなりました。

The Merge後の改善点

課題：ブロック確定時間と最低ステーク量

現在、Ethereumのブロック確定には2～3エポック（最大約15分）を要し、また、バリデーターとしてステークするためには最低32ETHが必要とされています。これは、PoSによって生じるトリレンマのバランスをとるためです。

https://vitalik.eth.limo/general/2024/10/14/futures1.html の図をもとに筆者作成

ブロックの確定に2,3エポックかかっているのは、すべてのバリデータが2つのメッセージを署名して安全にブロックを確定させるためです。結果として、署名を短時間で処理できるような高性能なノードが必要とされます。

ステーク量を32ETHから引き下げた場合、より多くの参加者がバリデーターになれるため、バリデーター数を増やすことが可能です。しかし、その分合意を得るまでに時間がかかるようになり、さらに高性能なノードが必要とされるため、ノード性能やセキュリティ要件がより厳しくなるという課題が生じます。

さらに、Ethereumでは、安全なファイナリティ（取引の不可逆性）を実現するために「成功した攻撃にも高いコストを攻撃者に課す」ことを目指しています。バリデーター数が増えることで合意にかかる時間も増加し、ブロックの確定時間が長引く可能性があります。よって、セキュリティを強化しつつも効率的にブロックを確定するための工夫が必要になります。

そこで、以下の2つの目標が示されています。

シングルスロットファイナリティ：1スロット（12秒）でブロックを確定させ、より高いセキュリティを確保する
1 ETHからのステーキング：最低ステーク量を32ETHから1ETHに引き下げ、より多くのバリデーター参加を促す

シングルスロットファイナリティにより、トランザクションが確認されると同時に確定され、より速く、安全な取引が可能になります。また、ステーク量の引き下げは、参加者数を増やし、ブロック選定の民主化にも貢献します。しかし、これではノード性能への要求が高くなるため、いくつかの解決策が提案されています。

シングルスロットファイナリティを実現するための解決策

シングルスロットファイナリティは、一つのスロットでブロックを確定させることを言います。シングルスロットファイナリティ自体は、ブロックチェーン上で不可能ではありません。例えば、Cosmos SDKなどで採用されているTendermintコンセンサスで実現されています。しかし、Ethereumではinactivity leakという仕組みが存在し、1/3 以上のバリデーターの投票を収集できなかった場合にある条件に従ってステークを没収してブロックを確定させる必要があります。Tendermintでは、このinactivity leakに対応できていないですが、Tendermint風のコンセンサスを改良して非アクティブリークに対応する提案が既に存在します。

ここで問題となるのは非常に多くのバリデーター数でシングルスロットファイナリティを実現しながら、ノード運営者のオーバーヘッドが極端に高くならないようにする方法を見つけることです。以下にその方法を挙げていきます。

署名集約やZKで無理やりまとめる
複数の署名を効率よく1つにまとめて検証する「署名集約」によって、迅速な処理を実現します。また、zk-SNARKを使い、膨大な署名を短い証明データで検証できるようにすることで、シングルスロットファイナリティの実現を目指します。
Orbit committes
https://vitalik.eth.limo/general/2024/10/14/futures1.html

Ethereumは、「成功した攻撃にも高いコストを課す」ことを重視していますが、他のブロックチェーンで採用されているようなバリデーターがランダムに選ばれる「委員会」によってブロックを確定する手法では十分とはいえません。また、すべてのバリデーターがブロックに投票し責任を負う現在の方式では、ノードへの負荷が大きくなり、効率が低下してしまいます。
この課題に対して、Orbit SSF（シングルスロットファイナリティ）では、全バリデーターが投票と責務を分担しつつ、オーバーヘッドを最小化する折衷案として、部分的に責任を負う委員会のような仕組みを取り入れ、セキュリティと効率を両立させます。
2層構造のステーキング
高いデポジットを必要とする層（上層）と、低いデポジットで参加可能な層（下層）の2層に分ける方法です。上層がブロックの確定を担当し、下層のバリデーターは上層ステーカーにステークを委任したり、ランダムサンプルに基づく証明や包含リストの生成などを行います。

各解決策には課題とトレードオフが存在し、Ethereumが持続可能で安全な進化を遂げるためには、これらの課題を把握し、最適な方法を検討することが重要です。

課題とトレードオフ

現状維持
現在のステーキングシステムを変更せずに維持する選択肢も考えられます。ただし、この場合はシステムの改善は期待できません。結果として、ステーキングが集中化する可能性が高まり、十分なセキュリティを維持できなくなるリスクがあります。
署名集約やZKで無理やりまとめる
数百万もの署名を5〜10秒という非常に短時間で集約する必要があります。この処理を分散的に行うのは極めて困難であるため、ノード内で完結する形での処理が求められます。ただし、その処理の内容まではネットワーク全体で確かめることができないので、そのリスクを許容する必要があります。
Orbit committes
現在採用されているプロトコルの安全性仮定を見直し、ファイナリティの要件を緩和する手法です。具体的には、攻撃を高コストにする仕組みを維持しながら、現状よりも攻撃コストを低く設定することを許容します（例：攻撃コストを250億ドルから25億ドルに引き下げる）。このアプローチにより、現実的なリスクと運用可能性のバランスを取ることが期待されます。
2層構造のステーキング
ステーキング構造を2層化することで、特定の中央集権化リスクが発生する可能性があります。例えば、低位層のステーカーが高位層のステーカーに権利を委譲する場合、高位層がブロック承認やトランザクションリストの決定権を独占するリスクが生じます。このため、権限集中を防ぐための追加の対策が必要になります。

これらの解決策のいずれか一つを採用するのではなく、複数の策を組み合わせることで、柔軟かつ効果的な対処が可能になると考えられます。

課題：バリデータの選出

現在のバリデータ選出方法には、次のブロックを提案するバリデータが事前に特定できてしまうという課題があります。これにより、攻撃者が次のブロック提案者のIPアドレスを突き止め、DoS攻撃を仕掛けることでブロック構築に干渉するリスクが生じます。

この問題を解決するには、ブロック生成の直前までブロック提案者がわからない仕組みが必要です。このアプローチは「シングルシークレットリーダー選出」と呼ばれています。

具体的には、乱数生成機構である「randao」を使用することで、ブロック生成時点まで提案者が不明である仕組みが実装可能です。ただし、randaoでは基本的に1人のバリデータが選ばれますが、場合によっては複数のバリデータが選出されることがあり、完全に「シングル」選出が保証されるわけではありません。

そこで、暗号技術を活用して各バリデータに隠されたIDを付与し、それらのIDをシャッフルした上で暗号化する方法が検討されています。この手法により、どのIDがどのバリデータに対応するかを秘匿し、安全に1人のバリデータを選出できる仕組みが可能になります。

しかし、この方法の実装にはEthereumに高度な暗号プロトコルを導入する必要があり、Ethereum全体の複雑性が増す要因となります。このため、Ethereumのステートレス化（例：verkle treeやzk-EVMの導入）が進む段階まで、こうした機能の導入は待つ必要があると考えられます。

Beam Chain：次世代コンセンサスレイヤの提案

Ethereumの実行レイヤ（EVM）やデータレイヤ（Blob）は、アプリケーションが使用する設計が既に最適化されており、大幅な改善の余地は少ないとされています。しかし、コンセンサスレイヤにはさらなる改良の可能性があります。このような背景を踏まえ、Ethereumの研究者であるJustin DrakeがDevcon 7で提案したのが「Beam Chain」です。

Beam Chainは、ゼロ知識仮想マシン（zkVM）を活用し、ステート遷移を検証することで、コンセンサスと実行レイヤを完全に分離することを目指しています。これにより、コンセンサスアルゴリズムを柔軟に設計・実装できる仕組みを提供します。また、量子コンピュータに耐性を持つハッシュベースの署名やハッシュベースのSNARKを採用し、将来の量子コンピュータ時代にも対応可能な安全性を備えています。さらに、BLS署名でもできないような署名の集約の集約を可能にすることで、トランザクション処理の効率化も期待されています。

現在、Beamchainはまだ提案段階にあり、完成は2029年ごろを目指しています。その採用は、セキュリティやスケーラビリティの限界が顕在化した場合や、zkVMを利用したコンセンサス分離によって、従来は解決不可能だった問題を解決し、新たな価値を具体的に創出できると確認された場合に現実味を帯びるでしょう。これらの要素から、BeamchainはEthereumの将来に向けた重要な選択肢として注目していくべきです。

https://www.youtube.com/watch?v=Plvy7fgFCm4

The Surge

The Surgeは、Ethereumのスケーラビリティ向上に重点を置いたフェーズです。Ethereumは、単体で全トランザクションを処理するのではなく、Layer 1 (L1) として機能するEthereumにLayer 2 (L2) のブロックチェーンを接続し、L2で多くのトランザクションを処理する体制を整えています。The Surgeでは、L1+L2全体で100,000以上のTPSを目指し、これを達成するための手法や相互運用性の確保についても検討しています。

具体的な手法としては、データアベイラビリティ（DA：Data Availability）の最適化やロールアップ技術の活用があります。L2上で圧縮されたトランザクションデータをL1に効率的に送り、L1が主にデータの保管とセキュリティを担うことで、Ethereum全体の処理効率が向上します。これにより、L1がスケーラビリティの基盤となり、L2は負荷分散と高速処理を担う役割を果たします。

また、L2が乱立する現状において、それぞれのL2間の相互運用性をどう確保するかも重要です。Ethereumコミュニティでは、異なるL2が互換性を持ち、ユーザーがどのL2上でもシームレスにトランザクションを移動できるようにするための標準化やプロトコルの整備が進められています。これにより、スケーラビリティ向上のためにL2が活用される一方で、ネットワーク全体の一貫性とユーザー体験の向上が図られることが期待されています。

さらに、2025年第一四半期から予定されているPectraアップグレードによって、Ethereumにおけるデータ管理の効率が強化され、L2の性能もさらに向上する見込みです。

Pectra アップグレードについて詳しく知りたい方は以下のレポートを参照してください。

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

以下では、スケーラビリティ向上に必要な技術や、その技術の導入にあたっての問題点、さらには、L2同士のインターオペラビリティについて解説していきます。

L2の必要性

Ethereumのスケーリング戦略の一つとして挙げられるのが、レイヤー2（L2）プロトコルです。L2はEthereumのセキュリティを享受しながら、データ保存や計算の大部分をEthereumの外側で行うことができるため、Ethereum本体の負荷を軽減しつつ、トランザクション処理能力を向上させることが可能です。ただし、この際に「データの可用性（DA：Data Availability）」に関する課題が発生します。具体的には、L2でバッチ処理されたトランザクションの検証に必要なデータをEthereum上に保存しておく必要がある場合を考えます。データ容量が大きすぎるあまり、L1における保存コストが大きくなり、その結果バッチ可能なトランザクション数が制限され、十分なスケーリング効果を得られない場合があります。

L2と並行してもう一つのスケーリング戦略として挙げられるのがシャーディングです。シャーディングは、ネットワーク全体で全てのトランザクションを検証・保存するのではなく、バリデータをグループに分割し、それぞれが異なるシャード（データの一部）を担当してトランザクションを並列に処理する仕組みです。シャーディング技術の研究が進むことで、Ethereumのデータ可用性に関する問題が大幅に緩和され、L2との併用によってさらなるスケーラビリティが期待されています。

Ethereumは今後、L2のロールアップ技術を中心にスケーラビリティを獲得するロードマップを描いています。では、ロールアップ中心の戦略が具体的にどのように実現されていくのか、また、L2の発展に伴って残されている課題についても順に解説していきます。

データ可用性サンプリング

以前は、L2上のトランザクションに必要なデータ可用性を保証するために、Ethereumのcalldataと呼ばれるメモリ領域が使用されていました。しかし、calldataはもともとスマートコントラクトの引数やパラメータを渡すための領域であり、その容量はデータ可用性を確保するにはやや不足していました。

この課題に対応するため、2024年3月13日に実施されたDencunアップグレードでは、blobと呼ばれる新しいデータ領域が追加されました。このblobにより、Ethereumのブロックチェーンは、1スロット（12秒間）ごとに約125 kBのデータ領域を3つ持つようになり、合計で1スロットあたり約375 kBのデータ可用性帯域幅が確保されるようになりました。

今後の目標としては、スロットあたり16MBのデータ可用性を目指しています。これにより、L2がより多くのトランザクションデータを処理できるようになり、Ethereum全体のスケーラビリティがさらに向上することが期待されています。

PeerDASの原理

PeerDASは、データを冗長に符号化し、データの50%以上が利用可能であれば全体を復元できる仕組みを提供します。データは分割され、ネットワーク全体に伝搬される際、既存のP2Pコンポーネントが活用されるため、各ノードは他のノードのデータ可用性を把握できます。この設計により、各ノードが最適なノードと接続し、効率的に必要なデータを取得することで、無駄な通信が削減され、データ伝搬の効率が向上します。

データの可用性の検証では、すべてのデータセルを確認する必要はありません。PeerDASでは、各ノードがランダムに選ばれた8つのセルを検証する仕組みを採用し、統計的にデータ全体の可用性を確かめます。検証されたセルにはKZGコミットメント（データの正確性を保証する暗号的証明）が含まれており、これを通じて他のノードにもセルの正当性が保証され、全ノードがデータの正確性に合意できる仕組みが形成されます。このプロセスにより、ネットワーク全体でのデータ可用性が効率的に保証され、各ノードがすべてのデータを保持する必要がなくなり、ノード運用の負担が軽減されます。

参考：https://medium.com/gaudiy-web3-and-ai-lab-jp/ef5bea05cf00

帯域幅と復元コストのトレードオフ

PeerDASにより、目標とするデータ可用性が確保される一方、帯域幅の制約があるノードではデータサンプリングが困難になるという課題もあります。これに対しては、blobの数を減らしサイズを大きくすることが対応策として検討されていますが、復元時のコストが上昇するため、帯域幅と復元コストのトレードオフが発生します。

2次元サンプリングの提案

より効率的なデータ可用性サンプリング（DAS）を目指し、2次元サンプリングの手法も提案されています。この手法により、さらに少ないデータ量で効率的な可用性確認が実現される可能性があり、ネットワーク全体のデータ管理効率が向上することが期待されています。

今後の課題

PeerDASやデータ可用性サンプリング（DAS）はスケーラビリティの向上に寄与していますが、いくつかの課題が残されています。特に、2次元のDAS（2D DAS）は研究段階にあり、その安全性や実装上の課題について慎重な検討が必要です。また、現在使用されているKZGコミットメントは量子耐性がないため、将来的には量子コンピュータに対抗可能な技術への移行が必要となります。

将来的に考えられる解決策として、以下の3つが挙げられます：

2D DASを実装
1D DASを拡張
DAを用いずにPlasmaをL2アーキテクチャとして採用

L1でさらなるスケーラビリティが必要とされる場合には、zkEVMとDASの組み合わせが有効な解決策として検討されています。このアプローチにより、L1がセキュリティとスケーラビリティを両立しつつ、L2を含む全体のパフォーマンスをさらに向上させることが期待されます。

信頼可能なL2の証明システム

現在、zkEVMを用いたL2ブロックチェーンはまだ発展途上にあり、コードのみを完全に信頼することは難しい場合があります。これは、ZKP（ゼロ知識証明）技術を用いてトランザクションやブロックの正当性を確認する際に、完全に信頼できる証明システムを一から構築するのが困難で、さらに、L2チェーンの開発スピードを高めるために、完全な分散化よりも、ある程度開発主導を行う組織が存在する場合が多いからです。このため、現段階ではL2開発を進める組織やその運営をある程度信頼する必要があります。

多くのL2プロジェクトでは、コードにバグが発生した場合や予期せぬ事態が生じた場合に、特定の結果を強制する権限を持つ「マルチシグ」（複数の署名者による承認方式）が導入されています。この仕組みは、運営側が問題に対応しやすくする一方で、完全な分散化が達成されていない状態を示します。L2プロジェクトは、このような「補助輪」をつけた段階からスタートし、時間をかけて分散性を高め、補助輪を外していくプロセスを取ります。

分散化への進捗を表すステージ

rollupによるスケーリングを目指すL2のプロジェクトは、完全に分散化されたチェーンを目指して徐々に「補助輪」を外していくために、ステージ0からステージ2まで設定し、L2プロジェクトを分類しています。

L2の分散化への進捗を測るため、Vitalik ButerinはL2プロジェクトを以下の3つのステージに分類しています：

ステージ0：ユーザーがノードを実行し、チェーンを同期できることが必須です。検証が完全に信頼・集中化されていても問題ありません。

ステージ1：信頼不要の証明システムが導入され、無効なトランザクションが受け入れられないようになっていることが必須です。証明システムを75％の賛成投票でオーバーライドできるセキュリティ評議会が存在しても良いです。また、評議会のブロック権限を持つ部分（26％以上）がロールアップを構築する主要企業の外部に存在する必要があります。アップグレードメカニズムは、弱い特性（例：DAO）でも許されますが、不正なアップグレードを承認した場合、ユーザーがその前に資金を引き出せるように十分な遅延が必要です。

ステージ2：信頼不要の証明システムが導入され、無効なトランザクションが受け入れられないようになっていることが必須です。セキュリティ評議会は、証明システム間の不一致や、1つの証明システムが同じブロックに対して異なるポストステートルートを認めるなどの明確なバグがある場合にのみ介入が許されます。アップグレードメカニズムは許可されていますが、非常に長い遅延が必要です。

EthereumのL2プロジェクトにおいては、ステージ2に到達することが目標であり、Vitalik Buterinは2025年以降、ステージ1以上のL2プロジェクトにのみ言及すると発表しています。

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

しかし、L2の完全な分散化を目指すにあたって、ステージ2に到達するための最大の障壁は、証明システムが完全に信頼可能であることです。つまり、zk-SNARKで生成される複数のトランザクションの正当性を示す証明（proof）が不正の余地なく正確であることが求められます。もしも証明システムに欠陥があり、不正なトランザクションを承認してしまった場合、評議会でもそれを止めたり巻き戻すことができません。

https://vitalik.eth.limo/general/2024/10/17/futures2.html

証明システムの信頼を確保する手段

そこで、ステージ2を実現するために、証明システムの信頼性を確保する手段として以下の2つが考えられます。

形式検証：
形式検証とは、証明システムがEVMの仕様に従って正当なブロックのみを承認することを数学的に証明する手法です。これはシステムの設計通りに正確に動作するかを確認するもので、すべてのケースについて論理的に証明することを目的としています。具体的な方法としては、システムの状態を設定し、指定された動作と一致するか検証するアプローチや、動作を論理式として記述し、それが正しいことを証明する方法があります。ただし、形式検証の実現には多大な時間と労力がかかるため、今後の課題です。
複数のProver：
2つ以上の独立した証明システムを用意し、2-of-3のマルチシグ方式を構成するアプローチです。ここでは異なる証明システムを並行して動作させ、2つのProverが一致した場合のみトランザクションを承認し、不一致が生じた場合にはセキュリティ評議会が決定を行います。この方法の課題は、少なくとも2つの証明システムを同時に破綻しないよう保証し、それぞれの安全性を十分に高める必要があることです。

Trusted Execution Environment（TEE）Proverの導入

Scrollでは、将来的にmulti-proverアプローチとしてTrusted Execution Environment（TEE：信頼実行環境）Proverを使用する予定です。TEE Proverは、保護された環境内でトランザクションを実行し、証明を生成します。TEEプローバーの大きな利点は、その効率性にあります。証明プロセスに関連するオーバーヘッドがほとんどなく、zkEVM Proverよりも迅速でコスト効率の高いソリューションです。これにより、ファイナリティタイムを遅延させずに証明を生成することが可能になります。

ただし、TEE Proverにはトレードオフも存在します。具体的には、特定のハードウェア上で動作するため、可用性の面での制限が生じる可能性があります。可用性の確保とセキュリティ強化のバランスを取りながら、安全で効率的なL2証明システムの構築が求められます。

参考：https://l2beat.com/scaling/projects/scroll#operator

L2同士のインターオペラビリティ

現在、L2エコシステムにおけるユーザーエクスペリエンスの悪さが問題となっています。特に、チェーン間のトークンブリッジ操作で資金を失うケースが多く、クリプトやPC操作に不慣れなユーザーにとって利用が難しい状況です。利便性を高めるためには、中央集権的なブリッジやRPCクライアントを経由する必要があり、そこで信頼を仮定する事態は避けなければなりません。

L2のインターオペラビリティに関して詳細は以下のレポートを参照してください。

このインターオペラビリティの問題を解決するには、どの部分を改善すべきでしょうか。現在目指している「ロールアップ中心のEthereum」が、「L1で実行シャーディングを行っている」という構造であると捉え直すと、いくつかの解決策が見えてきます。以下にいくつかの例を挙げます。

チェーン固有アドレス

ウォレットのアドレスにチェーンの情報を含めることで、どのチェーンに属しているかを明確に示す仕組みです。これにより、宛先にウォレットアドレスを入力した時点で、ウォレットが自動的に適切なチェーン固有の送信方法を判断できるようになります。

チェーン固有の支払いリクエスト

支払いリクエストメッセージの形式を標準化することで、個人間や個人からサービスへの支払い、さらにはdappsからの支払い要求を簡単に作成できるようにします。これにより、異なるチェーン間でも一貫性のある支払いが可能になります。

クロスチェーンスワップとガス支払い

異なるチェーン間でのトークン交換やガス支払いを標準化することが求められます。クロスチェーンでのトークン交換やガス支払いが円滑に行えるようになるため、ユーザーにとっても操作がシンプルになり、利便性が向上します。

ライトクライアント

ユーザーは、RPCクライアントを通じてトランザクションを実行するだけでなく、自らその内容を検証できるようにすることが望まれます。具体的には、ユーザーがEthereumのヘッダーを取得し、Merkle Proofを用いてトランザクションの検証を行う仕組みです。まずL1上でstateが正しく更新されていることを確認し、その後L2上でもMerkle Proofを使って状態の検証が行えるようにします。HeliosはすでにL1の検証を実現しており、L2への対応は今後の標準化が課題となっています。

キーストアウォレット

現在、スマートコントラクトウォレットを管理するキーを更新したい場合、そのウォレットが存在するすべてのチェーンで更新を行う必要があります。キーストアウォレットは、キーを1つの場所（L1または将来的にはL2）に置き、ウォレットのコピーがある任意のL2から読み取れるようにする技術です。これにより、キーの更新が一度の操作で済むようになります。効率を高めるためには、キーストアウォレットがL2からL1をコストなしで参照できる標準化された方法が必要であり、そのための提案としてL1SLOADとREMOTESTATICCALLの2つがあります。

アイデア：大胆な「共有トークンブリッジ」

通常、あるL2から別のL2に資産を移動するには、まずEthereumのL1に資産を引き出し、その後移動先のL2にデポジット（入金）する必要があります。この手順にはL1上でのトランザクション処理が含まれ、高額なガス代が発生するという課題があります。

これを解決するために提案されるのが、EthereumのL1上に「共有された最小限のロールアップ」を構築するアイデアです。このロールアップは、全てのL2の資産残高を一元管理し、チェーン間の操作を一括で処理します。これにより、L1でのガス代を節約し、ユーザーはよりコスト効率良く資産移動を行えるようになります。

同期コンポーザビリティ

同期コンポーザビリティとは、異なるブロックチェーンやプロトコル間での処理を「同期的（即時的）」に実行し、リアルタイムで結果を得る仕組みを指します。これにより、DeFiプロトコル間の取引が効率化され、金融操作全体の生産性向上が期待されます。

しかし、複数のL2間で同期的な呼び出しを行う場合、全てのL2間でトランザクションの順序を調整する必要があり、これには「共有シーケンシング」と呼ばれる高度な仕組みが求められます。

解決策に対する主な課題

上記の解決策の多くは、「標準化のタイミング」と「標準化をどの層で行うべきか」という課題に直面しています。標準化のタイミングが早すぎると、未成熟で劣った解決策が広まり、後から修正が困難になるリスクがあります。一方で、標準化が遅すぎる場合、競合するプロトコルやソリューションが乱立し、互換性や効率性を損なう可能性があります。

また、短期的な解決策と長期的な解決策が併存しているケースもあります。短期的な解決策は効果が弱い一方で実装が容易であり、実務上の迅速な対応を可能にします。一方で、長期的な解決策は「最終的に正しい」ものであるものの、実現には多くの時間とリソースが必要となります。このバランスをどう取るかが大きな課題です。

総論

本レポートでは、「Possible futures of the Ethereum protocol」シリーズのPart 1およびPart 2に基づき、Ethereumのスケーリングに関する技術的な選択肢と、それぞれの課題について解説しました。

全てのスケーリング手法を網羅的に解説することはできず、例えば汎用的なPlasmaを用いたスケーリング方法などは割愛しました。詳細に興味のある方は、本レポートの参照元を参照してください。

暗号技術やブロックチェーンエコシステムの発展により、これまで不透明だったスケーリング手法について、徐々に明確な方向性が見えてきています。本レポートで取り上げたスケーリング策が実現した場合、Ethereumはどのように活用され、エコシステムに何が必要で何が不要になるのでしょうか。その未来に期待が高まります。

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

有料プランではより多くのレポートがお読みいただけます。

法人プランではチャットでの質問やスポットコンサルも可能です。

あらゆるクリプトリサーチをキュレートした

HashHubアカデミーもぜひご活用ください。