はじめに:この記事では、少し破天荒に見えるWeb3インフラの設計パラダイム、ストレージ・コンセンサス・パラダイムSCP(Storage-based Consensus Paradigm)は、Ether Rollupのような主流のモジュール型ブロックチェーン・ソリューションとは理論的に異なる製品設計パラダイムですが、着地のしやすさやWeb2プラットフォームとのインターフェースの容易さという点では実現可能性が高いのです。というのは、彼は当初からRollupのような狭い実装経路に限定するつもりはなく、より広範でオープンなフレームワークでWeb2プラットフォームとWeb3設備を統合したかったからであり、これは独創的でかなり想像力豊かなアプローチと言える。
本文。strong>以下の特徴を持つパブリックチェーンのスケーリングソリューションを想定してみましょう:
従来のWeb2アプリや取引所に匹敵する速度を持ち、どのパブリックチェーンよりもはるかに優れている、L2、ロールアップ、サイドチェーンなどよりもはるかに優れています。
ガス代がかからず、所有コストはほぼゼロです。
資金の安全性が高く、取引所などの中央集権的な施設よりもはるかに高く、ロールアップ以下ですがサイドチェーン以上です。サイドチェーン。
Web2と同じユーザーエクスペリエンスで、ブロックチェーンの公開鍵や秘密鍵、ウォレット、インフラなどについて知る必要はありません。
このようなソリューションは、実にエキサイティングです。一方では、基本的に究極のスケーリングを達成し、他方では、Web3の大量導入において非常に強固な基盤を築き、基本的にWeb2とWeb3のユースケースのギャップをなくします。Web2とWeb3の経験のギャップは基本的になくなりました。
しかし、主流の議論や実践があまりに少ないため、これほど完全な解決策はあまり考えられません。
私たちは、非常に馴染み深いスケーリングの話題から始めましたが、SCPはスケーリングに限定されません。その設計は、スケーリングソリューションと、ビットコインやイーサのようなパブリックチェーンに関するコミュニティの議論に触発されました。そしてそのビジョンと実用的なアプリケーションは、新世代の非信頼インフラ、あるいは非ブロックチェーン構造化コンピューティングプラットフォームを構築することです。
SCPの基本コンポーネントとその仕組み
一般的に言えば、SCPは、イーサやセレスティアのコミュニティが「モジュラー」と呼んでいるような「モジュール化」されたインフラでもあります。イーサやセレスティアのコミュニティが「モジュラー型ブロックチェーン」と呼ぶものには、データ可用性レイヤー、実行レイヤー、コンセンサスレイヤー、決済レイヤーなどのモジュラー型部門がありますSCP。
データ可用性レイヤー:広く認知され実績のあるパブリックチェーン、またはイーサネットのようなデータ可用性レイヤーとしてのストレージ設備。Ether、Arweave、Celestiaなどの可用性レイヤー。
実行レイヤー:ユーザートランザクションを受信して実行するサーバーで、Rollupのソーターと同様に、ユーザーが署名したトランザクションデータのバッチをDAレイヤーに提出します。ただし、実行レイヤーはブロックチェーンスタイルのチェーンテーブル構造を持つ必要はなく、完全にWeb2データベース+コンピューティングシステムであっても良いが、コンピューティングシステム全体は透明性を備えたオープンソースでなければならない。
コンセンサス層:は、実行層からDA層に提出されたデータを引き出すノード群で構成され、実行層と同じアルゴリズムを使って、このデータに対して計算を行い、実行層の結果出力が正しいことを確認します。また、実行レイヤーの冗長化として機能する。また、ユーザはコンセンサス層のノードから返されたデータを読むことで、実行層に不正がないことを確認することができる。
決済レイヤー:は、他のチェーン上の契約またはアドレスを持つノード群で構成され、ユーザーがSCPにチャージしたり、SCPから現金を引き出したりする動作を処理するために使用されます。決済レイヤーのノードは、マルチシグネチャ契約またはTSSベースのアドレスを通じて、トップアップアドレスの引き出し機能を制御する。リチャージ時には、ユーザーはホストチェーンの指定されたアドレスにアセットをリチャージし、出金時には、ユーザーがリクエストを送信し、決済レイヤーノードがそのデータを読み取り、マルチシグネチャまたはTSSを介してアセットをリリースする。決済レイヤーのセキュリティの程度は、使用するクロスチェーンメカニズムによって異なります。
SCPの実用的なフレームワーク
SCPパラダイムを理解するには、以下のフレームワークを利用します。SCPパラダイムを理解するためのフレームワーク。SCPのフレームワークを満たす製品は、再チャージ、送金、引き出し、スワップなどの主要な機能を持つことができ、その上でさらに拡張することができます。次の図は、そのような商品の概略を示しています:
このプロジェクトのDA層は、図中の大きな円である常設保管施設Arweaveを使用している。
実行層のCoordinator。 ユーザーはトランザクションをコーディネータに提出し、コーディネータは計算を実行して結果を提示し、ユーザーの生の入力データを DA 層に一括して提出します。
ディテクター(Detector)は、コーディネーターが提出したトランザクションの生データをArweaveから取得し、コーディネーターのものと一致するアルゴリズムを使って、データと結果を検証します。Detectorクライアントはオープンソースで、誰でも実行できる。
ウォッチメン(Watchmen)は、出金システムをマルチサインするディテクターのセットを実行します。は取引データに基づいて出金要求を検証し、解除します。また、ウォッチメンはプロポーザルへの署名を担当する。
私たちはシステム全体を見ることができ、彼らが到達するコンセンサスはすべてオフチェーンにある。これは、ストレージコンセンサスパラダイムの核心であり、ブロックチェーン型のコンセンサスシステムを捨て、実行レイヤーが重いコンセンサス交換と確認プロセスから解放されることを可能にする。これはRollupと非常に似ているが、SCPはRollupとは異なる道を進み、スケーリング排他的なユースケースからWeb2からWeb3への新しい移行モデルへの移行を試みるようになった。
前述のオーケストレーターはサーバーですが、オーケストレーターが何でもできるという意味ではありません。Rollupのシーケンサーと同様に、Arweaveでユーザーが投稿した生データを一括送信した後、誰でも検出プログラムを実行して検証し、コーディネーターが返した状態と比較することができる。ある意味、これは碑文ベースのアプリと同じ線上にある。
このアーキテクチャでは、集中管理されたサーバー、データベースは基本的な課題となりません。これはSCPパラダイムのもう1つのポイントであり、「中心性」と「単一実体」の概念を切り離します。非信頼システムは集中化されたコンポーネントを持つことができ、単一実体は集中化されたコンポーネントを持つことができます。
信頼されないシステムは集中化されたコンポーネントを持つことができる。
私たちはスローガンを叫ぶことができます。次世代の非信頼インフラは、コンセンサス・プロトコルに頼る必要はないが、P2Pノードのネットワークを持つオープンソースシステムであるべきだ」と。
人々がブロックチェーンを発明し、利用したのは、非信頼性、台帳の一貫性、偽造不可能性、トレーサビリティ、その他の決まりきった基本的な理由によるもので、これらはビットコインのホワイトペーパーに明確に明記されている。しかしイーサ以降、古いパブリックチェーンのスケーリングソリューションであろうと、ロールアップやモジュラーブロックチェーンであろうと、私たちが作るものはブロックチェーンでなければならない(ノードのコンセンサスプロトコルからなる)という考え方を誰もが持つようになりました。ブロックチェーンのデータ構造を持っているだけで、ノードはコンセンサス・メッセージを直接交換しない)。
しかし、現状では、ブロックチェーンでなくとも、SCPフレームワークに基づいて、非信頼性、台帳の一貫性、非偽証可能性、トレーサビリティ、その他多くの要件を達成することは可能です。
実行レイヤー
実行レイヤーは、システム全体のコンピューティングプロセスを実行し、システム上で実行できるアプリケーションを決定するため、システム全体にとって重要です。
無限の実行環境
理論的には、実行レイヤーの実行環境はどのようなものにも見せることができます。プロジェクトの位置づけ:
交換。SCPに基づけば、DEXの分散化を維持しながら、CEXの迅速で0コストの特性を持つことができる、オープンで透明性の高い、高いTPSの取引所を構築することが可能です。
決済ネットワーク。アリペイ、ペイパルなどに似ている。
ローダー/コントラクトをサポートする仮想マシン/ブロックチェーン。どんな開発者でもその上にどんなアプリでもデプロイすることができ、すべてのユーザーデータを他のアプリと共有し、ユーザーコマンドで操作することができます。
任意の実行環境をサポートするSCPのデザインパターンには、ユニークな利点があります:歴史的なお荷物のある特定のコンポーネント、特にイーサリアムコミュニティのオリジナルのようなものに依存する必要がありません。特に、イーサリアムコミュニティによって開拓された「アカウントの抽象化」という概念は、SCPには本質的に必要ありません。
また、SCPアーキテクチャでは、アカウントの抽象化という概念自体が存在しません - Web2標準のアカウントやブロックチェーンのアカウントなどを自由に採用することができます。この観点から、多くの成熟したWeb2のユースケースは、再考やリファクタリングなしでSCP上で直接使用することができます。この点は、おそらくロールアップに対するSCPの利点です。
この点は、おそらくロールアップに対するSCPの利点です。透明性と非対称性
アカウントシステムについては前述しましたが、SCPがWeb2のアカウントシステムを利用できる一方で、それをそのまま使うことには問題があるようだということに、敏感な読者はお気づきでしょう。
なぜならば、このシステム全体が完全に透明だからです!ユーザーとサーバーの直接対話モデルを使用することは、深刻な問題を引き起こす可能性があり、その結果、セキュリティがまったくないシステム全体になってしまいます。伝統的なサーバーとユーザーのモデルがどのように機能するかをおさらいしましょう:
1. アカウント登録: ユーザーはアプリケーションの登録ページでユーザー名とパスワードを入力します。ユーザーのパスワードを保護するために、サーバーはパスワードを受け取り、ハッシュ関数を通して処理します。ハッシュの複雑さを増し、レインボーテーブル攻撃から保護するために、各ユーザのパスワードをランダムに生成された文字列(「ソルト」と呼ばれる)と連結し、一緒にハッシュ化するのが一般的です。ユーザー名、ソルト、ハッシュはサービスプロバイダのデータベースに平文で保存され、一般には利用できません。しかし、それでも、スパイに対しても攻撃に対しても、ソルト化され、保護される必要があります。
2.strong>ユーザーはログインフォームにユーザー名とパスワードを入力します。システムは処理されたパスワードハッシュとデータベースに保存されているハッシュを比較します。2つのハッシュが一致すれば、ユーザーは正しいパスワードを入力したことになり、ログイン処理が続行されます。
3.運用認証:ログイン認証が通過すると、システムはユーザーのセッションを作成します。通常、セッション情報はサーバーに保存され、サーバーはユーザーのブラウザやアプリケーションに識別子(クッキーやトークンなど)を送信します。ブラウザやアプリケーションはクッキーの識別子を保存し、各リクエストに識別子を添付し、クッキーに関連付けられたサーバからの許可を持っていることを示します。
典型的なWeb3ブロックチェーンとユーザーの相互作用システム
1.アカウント登録:。アカウント登録のようなプロセスは事実上ありませんし、ユーザー名とパスワードのシステムもありません。アカウント(アドレス)は登録する必要はなく、自然に存在し、秘密鍵を持つ者がアカウントを管理する。秘密鍵はウォレットによってローカルでランダムに生成され、ネットワークプロセスは一切関与しません。
2.ユーザーログイン:ブロックチェーンの使用はログインを必要とせず、ほとんどのdAppはログインプロセスを持たず、ウォレットに接続します。いくつかのdAppsは、ウォレットに接続した後、単にウォレットアドレスをフロントエンドに渡すのではなく、本当に秘密鍵を保持していることを確認するために、ユーザーに署名を検証することを要求します。
3.操作の認証:ユーザーは署名されたデータを直接ノードに提出し、ノードはトランザクションを検証してブロックチェーンネットワーク全体にブロードキャストし、ブロックチェーンネットワークのコンセンサスに合致したときにユーザーの操作が確認されます。
2つのモデルの違いは、対称性と非対称性による。サーバーとユーザーのアーキテクチャでは、両者が同じ秘密を保持します。ブロックチェーン-ユーザー・アーキテクチャでは、ユーザーだけが秘密を保持する。
SCPの実行レイヤーはブロックチェーンではないかもしれませんが、すべてのデータは一般に公開されているDAレイヤーと同期する必要があるため、SCPが使用するログインと操作の認証は非対称でなければなりません。しかし、やはり、大量導入に影響するような、ユーザーに秘密鍵を保持させたり、ウォレットを使用させたりするような面倒なアクションや劣悪なエクスペリエンスは避けたいので、SCP上に構築されたアプリケーションでは、ログインに従来のIDパスワードやOAuthの3者認証を使用したいという強い要望もあります。
非対称暗号とゼロ知識証明ペアは非対称性を持つので、私は2つの可能なシナリオを想定しています:
ID-パスワードシステムを使いたい場合、このパスワード保存モジュールをSCPから外して、他の誰にも見えないようにすることができます。SCPの実行レイヤーは、ブロックチェーンの公開鍵-秘密鍵アカウントと運用ロジックを内部的に使用したままで、登録やログインなどはありません。ユーザーのIDは、実際には秘密鍵に対応します。この秘密鍵はもちろんプロジェクト側で保存することはできず、より実現可能な解決策は、2-3個のMPCを使用して集中保存の問題を解決すると同時に、秘密鍵を使用する負担をユーザーに負わせないことでしょう。
OAuthログインに依存する場合、認証方法としてJWT(Json Web Token)を使用することができます。このアプローチは、本質的に認証としてWeb2大国が提供するサードパーティのログインサービスに依存しているため、上記よりも若干中央集権的に見えます。
サードパーティログインが初めて使用されるとき、JWTのユーザーのIDとサービスプロバイダのIDを特徴付けるフィールドがシステムに登録されます。その後のユーザー操作では、操作コマンドが公開入力として使用され、JWT全体がZKPとの各ユーザートランザクションを検証するための秘密の証人として使用されます。
各JWTには有効期限があり、ユーザーも次回ログイン時に新しいJWTを要求するため、永久保存の必要はありません。JWKに依存する必要性内のこのシステムに加えて、ここでは、JWKによって提供される公開鍵を検証するための大規模な工場として理解することができます。その後、JWKは、システムに入力する方法を分散化し、後で秘密鍵のローテーション方法などに対処するために、また、探索する価値がある。
どちらを使うにせよ、従来の方法よりも開発や計算に少しコストがかかりますが、それは分散化のために必要な代償です。もちろん、極端な分散化は必要ないと考えるプロジェクトオーナーや、開発段階ごとに異なるマイルストーンを持つプロジェクトオーナーは、このような設計がなくても問題ありません。
プライバシー
透明性の問題は、前述したように、ユーザーとの対話のパラダイムに影響を与えるだけでなく、ユーザーデータにも影響を与えます。ユーザーデータは直接公開される。ブロックチェーンでは問題にはなりませんが、アプリケーションによっては受け入れがたいため、開発者はプライバシー取引システムを構築することもできます。
課金
実行レイヤーがどのように課金するかは、もう一つの注目点です。というのも、DAレイヤーにデータを送信する際にも、独自のサーバーの稼働などのコストが発生するからです。従来のブロックチェーンがユーザーに課金する第一の中核的な目的は、トランザクションネットワークを混乱させるためにユーザーが重複したトランザクションを大量にスワイプするのを避けることであり、第二はガスに基づいてトランザクションをソートすることだけである。
実行レイヤーは、完全無料や部分的なチャージなど、さまざまなチャージ戦略をカスタマイズすることができます。
検閲耐性
実行レイヤーは検閲耐性がなく、理論的にはユーザートランザクションを無制限に拒否できます。一方、サイドチェーンやパブリックチェーンは完全な分散ブロックチェーンネットワークであり、検閲も困難です。
検閲耐性問題に対する明確な解決策はなく、SCPパラダイムにとっての問題です。
コンセンサス層
この層は、積極的にネットワークを形成しない緩く接続されたノードで構成されており、厳密にはコンセンサス層ではありません。このレイヤーは、実行レイヤーの現在の状態を外部(ユーザーなど)に確認するためだけに使用されます。
たとえば、これらのノードの状態が疑わしい場合、コーディネーターと同じコードを実行する検出クライアントをダウンロードすることができます。
しかし、データが一括で送信されるため、実行レイヤーからユーザーに返されるステータスは、DAレイヤーにあるものよりも常に最新であるという点で、ロールアップに似ています。
実行レイヤーは、まだDAレイヤーに提出されていないため、事前に確認されたソフトファイナルの結果をユーザーに与えます。
そしてコンセンサスレイヤーは、まだDAレイヤーに提出されていないため、事前に確認されたソフトファイナルの結果をユーザーに与えます。strong>一方、コンセンサスレイヤーはユーザーにハードな最終結果を提供する。しかし、クロスチェーンブリッジのようなアプリケーションでは、ハードファイナリティに従わなければなりません。例えば、取引所のチャージ・出金システムは、ロールアップ・シーケンサーによってチェーン外にブロードキャストされたデータを信じない。
結果を確認するために使用できることに加えて、コンセンサス層はまた、実行層のための災害に強い冗長性としても重要な役割を持っています。実行レイヤーが恒久的なストライキに陥り、深刻なダメージを受けた場合、どのコンセンサスレイヤーも理論的には実行レイヤーの仕事を引き継ぎ、ユーザーからのリクエストを受け取ることができる。そのような深刻な状況が発生した場合、コミュニティは実行レイヤーのサーバーとして機能する安定した信頼できるノードを選択できるはずです。
決済レイヤー
SCPはRollupではないので、Rollupの出金・決済レイヤーが行っているような、人の介入を必要としない、完全にSCPはRollupではないので、Rollupが行っているような、人の介入を必要とせず、暗号とスマートコントラクトコードに完全に基づいた現金の引き出しはできない。SCPクロスチェーンブリッジは、サイドチェーンまたはサードパーティウィットネスクロスチェーンブリッジと同程度に安全であり、、アセットのリリースにアクセスできるマルチシグネチャ管理者に依存する必要があり、私たちはこれをウィットネスモデルと呼んでいます。
ウィットネスブリッジを可能な限り非中央集権化することは、多くのクロスチェーンブリッジ研究のトピックです。多くのクロスチェーン・ブリッジ研究のトピックである。ここではスペースの都合上、詳細には触れません。よく設計されたSCPプラットフォームは、実際に分散型ブリッジを実現するために、評判の良い複数署名パートナーを持つ必要もある。
なぜSCPはスマートコントラクトをDAレイヤーとして持つチェーンを使わないのかと尋ねる人がいるかもしれません。そうすることで、契約を与える、完全に信頼のない決済レイヤーを作ることができます。
長期的には、いくつかの技術的な困難を克服することで、SCPもまた、イーサなどのコントラクトを持つDAレイヤーにDAレイヤーを置き、それに応じて検証のためにコントラクトを構築することができれば、マルチシグネチャを使用する必要なく、ロールアップと同じ決済セキュリティを得ることができます。
しかし実際には、これは最適ではないかもしれません:
1.イーサは特にデータ保存のために使用されるわけではなく、純粋なデータ保存パブリックチェーンと比較すると高価すぎます。そして、SCPパラダイムにとって、ストレージのコストが十分に低いか、固定されていることは非常に重要です。そうして初めて、Web2レベルのスループットをサポートすることが可能になるのです。
2.EVMに限らず、SCPではどんなロジックでも実装できるため、証明システムの開発は非常に困難です。そして、Optimismのような不正の証明がまだ生きていないチームや、zkEVMの開発の難しさを見ると、イーサリアム上であらゆる種類のシステムの証明を実装しようとすることは非常に難しいことが想像できます。
つまり、ロールアップは特定の状況下でのみより良いソリューションであり、EVMから離れ、より多くのWeb2機能を取り入れた、より広範でオープンなアプローチを求めているのであれば、イーサは適切な場所ではありません。ロールアップは正しい考え方ではありません。
SCPはある種のパブリックチェーンスケーリングソリューションではなく、より大きなWeb3コンピュートプラットフォームアーキテクチャです。
SCPと他のパラダイムを比較したチャート