暗号資産（仮想通貨）イーサリアム（ETH）の考案者であるヴィタリック・ブテリンのここ最近の発言を読んでいると、ロールアップ中心ロードマップ自体が変わったわけではありませんが、その中で想定されていたレイヤー2（L2）の“理想像”が、現実とのズレによって再定義され始めているように見えます。
 
これまで比較的シンプルに理解してきた構図は、「レイヤー1（L1）はセキュリティ、レイヤー2（L2）はスケーリング」でした。
 
しかし、いま起きている変化を見ると、この整理はそのままでは当てはまらなくなりつつあります。
より正確に言うと、レイヤー2（L2）を正当化する理由が「スケール」だけではなくなってきているというのが、ヴィタリック・ブテリンの最近の発言から見えてきます。
 
背景には2つの事実があります。

• レイヤー2（L2）のStage2（完全トラストレス化）や相互運用性の実現が、想定よりはるかに難航していること
• 一方で、レイヤー（L1）自体が着実にスケールし始め、ガスリミットの増加やZK関連の進展によって、L1のブロックスペースそのものが増えつつあること

この2つが同時に進んだことで、「レイヤー2（L2）がイーサリアム（ETH）のシャードのように振る舞う」という当初の構想と、現実のL2の姿がズレ始めています。

元々イーサリアムのレイヤー2（L2）は、何を目指していたのか

当初の思想は非常に明確でした。
イーサリアム（ETH）のスケーリングとは、「イーサリアムの信用」に裏打ちされたブロックスペースを増やすこと。
 
つまり、レイヤー2（L2）の中でETHを扱っても、それはイーサリアム本体と同じ保証を受けられる空間でなければならない、という考え方です。
高速なEVMチェーンを作って、マルチシグブリッジでレイヤー1（L1）に接続するだけでは、それは別チェーンに過ぎない、イーサリアム（ETH）をスケールしていることにはならない、という整理でした。
 
ここで想定されていたのが、「ブランド付きシャード」としてのレイヤー2（L2）です。イーサリアム（ETH）の一部として振る舞うロールアップ群、というイメージです。

しかし、現実のレイヤー2（L2）は「ブランド付きシャード」にはならなかった

ヴィタリック・ブテリンがかなり率直に触れているのがこの点です。
少なくとも一部のレイヤー2（L2）は、技術的理由だけでなく、規制対応や顧客要件の観点から、最終的なコントロールを手放す設計を今後も選ばない可能性に言及しています。(図1参照)

図1.ヴィタリック・ブテリンは、Stage 2へ進まない選択を示唆するレイヤー2（L2）の発言事例に触れ、当初想定されていたレイヤー2（L2）像とのズレに言及している（出所:https://x.com/RyanSAdams/status/2018728683591156010）
 
これはビジネスとしては極めて合理的ですし、顧客の要求にも適合します。
ただしこの選択は、「イーサリアム（ETH）の一部として振る舞うレイヤー2（L2）」という当初の理想像とは異なります。
 
ヴィタリック・ブテリンはここをドライに整理しています。 

それは正しい選択かもしれない。ただし、それは「イーサリアムをスケールしている」という意味とは違う。 

これはL2の価値を否定しているのではなく、L2の役割が再定義され始めているという話です。

なぜこれが問題にならないのか：レイヤー1（L1）側の底上げが進んでいるから

ここで重要なのが、レイヤー1（L1）側の変化です。
ガスリミットの増加やプロトコル改善によって、イーサリアム（ETH）の信用で裏打ちされたブロックスペースそのものが、着実に増えつつあります。
 
※関連レポート：イーサリアムのアップグレード・フサカ（Fusaka）の概要：PeerDASのスケーラビリティと新たなUX

ヴィタリック・ブテリンはこの流れの中で、将来的にレイヤー1（L1）スケーリングの文脈でZK系の証明をプロトコル側で扱う必要が出てくる可能性に触れています。
そしてその延長線上で、「rollup検証用のプリコンパイルをL1に組み込む価値が高まる」と述べています。
つまりレイヤー1（L1）のスケーリングを進める過程で、rollup検証がより自然にL1側に取り込まれていく可能性が示唆されているわけです。
（参照：https://x.com/VitalikButerin/status/2018711006394843585）
 
その結果として、レイヤー2（L2）がイーサリアム（ETH）のシャードである必要性が、以前ほど絶対ではなくなってきているという状況が生まれています。
これはレイヤー2（L2）が不要になるという話ではなく、レイヤー1（L1）が最低保証の底を押し上げた結果、レイヤー2（L2）は“差別化レイヤー”としての意味合いが強まっているという変化です。

native rollup precompile と Based rollup 提案から見える、L2保証の再整理

ヴィタリック・ブテリンがたびたび言及している native rollup precompile（ネイティブ・ロールアップ・プリコンパイル） という発想は、この一連の議論を理解するうえで重要なヒントになります。
これは、ZK-EVM証明の検証をプリコンパイルとしてレイヤー1（L1）に組み込む可能性に触れたもので、EVM部分の正しさをイーサリアム（ETH）本体が直接担保し、レイヤー2（L2）はそれ以外の部分を証明すればよい、という構造も考えられるという話です。
この見方に立つと、「EVM部分の保証」と「それ以外の保証」が切り分けられ、レイヤー2（L2）ごとの保証の違いがより明確に可視化されていく未来像が浮かびます。
 
この視点は、ethresear.ch に投稿された Based rollup × preconfirmations の提案とも自然につながります。
このプロポーザルでは、Based rollup（ベースド・ロールアップ）と Sequenced rollup（シーケンシャル・ロールアップ） を組み合わせることで、レイヤー1（L1）とレイヤー2（L2）の同期的コンポーザビリティを実現しようとする設計が示されています。
提案そのものに加えて、コメント欄や関連議論を見ると、これまで実現が難しいと考えられてきた要素、たとえば、レイヤー1（L1）がその場でレイヤー2（L2）の正しさを確認できるほど証明が速くなかったことや、レイヤー1（L1）で巻き戻し（リオーグ）が起きたときにレイヤー2（L2）も一緒に巻き戻る設計を受け入れにくかったこと、さらにレイヤー2（L2）のシーケンサーとレイヤー1（L1）側のブロック提案者がうまく連携する必要があったことなどです。
ただ最近は、これまで難しいと考えられてきた条件についても、技術的・運用的な観点から現実的な議論が行われるようになってきています。
 
こうした流れを踏まえると、ヴィタリック・ブテリンが述べる「レイヤー2（L2）はスペクトラムである」という見方が、より具体的な意味を持ち始めます。
レイヤー1（L1）リオーグに従い、リアルタイム証明を持ち、レイヤー1（L1）との強い同期性を受け入れるレイヤー2（L2）は、非常にイーサリアム（ETH）寄りの位置に立つことになります。
一方で、これを選ばないL2は、より独立性を重視する方向に進みます。
この提案とヴィタリック・ブテリンの発言を重ねると、レイヤー2（L2）ごとの保証の違いが設計上はっきり現れ始めている、と整理することもできそうです。

総括

ヴィタリック・ブテリンの発言や関連提案をあわせて読むと、レイヤー2（L2）をどのように捉えるべきかについて、新しい見方が提示されているように感じられます。
レイヤー2（L2）は単にスケールのためのレイヤーというより、イーサリアム（ETH）とどの程度強く結びつくかを設計として選べる存在として整理することもできるのではないか、という問題提起です。
 
レイヤー1（L1）の底上げが進む可能性や、native rollup precompile、Based rollup の議論などを踏まえると、レイヤー2（L2）が「シャードの代替」ではなく、保証や同期性の度合いによって性格が分かれる存在として理解される未来像も考えられます。
 
もしこの見方が広がるとすれば、レイヤー2（L2）を評価する基準は「どれだけスケールするか」ではなく、「どのような保証モデルを選んでいるか」へと移っていくかもしれません。
レイヤー2（L2）は単なるスケーリング手段ではなく、保証の設計そのものを選ぶレイヤーとして捉え直される可能性がありそうです。
 
【参考文献】
https://x.com/VitalikButerin/status/2018711006394843585
https://ethresear.ch/t/combining-preconfirmations-with-based-rollups-for-synchronous-composability/23863
https://ethresear.ch/t/synchronous-composability-between-rollups-via-realtime-proving/23998
 
  

【ご注意事項】
本記事は執筆者の見解です。本記事の内容に関するお問い合わせは、株式会社HashHub（https://hashhub.tokyo/）までお願いいたします。また、HashHub Researchの各種レポート（https://hashhub-research.com/）もご参照ください。

提供：HashHub Research
執筆者：HashHub Research