SCP の解釈: ロールアップ ベースのトラストレス インフラストラクチャ パラダイムからの脱却

ロールアップの考え方から抜け出し、より広範でオープンなフレームワークを使用して Web2 プラットフォームを Web3 と統合するにはどうすればよいでしょうか?

Wuyue 著、Geek Web3

**はじめに: **この記事では、少しユニークに見える Web3 インフラストラクチャ設計パラダイム、ストレージベースのコンセンサス パラダイム (SCP) を紹介します。この製品設計モデルは、理論的には主流のモジュラーとはかなり異なります。 Ethereum Rollup などのブロックチェーン ソリューションですが、実装の容易さと Web2 プラットフォームとの接続の容易さの点で非常に実現可能です。 Web2 プラットフォームと Web3 機能を統合するために、より広範でオープンなフレームワークを使用したいと考えていました。これは、広くオープンで想像力豊かなアプローチの頭脳であると言えます。

本文: 次の特性を持つパブリック チェーン拡張ソリューションを想像してみましょう。

• 従来の Web2 アプリケーションやエクスチェンジに匹敵する速度を持ち、パブリック チェーン、L2、ロールアップ、サイド チェーンなどをはるかに上回ります。 ※ガス代もかからず、利用コストはほぼ0です。 ※資金の安全性は取引所などの集中型施設をはるかに上回り、ロールアップには劣るもののサイドチェーン以上の安全性を誇ります。
• ブロックチェーンの公開鍵と秘密鍵、ウォレット、インフラストラクチャなどの知識がなくても、Web2 と同じユーザー エクスペリエンス。

このようなソリューションは確かに非常にエキサイティングです。一方で、基本的に究極の容量拡張を達成しましたが、他方では、Web3 の大量導入に向けた非常に強固な基盤も築き、基本的に Web2 と Web3 の間のギャップを解消しました。使用経験。

しかし、実際に主流の議論や実践が少なすぎるため、これほど完全な解決策がどれだけあるのか、私たちは想像することができないようです。

上記では、非常に馴染みのある拡張というトピックを導入として使いましたが、実際には、SCP は拡張に限定されず、その設計のインスピレーションは、ビットコインやイーサリアムなどのパブリック チェーンの拡張計画やコミュニティでの議論から得られています。そのビジョンと実際の応用は、非ブロックチェーン コンピューティング プラットフォームを含む、新世代のトラストレス インフラストラクチャを構築することです。 **

SCP の基本コンポーネントと動作原理

一般的に言えば、**SCP はイーサリアムやセレスティアのコミュニティで「モジュラー ブロックチェーン」と呼ばれるものにも似ており、**データ可用性レイヤー、実行レイヤー、コンセンサス レイヤー、決済レイヤーなどのモジュール区分があります。

• データ可用性レイヤー: Ethereum、Arweave、Celestia など、広く認識され実績のあるパブリック チェーンまたはストレージ施設によってデータ可用性レイヤーとして想定されています。
• 実行層: ユーザートランザクションを受信して実行し、同時にロールアップのシーケンサーと同様に、ユーザー署名トランザクションデータをバッチで DA レイヤーに送信するために使用されるサーバー。ただし、実行層は必ずしもブロックチェーン形式のリンク リスト構造を持つ必要はなく、完全に Web2 データベース + コンピューティング システムでもかまいませんが、コンピューティング システム全体がオープンソースで透過的である必要があります。
• コンセンサス層: ノードのグループで構成され、実行層から送信されたデータを DA 層にプルし、実行層と同じアルゴリズムを使用してこれらのデータを操作し、結果が正しいかどうかを確認します。実行層の出力が正しく、実行層の防災冗長化として利用可能。ユーザーは、コンセンサス層の各ノードから返されたデータを読み取り、実行層に不正がないことを確認することもできます。
• 決済層: ノードとコントラクト、または他のチェーン上のアドレスのグループで構成され、ユーザーが SCP に再チャージしたり、SCP からお金を引き出したりする動作を処理するために使用されます。クロスチェーンブリッジの。決済層ノードは、マルチサインコントラクトまたはTSSベースのアドレスを通じてリチャージアドレスの出金機能を制御します。ユーザーはリチャージの際にチェーン上の指定されたアドレスに資産を預け入れ、出金の際にリクエストを送信し、決済層のノードがデータを読み取った後、マルチシグネチャまたはTSSを通じて資産を解放します。決済層のセキュリティレベルは、採用されているクロスチェーンメカニズムによって異なります。

SCP の実践フレームワーク

SCP パラダイムは次のフレームワークを通じて理解できます。 SCP フレームワークを満たす製品は、リチャージ、送金、出金、スワップなどの主要な機能を持つことができ、これに基づいてさらに拡張することができます。 下の図は、そのような製品の概略図です:

※プロジェクトのDA層は、写真の大きな円の永久保存施設Arweaveを利用しています。

• **コーディネーター、実行層。 **ユーザーはコーディネーターにトランザクションを送信し、コーディネーターは操作を実行して操作結果を表示し、ユーザーの元の入力データをバッチで DA レイヤーに送信します。
• Detector は、コーディネーターによって送信された元のトランザクション データを Arweave から取得し、コーディネーターと一致するアルゴリズムを使用してデータと結果を検証します。検出器クライアントもオープンソースであり、誰でも実行できます。
• **ウォッチメン、出金システムのマルチシグネチャを担当するテスターのグループ。 **出金リクエストは取引データに基づいて検証され、リリースされます。さらに、監視員は提案書に署名する責任もあります。

システム全体を見ることができ、到達したコンセンサスはすべてオフチェーンにあります。これはストレージ コンセンサス パラダイムの中核です。ブロックチェーン スタイルのノード コンセンサス システムを放棄し、重いコンセンサスから実行層を解放します。通信と確認プロセスに必要な作業は 1 台のサーバーのみであるため、ほぼ無制限の TPS と経済性が実現します。これはロールアップに非常に似ていますが、SCP はロールアップとは異なる道をたどっており、容量拡張専用のユースケースから Web2 から Web3 への新しい移行モデルに変わりました。 **

先ほどのコーディネーターはサーバーですが、コーディネーターが何をしてもいいというわけではありません。 Rollup のソーターと同様に、ユーザーが送信した元のデータが Arweave 上でバッチで送信された後、誰でも検出プログラムを実行して検証し、コーディネーターから返されたステータスと比較できます。 **これはある意味、碑文申請の考え方と全く同じです。 **

このアーキテクチャでは、集中管理されたサーバーとデータベースが根本的な課題を引き起こすことはありません。これは、SCP パラダイムのもう 1 つのポイントでもあり、「集中化」と「単一エンティティ」という 2 つの概念を結び付けたり分離したりするものです。 **トラストレス システムでは、集中化されたコンポーネントが存在する可能性があり、**それがコア コンポーネントになることもあります。ただし、これは全体的なトラストレスには影響しません。

私たちはこのようなスローガンを叫ぶことができます。「次世代のトラストレス インフラストラクチャはコンセンサス プロトコルに依存する必要はなく、オープン ソース システムと P2P ノード ネットワークであるべきです」。

ブロックチェーンを発明し使用する人々の本来の目的は、一貫した台帳、偽造不可能、追跡可能、その他のありふれた基本事項を信頼しないことであり、これらはビットコインのホワイトペーパーで明確に述べられています。 **しかし、イーサリアム以降は、*古いパブリック チェーンの拡張計画であれ、ロールアップ ブロックチェーンやモジュラー ブロックチェーンであれ、誰もが「私たちが作るものはブロックチェーンでなければならない」という考え方を形成しました (それはコンセンサス プロトコルで構成されています)ノードの）、またはチェーンのように見えるロールアップのようなソリューション（ブロックチェーンのデータ構造を持っているだけですが、ノードはコンセンサスメッセージを直接交換しません）。

しかし現在では、SCPベースの枠組みの下では、ブロックチェーンでなくても、トラストレス性、台帳の一貫性、非偽造性、トレーサビリティなどの一連の要件を達成できるようになりました。実装の詳細をより明確にする。

実行層

実行層はシステム全体で重要であり、システム全体のコンピューティング プロセスを引き受け、システム上でどのアプリケーションを実行できるかを決定します。

無限の実行環境が可能

理論的には、実行層の実行環境は任意の形状にすることができ、プロジェクト当事者がプロジェクトをどのように位置付けるかに応じて、可能性は無限です。

*交換。 SCP をベースに、オープン、透明、高 TPS の取引所を構築することができ、CEX のスピードとゼロコストの特徴を併せ持つだけでなく、DEX の分散性も維持できます。ここでは、CEX と DEX の区別があいまいになります。

• 決済ネットワーク。 Alipay、PayPal などと同様です。
• プログラム/コントラクトをロードするための仮想マシン/ブロックチェーンをサポートします。開発者は、その上に任意のアプリケーションをデプロイし、すべてのユーザー データを他のプログラムと共有し、ユーザーの指示に従って操作できます。

**任意の実行環境をサポートする設計モデルである SCP には、独自の利点があります。 **歴史的な重荷を持つ特定のコンポーネント、特にイーサリアム コミュニティに特有の「アカウントの抽象化」概念に依存する必要がなくなりました。これは非常に重要です。本質的には必要ないと言われています。

SCP アーキテクチャでは、アカウント抽象化の概念はありません。Web2 標準アカウントとブロックチェーン アカウントを自由に使用できます。この観点から見ると、多くの成熟した Web2 ユースケースは、再考したり構築したりすることなく、SCP 上で直接使用できます。これはロールアップと比較した SCP の利点かもしれません。 **

透明性と非対称性

アカウント システムについては上で説明しましたが、敏感な読者であれば、SCP は Web2 アカウント システムを使用できますが、そのまま使用すると問題があるようであることに気づいたはずです。

なぜなら、このシステム全体が完全に透明だからです。ユーザーからサーバーへの対話モデルを直接使用すると、重大な問題が発生し、システム全体のセキュリティが失われます。 まず、従来のサーバー ユーザー モデルがどのように機能するかを確認しましょう。

1. アカウント登録: ユーザーはアプリケーションの登録ページでユーザー名とパスワードを入力します。ユーザーのパスワードを保護するために、サーバーはパスワードを受信した後、ハッシュ関数を通じてパスワードを処理します。ハッシュの複雑さを増し、レインボー テーブル攻撃から保護するために、多くの場合、各ユーザーのパスワードはランダムに生成された文字列 (「ソルト」と呼ばれる) と連結され、一緒にハッシュされます。 **ユーザー名、ソルト、およびハッシュはサービス プロバイダーのデータベースにクリア テキストで保存され、一般には公開されません。 **それでも、内部関係者や攻撃を防ぐためには、塩漬けとセキュリティ対策が依然として必要です。

2. ユーザー ログイン: ユーザーはログイン フォームにユーザー名とパスワードを入力します。システムは、処理されたパスワードのハッシュ値とデータベースに保存されているハッシュ値を比較します。 2 つのハッシュが一致する場合、ユーザーは正しいパスワードを入力したことになり、ログイン プロセスが続行されます。

3. 操作認証: ログイン認証が成功すると、システムはユーザーのセッションを作成します。通常、セッション情報はサーバーに保存され、サーバーは識別情報 (トークンなど) をユーザーのブラウザーまたはアプリケーションに送信します。ユーザーは、その後の操作でユーザー名とパスワードを再入力する必要がなくなりました。ブラウザまたはアプリケーションは識別子を保存し、各リクエストにそれを含めて、関連付けられたサーバーからの許可があることを示します。

典型的な Web3 ブロックチェーンとユーザーの対話システムを確認してみましょう:

1. アカウント登録: 実際にはアカウント登録プロセスはなく、ユーザー名とパスワードのシステムもありません。アカウント（アドレス）は登録する必要がなく、自然に存在し、秘密鍵を持っている人がアカウントを管理します。秘密キーはウォレットによってローカルでランダムに生成され、ネットワーク プロセスは関与しません。

2. ユーザーログイン: ブロックチェーンの使用にはログインは必要ありません。ほとんどの dApps にはログインプロセスがありませんが、ウォレットに接続されます。一部の dApps では、ユーザーがウォレット アドレスをフロントエンドに渡すだけでなく、ウォレットに接続した後に署名検証を実行して、ユーザーが実際に秘密キーを保持していることを確認する必要があります。

**3. 操作認証: ** ユーザーは署名されたデータをノードに直接送信し、検証後、ノードはトランザクションをブロックチェーン ネットワーク全体にブロードキャストし、ブロックチェーン ネットワークのコンセンサスを満たした後、ユーザーの操作が確認されます。 。

2 つのモードの違いは、対称性と非対称性によって引き起こされます。サーバーとユーザーのアーキテクチャでは、両方の当事者が同じ秘密を保持します。ブロックチェーン ユーザー アーキテクチャでは、ユーザーのみが秘密を保持します。

SCP の実行層はブロックチェーンではありませんが、すべてのデータは公開されている DA 層に同期する必要があるため、SCP で使用されるログインおよび操作検証方法は非対称である必要があります。 **しかし、ユーザーに秘密鍵の保持、ウォレットの使用、および大規模な導入に影響を与えるその他の煩わしい操作やエクスペリエンスの悪さを望んでいないため、SCP 上に構築されたアプリケーションで従来の ID パスワードまたは OAuth を使用するという強い需要もあります。では、この 2 つをどのように組み合わせるのでしょうか?

非対称暗号とゼロ知識証明の非対称な性質により、私は 2 つの可能な解決策を想定しました。

※ID-パスワードシステムを使用したい場合は、このパスワード保存モジュールをSCPに含めることはできません。そのため、他人に見られないようにすることができます。 SCP 実行層は依然として公開鍵と秘密鍵のアカウントとブロックチェーンの操作ロジックを使用しており、登録やログインなどはありません。 **ユーザーの ID は実際には秘密キーに対応します。 **もちろん、この秘密キーはプロジェクト側に保存することはできません。より現実的な解決策は、2 ～ 3 個の MPC を使用して、ユーザーに秘密キーを使用する負担を与えずに集中ストレージの問題を解決することです。

• **OAuth に依存してログインする場合、認証方法として JWT (Json Web Token) を使用できます。 **この方法は、基本的に ID 認証のために大手 Web2 メーカーが提供するサードパーティのログイン サービスに依存しているため、上記の方法よりも若干集中化されます。

• サードパーティを使用して初めてログインする場合は、システムのユーザー ID とサービス プロバイダー ID を表すフィールドを JWT に登録します。ユーザーの後続の操作では、操作指示が公開入力として使用され、JWT 全体が各ユーザーの ZKP とのトランザクションを検証するための秘密証人として使用されます。 ※各JWTには有効期限があり、次回ログイン時にも新規JWTを申請するため、永続的に保持する必要はありません。さらに、このシステムは JWK に依存する必要もあります。JWK は、JWK を検証するためにメーカーによって提供される公開キーとして理解できます。したがって、分散型の方法で JWK をシステムに入力する方法や、将来の秘密鍵のローテーションに対処する方法も検討する価値があります。

**どの方法を使用する場合でも、開発およびコンピューティングのコストは従来の方法よりも高くなりますが、これは分散化のために支払う必要のある代償でもあります。 **もちろん、プロジェクト当事者が極端な分散化が必要ないと考えている場合、または開発のさまざまな段階で異なるマイルストーンがある場合は、分散化は白か黒かではないため、これらの設計がなくても問題ありませんが、グレーゾーンがあるためです。その間。

プライバシー

上で述べた透明性の問題は、ユーザーのインタラクション パラダイムに影響を与えるだけでなく、ユーザー データにも影響を与えます。ユーザーデータは直接公開されます。ブロックチェーンでは問題になりませんが、これは一部のアプリケーションでは受け入れられないため、開発者はプライベート トランザクション システムを構築することもできます。

通行料金

経営層の課金のあり方も注目すべき点だ。なぜなら、DA層にデータを送信するには、独自のサーバーの運用を含むコストもかかるからです。従来のブロックチェーンでユーザーにガス料金を請求する主な目的の 1 つは、ユーザーが大量のトランザクションを繰り返し行うことでトランザクション ネットワークに損害を与えることを防ぐことであり、2 つ目はガスに基づいてトランザクションを分類することです。 Web2 には同様の懸念がないため、フラッディングや DDoS などの基本的な概念のみが存在します。

**実行層は、完全に無料または部分的に課金されるなど、さまざまな課金戦略をカスタマイズできます。**また、MEV (シーケンサー内で非常に成熟)、市場活動などの他の動作からも利益を得ることができます。

検閲への抵抗

実行層は検閲耐性がなく、理論的にはユーザーのトランザクションを無制限に拒否できます。 Rollupでは、L1コントラクトの強制収集機能により検閲耐性を保証できる一方、サイドチェーンやパブリックチェーンは完全な分散型ブロックチェーンネットワークであるため検閲が困難です。

**現時点では、SCP パラダイムの問題である検閲への抵抗の問題に対する明確な解決策はありません。 **

コンセンサス層

この層はルーズなノードで構成されており、これらのノードは積極的にネットワークを形成するわけではないため、厳密な意味でのコンセンサス層ではなく、現在の実行層の状態を外部（ユーザーなど）に確認するためにのみ使用されます。

たとえば、これらのノードの健全性に疑問がある場合は、コーディネーターと同じプログラム コードを実行する検出クライアントをダウンロードできます。 **

ただし、これはロールアップと似ており、データはバッチで送信されるため、実行層によってユーザーに返されるステータスは常に DA 層のステータスよりも新しいものになります。これには事前確認の問題が含まれます。

**実行層は、ユーザーに事前確認済みのソフトファイナル結果を提供します。**それらはまだ DA 層に送信されていないためです。

**コンセンサス層はユーザーにハードファイナリティを提供します。 **ユーザーは特に気にしないかもしれませんが、クロスチェーンブリッジなどのアプリケーションでは、ハードファイナリティに従う必要があります。たとえば、取引所の入出金システムは、ロールアップ シーケンサーによってオフチェーンでブロードキャストされたデータを信じず、データが認識される前に、データがイーサリアムにアップロードされるまで待たなければなりません。

コンセンサス層は結果の確認だけでなく、実行層の防災冗長化としても非常に重要な役割を果たします。 **実行レイヤーが永続的にストライキを起こして重大な犯罪を犯した場合、理論的には、コンセンサスレイヤーが実行レイヤーの作業を引き継ぎ、ユーザーリクエストを受け取ることができます。このような深刻な状況が発生した場合、コミュニティは実行層サーバーとして安定した信頼できるノードを選択する必要があります。

集落層

SCP はロールアップではないため、手動介入を必要とせず、ロールアップの出金決済層のような暗号化とスマート コントラクト コードに完全に基づいたトラストレス出金を実現することはできません。 **SCP クロスチェーン ブリッジのセキュリティ レベルは、サイドチェーンまたはサードパーティの監視クロスチェーン ブリッジのセキュリティ レベルと同じです。**資産を解放するには、承認されたマルチシグネチャ マネージャーに依存する必要があります。これを監視モードと呼びます。 。

ウィットネス ブリッジを可能な限り分散化することは、多くのクロスチェーン ブリッジの研究のテーマです。紙面の都合上、ここでは詳しく説明しません。適切に設計された SCP プラットフォームには、実際に分散型ブリッジの信頼できるマルチシグネチャ パートナーも必要です。

**なぜSCPはDA層としてスマートコントラクトを備えたチェーンを使用しないのかと疑問に思う人もいるかもしれません。 **これにより、契約ベースの完全にトラストレスな決済レイヤーが可能になります。

長期的には、技術的な困難を乗り越えれば、イーサリアムなどのコントラクトをDA層に置き、それに対応した検証用のコントラクトを構築できれば、SCPもRollupと同様の決済安全性を得ることができる。複数の署名を使用する必要はありません。

しかし、実際には、これは最良の選択ではない可能性があります:

1. イーサリアムはデータ ストレージに特化して使用されていないため、純粋なデータ ストレージのパブリック チェーンと比較して価格が高すぎます。 **SCP パラダイムの場合、ストレージ コストが十分に低い、または固定されていることが重要です。 **この方法でのみ、Web2 レベルのスループットをサポートできます。

2.** SCP は EVM をシミュレートできるだけでなく、あらゆるロジックを実装できるため、システムの開発が非常に難しいことがわかります。 **そして、不正行為の証明がまだオンラインになっていない Optimism のようなチームや、zkEVM の開発の難しさを考えると、さまざまなシステムの証明をイーサリアム上に実装するのは非常に難しいことが想像できます。

したがって、**ロールアップは、特定の状況下でのみより実用的な実現可能性が高いソリューションです。**より広範でオープンなソリューションを実装する場合は、EVM システムを廃止し、より多くの Web2 機能を統合し、イーサネットのアイデアを使用します。ファングロールアップは適していません。

**SCP は特定のパブリック チェーン拡張計画ではなく、より大規模な Web3 コンピューティング プラットフォーム アーキテクチャであるため、明らかにイーサリアム レイヤ 2 のアイデアに従う必要はありません。 **

SCP と他のパラダイムを比較した図