SCPの解釈：ロールアップ定型から脱却した非信頼性インフラ構造

2023.12.29

共有先

TechFlow厳選深潮セレクト

SCPの解釈：ロールアップ定型から脱却した非信頼性インフラ構造

SCPのビジョンと実際の応用は、新世代の非信頼インフラ、さらにはブロックチェーン構造ではない演算プラットフォームの構築にある。

2023.12.29 - 01:46:37

Web3業界の深掘り報道に専念し潮流を洞察

SCPのビジョンと実際の応用は、新世代の非信頼インフラ、さらにはブロックチェーン構造ではない演算プラットフォームの構築にある。

執筆：霧月、Geek Web3

導入：本稿では、やや異端的に見えるが将来性のあるWeb3インフラ設計のパラダイム——ストレージベースのコンセンサス・パラダイム（SCP: Storage-based Consensus Paradigm）について前向きに紹介する。この製品設計モデルは理論的にはイーサリアムRollupなどの主流モジュール型ブロックチェーンとは大きく異なるが、実装の容易さやWeb2プラットフォームとの接続性という点では非常に高い実現可能性を持つ。なぜならSCPは初めからRollupのように狭い実装経路に自分を縛るつもりはなく、むしろより広く開放的な枠組みを通じてWeb2プラットフォームとWeb3インフラを融合させることを目指しているためであり、まさに発想が大胆で想像力豊かなアプローチといえる。

以下のような特徴を持つ公的ブロックチェーンのスケーリングソリューションを想像してみてほしい。

従来のWeb2アプリケーションや取引所と同等の速度を持ち、あらゆる公的チェーン、L2、Rollup、サイドチェーンなどをはるかに凌駕する。
ガス料金は不要で、使用コストはほぼゼロ。
資金の安全性は中心化施設（例：取引所）よりもはるかに高く、Rollupには及ばないものの、サイドチェーン以上である。
Web2と同じユーザーエクスペリエンスを持ち、ブロックチェーンの公開鍵・秘密鍵、ウォレット、インフラなどに関する知識を一切必要としない。

このようなソリューションは非常に魅力的である。一方でスケーラビリティにおいて極限まで到達しており、他方でWeb3のマスアダプションの基盤も非常に堅固に築かれているため、Web2とWeb3の体験のギャップを事実上解消できる。

しかし、こうした完璧な要件を満たすソリューションはほとんど思いつかない。なぜなら、主流の議論や実践がまだ極めて少ないからである。

ここでは「スケーリング」という馴染み深いテーマを導入として用いたが、実際にはSCPはスケーリング専用のものではなく、その設計思想の源流はビットコインやイーサリアムなどの公的チェーンにおけるスケーリング案およびコミュニティの議論にある。そのビジョンと実際の応用は、新たな非信頼型インフラ、さらには非ブロックチェーン構造の計算プラットフォームの構築にある。

SCPの基本構成と動作原理

一般的に、SCPもまたイーサリアムやCelestiaコミュニティで言うところの「モジュラー型ブロックチェーン」と同様に、データ可用性層（DA層）、実行層、コンセンサス層、決済層といったモジュールに分かれている。

データ可用性層：広く認められ、長年の検証を経た公的チェーン、またはArweave、Celestiaなどのストレージ系インフラが担う。
実行層：ユーザーのトランザクションを受け取り実行し、署名済みのデータをまとめてDA層に提出するサーバー。Rollupのシーケンサーに似るが、必ずしもブロックチェーンのようなチェーン構造を持つ必要はなく、完全にWeb2のデータベース＋計算システムでもよい。ただし、計算システム全体はオープンソースであり、透明性が求められる。
コンセンサス層：一連のノードからなり、実行層がDA層に提出したデータを取得し、実行層と同じアルゴリズムで計算を行い、実行結果の正当性を確認する。災害対策としての冗長性も持つ。ユーザーはコンセンサス層の各ノードから返されるデータを読み取り、実行層が不正を行っていないことを保証できる。
決済層：一連のノードと他のチェーン上のコントラクトまたはアドレスから構成され、ユーザーがSCPへ入金・出金する行為を処理する。クロスチェーンブリッジに類似する。多シグコントラクトまたはTSSベースのアドレスにより、入金アドレスの出金機能を制御する。入金時は指定アドレスに資産を送信し、出金時はリクエストを送信。その後、決済層ノードがデータを読み取り、多シグまたはTSSによって資産を解放する。セキュリティレベルは採用するクロスチェーンメカニズムに依存する。

SCPの実践的フレームワーク

以下のフレームワークを通じてSCPパラダイムを理解できる。SCPフレームワークに合致する製品は、入金、送金、出金、Swapなどの主要機能を持ち、さらに拡張も可能である。下図はそのような製品の概念図である。

当該プロジェクトのDA層には永久ストレージインフラArweave（図中の大きな円）が採用されている。
コーディネーター（Coordinator）＝実行層。ユーザーがトランザクションを提出すると、コーディネーターがそれを実行し結果を表示した後、ユーザーの元データをまとめてDA層に提出する。
ディテクター（Detector）：Arweaveからコーディネーターが提出した元データを取得し、コーディネーターと同一のアルゴリズムでデータと結果を検証する。ディテクターのクライアントもオープンソースであり、誰でも実行可能。
ウォッチメン（Watchmen）：出金システムの多シグを管理する一組のディテクター。出金リクエストの検証と承認を行う。また、提案の署名も担当する。

このシステム全体では、コンセンサスはすべてオンチェーン外で成立している。これがストレージコンセンサスパラダイムの核心——ブロックチェーン型のノードコンセンサスシステムを放棄し、実行層が煩雑なコンセンサス通信や確認プロセスから解放され、単なるサーバーとしての役割に集中できるようにすることで、事実上無制限のTPSと経済効率を達成している。これはRollupと非常に似ているが、SCPはそれをスケーリング専用のユースケースからWeb2からWeb3への新しい移行モデルへと展開しようとしている。

前述のコーディネーターは単一のサーバーだが、それは即座に恣意的行動を意味しない。Rollupのシーケンサーと同様、ユーザーの元データをArweaveにバッチ提出した後、誰でもディテクターを実行して検証でき、コーディネーターが返す状態と比較できる。ある意味、これはインスクリプション（銘文）系アプリケーションの発想と全く同じである。

このアーキテクチャのもとでは、中心化されたサーバーやデータベースは根本的な課題とはならない。これこそがSCPパラダイムのもう一つの特徴であり、「中心化」と「単一実体」という二つの概念を切り離すことができる——非信頼型システム内に中心化されたコンポーネントがあってもよく、それがキーコンポーネントであっても、全体の非信頼性を損なわない。

次のようなスローガンを掲げることができる——「次世代の非信頼型インフラはコンセンサスプロトコルに依存しなくてもよいが、オープンソースシステムとP2Pノードネットワークであるべきだ」。

人々がブロックチェーンを発明・利用した初衷は、非信頼化、台帳の整合性、改ざん不可、トレーサビリティなど、ビットコイン白書にも明確に記述された古典的な要素にある。しかしイーサリアム以降、旧来の公的チェーンのスケーリング案であろうと、Rollupやモジュラー型ブロックチェーンであろうと、皆が固定観念に陥っている：我々が作るものこそが“ブロックチェーン”でなければならない（ノード間のコンセンサスプロトコルで構成される）、あるいは少なくとも“ブロックチェーンのように見えるもの”（データ構造はブロックチェーン風だが、ノード間での直接コンセンサスメッセージ交換はない）でなければならない。

しかし今や、SCPフレームワークに基づけば、ブロックチェーンでなくても非信頼化、台帳の整合性、改ざん不可、トレーサビリティなどの要件を実現できる。もちろん、より明確な実装詳細が必要ではあるが。

実行層

実行層はシステム全体において極めて重要であり、全システムの演算処理を担い、上にどのようなアプリケーションを動かせるかも決定づける。

無限の可能性を持つ実行環境

理論上、実行層の実行環境はどんな形にもできる。可能性は無限であり、プロジェクト側の方向性に依存する。

取引所：SCPを基に、公開・透明・高TPSの取引所を構築できる。CEX並みの迅速さとゼロコストを備えながら、DEXのような分散化も維持できる。CEXとDEXの境界はここで曖昧になる。
決済ネットワーク：Alipay、PayPalなどに類似。
プログラム／コントラクトのロードに対応した仮想マシン／ブロックチェーン：任意の開発者が任意のアプリケーションをデプロイでき、他のプログラムとすべてのユーザーのデータを共有し、ユーザーの指示に従って操作できる。

SCPが任意の実行環境をサポートする設計には独自の利点がある：歴史的負債を持つ特定のコンポーネント（特にイーサリアムコミュニティが提唱した「アカウント抽象化」など）に依存する必要がない。SCPにとっては、そもそもアカウント抽象化など不要なのである。

SCPアーキテクチャ自体にはアカウント抽象化の概念が存在しない——Web2標準アカウントでもブロックチェーンアカウントでも自由に選べる。この視点から言えば、多くの成熟したWeb2ユースケースを再考・再構築することなく、そのままSCP上で利用できる。これはSCPがRollupに対して持つ優位点かもしれない。

透明性と非対称性

上述のアカウントシステムについて、鋭い読者は気づくだろう。SCPは確かにWeb2のアカウント体系を利用できるが、そのまま使うのは問題がある。

なぜなら、このシステム全体は完全に透明だからだ！従来のサーバー-ユーザーのインタラクションモデルをそのまま使うと重大な問題が生じ、システムの安全性がまったく保てなくなる。まず、従来のサーバー-ユーザーモデルの仕組みを振り返ろう。

1. アカウント登録：ユーザーがアプリの登録画面でユーザー名とパスワードを入力。パスワード保護のため、サーバーはハッシュ関数で処理する。ハッシュの複雑化とレインボーテーブル攻撃への防御のため、通常は各ユーザーのパスワードにランダム文字列（「ソルト」と呼ぶ）を付加してハッシュ処理する。ユーザー名、ソルト、ハッシュ値はサービス提供者のデータベースに平文で保存され、外部には公開されない。それでも、内部犯や攻撃から守るためにソルト付きの安全処理が必要となる。

2. ユーザーログイン：ユーザーがログインフォームにユーザー名とパスワードを入力。システムは処理後のハッシュ値とデータベースの値を比較。一致すれば正しいパスワードと判断し、ログインを続行。

3. 操作認証：ログイン認証後、システムはユーザーにセッションを作成。通常、セッション情報はサーバーに保存され、サーバーは識別子（例：cookieやtoken）をユーザーのブラウザやアプリに送信。以後の操作ではユーザー名とパスワードの再入力は不要：ブラウザやアプリがcookie識別子を保持し、各リクエストに識別子を添えて、cookieに関連付けられたサーバーからの許可を得たことを示す。

次に典型的なWeb3のブロックチェーン-ユーザー相互作用体系を振り返る。

1. アカウント登録：実際には登録プロセスはなく、ユーザー名-パスワード方式もない。アカウント（アドレス）は登録不要で自然に存在し、秘密鍵を握る者がそのアカウントを制御する。秘密鍵はウォレットがローカルでランダム生成し、ネット接続は不要。

2. ユーザーログイン：ブロックチェーンの利用にはログイン不要。多くのdAppにはログインプロセスがなく、代わりにウォレット接続を行う。一部のdAppは接続後に署名による本人確認を求め、単にフロントエンドにアドレスを渡しただけではないことを保証する。

3. 操作認証：ユーザーが直接ノードに署名済みデータを提出。ノードが検証後、全ブロックチェーンネットワークにトランザクションをブロードキャスト。ネットワークのコンセンサス条件を満たせば、操作が確定する。

両者の差異は対称性と非対称性に起因する。サーバー-ユーザー構造では双方が同じ秘密を共有する。ブロックチェーン-ユーザー構造では、秘密を握るのはユーザーのみである。

SCPの実行層はブロックチェーンでなくてもよいが、すべてのデータは公開可能なDA層に同期される必要がある。よってSCPが用いるログイン・操作認証方式は非対称的でなければならない。しかし、大規模普及を妨げる秘密鍵管理やウォレット使用といった面倒な操作や劣悪なUXを避けたい。そのため、SCP上で従来のIDパスワードやOAuthによる第三者認証ログインを求める需要も強い。では、これらをどう統合すべきか？

非対称暗号とゼロ知識証明は非対称性を持つため、次の二つの可能案を想定する。

ID-パスワード方式を使いたい場合、パスワード保管モジュールをSCPに組み込まなければ、他人には見えなくなる。SCP実行層内部では依然としてブロックチェーンの公開鍵・秘密鍵アカウントと操作ロジックを使用し、登録もログインもない。ユーザーのIDは実際には秘密鍵に対応する。この秘密鍵をプロジェクト側に保存するのは好ましくないため、2-3のMPCを用いて中心化保管の問題を解決しつつ、ユーザーに秘密鍵操作の負担をかけない方法が現実的である。
OAuthログインを利用する場合、JWT（Json Web Token）を身分認証手段として活用できる。この方式は前者よりやや中心化寄りで、本質的にWeb2大手が提供する第三者ログインサービスに依存する。

初めて第三者ログインを使うとき、JWT内のユーザー身分とサービス提供者身分を表すフィールドをシステム内に登録。以降のユーザー操作では、操作命令をpublic inputとし、JWT全体をsecret witnessとして用い、ZKPで各トランザクションを検証。
各JWTには有効期限があり、ユーザーが次回ログイン時に新しいJWTを取得するため、永続保管は不要。また、JWK（JSON Web Key）にも依存する必要がある。これは大手がJWK検証用に提供する公開鍵と考えられる。JWKをどのように非中央集権的にシステムに導入し、秘密鍵のローテーションにどう対応するかは、今後の検討課題である。

いずれの方式も従来方式より開発・演算コストが高くなるが、これは非中央集権化に伴う必然的な代償である。もちろん、プロジェクト側が極度の非中央集権化を必須とせず、開発段階ごとに異なるマイルストーンを設定するなら、これらの設計がなくてもよい。非中央集権化は白黒ではなく、グレー領域が存在する。

プライバシー

上述の透明性問題はユーザーのインタラクションスタイルだけでなく、ユーザーのデータにも影響を与える。ユーザーのデータはすべて直接露出してしまう。ブロックチェーンでは問題にならないが、特定のアプリでは受け入れ難いため、開発者はプライバシートランザクションシステムを構築することもできる。

料金

実行層の料金体系も注目すべき点である。DA層にデータを提出するにはコストがかかり、サーバー運営費もかかる。伝統的ブロックチェーンがユーザーにガス料金を請求する第一の目的は、大量の重複トランザクションによるネットワーク破壊を防ぐこと、第二にガス量によるトランザクション順序付けである。Web2にはこのような懸念がなく、洪水攻撃やDDoSといった基本概念しかない。

実行層は完全無料または部分課金など、さまざまな料金戦略をカスタマイズできる。MEV（シーケンサーではすでに成熟）やマーケティング活動など他の手段からも収益を得られる。

検閲耐性

実行層には検閲耐性がない。理論上、ユーザーのトランザクションを無制限に拒否できる。RollupではL1コントラクトの強制投稿機能により検閲耐性を確保できるが、サイドチェーンや公的チェーンは完全な分散型ネットワークであるため、検閲が難しい。

現時点では検閲耐性問題を解決する明確なソリューションはなく、これがSCPパラダイムの弱点である。

コンセンサス層

この層は緩やかなノード群からなり、能動的にネットワークを形成しないため、厳密にはコンセンサスを持つ層ではなく、単に外界（ユーザーなど）に実行層の現在状態を確認させるためのものである。

例えば、これらのノードの動作状態に疑問があれば、ディテクタークライアントをダウンロードし、コーディネーターと同じコードを実行できる。

ただし、Rollupと同様、データはバッチ提出されるため、実行層がユーザーに返す状態は常にDA層より新しくなる。ここに「事前確定（pre-confirmation）」の問題が生じる。

実行層がユーザーに返すのは事前確定、ソフトファイナリティの結果——まだDA層に提出されていないため。

一方、コンセンサス層がユーザーに提供するのはハードファイナリティ。ユーザーにとってはあまり重要でないかもしれないが、クロスチェーンブリッジなどではハードファイナリティを遵守しなければならない。例えば、取引所の入出金システムはRollupのシーケンサーがオンチェーン外でブロードキャストしたデータを信用しない。それらのデータがイーサリアムに記録された後でなければ認められない。

結果の確認以外にも、コンセンサス層には重要な役割として、実行層の災害時バックアップがある。実行層が永久停止したり、重大な悪意行為を行った場合、理論上、任意のコンセンサス層ノードが実行層の仕事を引き継ぎ、ユーザーのリクエストを受け付けられる。こうした重大事態が起きた場合、コミュニティは安定かつ信頼できるノードを選んで実行層サーバーとするだろう。

決済層

SCPはRollupではないため、Rollupのような人為的介入なしに完全に暗号学的・スマートコントラクトベースで非信頼化された出金を実現できない。SCPのクロスチェーンブリッジの安全性はサイドチェーンや第三者証人型ブリッジと同等であり、権限を持つ多シグ管理者が資産の出金を許可する必要がある。これを「証人モデル（witness model）」と呼ぶ。

証人ブリッジをできる限り非中央集権化することは、多くのクロスチェーンブリッジ研究のテーマである。紙幅の都合上、ここでは詳述しない。良好に設計されたSCPプラットフォームは、実際には評判の良い非中央集権型ブリッジの多シグパートナーと協力する必要がある。

SCPがなぜDA層にスマートコントラクトを持つチェーンを使わないのか？そうすればコントラクトベースで完全に非信頼な決済層を構築できるのではないか。

長期的には、いくつかの技術的課題を克服できれば、DA層をイーサリアムなどコントラクト対応のDA層に置き換え、検証用コントラクトを構築することで、SCPもRollupと同等の決済安全性を多シグなしに得られる。

しかし実際には、これが最適な選択とは限らない。

1. イーサリアムはデータ保存専用ではないため、純粋なデータストレージ向け公的チェーンと比べて価格が高すぎる。SCPパラダイムにとって、十分に低コストまたは固定コストのストレージは極めて重要である。そうでなければ、Web2レベルのスループットを支えることは不可能。

2. 証明システムの開発は非常に困難である。SCPではEVMの模倣だけでなく、あらゆるロジックを実現できる。Optimismのようなチームでも、現時点で詐欺証明（fraud proof）は未実装であり、zkEVMの開発難易度を見ても、イーサリアム上で多種多様なシステムの証明を実現するのは極めて難しい。

よってRollupというアプローチは特定条件下でのみ実用性が高い。より広範で開放的、EVM枠組みから脱却し、より多くのWeb2機能を取り入れたい場合は、イーサリアムRollupの考え方は適していない。

SCPは特定の公的チェーンのスケーリング案ではなく、より大きなWeb3計算プラットフォームのアーキテクチャであるため、明らかにイーサリアムLayer2のアプローチを取る必要はない。