文章

副題

序文

序文

DeFi アプリケーションと従来のアプリケーションの違いは非常に大きく、ビジネス モデルも製品モデルも異なり、実装されているテクノロジー スタックさえも大きく異なります。一般に、従来のアプリケーションは Web2 アプリケーションとも呼ばれますが、DeFi アプリケーションは Web3 に分類できます。

ビジネスモデルや製品モデルについて話す代わりに、テクノロジースタックについてのみ話します。現在DeFiアプリケーションに関与しているテクノロジースタックには、主にSolidity、Subgraph、Price Oracle、Hardhat、Ethersなどが含まれます。これらのテクノロジースタックのほとんどは、Ali、Tencent、Byte などの大手インターネット企業の P9 レベルの大手企業の一部でも聞いたことがないものです。従来のアプリケーション アーキテクチャで人気のあるマイクロサービス アーキテクチャ、ビッグ データ アーキテクチャ、クラウドネイティブ アーキテクチャは、基本的に DeFi アプリケーションでは役に立ちません。

私は 2017 年半ばからブロックチェーンの研究をしています。この業界で数年間深く学んできた後、いくつかの DeFi アプリケーションを実行し、ようやくある程度の基礎ができました。私の経験に基づいて、DeFi アプリケーションのアーキテクチャ設計を理解する方法について話しましょう。

副題

全体構造

DeFi アプリケーション システムの一般的なアーキテクチャを見てみましょう。

• 次のいくつかのモジュールを 1 つずつ紹介します。

• ブロックチェーン: 基盤となるブロックチェーン ネットワーク。DeFi アプリケーションは通常、複数の異なるブロックチェーン ネットワークにデプロイされます。

• スマート コントラクト: スマート コントラクトは、DeFi アプリケーションの中核となるビジネス実現であり、魂でもあります。

• Price Oracle: 価格情報を提供するために使用される価格オラクルは、一般にオフチェーン オラクルとオンチェーン オラクルに分類できます。

• Keeper サービス: スマート コントラクトのタスク トリガーとエグゼキューター。スマート コントラクト自体には実行タスクを自動的にトリガーする機能がないため、外部のタスク トリガーが支援する必要があります。

• サブグラフ: インデクサーとしても知られるサブグラフは、主にチェーン上のデータをフロントエンド クエリに便利なデータに再構築します。

• グラフ ノード: サブグラフが実行される環境は、チェーン上のブロック データを処理のためにサブグラフに同期します。

• ウォレット: ウォレット アプリケーション、最も主流は MetaMask です

• WebUI: フロントエンドに表示される UI ページ。通常は Vue や React などのフロントエンド フレームワークを使用します。

SDK: フロントエンドUIの呼び出しを容易にするために、サブグラフのクエリ、スマートコントラクトの呼び出し、ウォレットの接続などをカプセル化します。

多くの人が疑問を持つと思います。なぜ DeFi アプリケーション システムにはこれほど多くの異なるコンポーネントがあるのでしょうか?

まず、スマートコントラクト自体には自動実行メカニズムがありません。 Web2 アプリケーションにはタイマーがあるため、タイマーを使用して多くのタスクを自動的に実行できます。ただし、スマート コントラクトにはタイマーがないため、一部のタスクは自動的に実行できず、これらのタスクの実行をトリガーするには外部プログラムが必要です。このような外部プログラムをKeeperと呼び、例えばCompoundの清算業務を実行する清算人もKeeperの一種である。

ほとんどの Keeper はオフチェーンの集中プログラムです。ここ 1 年で、いくつかの分散型 Keeper ネットワークが次々と登場しており、私が知っているネットワークには、keep3r.network、Chainlink Keepers、KeeperDAO などがあります。

第 2 に、これもスマート コントラクト自体の制限のため、Web2 アプリケーションのように、外部プログラムに対してネットワーク リクエストを積極的に開始してデータを取得することは不可能です。そうしないと、スマート コントラクトが価格データを取得するために Coinbase や Binance などの集中型取引所にネットワーク リクエストを送信できる場合、異なるノードでは、異なるリクエスト時間と異なる価格が取得されるため、コンセンサスに達することができなくなります。しかし、スマートコントラクトは価格情報を取得する必要があるため、Price Oracle が存在します。

価格 オラクルは主に、オフチェーンオラクルとオンチェーンオラクルの 2 つのカテゴリに分類できます。

オフチェーンオラクルはChainlinkに代表され、その基本原理は、複数の取引所（集中型および分散型取引所を含む）のデータソースを複数のレベルで集約し、最終的な価格データをオンチェーンインテリジェンスコントラクトに更新することです。チェーン上のスマートコントラクトの価格情報を直接読み取ります。オンチェーンオラクルはUniswapのTWAP（時間加重平均価格）に基づいており、その原理は前の記事で説明しました。「DeFi 取引商品の Uniswap の分析: V2 のパート 2」

それについてはすでに議論されているので繰り返しません。

さらに、スマート コントラクトに保存されるデータは従来の Web2 データベースとは完全に異なり、MySQL や MongoDB データベースのようにデータのインデックス付けやクエリを実行したり、データをグループ化、並べ替え、結合したりすることもできません。そしてこの需要は厳格な需要でもあり、この需要に応えるために登場したのがブロックチェーンデータインデックスプロトコルであるThe Graphです。サブグラフはプロトコルのコアコンポーネントであり、グラフノードはその動作環境です。

異なる DeFi アプリケーションごとに、実際のアーキテクチャは若干異なる場合があります。たとえば、Uniswap は Keeper Services や Price Oracle を必要としません。しかし、わずかに複雑な DeFi アプリケーションのほとんどは基本的にこれらのコンポーネントを必要とするため、このアーキテクチャがほとんどの DeFi アプリケーションの一般的なアーキテクチャになっています。

副題

スマートコントラクトの設計

DeFiアプリケーションシステム全体の中で最も核心的かつ複雑なのはスマートコントラクトであり、スマートコントラクトは依然としてオープンソースである必要があり、そのセキュリティも非常に重要であるため、スマートコントラクトの設計は当然非常に重要な部分となります。

具体的な設計は製品ごとに異なりますが、比較的洗練されたスマート コントラクト製品を設計するのに役立つ一般的な設計原則がいくつかあります。私の意見では、いわゆる相対的な優雅さにおいて最も重要なことは、セキュリティ、機能性、拡張性といったいくつかの特性を満たすことです。

すべてのスマート コントラクトはオープンソースである必要があるため、さまざまなセキュリティの抜け穴、特にフラッシュ ローン攻撃、リエントリー攻撃、許可の抜け穴などを回避するには、セキュリティを最優先する必要があります。メインネットワークの正式な立ち上げ前に、より多くの専門家が協力して隠されたネットワークを発見できるように、内部セキュリティ監査と外部監査が十分に実施されるべきであり、内部テストと外部オープンテストを含む適切なテスト、さらには公的報酬も提供されるべきである。抜け穴。

機能を満たすことは基本要件であり、例えば、預け入れ、引き出し、借り入れができるローン商品や、レバレッジ取引を拡大できるデリバティブDEXなども満たさなければならない基本要件です。ただし、それが満たされる範囲は他の制約によって制限される場合があります。たとえば、フラッシュ ローン攻撃を防ぐために、デリバティブ DEX では、同じ口座が同じブロック内でポジションをオープンおよびクローズすることを禁止する場合があります。

スケーラビリティも非常に重要な機能であり、結局のところ、アプリケーション システムは 1 つのバージョンだけをリリースするだけでは十分ではなく、常に新しい機能を繰り返し追加する必要があります。たとえば、デリバティブ DEX の場合、最初のバージョンでは市場価格取引機能のみを実装できますが、2 番目のバージョンでは価格指値取引機能を追加する必要があり、3 番目のバージョンではストップ プロフィットおよびストップロス機能を追加する必要があります。

これらの機能はすべて正の相関関係にあるわけではありません。たとえば、セキュリティをさらに向上させると、機能とスケーラビリティが低下する可能性があります。選択は、バランスの取れた状態に達することです。

目標を達成するために従う必要がある設計原則とその背後にある重要な設計アイデアは、単一責任原則、開閉原則、依存関係逆転原則、インターフェイス分離など、アーキテクトがよく知っているものです。原理などと、分離、低結合、高凝集、適度な設計などのアーキテクチャのアイデアに焦点を当てます。

アーキテクチャ設計の核心は複雑な問題を単純化することですが、これはオープンソースのスマートコントラクトに適用される場合にはさらに重要になります。

副題

デザインの実践

現在私が担当しているDeFiアプリケーションを例に、私の実践の概要をお話します。

まず背景を簡単に紹介すると、私が最近新しいチームに加わり、DeFiプロダクト、正確にはデリバティブDEXを担当していることは、少数の友人は知っています。取引モードは主にAMMモードを採用していますが、Uniswapのような二通貨流動性を提供するAMMではなく、Elastic AMMと呼ばれる単一通貨流動性を提供するAMMです。具体的な事業は立ち上げないので詳しくは後ほどお話しますが、今回は主にアーキテクチャ設計における留意点についてお話します。

アプリケーション システム全体の全体的なアーキテクチャは上記とほぼ同じであるため、全体的なアーキテクチャについては繰り返すつもりはありませんが、主にスマート コントラクトの設計について話したいと思います。

スマートコントラクトレベルでは、実際には主契約と周辺契約に分かれます。 **そして、私が主に話したいのは、メイン契約の設計についてです。次の図は、メイン契約のアーキテクチャです。

緑色はシステムに参加しているいくつかの役割のみを表し、他の色はスマート コントラクトのサブモジュールです。

まず、階層構造の考え方を採用し、システムを階層に分割し、上位層は下位層に依存しますが、下位層は上位層に依存することはできません。次に、モジュールはインターフェイスのみに依存し、特定の実装には依存しません。このようにして、モジュール間の結合度を低くすることができます。

トレーダーと LP のユーザーとして、これらはすべて一律にルーターと対話し、ルーターはルーティング ゲートウェイの役割を果たすのと同等です。さらに、基礎となる層には依存関係がないため、アップグレードや置き換えが簡単です。

各取引ペアにはアム契約とマージン契約があり、アムとマージンは相互に拘束されています。したがって、ファクトリー パターンを使用してさまざまな取引ペアを作成することを考えるのは自然なことです。当初の設計では、実際にはファクトリー コントラクトは 1 つだけでしたが、実際の実装では、最終的にファクトリー コントラクトがスマート コントラクトの最大バイト数を超えていることが判明したため、ファクトリー コントラクトは 3 つに分割されました。

Amm の責任は基礎となる為替取引に責任を負い、Margin の責任はユーザーのポジションを管理することです。 LiquidityERC20 は、Amm によって継承された流動性トークン コントラクトです。 Vault は、Margin に継承された主契約内の実際の資産を管理します。このモジュールはプロトコル全体の中核であり、証拠金の追加と削除、ポジションの開閉、流動性の追加と削除など、最下層の基本機能のみを実装します。 Router によって実現される ETH と WETH の交換サポートなど、スケーラブルな機能は上位層モジュールによって実装でき、その後、価格指値注文、ストッププロフィット、ストップロスなどをサポートする上位層コントラクトを追加できます。

副題

要約する

要約する

実際、DeFi アプリケーション システムの全体的な複雑さは Web2 アプリケーション システムよりもはるかに劣っていますが、テクノロジー スタックがほぼ完全に異なり、製品の考え方もかなり異なり、DeFi アプリケーションはすべてオープンソースであるため、これらはこの業界の敷居となる。そのため、未経験者が今から始めるのは実は簡単ではなく、Web2のハイエンド人材であってもWeb3に入ってからは学習と蓄積に時間がかかります。