
魔改造レイヤー2:モジュラーの終着点は新たな「レイヤー1」の入り口か?
TechFlow厳選深潮セレクト

魔改造レイヤー2:モジュラーの終着点は新たな「レイヤー1」の入り口か?
Layer 2はもはやイーサリアムのLayer 2だけではない。
執筆:Haotian
市場に「並列EVM(Parallel EVM)」という新しいナラティブが登場し、Layer2の文脈で非常に興味深い展開を見せている。これにより、「精緻化」された新しいRollupパラダイムが実現可能になり、極端に言えばSolanaがイーサリアムの新たなLayer2となるような大胆な改造も理論上は可能になる。
筆者の見解では、並列EVMとは単にRollupの高度な「モジュール化」を象徴するものであり、DA(データ可用性)層が第三者に侵食されたことに続き、VM(仮想マシン)の実行層までもが再び影響を受けた結果である。将来的には、Layer2の定義自体が再構築されるだろう。なぜか?以下、啓蒙的な視点から分析してみよう。
この話題を理解するには、まず「EVM」のシングルスレッド実行モデルを明確にする必要がある。
このモデルでは、トランザクションが順番に一つずつ処理・確認されなければならないと規定されており、それが取引処理速度、ブロック生成時間、トランザクションスループットなどに直接影響を与える。これは、イーサリアムメインネットにおける高GAS料金や混雑の主な原因となっている。また、当初シングルスレッド方式が採用された背景には、当時の技術的制約もある。
イーサリアム上のトランザクションは、分散した独立ノードによって検証および実行され、すべてのアドレス(残高、スマートコントラクトコードなど)に関するデータが各ノード間で一貫した状態を保ちつつ、同一資産の二重支払い(ダブルスペンディング)が発生しないように保証しなければならない。
そのため、トランザクションは順次処理される必要がある。もし並列処理が行われれば、ノード間のデータ同期エラーが発生し、重大なダブルスペンディング事故につながる可能性がある。
わかりやすく例えるなら、銀行にサービス窓口が1つしかない場合、顧客は預け入れ・引き出し・ローンなどの業務を順番に待たなければならない。ある顧客の手続きが完了して初めて次の顧客の処理が始まる。メリットは、銀行の勘定システムが正確に記録されることだが、待ち時間が長くなる。
一方、複数の窓口を開設すれば、顧客は異なる窓口で同時に業務を処理できるが、2つの窓口が同じ口座から引き落としを行おうとした場合、窓口間の帳簿調整が遅れればダブルスペンディングが起きてしまう。効率は上がるが、会計ロジックの複雑さがシステムに負荷をかける。
スタンドアロンチェーン(Layer1)のシナリオにおいて、基盤レイヤーが並列処理をサポートしていれば、この問題は解決される。例えば、Solanaは計算とストレージ状態を分離しているため、VMがユーザーからの複数のトランザクションを受け取った後、ノードはそれらをソートし、独立したストレージシステムを使ってトランザクション間に状態の競合がないかを検出する。競合がなければ同じブロックにまとめる。競合があれば、そのトランザクションは除外され、次のブロックへ回される。
対照的に、イーサリアムのストレージ状態はリアルタイムで逐次計算されるため、各トランザクションは前のトランザクションの完了を待ってから状態を更新しなければならず、ブロックにまとめる前のトランザクション選別作業ができず、並列処理の可能性が制限されている。
Layer2 Rollupのシナリオでは、並列処理を実現するアプローチも同様である。SolanaがPOHタイムスタンプを待機中にトランザクションの計算とストレージ状態の検査を行うプロセスを、RollupチェーンにおけるSequencerによるトランザクション処理→L1へのBatch送信プロセスと見なすことができる。
現在のLayer2では、Batch前にSequencerがまずトランザクションに時系列でnonceを割り当て、順次L1にBatchしている。では、これをマルチスレッド化するにはどうすればよいのか?
1)AA(アカウント抽象)モデルを活用することで、アカウント状態のレベルで複数のトランザクションを同時に発行できるようにする。例えば、2件のTransferを同時実行する場合、AAスマートコントラクトがnonceを付与し、順序通りに実行させる。しかし、一方がTransferで他方がApproveであれば、nonceの制約を受けず、より柔軟に並列処理できる。AAアカウントモデルでは、各アカウントが独自のトランザクション処理ロジックを定義でき、nonceと組み合わせることで高い並列性を実現できる。
2)Sequencer内のトランザクションに対して「精緻化」された加工処理を行う。Layer2のトランザクションがSequencerに提出された際、Sequencerはそれらのロジックを迅速に解析し、精緻なソートとフィルタリングを行う。例えば、同一アカウントが2件のTransferを発行した場合は、後発のものを除外して次回のBatchに回す。一方、同一アカウントが異なる性質の操作(例:SwapとStake)を同時に行った場合は、同じブロックにまとめてBatchできる。
単純に聞こえるかもしれないが、現実はそうではない。DeFiのケースだけで見ても、Sequencerがトランザクションの精緻管理を実現するには、以下の2つの大きな課題がある:
1)トランザクションデータをリアルタイムで解析し、送信されたデータ内のスマートコントラクト呼び出しメソッドやパラメータを正確に把握する必要がある。例えばDeFiで一般的なStaking操作では、トークン移転、状態更新、ステーキング期間、潜在的な報酬計算などが関係する。多数のユーザーが同時にステーキングトランザクションを送信し、さらにステーキング後にTransferを行うトランザクションが混在し、Oracle価格の変動なども絡めば、Sequencerが正しく解析・処理できないと重大な事故につながる。
2)Sequencerの非中央集権化を確保しなければならない。現在のLayer2でも、Sequencerは単にトランザクションをBatchするだけの存在でありながら、すでに権限が大きすぎる。もしSequencerの非中央集権化が解決できないまま「精緻化」Rollupを導入すれば、さらに大きな権限を付与することになる。悪意のあるSequencerが偽のトランザクションを挿入したり、MEVのサンドイッチ攻撃を公然と行ったり、Oracleの清算を悪意操作するリスクが高まる。
最近注目を集めているMetisは、表面上はSequencerの非中央集権化を実現しただけだが、本質的には将来の「精緻化Rollup」に向けて基本的な合意形成の土台を築いた点で重要である。
もちろん、Sequencerによって高度に精緻化されたRollupのトランザクション集約と処理を行うことは、現時点ではまだ構想の域を出ていない。しかし、AAアカウント抽象やブロックチェーン全体のモジュール化・オープンコンポジション思想が、こうした構想を現実にするための前提条件を整えつつある。
以上。
しかも前述の通り、現在のLayer2はますますモジュール化が進んでいる。OP StackフレームワークにZK技術を組み込んでプライバシー拡張を実現したり、元々のイーサリアムDAをCelestiaのようなサードパーティDAに置き換えてコスト削減を図ったり、ETHをGas手数料として使うという伝統さえも変わりつつあり、Layer2ネイティブトークンに実用性が付与されつつある。さらには、Layer2がBatch済みのトランザクションを異なるVM実行環境に送信することも可能になる。つまり、トランザクションをSolanaとイーサリアムに分割処理するといったことも理論上は可能だ。
そうなれば、まったく新しいパラダイムが出現する。今のLayer2はもはや単なるイーサリアムのLayer2ではなく、SolanaがイーサリアムのLayer2になることもあり得るし、Layer2という概念自体が根本から改変される。
大胆に想像しよう。今やLayer2は、高並列トランザクション処理能力を持つエントリーレベルの「Layer1」となり、かつてのLayer1であったイーサリアムやSolanaは、資産決済とセキュリティ担保のための新しい「Layer2」と化すのだ。
Layer2は決して固定された概念ではない。Layer2プラットフォームは、大規模な並列取引処理を解決し、新たなユーザー層を惹きつけるという使命を常に抱えている。
この使命が達成されれば、モジュール化の思想のもと、イーサリアムLayer1の正統性が覆されるだけでなく、全チェーンのDAのデータ可用性、VMの実行層、さらには相互運用性(interoperability)の通信プロトコルまですべてが、Layer2がMass Adoptionを実現するためのインフラとなる。
そのとき、Layer2はもはやLayer1の補助的存在ではなく、強力な総合型トランザクション集約・分配処理プラットフォームとなる。では問おう、いったいどちらがどちらのLayer2なのだと?
TechFlow公式コミュニティへようこそ
Telegram購読グループ:https://t.me/TechFlowDaily
Twitter公式アカウント:https://x.com/TechFlowPost
Twitter英語アカウント:https://x.com/BlockFlow_News











