アーキテクチャの観点から分析すると、真のCrypto-native DAppとは何でしょうか?
執筆: msfew、Foresight Research
0. Web2 アプリのアーキテクチャ
私たちが現代的な toC アプリケーションを開発する際、Web アプリ、モバイル アプリ、デスクトップ アプリに関わらず、基本的なアーキテクチャは以下の三つの端で要約できます:
左から右にそれぞれ:
フロントエンド: クライアントとも呼ばれます。アプリのフロントエンドは、ユーザーがブラウザ内で見るページや、モバイルデバイスで使用するアプリです。フロントエンドはビューと表示を制御します。
バックエンド: サーバーサイドとも呼ばれます。アプリのバックエンドの存在意義は主にフロントエンドにインターフェースとデータを提供することです。通常、アプリの主要なビジネスロジックはバックエンドにあります。
データベース: データベースはその名の通り、データを専門に保存します。バックエンドはデータベースの内容を読み取ったり、変更したりします。
なぜソフトウェアにはこの三つの端が必要なのでしょうか?なぜフロントエンドが直接データベースに接続しないのでしょうか?中間にバックエンドが必要な理由は実際に多くの側面があります:
a) エンジニアリング
開発者の視点: 現代のアプリのフロントエンドは、複雑なデータモデルとビューの状態管理を同時に処理する余裕がありません。エンジニアリングの観点から言えば、各エンジニアが全知全能で肥大化したシステムを維持するのは良くありません。さらに、多くのロジックはフロントエンドが表示する必要がないものです。例えば、eコマースプラットフォームの在庫などです。
アーキテクチャの観点: 各端にはデータを記述するための独自のルールと言語があります。フロントエンドは人間が理解できる思考でページを構築し、バックエンドはオブジェクト指向の言語でデータを操作し、データベースは関係代数言語で物理ストレージにアクセスします。三つの端を統一するための万能のルールを定めることはできません。また、言語がそれぞれの役割を果たすため、パフォーマンスの重点も異なります。
b) 通信
プロトコルの観点: 図を観察すると、三つの端を接続する二つの接続方法が異なることがわかります。通常、toC のアプリケーションでは、フロントエンドとバックエンドの通信には HTTP プロトコルが使用され、バックエンドとデータベースは異なるプロトコルを持っています。例えば、MySQL と MongoDB は異なるプロトコルを持っています。非常に薄いバックエンド (GraphQL + Hasura) を介して、または新しいプロトコル (OData) を規定することで、フロントエンドがデータベースに直接接続するのと似た効果を得ることができます。また、CouchDB のようにこの通信のために生まれたプロトコルもありますが、他の欠点は依然として解決されていません。
データマッピングの観点: フロントエンドは UI を処理し、バックエンドはオブジェクトを処理し、データベースはデータを処理します。フロントエンドとバックエンドの接続は UI とオブジェクトのマッピングを使用し、バックエンドとデータベースの接続はオブジェクト関係を使用してマッピングする必要があります。
c) セキュリティ
データの観点: 現在、私たちが使用しているアプリケーションの多くは Web ベースのアプリケーションであるため、フロントエンドが直接データベースに接続すると、ブラウザという不安全でオープンな環境下でデータ漏洩やハッカー攻撃を防ぐのが非常に難しくなります。データベースは理論的にはさまざまな認証手段を通じてデータの可視性を制御できますが、バックエンドの存在意義の一つは、信頼できる環境で設計された方法で実行し、既知のセキュリティ問題を排除することです。
d) Web2 アプリのアーキテクチャが DApp に与える示唆
以上の三つの観点から、なぜ Web2 アプリが三端アーキテクチャであるのかを分析しました。これにより、ブロックチェーン DApp に対するいくつかの考察が得られました:
エンジニアリング: ブロックチェーンのモジュール化思想に対応しています。各コンポーネントがそれぞれの役割を果たし、ストレージはストレージチェーンを使用し、ユーザーデータは従来のパブリックチェーンで保存します。開発者は高い開発メンタル負担を抱える必要はありません。
通信: ブロックチェーンネットワークの異なるコンセンサスメカニズムに対応しています。これらの異なるメカニズムは、ブロックチェーンの相互運用性を難題にしますが、Cosmos や Polkadot のような相互運用プロトコルが全ネットワークをリンクしようとしています。しかし、Web2 アプリの観点から見ると、これは必ずしも最良の解決策を意味するわけではありません。データマッピングはアカウント指向または UTXO の設計パターンに対応でき、両者はパフォーマンス、プライバシー、開発の複雑さにおいてそれぞれ利点と欠点があります。
セキュリティ: ブロックチェーンの非中央集権と「Verify, Not Trust」という思想に対応しています。セキュリティはブロックチェーン分野でより重要であるため、データの処理と可視性を調整するために、検証可能で、完全に透明で公開された方法が必要です。これにより、透明で許可不要な DeFi、公開され所有権を持つ NFT、そして DApp にとって最も重要な可組み合わせ性が実現されます。
1. Web3 DApp アーキテクチャ
ほとんどの Web3 DApp は以下のアーキテクチャに従っています:
シンプルなアプリ (純粋にチェーン上のデータで、インタラクションが複雑でない)、例えば: Uniswap や純粋にチェーン上に保存された NFT プロジェクト。
フロントエンドは Web2 アプリと違いがありません。
バックエンドなし (チェーン上のスマートコントラクトがバックエンドとして機能します)。
ブロックチェーンがデータベースとして機能します。
a) Web3 DApp の詳細なコンポーネント
より詳細に言えば、完全な Web3 DApp のワークフローは、より多くのコンポーネントを含みます:
フロントエンド: ブラウザ、ウォレット、ページ。
フロントエンドとバックエンドの通信: ノードプロバイダー、インデックスプロトコル。
概念的なバックエンド: ブロックチェーンネットワーク上のスマートコントラクト。
バックエンドデータベース通信: ノードプロバイダー、ストレージネットワークゲートウェイ。
データベース: スマートコントラクトの状態と分散型ストレージネットワーク。
b) Web3 DApp はどのようにバックエンドなしを実現するのか?
ブロックチェーンネットワーク上のチューリング完全なスマートコントラクトの存在により、ブロックチェーンは最良のサーバーレスプラットフォームとなり、Trustware として見なされることができます。アプリのデータとバックエンドロジックはスマートコントラクト内で実現できます。
サーバーレス関数と比較して、スマートコントラクトはより優れたものであり、Web2 アプリよりも優れたアーキテクチャとモデルを生み出します:
支払い方法: サーバーレス関数は通常開発者が費用を支払いますが、スマートコントラクトの大部分のインタラクション費用はユーザーが支払い、ユーザーはチェーン上のスペースに対して喜んで費用を支払います。
実行環境: サーバーレス関数は非常に柔軟な実行環境を持っていますが、スマートコントラクトの実行環境は選択肢が少ないものの、非常に軽量です。
デプロイ環境: サーバーレス関数は中央集権的なクラウドサービスプラットフォームにデプロイされますが、スマートコントラクトは分散型で許可不要のネットワークにデプロイされます。さらに、ネットワークの運営コストは中央集権的なプラットフォームからマイナーに移転され、経済システムはより自律的になります。
しかし、真に完全なアプリにとって、スマートコントラクトだけをバックエンドとして使用することでは完全な機能を実現することはできません。そのため、Keeper ネットワークやオラクルなどの他のコンポーネントが必要になります。
2. Web3 Crypto-native DApp アーキテクチャ
Web3 DApp は、スマートコントラクトをバックエンドとして実現したシンプルな分散型アプリケーションを指します。複雑なアプリを完成させるためには、多少なりとも中央集権的なサービスを導入することがあります。真に Crypto-native で trustless な DApp を実現するには、アーキテクチャに新しい変化を加える必要があります。
Web2 の複雑なアプリは、実際には私たちが以前に要約した三端以上のものであり、多くのモジュール化、中間層、水平展開のアーキテクチャ分割が必要です。
a) フロントエンド ⇒ オープンソース + セルフホスティング フロントエンド
Web3 フロントエンドのトリガーロジックは、実際には Web2 自体とは異なります。Web3 の操作はすべてユーザーによって行われ、確認され、チェーン上のアドレスを中心にしています。Web2 では、クライアントが直接サーバーやデータベースにデータ更新をトリガーします。Web3 フロントエンドの発展には、二つの大きなトレンドがあると考えています:
フレームワークの選択: フロントエンドの二大フレームワークである React と Vue の中で、React が Web3 の主導的地位を占めています。これは主にエコシステムとさまざまなコンポーネントの蓄積によるものです。
例えば web3-react や Center.dev。しかし、私個人の感覚では、React プロジェクトの主導権は常に Meta の手にあり、オープンソースライセンスの変更も何度も議論を引き起こしているため、もし機会があれば Vue フレームワークを使用し、依存関係ができるだけ少ない第三者ライブラリを使ってフロントエンド開発を行う方が、React よりも良いと思います。
フロントエンドのホスティング: フロントエンドは DApp がハッキングされる (悪意のあるハイジャックやスクリプト注入) および検閲される (Uniswap や Flashbots のソースコードには OFAC のブラックリストが含まれています) のが最も多い場所です。Yearn Finance は早くからユーザーに DApp のフロントエンドを自分でホスティングすることを奨励していました。Arweave のような永久保存ネットワークにフロントエンドをホスティングすることも、各バージョンのフロントエンドが削除されず、永久にアクセス可能であることを保証します。Trustless.fi もフロントエンドマーケットプレイスの概念を提案し、ユーザーが複数のコミュニティでホスティングされたフロントエンドの中から選択できるようにしています。これにより中立性と「フロントエンドの多様性」が保証されます。Etherscan などの他のブロックチェーンブラウザも中立的なフロントエンドと見なされ、ユーザーはそれを通じて直接インタラクションを行うことができます。また、特定のアプリケーションが契約にフロントエンドを生成することもあります。最近、Tornado が検閲され、多くのコミュニティ (例えば codeisspeech や theshake) が自発的にそのフロントエンドをホスティングしています。
これら二つの点の発展は、DApp のフロントエンドに検閲耐性をもたらし、DApp 全体のセキュリティと非中央集権性を大幅に向上させるでしょう。
b) バックエンド ⇒ ZKP + スマートコントラクト
アプリアーキテクチャの進化プロセスは次のようになります:
Web2 アプリ: フロントエンド ⇒ バックエンド ⇒ データベース
Web3 シンプルアプリ: フロントエンド ⇒ スマートコントラクト
Web3 複雑アプリ: フロントエンド ⇒ ZKP ⇒ スマートコントラクト
スマートコントラクトはアプリ全体を非中央集権化しますが、公開ネットワーク上のスマートコントラクトを使用してアプリのロジックを処理することは二律背反です。データとコードが公開され、透明性と可組み合わせ性が保証されますが、プライバシーとセキュリティリスクが完全に露呈し、同時にチェーン上のスペースと計算コストが非常に高くなります。
ZKP は Web3 時代の RSA となり、アプリの通信セキュリティの短所と非中央集権の短所を解消し、真に信頼できるかつ信頼しない DApp を実現します。
ZKP の導入は、フロントエンドとバックエンドの間の中間層および通信手段として、再びその二つの大きな利点を非常に良く発揮します:
プライバシー: Web2 アプリでは、プライバシーは常にデフォルトの選択肢と見なされていましたが、ブロックチェーンネットワークの性質により DApp は常に形骸化した「プライバシー」を持っています。ZKP は中間層として、敏感なデータをオフチェーンで処理することができ、この問題を解決します。
スケーラビリティ: チェーン上のスペースは限られているため、多くの Web2 アプリの複雑なアルゴリズムを実現できません。ZKP は計算の信頼性を保証しながら、アルゴリズムをオフチェーンで実行し、チェーン上で検証します。
無数のプロジェクトがこれら二つの方向に向かって努力していますが、ここでは具体的には挙げません。主に克服すべき二つの難点があります:
計算の実現可能性: ZKP の計算の種類は制限されており、すべての計算が ZKP で解決できるわけではありません。
最適化: 操作の複雑さが増すと、計算時間とスペースが大幅に増加します。これには多くのソフトウェアとハードウェアの最適化が必要です。また、多くのケースではスループットの向上にしか顕著な改善ができず、全体の証明のオーバーヘッドを削減するのは難しいです。
c) データベース ⇒ 非中央集権ノードサービス
私たちは以前、DApp がどのようにブロックチェーンをバックエンドおよびデータベースとして使用するかについて説明しました。DApp がブロックチェーンネットワークに接続するためには、ノードサービスが必要です。
現在、DApp が一般的に使用しているのは中央集権的な NaaS であり、例えば Alchemy や Infura です。私の構想では、将来的には三つのより良い方向があります:
非中央集権 NaaS、プロトコル化された Infura ですが、これは特に大きな必要性や実現可能性はありません。NaaS の非中央集権化の目的は主に検閲に対抗するためだけです。
多中心 NaaS、複数の中央集権的 NaaS をバックアップとして使用します (Chainlink + Uniswap のオラクルの組み合わせに似ています)。これはより実現可能で信頼できるソリューションであり、検閲耐性と稼働時間を保証します。
自己ホスティング NaaS。究極のソリューションであり、「データベース」接続の信頼性とさまざまなデータのプライバシーおよび検閲耐性を保証し、ネットワークの非中央集権性を高めます。自己ホスティングフロントエンドと組み合わせることで、全体の DApp は非常に非中央集権化されます。
d) Crypto-native DApp の事例
最近制裁を受けた Tornado.cash (特に旧バージョン) は、非常に Crypto-native な DApp であり、私たちの多くの定義を満たしています:
フロントエンドは NuxtJS の Vue フレームワークを使用しており、一般的な React フレームワークではありません。
完全にフロントエンドコード内の ZK 回路とスマートコントラクトで実現されており、サーバーサイドのコードは一切ありません。
コードは完全にオープンソースで、IPFS にホスティングされています。
旧バージョンには秘密鍵やマルチシグによる制御がありません。
私は、今後さらに多くのアプリが Tornado.cash のパラダイムに基づいてアーキテクチャを構築することになると信じています。これは私の中で最も完璧な非中央集権的な Web3 アプリアーキテクチャです。
3. Web3 インフラ
上記は簡略化されたアーキテクチャですが、以下はより具体的な実際の DeFi アプリのアーキテクチャです:
これにはノードサービス以外のいくつかの補完的なインフラストラクチャが含まれています:
インデクサー: 左側の The Graph。チェーン上のデータは便利にクエリできないため、インデクサーがコントラクト関連データを組み立てる必要があります。
オラクル: 右下の Chainlink。チェーン上でコントラクトやネットワーク以外の価格データを取得する必要があるため、チェーン上 (Uniswap TWAP) またはオフチェーンオラクル (Chainlink) から価格を供給する必要があります。
Keeper: 右下の Keep3r Network。スマートコントラクト自体には自動的に実行タスクをトリガーする能力がないため、外部トリガーの支援が必要です。
これらの基盤インフラは DApp の構築において非常に重要であり、今後の文章でオラクルとインデクサーの問題と革新の機会について詳しく紹介します。
なぜこれらの基盤インフラだけが考慮され、NFT 制作ツール、ノーコードコントラクト生成ツール、コントラクトフロントエンド生成ツールが考慮されなかったのでしょうか?それは、私個人の見解として、良い Web3 インフラストラクチャは継続的に価値を捕捉する能力を持ち、それを使用するアプリと共に成長し続ける必要があるからです。一度の支払いで終わるのではなく、これが Web2 SaaS と Web3 プロトコルから得られた経験です。
熊市は基盤インフラを構築し、向上させる非常に良い機会です。私は、これらの革新的な Fat Infra が次の DApp の革新を支え、ベースレイヤーとして巨大な価値を捕捉することになると信じています。