Foresight Ventures: 暗号ネイティブ DApp アーキテクチャ

Foresight

特邀专栏作者

2022-08-25 03:28

この記事は約7192文字で、全文を読むには約11分かかります

web2 と web3 の初期のアプリケーション構築の経験から、私たちは真の暗号ネイティブ DApp アーキテクチャの将来に期待することができ、そこからインフラストラクチャの革新の方向性につい

AI要約

展開

オリジナル著者: msfew@Foresight Ventures

オリジナル著者: msfew@Foresight Ventures

最初のレベルのタイトル

0. Web2 アプリのアーキテクチャ

Web アプリ、モバイルアプリ、デスクトップアプリのいずれであっても、最新の toC アプリケーションを開発する場合、その基本アーキテクチャは次の 3 つの端末に要約できます。
左から右に次のとおりです。
フロントエンド: クライアントとも呼ばれます。アプリケーションのフロントエンドは、ユーザーがブラウザに表示するページ、またはモバイルデバイスで使用されるアプリです。フロントエンドはビューと表示を制御します。

データベース: 名前が示すように、データベースはデータの保存専用であり、バックエンドはデータベースの内容を読み取りまたは変更します。

なぜソフトウェアにはこれら 3 つの端子が必要なのでしょうか? なぜフロントエンドがデータベースに直接接続されていないのですか? なぜ中間にバックエンドがあるのですか? これには実際には多くの理由があります。

副題

a) エンジニアリング

開発者の観点: 最新のアプリケーションのフロントエンドには、複雑なデータモデルとビューの状態管理を同時に処理するエネルギーがありません。エンジニアリングの観点から見ると、すべてのエンジニアがすべての機能を備えた肥大化したシステムを維持するのは良くありません。さらに、電子商取引プラットフォームの在庫など、他の多くのロジックでは、フロントエンドが表示に参加する必要はありません。

アーキテクチャの観点: 各エンドには、データを記述するための独自のルールと言語のセットがあります。フロントエンドは人間が理解できるアイデアを使用してページを構築し、バックエンドはオブジェクト指向言語を使用してデータを操作し、データベースはリレーショナル代数言語を使用してアクセスします物理ストレージ 3 つの端末を統一するための一連の普遍的なルールを指定する方法はありませんが、同時に、各言語が独自の役割を実行するため、パフォーマンスの重視点も異なります。Hasurab) コミュニケーションODataプロトコルの観点: 図を見ると、3 つの端末を接続する 2 つの接続方法が異なることがわかります。通常、toC アプリケーションのフロントエンドとバックエンドは HTTP プロトコルを使用して通信し、バックエンドとデータベースはMySQL と MongoDB など、異なるプロトコルを使用すると、シンバックエンド (GraphQL +

) データベースへのフロントエンドの直接接続と同様の効果を実現するために、そのような通信用の CouchDB などのプロトコルもありますが、それでも他の欠点は解決されていません。

データマッピングの観点: フロントエンドは UI を処理し、バックエンドはオブジェクトを処理し、データベースはデータを処理します。フロントエンドとバックエンド間の接続には、UI とオブジェクト間のマッピング、およびバックエンドとオブジェクト間の接続が使用されます。データベースはオブジェクトの関係を使用してマップする必要があります。

c) セキュリティ

データの観点: 現在、私たちが使用するアプリケーションは Web ベースのアプリケーションが増えているため、フロントエンドがデータベースに直接接続されている場合、データ漏洩やハッキングを防ぐことは困難です。理論的には、データベースは次のような方法でデータの可視性を制御できます。バックエンドの存在のもう 1 つの大きな重要性は、バックエンドが信頼できる環境で設計された方法で動作し、既知のセキュリティの質問を排除することを保証することです。

副題

d) Web2アプリケーションアーキテクチャのDAppへの啓蒙
上記の 3 つの観点から、Web2 アプリケーションが 3 端末アーキテクチャを持つ理由を分析しました。これにより、ブロックチェーン DApps についてもいくつかの考察が得られました。
通信: ブロックチェーンネットワークのさまざまなコンセンサスメカニズムに対応します。これらのさまざまなメカニズムも、ブロックチェーンの相互通信を困難な問題にしていますが、ネットワーク全体をリンクしようとする Cosmos や Polkadot などの相互運用プロトコルもあります。一般に、これが最適なソリューションであるというわけではありませんが、データマッピングはアカウント指向または UTXO 設計パターンに対応できますが、どちらにもパフォーマンス、プライバシー、開発の複雑さの点で独自の長所と短所があります。

セキュリティ: ブロックチェーンの分散化と信頼ではなく検証の考え方に対応ブロックチェーン分野ではセキュリティがより重要であるため、データ処理とデータには検証可能でありながら完全に透明でオープンな方法が必要であり、可視性を達成するために調整されています透明でパーミッションレスな DeFi、オープンで独自の NFT、そして DApp の最も重要な構成可能性です。

最初のレベルのタイトル

Web3 DApp アーキテクチャ
ほとんどの Web3 DApp は次のアーキテクチャに従っています。
単純なアプリケーション (純粋なオンチェーンデータと複雑でない相互作用)。例: Uniswap および純粋なオンチェーン NFT プロジェクト。
フロントエンドは Web2 アプリと何ら変わりません。
データベースとしてのブロックチェーン。

ほとんどの Web3 DApp は次のアーキテクチャに従っています。

副題a) Web3 DApp 改良コンポーネント:

より具体的に言うと、完全な Web3 DApp のワークフローには以下が含まれます。
より多くのコンポーネント
フロントエンド: ブラウザ、ウォレット、ページ。
フロントエンドおよびバックエンド通信: ノードプロバイダー、インデックスプロトコル。
バックエンドデータベース通信: ノードプロバイダー、ストレージネットワークゲートウェイ。

データベース: スマートコントラクトの状態と分散型ストレージネットワーク。

副題b) Web3 DApp にはバックエンドがないのはなぜですか?,ブロックチェーンネットワーク上のチューリング完全スマートコントラクトの存在、

ブロックチェーンを最高のサーバーレスプラットフォームにする

または、Trustware のワールドコンピューターとみなすこともでき、アプリケーションのデータとバックエンドロジックはスマートコントラクトに実装できます。
サーバーレス機能と比較すると、スマートコントラクトは優れており、Web2 アプリケーションよりも優れたアーキテクチャとパターンを作成します。
支払い方法: サーバーレス機能は通常開発者によって支払われますが、スマートコントラクトのインタラクションコストのほとんどはユーザーによって支払われ、ユーザーはチェーン上のスペースに対して喜んで支払います。

実行環境: サーバーレス関数は非常に柔軟な実行環境を備えていますが、スマートコントラクトの実行環境は選択肢がほとんどありませんが、非常に軽量です。

導入環境: サーバーレス機能は集中型のクラウドサービスプラットフォームに導入され、スマートコントラクトは分散型のパーミッションレス分散ネットワークに導入されます。さらに、ネットワークの運用コストも集中型プラットフォームからマイナーと経済に移転されます。システムはより自律的になります。

ただし、真に完全なアプリケーションの場合、バックエンドとしてのスマートコントラクトだけで完全な機能を実現することは不可能であるため、Keeper ネットワークやオラクルマシンなどの他のコンポーネントが必要になります。

2. Web3 暗号ネイティブ DApp アーキテクチャ実際、Web2 の複雑なアプリケーションは、これまでに概説した 3 つの端末をはるかに超えており、多くのモジュール化、中間層、水平拡張が必要です。.

アーキテクチャの分割

副題

a) フロントエンド ⇒ オープンソース + セルフホスト型フロントエンド

Web3 フロントエンドの開発には、2 つの大きなトレンドがあると思います。web3-reactそしてCenter.devフレームワークの選択: React と Vue という 2 つのフロントエンドフレームワークのうち、React は Web3 で支配的な地位を占めています。これは主に、エコロジーとさまざまなコンポーネントの蓄積によるものです。そしてしかし個人的には、React プロジェクトの主導権は常に Meta の手にあると感じています。オープンソースライセンスの変更また、何度も論争を引き起こしているため、Vue フレームワークを使用する機会があれば、
できるだけ依存しないようにするフロントエンド開発に関しては、React よりも優れています。フロントエンドホスティング: フロントエンドは DApp にハッキングされ (悪意のあるハイジャックまたはスクリプトインジェクション)、検閲されています (Uniswap と Flashbots の両方のソースコード内)。OFACのブラックリスト; ) 最も大きな被害を受けた地域の資金調達を非常に早期に実現DApp のフロントエンドを自分でホストするようユーザーに奨励するTrustless.fiArweave などの永続ストレージネットワークでフロントエンドをホストするまた、各バージョンのフロントエンドが削除されず、永続的にアクセスできるようにすることもできます。,フロントエンドマーケットプレイスの概念も提案されており、ユーザーがコミュニティでホストされている複数のフロントエンドから選択できるようになり、中立性と「フロントエンドの多様性」も確保できます。実際には、Etherscan などの他のブロックチェーンブラウザーも検討されています。okcontractユーザーはそれを通じて直接対話できます。また、コントラクト生成フロントエンド用の専用アプリケーションもあります。codeisspeechそしてtheshake; 最近トルネードは検閲され、多くのコミュニティ（

そして) それを自発的にホストするフロントエンド内。,フロントエンドは検閲耐性を備えています

DApp の全体的なセキュリティと分散化が大幅に向上します。

副題

b) バックエンド ⇒ ZKP + スマートコントラクト
アプリのアーキテクチャの進化プロセスは次のようになります。
Web2アプリケーション：フロントエンド ⇒ バックエンド ⇒ データベース

Web3 シンプルアプリケーション：フロントエンド ⇒ スマートコントラクト

Web3 複合アプリケーション: フロントエンド ⇒ ZKP ⇒ スマートコントラクト

スマートコントラクトはアプリケーション全体を分散化しますが、オープンネットワーク上でスマートコントラクトを使用してアプリケーションのロジックを処理することは諸刃の剣であり、データとコードは公開されるため、透明性、チェック可能性、構成可能性が保証されます。しかし、プライバシーとセキュリティのリスクも完全に暴露され、チェーン上のスペースと計算のコストが非常に高くなります。

ZKP は Web3 時代の RSA となり、アプリケーション通信のセキュリティと分散化の欠点を解消し、信頼できる DApps とトラストレスな DApps を真に実現します。
中間層およびフロントエンドとバックエンド間の通信方法として ZKP を追加すると、その 2 つの利点が再びうまく機能します。

プライバシー: Web2 アプリケーションでは、プライバシーは常にデフォルトのオプションですが、ブロックチェーンネットワークの性質により、DApp は常に仮想「プライバシー」を持つことができます。中間層として、ZKP は機密データをオフチェーンで処理して、この問題を解決できます。

拡張: チェーン上のスペースは限られているため、Web2 アプリケーションの多くの複雑なアルゴリズムは実装できませんが、ZKP はアルゴリズムをチェーン外で実行し、計算の信頼性を確保しながらチェーン上で検証できます。
計算の実行可能性: ZKP 計算の種類は限られており、すべての計算を ZKP で解決できるわけではありません。

最適化: 演算の複雑さが増すと、計算時間と計算スペースが大幅に増加し、多くのソフトウェアとハードウェアの最適化が必要になりますが、同時に、多くの場合、スループットは大幅に改善することしかできず、オーバーヘッドも大きくなります。全体的な証明を減らすのは困難です。

副題

c) データベース ⇒ 分散ノードサービス

DApp がバックエンドおよびデータベースとしてブロックチェーンを使用する方法については以前に説明しましたが、DApp をブロックチェーンネットワークに接続するには、ノードサービスが必要です。
現在、DApps は Alchemy や Infura などの集中型 NaaS で一般的に使用されていますが、私のビジョンでは、将来的には 3 つのより良い方向性があると考えています。
マルチセンター NaaS、代替として複数の集中型 NaaS を使用する (Chainlink + Uniswap オラクルの組み合わせと同様) これは、より実現可能で信頼性の高いソリューションであり、検閲防止と稼働時間を保証できます。

セルフホスト型 NaaS: 究極のソリューションは、「データベース」接続の信頼性、さまざまなデータのプライバシーと検閲防止を確保できるだけでなく、ネットワークの分散化の度合いを高めることもできます。、DApp全体が非常に分散化された変化になります。

副題Tornado.cashd) 暗号ネイティブ DApp インスタンス

最近認可された
(特に BossBen) は非常に暗号ネイティブな DApp であり、私たちの定義の多くを満たしています。
フロントエンドは一般的に使用されている React フレームワークではなく、NuxtJS の Vue フレームワークを使用します。サーバー側コードを使用せず、フロントエンドコードで ZK 回路とスマートコントラクトを使用して完全に実装されます。.
コードは完全にオープンソースであり、

IPFSでホストされるTornado.cash今後さらに応用が進むと思います

3. Web3 Infra

これは、私の考える最も完璧な分散型 Web3 アプリケーションアーキテクチャです。

最初のレベルのタイトル上記はアーキテクチャの単なる簡略化されたバージョンですが、実際の DeFi アプリケーションのより具体的なアーキテクチャは次のとおりです。:

ノードサービス以外にもいくつかのサービスが含まれています
補助的なインフラストラクチャ
インデクサー: 左側のグラフチェーン上のデータを簡単にクエリする方法がないため、コントラクト関連のデータを組み立てるにはインデクサーが必要です。

オラクル: 右下隅のチェーンリンクチェーンはネットワーク外の契約や価格などのデータを取得する必要があるため、チェーン (Uniswap TWAP) またはオフチェーンのオラクル (チェーンリンク) に価格を供給する必要があります。

Keeper: 右下隅の Keep3r ネットワークスマートコントラクト自体にはタスクの実行を自動的にトリガーする機能がないため、支援のために外部トリガーが必要です。

これらのインフラストラクチャは DApp の構築において重要であり、今後の記事で Oracle と Indexer の問題点とイノベーションの機会について詳しく紹介します。

フォーサイト・ベンチャーズについて

フォーサイト・ベンチャーズは、今後数十年の仮想通貨の革新に賭け、VCファンド、セカンダリーアクティブ運用ファンド、マルチストラテジーFOF、特定目的Sファンド「フォーサイトセカンダリーファンドl」の複数のファンドを運営しており、総資産運用規模は4億米ドル以上。 Foresight Ventures は、「ユニーク、独立、積極的、長期的」というコンセプトを堅持し、強力なエコロジーの力を通じてプロジェクトを広範囲にサポートします。そのチームは、Sequoia China、CICC、Google、Bitmain などのトップ金融およびテクノロジー企業の上級人材で構成されています。

Website: https://www.foresightventures.com/

Twitter: https://twitter.com/ForesightVen

Medium: https://medium.com/@foresightventures-zh

Substack: https://foresightventures.substack.com

Discord: https://discord.com/invite/jYtyfxfB

Linktree: https://linktr.ee/foresightventures