ストレージ・コンセンサス・パラダイム：次世代ブロックチェーンはブロックチェーンである必要はない

出典：Mistymoon、Geek Web3

以下の特徴を持つパブリックチェーンのスケーリングソリューションを想像してみてください：

• 従来のWeb2アプリケーションや取引所に匹敵する速度を持ち、パブリックチェーン、L2、ロールアップ、サイドチェーンなどの速度をはるかに超える。

• ガス料金はかからず、利用コストは0です。

• 資金の安全性が高く、取引所のような中央集権的な施設よりもはるかに高く、ロールアップには劣りますが、サイドチェーンには匹敵します。

• Web2と同じユーザーエクスペリエンスで、ブロックチェーンの公開鍵や秘密鍵、ウォレット、インフラなどの知識は必要ありません。

このようなソリューションは実にエキサイティングです。一方では、スケーリングという点で基本的に極限まで進んでおり、他方では、Web3の大量導入という点で非常に強固な基盤を築き、基本的にWeb2とWeb3の使用体験のギャップをなくしています。

しかし、主流の議論や実践があまりに少ないため、これほど完全なソリューションは他には考えられません。この論文では、次世代Web3コンピューティングプラットフォームのための、この非常に優れた、カーブの先端を行く設計パラダイム、ストレージベースのコンセンサスパラダイム（SCP）を前向きに紹介します。

前述では、スケーリングという非常に馴染みのあるトピックを導入として使いましたが、実際にはSCPはスケーリング用途に限定されるものではなく、その設計は、スケーリングシナリオと、ビットコインやイーサなどのパブリックチェーンに関するコミュニティの議論にインスパイアされています。そしてそのビジョンと実用化は、新世代のパブリックまたは非ブロックチェーン構造化コンピューティングプラットフォームを構築することです。

SCPの基本コンポーネントとその仕組み

• データ可用性レイヤー：広く認知され、実績のあるパブリックチェーンまたは永続的なストレージ施設が、データ可用性レイヤーとして機能します。

• 実行レイヤー：サーバーは、ユーザートランザクションを受信して実行し、ユーザーによって署名されたトランザクションの生データをDAレイヤーにバッチ送信するために使用されます。ただし、この実行レイヤーは必ずしもブロックチェーンのデータ構造や、EVM互換性などのブロックチェーン関連の概念を持つ必要はない。また、完全にWeb2データベース＋計算システムにすることもできますが、計算システム全体がオープンソースでなければなりません。

• コンセンサス確認レイヤー：は、実行レイヤーによってDAレイヤーに提出された生データを引き出し、実行レイヤーと同じアルゴリズムを使ってそのデータを操作するノード群で構成されます。実行レイヤーの冗長化として使用することができる。また、合意確認層の各ノードから返されるデータを確認することで、実行層に不正がないことを確認することができる。

• 決済レイヤー：チェーン上の他のコントラクトまたはアドレスを持つノード群で構成され、ユーザーがSCPに入金したり、SCPから現金を引き出したりするのに使用されます。ノードは、マルチシグネチャ契約またはTSSベースのアドレスを通じて、トップアップアドレスの引き出し機能を制御する。チャージ時にはホストチェーンの指定アドレスにチャージし、出金時には実行レイヤーにリクエストを送り、決済レイヤーのノードがDAレイヤーからデータを読み込んだ後、マルチシグネチャまたはTSSを実行して資産を放出する。決済レイヤーのセキュリティレベルは、サイドチェーンやクロスチェーンブリッジのクロスチェーンメカニズムと同じです。
  

everPay

everPayはSCPのパイオニアであり、すでにSCPに基づく独自の製品を率先して構築しています。 現在、everPayの主な機能は再チャージ、送金、引き出し、スワップです。

everPayの主な機能はリチャージ、送金、出金、スワップで、その上、後からほとんどすべてのWeb3とWeb2の機能で拡張することができます。

それでは、ストレージコンセンサスパラダイムを完全に理解するために、everPayのワークフローを見ていきましょう。

everPayのDAレイヤーは、永続的なストレージであるArweaveを使用します。

コーディネーターは実行レイヤーです。ユーザーはトランザクションをコーディネータに提出し、コーディネータは計算を実行して結果を提示し、次にユーザーの生の入力データをDA層に一括して提出する。

Detector（ディテクター）は、コーディネーターが提出したトランザクションの生データをArweaveから取り出し、コーディネーターのものと一致するアルゴリズムを使ってデータと結果を検証する。Detectorクライアントも同様にオープンソースであり、誰でも実行することができる。

ウォッチメンは、出金システムをマルチサインするディテクターのセットを実行します。取引データに基づいて出金要求を検証し、解除する。また、ウォッチメンはプロポーザルに署名する役割も担っている。

私たちは、彼らがコンセンサスに達したシステム全体が、ストレージコンセンサスパラダイムの本質である、チェーンの外に配置されていることを見ることができます - それはノード間のブロックチェーンスタイルのコンセンサスシステムを放棄し、このようにエグゼクティブレイヤーは、重いコンセンサス交換を取り除くことができ、そして確認プロセスは、ほぼ無制限のTPSと経済性を達成するように、サーバーの良い仕事をする必要があります。これはRollupと非常によく似ていますが、SCPは間違いなくRollupの概念をさらに抽象化し、高度化し、スケーリング排他的なユースケースから新世代のWeb3コンピューティングプラットフォームの設計パラダイムに変えます。

everPayのコーディネータはサーバーですが、だからといってコーディネータが何でもできるというわけではありません。Rollupのシーケンサーと同様に、Arweaveでユーザーが投稿した生データを一括送信した後、誰でも検出プログラムを実行してそれを検証し、コーディネーターから返された状態と比較することができます。これ自体は、状態遷移関数（STF）が決定論的関数であり、入力 -> STF -> 出力だからである。誰もが同じSTFと同じ入力（すべてDAに提出され、改ざんされることがなく、公開されている）を持っている限り、得られる出力は同じでなければなりません。

このアーキテクチャでは、中央集権化されたサーバーやデータベースは基本的な問題になりません。これはSCPパラダイムのもうひとつの本質であり、「集中型」と「単一実体」の概念を切り離すものです。分散型システムは、集中型コンポーネントを持つことができます。

ここから、センセーショナルだが論理的なスローガン、「次世代のブロックチェーンはブロックチェーンである必要はない」を叫ぶことができる。人々が分散化、台帳の一貫性、偽造不可能性、トレーサビリティ、その他の決まりきった基本的なことを意図してブロックチェーンを発明し、使用してきたため、古いパブリックチェーンのスケーリングソリューションであれ、真新しいものであれ、ある種の考え方が形成されてきました。(ブロックチェーンのデータ構造を持つだけで、ノードがコンセンサスを交換することはない）。しかし今のところ、SCPベースのソリューションは、ブロックチェーンでなくても、中心性、ブックの一貫性、非偽証可能性、トレーサビリティなど、さまざまなニーズを満たすことができる。

実行レイヤー

実行レイヤーは、システム全体のスループットとオペレーションを担当し、システム上で実行できるアプリケーションの種類を決定するため、システム全体にとって重要です。

無限の実行環境

理論的には、実行層の実行環境はどのようなものにもすることができ、プロジェクトの位置づけ次第で可能性は無限に広がります。独自プロジェクト：

• Exchange.SCPに基づけば、DEXの非中央集権的な性質を維持しながら、CEXの迅速で0コストの特徴を持つことができる、オープンで透明性の高い、無制限のTPS取引所を構築することが可能です。

• 決済ネットワーク。アリペイ、ペイパルなどに似ている。

• ローダー/コントラクトをサポートする仮想マシン/ブロックチェーン。どんな開発者でも、その上にどんなアプリケーションでもデプロイすることができ、すべてのユーザーのデータを他のアプリケーションと共有し、ユーザーの指示に従って操作することができる。

ユーザーはブロックチェーン形式のウォレットから完全に解放され、またサーバーとしかやり取りしないため、従来のインターネットアプリケーションと同じユーザーエクスペリエンスを持ちながら、同時に分散化されています。

上記のプロセスには、クロスチェーンスワップやアカウントの抽象化といった似たような概念がすでに含まれていることがわかりますが、もちろん似ているだけで、SCPの文脈でのみ理解しています。特に、アカウントの抽象化のような概念はSCPには当然必要なく、言うなればEtherCommunityのお荷物の遺産である。何度も努力を重ねた結果、EthernetコミュニティはついにWeb3大量導入の問題の1つであるアカウント問題に対処するためにEIP-4337標準を導入した。そして、EIP-4337は単なる標準であり、その上でのアプリケーションの実践はまだテストされていない。一方、SCPアーキテクチャ自体にはアカウント抽象化の概念はなく、Web2標準のアカウントやブロックチェーンのアカウントなどを自由に採用することができる。この観点から、多くの成熟したWeb2のユースケースは、再考やリファクタリングなしでSCP上で直接使用することができます。

透明性と非対称性

アカウントシステムについては前述しましたが、敏感な読者ならすでにお気づきでしょうが、SCPはWeb2のアカウントシステムを活用できる一方で、それをそのまま使うことには問題があるようです。

なぜなら、このシステム全体が、完全に透明だからです！ユーザーとサーバーの直接的な相互作用モデルを使用することは、深刻な問題を引き起こす可能性があり、その結果、システム全体がセキュリティを欠いたものになってしまいます。

1.アカウント登録:ユーザーはアプリケーションの登録ページでユーザー名とパスワードを入力します。ユーザーのパスワードを保護するために、サーバーはパスワードを受け取り、ハッシュ関数を通して処理します。ハッシュの複雑さを増し、レインボーテーブル攻撃から守るために、各ユーザのパスワードをランダムに生成された文字列(「ソルト」と呼ばれる)と連結し、一緒にハッシュするのが一般的です。ユーザー名、ソルト、ハッシュはサービス・プロバイダーのデータベースに平文で保存され、一般には公開されない。しかし、その場合でも、スパイや攻撃に対する安全性を確保するために、ソルトが必要である。

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

3.運用認証：ログイン認証が通過すると、システムはユーザーのセッションを作成します。通常、セッション情報はサーバーに保存され、サーバーはユーザーのブラウザやアプリケーションに識別子（クッキーやトークンなど）を送信します。ブラウザやアプリケーションはトークンを保存し、各リクエストに添付します。

典型的なWeb3ブロックチェーンとユーザーの相互作用システムを見てみましょう。

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

2.ユーザーログイン：ブロックチェーンを使うのにログインは必要なく、ほとんどのdAppはログインプロセスを持たず、ウォレットに接続します。ほとんどのdAppsはログインプロセスを持たず、ウォレットに接続します。いくつかのdAppsはウォレットに接続した後、ユーザーが本当にこのウォレットの秘密鍵を保持していることを確認するために、接続されたウォレットの身元を署名で確認することを要求します。

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

2つのモデルの違いは、対称性と非対称性に起因する。サーバーとユーザーのアーキテクチャでは、両者が同じ秘密を保持します。SCPの実行レイヤーはブロックチェーンではないかもしれませんが、すべてのデータは一般に公開されているDAレイヤーと同期する必要があるため、SCPがログインや操作に使用する認証方法は非対称でなければなりません。しかし、大規模な導入に影響するような、ユーザーに秘密鍵を保持させたり、ウォレットを使用させたりするような面倒なアクションや劣悪なエクスペリエンスも避けたいため、SCP上に構築されたアプリケーションでは、ログインに従来のIDパスワードやOAuthの3者認証を使用したいという強い要望もあります。

非対称暗号とゼロ知識証明ペアは非対称性を持つので、私は2つの可能なシナリオを想定しました:

• ID パスワード方式を使いたい場合、このパスワード節約モジュールを SCP から除外することができます。SCP実行レイヤーは、ブロックチェーンの公開鍵-秘密鍵アカウントと運用ロジックを内部的に使用し、登録やログインなどは行いません。ユーザーIDは、実際にユーザーが使用するIDに対応します。ユーザーIDは、実際には秘密鍵に対応する。この秘密鍵はもちろんプロジェクト側に保存することはできません。より実現可能な解決策は、2-3個のMPCを使用して、ユーザーに秘密鍵の使用を負担させないようにしながら、集中保存の問題を解決することでしょう。

• OAuthログインに頼る場合、認証方法としてJWT（Json Web Token）を使うことができます。このアプローチは、基本的に認証のためにWeb2ベンダーが提供するサードパーティのログインサービスに依存するため、上記よりも若干中央集権的です。サードパーティログインが初めて使用されるとき、JWT のユーザーの ID とサービスプロバイダの ID を特徴付けるフィールドがシステムに登録される。その後のユーザの操作では、操作指示が公開入力として使用され、JWT全体がZKPとの各ユーザ取引を検証する秘密の証人として使用される。各JWTには有効期限があり、ユーザーは次回ログイン時にも新しいJWTを要求するので、安全に保管する必要はない。JWKに依存する必要性の中でこのシステムに加えて、ここではJWKを検証するために大手メーカーが提供する公開鍵と理解することができる。そして、JWKがどのようにシステムに分散投入されるのか、将来的に秘密鍵のローテーションに対処する方法なども探求する価値がある。

どの方法を使うにせよ、これは従来の開発やコンピューティングの方法よりも少し高価ですが、分散化のためには必要な代償です。もちろん、極端な分散化は必要ないと考えるプロジェクトや、開発の段階ごとに異なるマイルストーンを持つプロジェクトは、このような設計がなくても問題ありません。

Privacy

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

課金

実行レイヤーがどのように課金されるかは、もう一つの注目点です。というのも、DAレイヤーにデータを提出する際にも、独自のサーバーの稼働などを含むコストが発生するからです。従来のブロックチェーンがユーザーにガスを課金する第一の中核的な目的は、ユーザーが大量の重複トランザクションをスワイプしてトランザクションネットワークを混乱させるのを避けることであり、第二はガスに基づいてトランザクションをソートすることだけである。web2には同様の懸念がないため、フラッディングやDDoSなどの基本的な概念しかない。

実行レイヤーは、完全無料や部分課金など、さまざまな課金戦略でカスタマイズでき、MEV（シーケンサーではすでに非常に確立されている）やマーケティングキャンペーンなど、他の行動からも利益を得ることができます。

検閲への耐性

実行レイヤーは検閲に耐性がなく、理論的にはユーザーからのトランザクションを無制限に拒否できます。一方、サイドチェーンやパブリックチェーンは完全な分散ブロックチェーンネットワークであり、検閲も困難です。

この問題を解決する明確なソリューションはなく、SCPパラダイムにとっての問題です。

コンセンサス確認レイヤー

このレイヤーは緩く接続されたノードで構成されており、積極的にネットワークを構成しているわけではないため、コンセンサスレイヤーではありませんが、単に実行レイヤーの現在の状態を外部（ユーザーなど）に確認するために使用されます。例えば、everPayの運用状況に懐疑的な場合は、コーディネーターと同じSTFを実行するディテクタークライアントをダウンロードすることができます。

これはRollupと似ていますが、データが一括で送信されるため、実行レイヤーはDAレイヤーで利用可能なものよりも常に更新されたステータスをユーザーに返します。ここには、ソフトファイナリティとハードファイナリティの問題がある。実行レイヤーは、まだDAレイヤーに提出されていないので、ユーザーにソフト的な最終性を与え、一方、コンセンサス確認レイヤーは、ユーザーにハード的な最終性を与える。ユーザーは特に気にしないかもしれないが、クロスチェーンブリッジのようなアプリケーションでは、ハードファイナリティは守られなければならない。例えば、取引所のリチャージと引き出しシステムは、ロールアップシーケンサーの瞬時の最終性には依存しません。

結果を確認するために使用できることに加えて、コンセンサス確認レイヤーは、実行レイヤーのための災害に強い冗長性としての重要な役割を持っています。もし実行レイヤーが永久ストライキを起こし、深刻ないたずらをした場合、この時点でどのコンセンサス確認レイヤーも理論的には実行レイヤーの仕事を引き継ぎ、ユーザーからのリクエストを受け取ることができる。そのような深刻な状況が発生した場合、コミュニティは実行レイヤーのサーバーとして機能する安定した信頼できるノードを選ぶことができるはずだ。

決済レイヤー

SCPはRollupではないため、Rollupの出金や決済レイヤーのように、人の介入を必要とせず、完全に数学とスマートコントラクトコードに基づいているような、信頼のおける出金はできません。それはサイドチェーンやクロスチェーンブリッジのクロスチェーンメカニズムと同程度に安全であり、私たちがウィットネスモデルと呼んでいるアセットに対してアセットをリリースする特権的なオブザーバーに依存しています。

ウィットネスブリッジを可能な限り非中央集権的なものにすることは、多くのクロスチェーンブリッジ研究の主題となってきました。紙面の都合上、ここではその詳細には触れません。よく設計されたSCPプラットフォームは、everPayとMPCサービスプロバイダーのSafeheronの深い協力のように、分散型ブリッジを実際に行うための評判の良い複数署名パートナーも持たなければなりません。

なぜSCPはスマートコントラクトを持つチェーンをDAレイヤーとして使わないのかと尋ねる人もいるかもしれません。そうすれば、コントラクトを与える、完全に信頼のおける決済レイヤーを作ることができます。

長期的には、いくつかの技術的な困難を克服することで、SCPも、イーサのようなコントラクトを持つDAレイヤーにDAレイヤーを置き、検証のためにコントラクトを適宜構築することができれば、マルチシグネチャを使用する必要なく、ロールアップと同じ決済セキュリティを得ることができます。

しかし実際には、これは最適ではないかもしれません。

1.イーサネットはデータストレージ専用ではなく、純粋なデータストレージパブリックチェーンには高価すぎます。また、SCPパラダイムでは、十分に低い、または固定のストレージコストが重要です。

2.システムの開発が非常に難しいことの証明 SCPでは、EVMのモデリングだけでなく、どんなロジックでも実装することが可能だからです。不正の証明がまだ生きていないOptimismのようなチームや、zkEVMの開発の難しさを見ると、イーサリアム上で多種多様なシステムの証明を実装しようとすることは非常に難しいことが想像できます。

もう1つの重要なポイントは、このいわゆる決済セキュリティはロールアップと同じですが、イーサなどのスマートコントラクトによるチェーンのDAレイヤーのみで、元のデータはすべてイーサに渡されるため、イーサ上のあなたの決済コントラクトは、チェーンの最終的な状態を証明するために元の入力データを「参照」することしかできません。入力データは、Ether上の決済コントラクトが最終的な状態の正しさを証明するために、元の入力データを「参照」するために使用されます（直接参照されるのではなく、ハッシュやアキュムレータなどを通じて間接的に参照されることに注意してください。）しかし、他のチェーンには何もデータがないため、他のチェーンに対して同じセキュリティを享受することはできない。他のチェーンに渡りたい場合は、結局ウィットネスモードのクロスチェーンブリッジを使わなければならない。

つまり、Rollupソリューションは、特定の観点から、つまりチェーンを自分のホームチェーンと考えた場合にのみ、より優れた決済セキュリティを持つということです。SCPはある種のパブリックチェーンスケーリングソリューションではなく、より大規模なWeb3コンピュートプラットフォームアーキテクチャなので、必ずしもチェーン中心の観点から実装する必要はありません。決済レイヤーをスマートコントラクトに基づかせることで、マザーチェーン以外のチェーンの決済を保護することはできません。

まとめ

SCPと他のパラダイムの比較表です。

SCPは新しいWeb3コンピューティングプラットフォームパラダイムであり、アプリケーションのスピードという点では従来のWeb2トランザクションに匹敵し、トランザクションコストはごくわずかです。SCPは新しいWeb3コンピューティングプラットフォームパラダイムであり、アプリケーションのスピードと無視できるトランザクションコストの点で、従来のWeb2トランザクションに匹敵し、主流のソリューションと一致するセキュリティで無限のアプリケーションの可能性を構築することができます。現在、SCPパラダイムの下で、everPay、PermaSwap、Mind Networkなど、数多くのアプリケーションが登場しています。