著者: Wuyue, Geek Web3**はじめに:**この記事では、少し異端に見えるWeb3インフラストラクチャ設計パラダイムを前向きに紹介します - **ストレージコンセンサスパラダイムSCP(ストレージベースのコンセンサスパラダイム)**、この製品設計モデルは理論的にはイーサリアムロールアップなどの主流のモジュラーブロックチェーンソリューションとは大きく異なりますが、**着地の単純さとWeb2プラットフォームとの接続の難しさにおいて、実現可能性は非常に高い** 彼は最初からRollupのような狭い実装パスに限定するつもりはなかったため、より広く、よりオープンなフレームワークを使用して、**Web2プラットフォームとWeb3インフラストラクチャを融合**したいと考えていました。 はじめにこの記事では、やや異端的なWeb3インフラストラクチャ設計パラダイムであるストレージコンセンサスパラダイム(SCP)を前向きに紹介します このプロダクトデザインモデルは、理論的にはEthereum Rollupのような主流のモジュラーブロックチェーンソリューションとは大きく異なりますが、最初からRollupのような狭い実装パスに限定するつもりはなく、Web2プラットフォームとWeb3の機能を、より広くオープンなフレームワークで統合したいと考えているため、実装のシンプルさとWeb2プラットフォームとの接続の難しさの点で非常に実現可能です。Body: 以下の特徴を持つパブリックチェーンのスケーリングスキームを想像してみましょう。*従来のWeb2アプリケーションや取引所に匹敵する速度を持ち、パブリックチェーン、L2、ロールアップ、サイドチェーンなどをはるかに上回っています。※ガス代は無料で、利用料はほぼゼロです。*取引所などの中央集権的な施設をはるかに超えた資金の高いセキュリティ、ロールアップには劣りますが、サイドチェーン以上。* 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から引き出し、コーディネーターと一貫性のあるアルゴリズムを使用してデータと結果を検証します。 検出器クライアントもオープンソースであり、誰でも実行できます。* **ウォッチメン、撤退システムのマルチシグネチャを担当する検出器のグループ。 **出金リクエストは、取引データに基づいて検証され、リリースされます。 さらに、監視員は提案書に署名する責任もあります。システム全体を見ることができ、それらが達成するコンセンサスはすべてオフチェーンであり、これはストレージコンセンサスパラダイムの中核です - ブロックチェーンスタイルのNodeConsensusシステムを放棄し、実行レイヤーが重いコンセンサス通信と確認プロセスを取り除き、サーバーの作業を行うだけで、ほぼ無制限のTPSと経済性を実現できます。 これはRollupと非常によく似ていますが、SCPはRollupとは異なる道をたどり、スケール固有のユースケースからWeb2からWeb3への新しい移行モデルに移行しようとしています。 **上記のコーディネーターはサーバーですが、これはコーディネーターがやりたいことを何でもできるという意味ではありません。 Rollupのシーケンサーと同様に、ユーザーが送信した生データをArweaveにバッチで送信した後、誰でもテスタープログラムを実行して検証し、コーディネーターから返された状態と比較できます。 これは、ある程度、碑文の適用と同じ考え方です。 **このアーキテクチャでは、集中管理されたサーバーまたはデータベースは根本的な課題を提起しません。 これはSCPパラダイムのもう一つのポイントであり、「中央集権化」と「単一エンティティ」の2つの概念を結合し、分離します - **トラストレスシステムでは、中央集権的なコンポーネント、**コアコンポーネントさえも存在する可能性がありますが、これは全体的なトラストレスには影響しません。「**次世代のトラストレスなインフラストラクチャは、コンセンサスプロトコルに依存する必要はなく、オープンソースシステムとP2Pノードネットワークであるべきだ**」というスローガンを叫ぶことができます。ブロックチェーンを発明して使用する人々の本来の意図は、トラストレスであり、台帳は一貫性があり、偽造不可能で、追跡可能であり、その他の決まり文句の基本であり、ビットコインホワイトペーパーに明確に記載されています。 しかし、イーサリアム以降は、古いパブリックチェーンのスケーリングスキームであろうと、ロールアップやモジュラーブロックチェーンであろうと、誰もが考え方を形成しました:私たちが行うことは、ブロックチェーン(ノードのコンセンサスプロトコルで構成される)またはチェーンソリューションのように見えるロールアップ(ブロックチェーンのデータ構造のみがありますが、ノードには直接のコンセンサスメッセージ交換がありません)。しかし今は、SCPの枠組みに基づいて、ブロックチェーンでなくても、トラストレス、一貫性のある台帳、非偽造、トレーサビリティなどの一連の要件を実現でき、もちろん、より明確な実装内容があることが前提です。### 実行レイヤー実行層はシステム全体において重要であり、システム全体の計算プロセスを引き受け、システム上で実行できるアプリケーションの種類も決定します。#### **無限の実行環境**理論的には、実行レイヤーの実行環境は任意の形式で作成でき、プロジェクトチームがプロジェクトをどのように配置するかに応じて、可能性は無限大です。*Exchange。 SCPに基づいて、DEXの分散化を維持しながら、CEXの速度とゼロコストの特性を持つ、オープンで透明性の高い高TPS取引所を構築できます。 ここでは、CEXとDEXの区別が曖昧になります。*支払いネットワーク。 Alipay、PayPalなどに似ています。*仮想マシン/ブロックチェーンローダー/コントラクトのサポート。 開発者は、任意のアプリケーションをデプロイし、すべてのユーザーデータを他のプログラムと共有し、ユーザーの指示に従って操作できます。SCPは、任意の実行環境をサポートする設計パターンであり、独自の利点があります:歴史的な荷物を持つ特定のコンポーネント、特にSCPにとって本質的に望ましくないイーサリアムコミュニティによって作成された「アカウント抽象化」の概念に依存する必要がなくなります。SCPアーキテクチャでは、アカウント抽象化の概念はなく、Web2標準アカウントとブロックチェーンアカウントを自由に採用できます。 この観点から見ると、成熟したWeb2のユースケースの多くは、SCPで直接動作するように再考したり、構築したりする必要はありません。 これは、ロールアップに対する SCP の利点である可能性があります。 **#### **透明性と非対称性**上記のアカウントシステム、そして敏感な読者は、SCPがWeb2のアカウントシステムを利用できるにもかかわらず、それをそのまま使用するのは問題があるように見えることに気づいているはずです。システム全体が完全に透過的であるため、ユーザーとサーバーの対話モデルを直接使用すると、深刻な問題が発生し、セキュリティがまったく発生しません。 従来のサーバーユーザーモデルがどのように機能するかを確認しましょう。1.アカウント登録:ユーザーは、アプリケーションの登録ページでユーザー名とパスワードを入力します。 ユーザーのパスワードを保護するために、サーバーはパスワードを受け取った後、ハッシュ関数を介してパスワードを処理します。 ハッシュの複雑さを増し、レインボーテーブル攻撃から防御するために、各ユーザーのパスワードは通常、ランダムに生成された文字列(「ソルト」と呼ばれる)に接続され、ハッシュ化されます。 **ユーザー名、ソルト、ハッシュは、サービスプロバイダーのデータベースにプレーンテキストで保存され、一般には公開されていません。 しかし、それでも、1つは内部の幽霊を防ぐため、もう1つは攻撃を防ぐために、塩と安全な処理を追加する必要があります。2.ユーザーログイン:ユーザーはログインフォームにユーザー名とパスワードを入力します。 処理されたパスワードハッシュは、データベースに保存されているハッシュ値と比較されます。 2 つのハッシュが一致し、ユーザーが正しいパスワードを入力したことを示す場合、ログイン プロセスは続行されます。3.操作認証:ログイン検証に合格すると、システムはユーザーのセッションを作成します。 通常、セッション情報はサーバーに保存され、サーバーは識別子(トークンなど)をユーザーのブラウザまたはアプリケーションに送信します。 ユーザーは次のステップでユーザー名とパスワードを再入力する必要がなくなり、ブラウザまたはアプリが識別子を保存し、各リクエストに識別子を添付して、関連付けられたサーバーからのアクセス許可があることを示します。**典型的なWeb3ブロックチェーンとユーザーインタラクションシステムを確認しましょう。1.アカウント登録:アカウント登録プロセスは事実上なく、ユーザー名とパスワードのシステムもありません。 アカウント(アドレス)は登録を必要とせず、自然に存在し、秘密鍵を持っている人がアカウントを制御します。 秘密鍵はウォレットによってローカルにランダムに生成され、ネットワークプロセスは関与しません。2.ユーザーログイン:ブロックチェーンの使用はログインを必要とせず、ほとんどのdAppsにはログインプロセスがありませんが、ウォレットに接続します。 一部のdAppsでは、WalletAddressをフロントエンドに渡すだけでなく、ユーザーが本当に秘密鍵を保持していることを確認するために、ウォレットに接続した後にユーザーが署名して確認する必要があります。3.操作認証:ユーザーは署名されたデータをノードに直接送信し、ノードは検証後にトランザクションをブロックチェーンネットワーク全体にブロードキャストし、ブロックチェーンネットワークのコンセンサスを満たした後、ユーザーの操作を確認します。2つのモードの違いは、対称性と非対称性によって生じます。 サーバー/ユーザー アーキテクチャでは、両者が同じシークレットを保持します。 ブロックチェーン・ユーザー・アーキテクチャでは、ユーザーのみがシークレットを保持します。SCPの実行層をブロックチェーンにすることはできませんが、すべてのデータは公開されているDA層に同期する必要があるため、SCPで使用されるログインと操作の認証方法は非対称である必要があります。 しかし、ユーザーに秘密鍵を保管させたり、ウォレットを使用させたりするなど、大量導入に影響を与える煩雑なアクションや貧弱なエクスペリエンスは望ましくないため、SCP上に構築されたアプリケーションも従来のIDパスワードまたはOAuthスリーパーティ認証ログインを使用する必要性が強いため、この2つをどのように組み合わせるのでしょうか?非対称暗号とゼロ知識証明ペアの非対称性のため、私は2つのシナリオを想定しています。※IDパスワードシステムを利用したい場合は、このパスワード保存モジュールをSCPから外して、他の誰にも見られないようにすることができます。 SCP実行レイヤーは、登録やログインなどを行わずに、ブロックチェーンの公開鍵と秘密鍵のアカウントと操作ロジックを引き続き使用します。 ユーザーの ID は、実際には秘密キーに対応します。 **もちろん、この秘密鍵をプロジェクト側で保持することはできず、より実行可能な解決策は、2〜3 MPCを使用して集中ストレージの問題を解決し、ユーザーに秘密鍵の使用を許可しないことです。OAuthログインに依存する場合、認証手段としてJWT(Json Web Token)を使用できます。 **この方法は、基本的にWeb2メーカーが提供するサードパーティのログインサービスにID認証として依存する必要があるため、上記よりもわずかに中央集権化されます。※初めてサードパーティでログインする場合は、ユーザーのIDとサービスプロバイダーのIDを表すフィールドをJWTに登録します。 ユーザーのその後の操作では、操作指示がパブリック入力として使用され、JWT全体が秘密の証人として使用され、各ユーザーのZKPとのトランザクションが検証されます。各JWTには有効期限があり、ユーザーは次回のログイン時に新しいJWTを申請するため、永久に保持する必要はありません。 さらに、このシステムは、JWKを検証するために大規模な工場から提供される公開鍵として理解できるJWKにも依存する必要があります。 したがって、JWK Decentralizationをシステムにどのように導入するか、および将来の秘密鍵ローテーションに対処する方法も検討する価値があります。いずれにせよ、従来の方法よりも開発と計算にコストがかかりますが、分散化に支払うために必要な価格でもあります。 **もちろん、プロジェクトチームが究極の分散化が必要だと考えていない場合、または開発のさまざまな段階で異なるマイルストーンがある場合は、分散化は白黒ではなく、中間に灰色の領域があるため、これらの設計を行っても問題ありません。#### **プライバシー**上記の透明性の問題は、ユーザーの操作パラダイムだけでなく、ユーザーのデータにも影響を与えます。 ユーザーのデータが直接公開されます。 これはブロックチェーンでは問題になりませんが、一部のアプリケーションではあまり受け入れられないため、開発者はプライベートトランザクションシステムを構築することもできます。#### **料金**実行レイヤーがどのように課金されるかも、別の懸念事項です。 これは、DAレイヤーへのデータ送信には、独自のサーバーの運用など、関連するコストも発生するためです。 ユーザーにガス料金を請求する従来のブロックチェーンの1つ目の目的は、ユーザーが大量の反復的なトランザクションをスワイプしてトランザクションネットワークを混乱させないようにすることであり、2つ目はガスに従ってトランザクションを並べ替えることです。 Web2には同様の懸念がないため、フラッドやDDoSなどの基本的な概念しかありません。実行レイヤーは、完全無料または部分的な充電など、さまざまな課金戦略をカスタマイズでき、MEV(シーケンサーで非常に成熟している)やマーケティング活動などの他の動作を収益化することもできます。#### **検閲への耐性**実行層は検閲に耐性がなく、理論的にはユーザーのトランザクションを無期限に拒否することができます。 Rollupでは、L1コントラクトの強制アグリゲーション機能によって検閲耐性を保証できますが、サイドチェーンまたはパブリックチェーンは完全な分散型ブロックチェーンネットワークであり、これもレビューが困難です。**現在、SCPパラダイムの問題である検閲耐性の問題に対する明確な解決策はありません。 **### **コンセンサスレイヤー**このレイヤーはルーズなノードで構成されており、これらのノードは積極的にネットワークを形成しないため、厳密にはコンセンサスレイヤーではなく、実行レイヤーの現在の状態を外部(ユーザーなど)に確認するためにのみ使用されます。たとえば、これらのノードの正常性ステータスに疑問がある場合は、コーディネーターと同じプログラム コードを実行するディテクター クライアントをダウンロードできます。 **ただし、これはロールアップと似ており、データはバッチで送信されるため、実行レイヤーは常に DA レイヤーよりも新しい状態をユーザーに返します。 これには、事前確認の問題が含まれます。実行レイヤーは、DAレイヤーにまだ送信されていないため、事前確認とソフトファイナリティの結果をユーザーに提供します。**コンセンサスレイヤーは、ユーザーにハードファイナリティを提供します。 ユーザーはこれを特に気にしないかもしれませんが、クロスチェーンインタラクションブリッジなどのアプリケーションでは、ハードファイナリティに従う必要があります。 例えば、取引所の入出金システムは、オフチェーンのロールアップシリアライザーによってブロードキャストされたデータを信頼せず、このデータがイーサリアムにアップロードされるのを待ってから認識する必要があります。コンセンサス層は、結果を確認するために使われるだけでなく、実行層としての災害の冗長性という重要な役割も果たします。 **実行レイヤーが永続的に攻撃し、深刻な悪を行う場合、現時点では、理論的には、任意のコンセンサスレイヤーが実行レイヤーの作業を引き継ぎ、ユーザーのリクエストを受け取ることができます。 このような深刻な状況が発生した場合、コミュニティは実行レイヤーのサーバーとして安定した信頼性の高いノードを選択する必要があります。### **集落層**SCPはRollupではないため、Rollupの出金決済レイヤーのように人間の介入なしには、暗号とスマートコントラクトのコードのみに基づいてトラストレスな出金を実現することはできません。 SCPクロスチェーン・インタラクション・ブリッジは、サイドチェーンまたはサードパーティー・ウィットネス・クロスチェーン・インタラクション・ブリッジと同じであり、アセットをリリースするには、認可されたマルチシグネチャー・マネージャーに依存する必要があり、これをウィットネス・モデルと呼んでいます。証人ブリッジを可能な限り分散化することは、多くのクロスチェーン相互作用研究の主題です。 スペースの都合上、ここでは詳しく説明しません。 適切に設計されたSCPプラットフォームには、実際に評判の良いDecentralization Bridgeマルチシグパートナーも必要です。**なぜSCPはDAレイヤーとしてスマートコントラクトのチェーンを使わないのかと疑問に思う人もいるかもしれません?** これにより、コントラクトを提供し、完全にトラストレスな決済レイヤーを作ることができます。長い目で見れば、何らかの技術的な困難が克服されれば、イーサリアムなどのコントラクトでDAレイヤーを配置し、それに対応する検証用のコントラクトを構築できれば、SCPもマルチシグを使用することなく、Rollupと同じ決済セキュリティを得ることができます。しかし、実際には、これは必ずしも最適ではありません。1.イーサリアムは特にデータ保存に使用されておらず、純粋なデータストレージのパブリックチェーンと比較して価格が高すぎます。 SCPパラダイムでは、十分に低い、または固定されたストレージコストが重要です。 この方法でのみ、Web2 レベルのスループットをサポートできます。2. SCPはEVMをシミュレートするだけでなく、あらゆるロジックを実装できるため、システムの開発が非常に難しいことを証明します。 ** Optimismのようなチームが未だに不正証明のためにオンラインになっていないという事実と、zkEVM開発の難しさを見ると、イーサリアム上で様々なシステムの証明を実装することは非常に難しいことが想像できます。したがって、Rollupソリューションは特定の状況でのみより実用的であり、EVMシステムからより多くのWeb2機能に移行する、より広く、よりオープンなアプローチを実装することを計画している場合、Ethereum Rollupのアイデアは適切ではありません。**SCPはパブリックチェーンのスケーリングスキームではなく、より大きなWeb3コンピューティングプラットフォームアーキテクチャであるため、イーサリアムレイヤー2の考え方に従う必要は明らかにありません。 **#### **SCPと他のパラダイムを比較した図**
SCPの解釈:ロールアップ式の外側にあるトラストレスなインフラストラクチャパラダイム
著者: Wuyue, Geek Web3
**はじめに:**この記事では、少し異端に見えるWeb3インフラストラクチャ設計パラダイムを前向きに紹介します - ストレージコンセンサスパラダイムSCP(ストレージベースのコンセンサスパラダイム)、この製品設計モデルは理論的にはイーサリアムロールアップなどの主流のモジュラーブロックチェーンソリューションとは大きく異なりますが、着地の単純さとWeb2プラットフォームとの接続の難しさにおいて、実現可能性は非常に高い 彼は最初からRollupのような狭い実装パスに限定するつもりはなかったため、より広く、よりオープンなフレームワークを使用して、Web2プラットフォームとWeb3インフラストラクチャを融合したいと考えていました。 はじめにこの記事では、やや異端的なWeb3インフラストラクチャ設計パラダイムであるストレージコンセンサスパラダイム(SCP)を前向きに紹介します このプロダクトデザインモデルは、理論的にはEthereum Rollupのような主流のモジュラーブロックチェーンソリューションとは大きく異なりますが、最初からRollupのような狭い実装パスに限定するつもりはなく、Web2プラットフォームとWeb3の機能を、より広くオープンなフレームワークで統合したいと考えているため、実装のシンプルさとWeb2プラットフォームとの接続の難しさの点で非常に実現可能です。
Body: 以下の特徴を持つパブリックチェーンのスケーリングスキームを想像してみましょう。
*従来のWeb2アプリケーションや取引所に匹敵する速度を持ち、パブリックチェーン、L2、ロールアップ、サイドチェーンなどをはるかに上回っています。 ※ガス代は無料で、利用料はほぼゼロです。 *取引所などの中央集権的な施設をはるかに超えた資金の高いセキュリティ、ロールアップには劣りますが、サイドチェーン以上。
このソリューションは実にエキサイティングで、一方では基本的に究極のスケーリングを達成し、他方ではWeb3の大量採用に強固な基盤を築き、Web2とWeb3の経験のギャップを基本的に解消しています。
しかし、主流の議論や実践が少なすぎるため、これほど完全な解決策はあまり考えられないようです。
実際、**SCPはスケーリングに限定されるものではなく、その設計のインスピレーションはビットコイン、イーサリアム、その他のパブリックチェーンのスケーリングソリューションやコミュニティの議論から来ています。 そのビジョンと実用的なアプリケーションは、新世代のトラストレスインフラストラクチャと、非ブロックチェーン構造のコンピューティングプラットフォームを構築することです。 **
SCP の基本コンポーネントとその仕組み
一般的に言えば、SCPはイーサリアムとセレスティアのコミュニティが「モジュラーブロックチェーン」と呼ぶもののようなもので、データ可用性レイヤー、実行レイヤー、コンセンサスレイヤー、決済レイヤー、その他のモジュールを備えています。
データ可用性レイヤー:Ethereum、Arweave、Celestiaなど、広く認知され実績のあるパブリックチェーン、またはデータ可用性レイヤーとしてのストレージ施設によって実施されます。 実行レイヤー: ロールアップのシーケンサーと同様に、ユーザートランザクションを受信して実行し、ユーザーが署名したトランザクションデータをバッチでDAレイヤーに送信するサーバー。 ただし、実行層はブロックチェーンスタイルのリンクリスト構造を持つ必要はなく、完全にWeb2データベース+コンピューティングシステムにすることができますが、コンピューティングシステム全体がオープンソースで透過的でなければなりません。 コンセンサス層:実行層からDA層に投入されたデータを取得し、実行層と同じアルゴリズムでデータを算出し、実行層の結果出力が正しいかを確認するノード群で構成されており、実行層の防災冗長化として活用できます。 また、ユーザーはコンセンサスレイヤーの各ノードから返されたデータを読み取って、実行レイヤーに不正がないことを確認することもできます。 決済レイヤー:チェーン上のノードと他のコントラクトまたはアドレスのグループで構成され、SCPへの入金またはSCPからの撤退のユーザーの行動を処理するために使用され、クロスチェーンインタラクションブリッジの動作モードにいくらか似ています。 決済レイヤーノードは、マルチシグコントラクトまたはTSSベースのアドレスを通じて、預金アドレスの引き出し機能を制御します。 入金の際、ユーザーは指定されたチェーンのアドレスに資産を預け入れ、出金時にリクエストを送信し、決済レイヤーノードがデータを読み取り、マルチシグまたはTSSを介して資産を解放します。 決済層のセキュリティの程度は、採用されているクロスチェーン相互作用メカニズムに依存します。
SCPの実践の枠組み
SCPパラダイムは、次のフレームワークを通じて理解できます。 SCPフレームワークを満たす製品は、預金、送金、引き出し、スワップなどの主要な機能を持つことができ、これに基づいてさらに拡張することができます。 **次の図は、そのような製品の概略図です。
システム全体を見ることができ、それらが達成するコンセンサスはすべてオフチェーンであり、これはストレージコンセンサスパラダイムの中核です - ブロックチェーンスタイルのNodeConsensusシステムを放棄し、実行レイヤーが重いコンセンサス通信と確認プロセスを取り除き、サーバーの作業を行うだけで、ほぼ無制限のTPSと経済性を実現できます。 これはRollupと非常によく似ていますが、SCPはRollupとは異なる道をたどり、スケール固有のユースケースからWeb2からWeb3への新しい移行モデルに移行しようとしています。 **
上記のコーディネーターはサーバーですが、これはコーディネーターがやりたいことを何でもできるという意味ではありません。 Rollupのシーケンサーと同様に、ユーザーが送信した生データをArweaveにバッチで送信した後、誰でもテスタープログラムを実行して検証し、コーディネーターから返された状態と比較できます。 これは、ある程度、碑文の適用と同じ考え方です。 **
このアーキテクチャでは、集中管理されたサーバーまたはデータベースは根本的な課題を提起しません。 これはSCPパラダイムのもう一つのポイントであり、「中央集権化」と「単一エンティティ」の2つの概念を結合し、分離します - **トラストレスシステムでは、中央集権的なコンポーネント、**コアコンポーネントさえも存在する可能性がありますが、これは全体的なトラストレスには影響しません。
「次世代のトラストレスなインフラストラクチャは、コンセンサスプロトコルに依存する必要はなく、オープンソースシステムとP2Pノードネットワークであるべきだ」というスローガンを叫ぶことができます。
ブロックチェーンを発明して使用する人々の本来の意図は、トラストレスであり、台帳は一貫性があり、偽造不可能で、追跡可能であり、その他の決まり文句の基本であり、ビットコインホワイトペーパーに明確に記載されています。 しかし、イーサリアム以降は、古いパブリックチェーンのスケーリングスキームであろうと、ロールアップやモジュラーブロックチェーンであろうと、誰もが考え方を形成しました:私たちが行うことは、ブロックチェーン(ノードのコンセンサスプロトコルで構成される)またはチェーンソリューションのように見えるロールアップ(ブロックチェーンのデータ構造のみがありますが、ノードには直接のコンセンサスメッセージ交換がありません)。
しかし今は、SCPの枠組みに基づいて、ブロックチェーンでなくても、トラストレス、一貫性のある台帳、非偽造、トレーサビリティなどの一連の要件を実現でき、もちろん、より明確な実装内容があることが前提です。
実行レイヤー
実行層はシステム全体において重要であり、システム全体の計算プロセスを引き受け、システム上で実行できるアプリケーションの種類も決定します。
無限の実行環境
理論的には、実行レイヤーの実行環境は任意の形式で作成でき、プロジェクトチームがプロジェクトをどのように配置するかに応じて、可能性は無限大です。
*Exchange。 SCPに基づいて、DEXの分散化を維持しながら、CEXの速度とゼロコストの特性を持つ、オープンで透明性の高い高TPS取引所を構築できます。 ここでは、CEXとDEXの区別が曖昧になります。 *支払いネットワーク。 Alipay、PayPalなどに似ています。 *仮想マシン/ブロックチェーンローダー/コントラクトのサポート。 開発者は、任意のアプリケーションをデプロイし、すべてのユーザーデータを他のプログラムと共有し、ユーザーの指示に従って操作できます。
SCPは、任意の実行環境をサポートする設計パターンであり、独自の利点があります:歴史的な荷物を持つ特定のコンポーネント、特にSCPにとって本質的に望ましくないイーサリアムコミュニティによって作成された「アカウント抽象化」の概念に依存する必要がなくなります。
SCPアーキテクチャでは、アカウント抽象化の概念はなく、Web2標準アカウントとブロックチェーンアカウントを自由に採用できます。 この観点から見ると、成熟したWeb2のユースケースの多くは、SCPで直接動作するように再考したり、構築したりする必要はありません。 これは、ロールアップに対する SCP の利点である可能性があります。 **
透明性と非対称性
上記のアカウントシステム、そして敏感な読者は、SCPがWeb2のアカウントシステムを利用できるにもかかわらず、それをそのまま使用するのは問題があるように見えることに気づいているはずです。
システム全体が完全に透過的であるため、ユーザーとサーバーの対話モデルを直接使用すると、深刻な問題が発生し、セキュリティがまったく発生しません。 従来のサーバーユーザーモデルがどのように機能するかを確認しましょう。
1.アカウント登録:ユーザーは、アプリケーションの登録ページでユーザー名とパスワードを入力します。 ユーザーのパスワードを保護するために、サーバーはパスワードを受け取った後、ハッシュ関数を介してパスワードを処理します。 ハッシュの複雑さを増し、レインボーテーブル攻撃から防御するために、各ユーザーのパスワードは通常、ランダムに生成された文字列(「ソルト」と呼ばれる)に接続され、ハッシュ化されます。 **ユーザー名、ソルト、ハッシュは、サービスプロバイダーのデータベースにプレーンテキストで保存され、一般には公開されていません。 しかし、それでも、1つは内部の幽霊を防ぐため、もう1つは攻撃を防ぐために、塩と安全な処理を追加する必要があります。
2.ユーザーログイン:ユーザーはログインフォームにユーザー名とパスワードを入力します。 処理されたパスワードハッシュは、データベースに保存されているハッシュ値と比較されます。 2 つのハッシュが一致し、ユーザーが正しいパスワードを入力したことを示す場合、ログイン プロセスは続行されます。
3.操作認証:ログイン検証に合格すると、システムはユーザーのセッションを作成します。 通常、セッション情報はサーバーに保存され、サーバーは識別子(トークンなど)をユーザーのブラウザまたはアプリケーションに送信します。 ユーザーは次のステップでユーザー名とパスワードを再入力する必要がなくなり、ブラウザまたはアプリが識別子を保存し、各リクエストに識別子を添付して、関連付けられたサーバーからのアクセス許可があることを示します。
**典型的なWeb3ブロックチェーンとユーザーインタラクションシステムを確認しましょう。
1.アカウント登録:アカウント登録プロセスは事実上なく、ユーザー名とパスワードのシステムもありません。 アカウント(アドレス)は登録を必要とせず、自然に存在し、秘密鍵を持っている人がアカウントを制御します。 秘密鍵はウォレットによってローカルにランダムに生成され、ネットワークプロセスは関与しません。
2.ユーザーログイン:ブロックチェーンの使用はログインを必要とせず、ほとんどのdAppsにはログインプロセスがありませんが、ウォレットに接続します。 一部のdAppsでは、WalletAddressをフロントエンドに渡すだけでなく、ユーザーが本当に秘密鍵を保持していることを確認するために、ウォレットに接続した後にユーザーが署名して確認する必要があります。
3.操作認証:ユーザーは署名されたデータをノードに直接送信し、ノードは検証後にトランザクションをブロックチェーンネットワーク全体にブロードキャストし、ブロックチェーンネットワークのコンセンサスを満たした後、ユーザーの操作を確認します。
2つのモードの違いは、対称性と非対称性によって生じます。 サーバー/ユーザー アーキテクチャでは、両者が同じシークレットを保持します。 ブロックチェーン・ユーザー・アーキテクチャでは、ユーザーのみがシークレットを保持します。
SCPの実行層をブロックチェーンにすることはできませんが、すべてのデータは公開されているDA層に同期する必要があるため、SCPで使用されるログインと操作の認証方法は非対称である必要があります。 しかし、ユーザーに秘密鍵を保管させたり、ウォレットを使用させたりするなど、大量導入に影響を与える煩雑なアクションや貧弱なエクスペリエンスは望ましくないため、SCP上に構築されたアプリケーションも従来のIDパスワードまたはOAuthスリーパーティ認証ログインを使用する必要性が強いため、この2つをどのように組み合わせるのでしょうか?
非対称暗号とゼロ知識証明ペアの非対称性のため、私は2つのシナリオを想定しています。
※IDパスワードシステムを利用したい場合は、このパスワード保存モジュールをSCPから外して、他の誰にも見られないようにすることができます。 SCP実行レイヤーは、登録やログインなどを行わずに、ブロックチェーンの公開鍵と秘密鍵のアカウントと操作ロジックを引き続き使用します。 ユーザーの ID は、実際には秘密キーに対応します。 **もちろん、この秘密鍵をプロジェクト側で保持することはできず、より実行可能な解決策は、2〜3 MPCを使用して集中ストレージの問題を解決し、ユーザーに秘密鍵の使用を許可しないことです。 OAuthログインに依存する場合、認証手段としてJWT(Json Web Token)を使用できます。 **この方法は、基本的にWeb2メーカーが提供するサードパーティのログインサービスにID認証として依存する必要があるため、上記よりもわずかに中央集権化されます。
※初めてサードパーティでログインする場合は、ユーザーのIDとサービスプロバイダーのIDを表すフィールドをJWTに登録します。 ユーザーのその後の操作では、操作指示がパブリック入力として使用され、JWT全体が秘密の証人として使用され、各ユーザーのZKPとのトランザクションが検証されます。
各JWTには有効期限があり、ユーザーは次回のログイン時に新しいJWTを申請するため、永久に保持する必要はありません。 さらに、このシステムは、JWKを検証するために大規模な工場から提供される公開鍵として理解できるJWKにも依存する必要があります。 したがって、JWK Decentralizationをシステムにどのように導入するか、および将来の秘密鍵ローテーションに対処する方法も検討する価値があります。
いずれにせよ、従来の方法よりも開発と計算にコストがかかりますが、分散化に支払うために必要な価格でもあります。 **もちろん、プロジェクトチームが究極の分散化が必要だと考えていない場合、または開発のさまざまな段階で異なるマイルストーンがある場合は、分散化は白黒ではなく、中間に灰色の領域があるため、これらの設計を行っても問題ありません。
プライバシー
上記の透明性の問題は、ユーザーの操作パラダイムだけでなく、ユーザーのデータにも影響を与えます。 ユーザーのデータが直接公開されます。 これはブロックチェーンでは問題になりませんが、一部のアプリケーションではあまり受け入れられないため、開発者はプライベートトランザクションシステムを構築することもできます。
料金
実行レイヤーがどのように課金されるかも、別の懸念事項です。 これは、DAレイヤーへのデータ送信には、独自のサーバーの運用など、関連するコストも発生するためです。 ユーザーにガス料金を請求する従来のブロックチェーンの1つ目の目的は、ユーザーが大量の反復的なトランザクションをスワイプしてトランザクションネットワークを混乱させないようにすることであり、2つ目はガスに従ってトランザクションを並べ替えることです。 Web2には同様の懸念がないため、フラッドやDDoSなどの基本的な概念しかありません。
実行レイヤーは、完全無料または部分的な充電など、さまざまな課金戦略をカスタマイズでき、MEV(シーケンサーで非常に成熟している)やマーケティング活動などの他の動作を収益化することもできます。
検閲への耐性
実行層は検閲に耐性がなく、理論的にはユーザーのトランザクションを無期限に拒否することができます。 Rollupでは、L1コントラクトの強制アグリゲーション機能によって検閲耐性を保証できますが、サイドチェーンまたはパブリックチェーンは完全な分散型ブロックチェーンネットワークであり、これもレビューが困難です。
**現在、SCPパラダイムの問題である検閲耐性の問題に対する明確な解決策はありません。 **
コンセンサスレイヤー
このレイヤーはルーズなノードで構成されており、これらのノードは積極的にネットワークを形成しないため、厳密にはコンセンサスレイヤーではなく、実行レイヤーの現在の状態を外部(ユーザーなど)に確認するためにのみ使用されます。
たとえば、これらのノードの正常性ステータスに疑問がある場合は、コーディネーターと同じプログラム コードを実行するディテクター クライアントをダウンロードできます。 **
ただし、これはロールアップと似ており、データはバッチで送信されるため、実行レイヤーは常に DA レイヤーよりも新しい状態をユーザーに返します。 これには、事前確認の問題が含まれます。
実行レイヤーは、DAレイヤーにまだ送信されていないため、事前確認とソフトファイナリティの結果をユーザーに提供します。
**コンセンサスレイヤーは、ユーザーにハードファイナリティを提供します。 ユーザーはこれを特に気にしないかもしれませんが、クロスチェーンインタラクションブリッジなどのアプリケーションでは、ハードファイナリティに従う必要があります。 例えば、取引所の入出金システムは、オフチェーンのロールアップシリアライザーによってブロードキャストされたデータを信頼せず、このデータがイーサリアムにアップロードされるのを待ってから認識する必要があります。
コンセンサス層は、結果を確認するために使われるだけでなく、実行層としての災害の冗長性という重要な役割も果たします。 **実行レイヤーが永続的に攻撃し、深刻な悪を行う場合、現時点では、理論的には、任意のコンセンサスレイヤーが実行レイヤーの作業を引き継ぎ、ユーザーのリクエストを受け取ることができます。 このような深刻な状況が発生した場合、コミュニティは実行レイヤーのサーバーとして安定した信頼性の高いノードを選択する必要があります。
集落層
SCPはRollupではないため、Rollupの出金決済レイヤーのように人間の介入なしには、暗号とスマートコントラクトのコードのみに基づいてトラストレスな出金を実現することはできません。 SCPクロスチェーン・インタラクション・ブリッジは、サイドチェーンまたはサードパーティー・ウィットネス・クロスチェーン・インタラクション・ブリッジと同じであり、アセットをリリースするには、認可されたマルチシグネチャー・マネージャーに依存する必要があり、これをウィットネス・モデルと呼んでいます。
証人ブリッジを可能な限り分散化することは、多くのクロスチェーン相互作用研究の主題です。 スペースの都合上、ここでは詳しく説明しません。 適切に設計されたSCPプラットフォームには、実際に評判の良いDecentralization Bridgeマルチシグパートナーも必要です。
なぜSCPはDAレイヤーとしてスマートコントラクトのチェーンを使わないのかと疑問に思う人もいるかもしれません? これにより、コントラクトを提供し、完全にトラストレスな決済レイヤーを作ることができます。
長い目で見れば、何らかの技術的な困難が克服されれば、イーサリアムなどのコントラクトでDAレイヤーを配置し、それに対応する検証用のコントラクトを構築できれば、SCPもマルチシグを使用することなく、Rollupと同じ決済セキュリティを得ることができます。
しかし、実際には、これは必ずしも最適ではありません。
1.イーサリアムは特にデータ保存に使用されておらず、純粋なデータストレージのパブリックチェーンと比較して価格が高すぎます。 SCPパラダイムでは、十分に低い、または固定されたストレージコストが重要です。 この方法でのみ、Web2 レベルのスループットをサポートできます。
したがって、Rollupソリューションは特定の状況でのみより実用的であり、EVMシステムからより多くのWeb2機能に移行する、より広く、よりオープンなアプローチを実装することを計画している場合、Ethereum Rollupのアイデアは適切ではありません。
**SCPはパブリックチェーンのスケーリングスキームではなく、より大きなWeb3コンピューティングプラットフォームアーキテクチャであるため、イーサリアムレイヤー2の考え方に従う必要は明らかにありません。 **
SCPと他のパラダイムを比較した図