Google Cloud が参入、Puffer UniFi は Based Rollup のラストワンマイルを埋められるか？

あるWeb2大手企業の参入によって、これまで主に技術文脈で語られてきた「Gateway」という新しい概念が、一般の視野に入ってきました。

9月22日、PufferはGoogle Cloudとの提携を発表しました。Google Cloudは重要インフラパートナーとして、Puffer Preconfを通じてGatewayを運用し、Puffer UniFiの実行レイヤーをサポートし、取引処理を支援するとともに、取引が最終的にイーサリアムに決済される前にExecution Preconfirmationを提供します。

さらに注目すべきは、Puffer UniFiがGoogle Cloud Gatewayを使用する最初のRollupとなることです。

しかし、これを単に「また一つのWeb2巨人がWeb3に参入した」と理解するだけでは、この提携の背後にあるより議論に値する部分を見逃してしまうかもしれません。

なぜなら、Google Cloudが今回果たす役割は、従来の意味でブロックチェーンプロジェクトに計算リソース、ノードホスティング、またはクラウドサービスを提供する周辺的な役割ではないからです。むしろ、それはPuffer UniFiのリアルタイム実行アーキテクチャに直接入り込み、取引処理、Preconfirmation、そして最終的なイーサリアム決済をつなぐGateway層の一つとなっています。

これはまた、より大きな問いを引き起こします。Puffer UniFiは一体何を構築しているのか？なぜGatewayが必要なのか？そしてGoogle Cloudはなぜ、この比較的低レイヤーの位置からイーサリアムに切り込もうとしているのか？

その答えは、おそらくイーサリアムL2が入りつつある新たな段階から語る必要があるでしょう。

一、Puffer UniFi：後半戦Rollupの一つの答え

2026年に入ると、イーサリアムのRollup戦略は明らかに微妙な時期にあります。

Vitalik ButerinがL2の道筋に対する反省を提起したことから始まり、イーサリアムのスケーリングツールとしてのL2の段階的な歴史的使命は、市場と世論のレベルで完了を宣言されました。

一つの問いがますます先鋭化し始めています。すなわち、L2がもはやL1の渋滞圧力を分担するためのスケーリングツールではなくなったとき、それは一体どのように自らの存在を定義すべきなのか？そしてどのようにL1とより統一された安全性、順序付け、流動性、コンポーザビリティの関係を再形成すべきなのか？

Puffer UniFiは、その一つの答えを出そうとしています。

Puffer UniFiが選択したのは、比較的独立した中央集権的な順序付けシステムを運用し続けることではなく、Based Rollupへと向かうことです。つまり、Rollupの順序付け権をより直接的にEthereum L1にアンカリングし、イーサリアムのバリデータ体系が順序付けに参加し、最終的にEthereum自体の安全性と中立性を継承するのです。

これはL2がすでに意味を失ったということを意味するものではありません。

より正確に言えば、単純なスケーリングという段階的任務が徐々に完了するにつれて、Rollupは自らの価値定位を再び問い直す必要が出てきました。未来は汎用的な実行レイヤーとして存在し続けるのか、それともより明確なアプリケーション、シナリオ、ユーザー体験を中心に、イーサリアムとより緊密に協調するアプリケーションインフラとなるのか？

何しろ5年前のイーサリアムにとって、L2スケーリングは非常に現実的で、非常に成功的な路線と言えましたが、5年後の今日、資産と流動性は数十の独立した孤島に分散しており、Rollupは再定位する必要があります。例えばVitalikが提唱する、明確なアプリケーションシナリオとビジネス境界を持つアプリチェーン志向のようなものです。

Based Rollupの意義は、まさにこの関係を再調整しようとするところにあります。

その中核的な考え方は複雑ではありません。Rollupが最終的に依然としてイーサリアムに依存して決済とセキュリティ検証を完了するのであれば、順序付け権もより直接的にイーサリアムL1に戻すことができ、イーサリアムのバリデータ体系がRollupの順序付けを担当すれば、理論上はRollupの単一シーケンサーへの依存を排除できるだけでなく、L1とL2の間の同期コンポーザビリティも真に実現できるのです。

言い換えれば、Based Rollupが提示するのは「より速いL2をもう一つ作る」ことではなく、イーサリアムのネイティブな路線により近い答えです。すなわち、スケーリングがもはや分裂を意味しないようにし、L2の成長が再びL1の安全性と価値に還元されるようにするのです。

これは理論上ほとんど非の打ちどころのない方向性ですが、問題は、理論上の最適解が自動的に現実の使用可能なシステムと等しいわけではないということです：

• 第一の現実的制約は速度です。イーサリアムL1のブロック生成時間は約12秒であり、もしRollupの順序付けが完全にL1のリズムに従うなら、各取引は少なくとも1つのL1ブロックを待たなければ比較的信頼できる確認を得られません。通常の送金ならまだ受け入れられるかもしれませんが、即時決済、オーダーブック、永久先物契約、さらには高頻度DeFiアプリケーションにとっては、明らかに中央集権的シーケンサーが提供するサブ秒レベルのフィードバックには及ばないでしょう（関連記事『Preconfs 進化論：「パッチ」から「インフラ」へ、UniFi AVS はいかに Based Rollup のゲームルールに影響を与えるか？』）；
• 第二の制約は実行負担です。周知の通り、イーサリアムは長期的に検証ハードルを下げることを堅持し、より多くの一般ハードウェアと個人ノードがネットワークコンセンサスに参加できるよう努めてきました。しかしBased RollupはL1バリデータに高頻度の順序付け、低遅延実行などの役割を直接担うことを要求し、バリデータのハードウェア、ネットワーク、運用保守のハードルを押し上げがちで、かえって実行レイヤーに新たな中央集権的圧力を生み出す可能性があります；
• 第三の制約はインセンティブ構造に由来します。多くのL2チームにとって、Basedアーキテクチャに移行することが技術的複雑さの上昇を意味し、十分な収益も得られないのであれば、自らの中央集権的シーケンサーを維持し続けることが依然としてより合理的な選択です；

ですから、Based Rollupの問題は方向性が間違っていることではなく、真に使用可能になるまでに現実的なインフラがもう一層欠けていることです。システムが完全にL1の12秒のリズムに縛られている限り、速度を両立させることは難しく、再中央集権化することなく、メインネットの中立性を保ちながら中央集権的シーケンサーに近いインタラクション体験を得ようとすれば、実行レイヤーに新たな役割分担を導入しなければなりません。

これがまさにPuffer UniFiが解決しなければならない中核的矛盾です。

Puffer Preconfはまさにこの背景の下でPuffer UniFiの中核技術スタックに組み込まれました。EigenCloud（旧EigenLayer）上に構築された一連の事前確認サービスとして、順序付け権は依然としてEthereum L1にアンカリングされますが、高性能な順序付け、低遅延フィードバック、実行事前確認は、必ずしもすべてL1 Validatorが自ら行う必要はありません。

言い換えれば、Based Rollupが答えるのがPuffer UniFiが「最終的に誰に依存して順序付けと決済を行うか」であるなら、Puffer Preconfが解決するのは「最終決済の前に、ユーザーがどのようにリアルタイムで信頼できる実行体験を得るか」です。

そしてこれこそがGatewayを理解する出発点です。

二、リアルタイム実行：Puffer UniFiにPreconfが必要な理由

Gatewayを理解する前に、まずPreconfirmationが一体何を約束しているのかを理解する必要があります。

実際、主流のL2では、ユーザーが迅速に取引フィードバックを見ることができるのは、多くの場合、中央集権的シーケンサーがまず一種のsoft guaranteeを提示し、この取引がすでにキューに入ったと伝え、フロントエンドもすぐに実行結果を表示するため、ユーザーは体験上「すでに確認された」と感じるからです。

しかし厳密に言えば、この迅速なフィードバックは、単一のシーケンサーへの信頼に大きく基づいています。

一度シーケンサーがダウン、遅延、不正行為、または検閲に遭遇すると、このような約束はしばしば十分に強力な経済的制約と検証可能な責任メカニズムを欠いています。言い換えれば、従来のRollupの「速さ」は、大部分がシーケンサー自体の信用に由来しているのです。

Puffer UniFiにとって、これは明らかに十分ではなく、Puffer Preconfが解決しようとしているのはまさにこの問題です。

それは「迅速な確認」を、単一のオペレーターへの信頼から、経済的保証、署名コミットメント、責任メカニズムに支えられた実行コミットメントへと引き上げようとしています。これは単にPuffer UniFiをより速くするだけでなく、この「速さ」を信頼できるものにするのです。

このアーキテクチャを理解するには、その役割分担を見極める必要があります。

Puffer Preconfの設計では、L1バリデータは依然として順序付け権の最終的な源泉であり、イーサリアムの安全性と中立性のアンカーですが、自ら高性能な順序付けシステムを運用する必要もなく、すべての低遅延実行作業を直接担う必要もありません。むしろ、リステーキングと委任メカニズムを通じて、バリデータはこの部分の複雑な作業をより専門的なGatewayに委ね、Gatewayがその代理としてSequencingとExecution Pre-Confirmationを引き受けることができます。

言い換えれば、順序付けと事前確認の職責を実際に引き受けるのは、新しい役割であるGatewayです。

それは従来の中央集権的Sequencerの単純な改名ではなく、ましてやRollupに付加された「加速プラグイン」でもありません。それはむしろ、L1主権の下で、順序付けと事前確認の職責を委任された専門的な実行代理レイヤーに近いものです：

• 一方で、L1 Proposerにより高性能な順序付けと事前確認サービスを提供するのを支援します；
• 他方で、担保、署名コミットメント、スラッシング、収益分配などのメカニズムを通じて、自らが新たな無制約な中央集権ノードになることを避けます；

Gatewayによって、バリデータは自ら高性能な順序付けシステムを運用する必要がなくなりますが、順序付け権の最終的な帰属は依然としてイーサリアムL1にアンカリングされています。

これはまた、なぜPufferがExecution Pre-Confirmationを強調し、単なるInclusion Promiseではないのかを説明しています。Inclusion promiseはこの取引がブロックに含まれることだけを約束しますが、Execution Preconfirmationはさらに「この取引が事前に約束された状態通りに実行されるかどうか」という問題を解決するのです。

この違いは高付加価値チェーン上のアプリケーションにとって極めて重要です。

永久先物契約DEXを例にとりましょう。このようなシナリオにとって、ユーザーが最も恐れるのは注文がブロックに取り込まれないことではなく、取り込まれたものの、最終的な約定価格、約定順序、または清算状態がすでに偏移してしまっていることです。この背景の下で、Execution Preconfはユーザーが注文時に見た状態で約定することを保証し、追加のスリッページや予期しない実行結果を被ることを防ぎます。

同じ論理はオンチェーン中央指値注文帳、機関投資家の注文フロー、決済・清算、レンディング清算、クロスレイヤーリアルタイム状態読み取りなどのシナリオにも適用されます。CLOBは決定論的な実行順序と低遅延フィードバックを必要とし、機関取引は追責可能な状態コミットメントを必要とし、決済と給与分配は予測可能な決済体験を必要とし、清算システムは激しい相場の中で可能な限り状態ドリフトを減らす必要があります。

もちろん、いかなる強いコミットメントも強い制約を伴わなければなりません。Puffer Preconfのようなアーキテクチャでは、Gatewayの信頼性は自ら信頼できると主張することからではなく、自らの行為に対して経済的結果を負わなければならないことから来ています。ここには少なくとも二層の制約があります：

Gatewayはlookaheadスケジューリングに参加するために担保を提供する必要があります；もしあるGatewayが自ら担当するウィンドウ内で要求通りにタイムリーにbatchをL1に提出しなかった場合、後続のGatewayが代理で提出し、前者に対するスラッシングをトリガーできます；

ユーザーの視点から見れば、もしある事前確認コミットメント付きの取引が最終的に履行されなかった場合、ユーザーは署名付きのコミットメント領収書を利用して賠償を請求したり返金を申請したりできます；

注意すべきは、具体的なスラッシングメカニズムはネットワークの段階と実装バージョンの進化に伴って変化するため、より正確な言い方は「Gatewayがすべてのシナリオですでにslashingされている」ではなく、Puffer Preconfの設計方向は、担保、報酬、罰則、署名責任によって、従来の中央集権的シーケンサーの下での制約のないソフトコミットメントを置き換えることだということです。

技術アーキテクチャの他に、もう一つ避けて通れない問題はインセンティブです。

何しろ従来のRollupモデルでは、順序付け収益の大部分はRollup運営者に帰属します；純粋なBasedアーキテクチャでは、この部分の収益はより自然にL1バリデータに流れ、どちらも十分にバランスが取れていません。

Puffer Preconfの考え方は、事前確認手数料と順序付け関連収益を、L2 Operator、Gateway、L1 Validator、プロトコル自体などの異なる役割に分割することです。こうすることで、L2チームは「体験の維持」と「イーサリアムへの回帰」の二者択一を迫られることなく、L1バリデータもより高性能な事前確認サービスに参加する動機を持