イーサリアムでの借入: MakerDAO、Yield、Aave、Compound、および Euler のアーキテクチャ進化の比較

借入はイーサリアムベースのブロックチェーン アプリケーションの基礎です。と数十億の資産が貸し出される借用の仕組みを理解することは、開発者、アーキテクト、研究者にとって非常に重要です。

プログラミング パラダイムの進化と同様に、これらの DeFi アプリケーションには多様なアーキテクチャ設計があり、セキュリティから効率、ユーザー エクスペリエンスに至るまでの優先順位の変化を反映しています。

この分析では、次のようなアプリケーションのアーキテクチャを調べます。メーカーダオ、コンパウンド、アーベ、オイラー、 そして収率。将来の融資アプリケーションの開発にとって重要な教訓となる、主要なイノベーションと設計パターンに焦点を当てます。

あなたが開発者、アーキテクト、またはセキュリティ研究者であれば、この記事はあなたのためのものです。最後には、イーサリアム上の新しい借入アプリケーションを簡単に理解し、そのアーキテクチャを迅速かつ包括的に把握できるようになります。これらの DeFi 巨人がゼロからどのように構築されているかを詳しく見てみましょう。

DeFiで借りる

DeFi の借入のほとんどは、過大担保。ユーザーは、ローン以上の価値のある担保を提供した場合、特定の資産を借りることができます。従来のローンとは異なり、これらのローンの多くには定期的な返済や固定終了日がありません。要するに、借りても返済しなくても大丈夫です。

ただし、落とし穴があります。

担保の価値は常にローンの価値を所定のマージンだけ上回らなければなりません。

担保価値がこれを下回った場合、融資は行われません。清算された。

清算中、他の誰かがローンの一部または全額を返済し、その代わりに担保の一部または全額を受け取ります。

この財務構造に従ったすべての借入申し込みには同じ構成要素が必要であり、これらはさまざまな方法でアレンジできます。

• ユーザーの担保と借用資産を保管するための金庫
• 各ユーザーの担保と負債を追跡する会計システム
• 借り手の金利を決定する関数
• ローンが十分に担保されているかどうかを検証するメカニズム。通常は外部の価格オラクルが関与します。
• 過少担保ローンの清算経路
• 総借入額と、グローバルおよびユーザーごとの借入限度額、担保最低額、特定の超過担保比率などのその他の安全指標を記録するリスク管理システム
• ユーザーが担保の追加と削除、借入、および原資産の返済を行うためのインターフェース
  

借入と貸付は別個の機能として考えることができます。 DeFi では、ほとんどの借入アプリケーションに両方の機能が含まれていますが、必ずしも十分に統合されているわけではありません。

Compound、Aave、Euler では、それらは です。借り手と貸し手の金利は内部的に相関しています。実際、それがこれらのアプリケーションを最小限の介入で動作させる理由です。

一方、MakerDAOとYieldは、借り手に貸し出す資産のオリジネーターです。

他のユーザーが借用できるように、ユーザーがアセットを提供する必要はありません。

この記事ではオンチェーン借入に焦点を当て、融資についてはほとんど無視します。借入は担保要件によりはるかに複雑であり、通常、借入パターンを理解することでプロトコル全体をより深く理解できるようになります。

MakerDAO のアーキテクチャの進化

メーカーダオ、イーサリアムの用語では古代、 2019年11月に現在の形で発売されましたが、そしてそれは保持します49億5,000万ドルの担保。機能ごとに明確な規約と独自の用語を備えたモジュール式アーキテクチャにもかかわらず、理解と検証は容易です。

MakerDAO の財務機能は、参加する契約。

があります別途契約担保資産として承認されたトークンごとに。

それに対して、MakerDAOは借入資産であるDAIを保有していません。

代わりに、それは単にミント＆バーンズDAI要求に応じ。

会計は社内で処理されます。バット.ソル契約。ザ・ジョインズこの契約を更新する担保がシステムに出入りするとき。ユーザーが借りる場合、 vat.sol コントラクトを直接操作する。

このアクションにより、ユーザーの負債残高が更新され、DAI 参加時に DAI を鋳造できるようになります。

返済するには、ユーザーは DAI 参加で DAI を書き込みます。このプロセスにより付加価値税が更新され、ユーザーがローンを決済できるようになります。

さらに、 vat.sol契約は、 危機管理エンジン。グローバルな借入制限を維持し、ユーザーごとの最低しきい値を設定し、担保比率を監視します。

ユーザーの負債または担保残高に変更が加えられると、vat.sol 契約ではレートとスポットの両方が評価されます。

これらは、使用された担保および一般的な DAI 対担保価格比率に基づく金利を指します。興味深いことに、これらの値は他の MakerDAO コントラクトによって vat.sol コントラクトに入力されますが、これは他のほとんどのアプリケーションとは異なる方法です。

MakerDAO は設計段階で安全性を優先しました。当時は、ガスコストなどの要素は二の次で、ユーザー エクスペリエンスはそれほど重要ではなく、競争は無視できました。

その結果、奇妙で、使用コストが高く、操作が困難に見えるかもしれません。

しかし、同社が管理する膨大な資産と重大な違反なしの運用実績は、その堅牢な設計と実行を強調しています。

ハイライト:

• 各資産には、最大限に分散された財務機能で独自の契約があります。
• 会計機能は単一の契約内に集中されており、担保チェックなどのリスクパラメータも文書化および強制されます。
• 他のアプリとは異なり、オラクルは契約を更新し、担保を監督します
• 価格と金利のオラクルは異なるインターフェイスを利用します
• 金利は外部から発生する
• 借りるには、ユーザーは複数の契約を操作する必要があります

Yield プロトコルのアーキテクチャの進化

収量 v1を使用した固定金利の概念実証として機能しました。収量スペース。このバージョンは、MakerDAO 上に担保付き債務エンジンを構築しました。ただし、Yield v1 は使用コストが高く、新しい機能を追加するのが困難でした。

YieldSpace の可能性を認識し、私たちはすぐに開発に移行しました。収量v2 。依然として MakerDAO からインスピレーションを得ていますが、現在は完全に独立した Yield v2 2021年10月発売; Yield v2 は、ガスコストの削減とユーザー エクスペリエンスの向上を優先しました。

すべての会計、リスク管理、担保チェックが 1 つの契約に統合されました。大釜。 MakerDAO のアプローチを反映して、財務機能を複数の組織に分散しました。参加するそれぞれが特定の資産に特化した契約。

オラクルの統合を刷新し、価格と金利のオラクルを統合しました。共通インターフェース。 MakerDAO からのオラクル フローを逆にして、Cauldron がオラクルに相談する担保チェックに必要な場合。私の知る限り、これは MakerDAO を除くどこでも推奨されるフローです。

MakerDAO のアプローチからのもう 1 つの大きな逸脱は、柄杓。この契約は、ユーザーと Yield の間の唯一の仲介者として機能します。財務と会計を広範囲に制御できますが、その代わりに、機能開発に非常に高い柔軟性を提供します。

要約すると、Yield v2 での借入は次のように機能します。

• 各資産には独自の専用の財務契約があり、財務機能の最大限の分散が保証されます。
• 単一の契約により、会計機能が集中化されます。この契約は、リスク管理措置を監督し、担保チェックも実行します。
• 担保機能はオラクルに相談して価格と金利を決定します。
• 価格オラクルと金利オラクルはどちらも統一インターフェイスを共有します。
• 金利は外部で生成されます。
• ユーザーは、1つの契約に対して1回の申し込みで借入が可能です。

複合金融のアーキテクチャの進化

のコンパウンドの最初のバージョンでしたコンセプトの証明、イーサリアム上にマネーマーケットが確立できることを示しています。このため、デザインはシンプルさを優先しました。のMoneyMarket.sol契約には、融資を含むすべての機能がカプセル化されています。

• 財務、会計、担保チェックなどのリスク管理タスクが 1 つの契約に統合されます。
• この契約はオラクルから価格を取得しますが、資産の利用状況に基づいて金利を決定します。
• ユーザーはこの契約のみを操作しますが、担保の提供と資産の借入を行うには別の呼び出しを行う必要があります。

コンパウンド v2

Compound v2 は 2019 年 5 月にリリースされました、イールドファーミング時代の火付け役となり、無数のフォークを刺激しました。金融市場としても機能し、ユーザーは資産の貸し借りを行うことができました。

それに基づいて白書と構造を考慮すると、主要な目標がコンパウンド v2を使用することでした融資ポジションを表すERC20規格。これにより構成可能性が確保され、ユーザーが Compound に融資し、それらの有利なポジションを他のブロックチェーン アプリケーションで使用できるようになりました。

興味深いことに、ホワイトペーパーでは Compound v2 に組み込まれていることを強調していませんでした。 報酬スマートコントラクトに組み込まれます。この省略を考慮すると、この機能の計り知れない影響は予想されていなかったかもしれません。

• 各資産には独自の財務契約があり、財務機能の配分が最大化されます。
• 会計機能も分散されており、各 cToken はユーザーの担保と負債を記録します。
• 単一の契約である会計監査は、担保チェックを含むリスク管理パラメーターを記録し、施行します。
• 担保チェックを担当する契約は、価格についてはオラクルを参照し、金利については cToken を参照します。
• 価格オラクルと金利オラクルは、異なるインターフェースで動作します。
• 金利は資産の利用状況から内部的に導出されます。
• ユーザーは借用するには複数の契約を操作する必要があります。

コンパウンド v3

2022年発売、コンパウンド v3より保守的なリスク管理戦略を採用し、流動性をいくつかのグループに分離します。 プール借用可能資産ごとに。このデザインからは、使いやすさとガス代についての懸念も明らかになります。

このシステムは、必要な呼び出しの数が減るため、開発者とユーザーの両方にとってより直感的です。さらに、単一の契約設計により、契約間の通話が最小限に抑えられ、ガスコストが削減されます。分離された金融市場は、現在大きなセキュリティ上の懸念となっているオラクルベースの攻撃に対する防御手段です。

で言及されているその他の関連機能リリースノート含む：

• 完全に刷新されたリスク管理および清算エンジン。この設計により、資金の安全性が強化されると同時に、より借り手に優しいものになります。
• リスクを軽減するために、個々の担保資産に対して市場全体で制限を設定します。
• 収益と借入の金利モデルは現在分離されており、ガバナンスが経済政策を完全に制御しています。

興味深いことに、Compound v3 は、単一のコントラクトで各借入可能資産のすべての機能を処理することで、Compound v1 のアーキテクチャを反映しています。その他の注目すべき機能は次のとおりです。

• 借りられるのは貸付資産のみです。担保資産はできません。
• Compound v3 では、担保は収益をもたらしません。

担保借入の禁止により、担保を預ける者の安全性が高まります。これにより、ガバナンスのエラーや意図的な攻撃によって担保が危険にさらされる可能性が低くなります。

供給された担保の収益がなくなるのは、コンパウンドが v2 で多くの流動性を蓄積できた結果である可能性があります。 Compound v2 では、借入限度額は、ユーザーがアプリケーションに貸与した資産を下回るか、それほど高くないのではないかと直感しました。

v3 でも同様のレベルの流動性を管理すると仮定すると、担保の貸し出しを禁止することでアプリケーションを安全にし、これが v3 の中核目標の 1 つです。

アーキテクチャの観点から:

• すべての金融市場は、財務、会計、リスク管理との個別の契約です。
• 各金融市場は、承認されたすべての担保資産トークンとともに借入可能な資産を保持するため、資産がアプリケーション全体に分散されます。
• 価格フィードは唯一の外部入力です。貸付金利は社内で生成
• 供給/引き出し/借入/返済などの従来の機能がスマートに統合されています。さて、金融市場から借入可能な資産を引き出すことは借入を意味し、それを供給することはユーザーの借金に基づいた返済または貸付を意味します。
• ルーティング コントラクトが統合され、1 回の通話で複数の操作が可能になります

Aave のアーキテクチャの進化

Aave v1だった2019年10月発売、ETHLendの後継。 ETHLend のピアツーピア アプローチの代わりに、Aave v1 では共有流動性プールが導入されました。

Yield v2 と同様に、 ルーター契約ビジネスロジックも保持していました。のレンディングプールコア会計、リスク管理、財務機能を実装しました。財務を単一の契約にプールすることが Compound v2 との相違点でした。

担保小切手を残す決定独自の契約、アカウンティング コントラクトではなくルーターから呼び出されるのは弱いように思えますが、Aave v2 は v1 のリリースから 2 年後にしかリリースされなかったため、おそらく目的には適していました。

• LendingPoolCore 契約は財務と会計を処理します
• LendingPoolDataProvider は担保チェックを管理し、オラクルと対話します。
• LendingPool はユーザーのエントリ ポイントとして機能し、ビジネス ロジックを実装します。
• 貸借の金利は価格フィードのみに基づいて内部で決定されます。

Aave v2

Aave v2だった2021年12月発売。 Aave v1 と同様の機能を保持しながら、Aave v1 と Compound v2 の両方に比べて改良され、よりシンプルなアーキテクチャが導入されました。このリリースでは、Aave も導入されましたaトークン(Compound の cToken に似ています) およびvトークン、トークン化された負債を表します。

使用が制限されていた Aave v1 の特定の機能は、簡略化のために省略されました。未収利息の複雑な表現など、Aave v1 の問題は、Aave v2 で解決されました。

• LendingPool 契約は、担保チェックなどのグローバルな会計機能とリスク管理機能を統合します。ユーザーのプライマリ アクセス ポイントとして機能します
• aトークンは担保を意味し、貸し出しポジションに似ています。ユーザーの担保は aToken の保有を通じて反映され、財務機能はすべての aToken に分散されます。
• vToken は債務ポジションを表すために使用されます。ユーザーの負債は、ユーザーが保有する vToken によって表されます

Aave v3

Aave v3だった2023年1月発売マルチチェーンのサポートやその他の機能を備えています。これらの追加によってコア アーキテクチャが変更されることはありません。このアップデートでは、リスク管理とガス効率も向上しました。

多くの進歩にもかかわらず、この調査の目的では、Aave v3 は Aave v2 と実質的に変わりません。実際、Aave v2 のアーキテクチャが 2023 年になっても堅牢であることを示唆している可能性があります。

オイラーのアーキテクチャの進化

オイラーだった2022年12月発売、パーミッションレス機能と最小限のガバナンスを備えたマネーマーケットを提供することを目指しています。

そのデザインの特徴は、ダイヤモンドのようなパターン。あ単一のコントラクトがアプリケーションのすべてのストレージを保持します。このストレージには、別の方法でアクセスできます。 プロキシ、それぞれがシステムの異なる概念的要素を管理します。

1 つの契約にすべての資産、会計、リスク管理データが保存されていますが、Aave v2 と同様に、担保と融資用の eToken と債務用の dToken が依然として存在します。ただし、これらのトークン コントラクトは、中央ストレージ コントラクトの単なるビューです。

• のストレージ契約は会計変数を管理します。
• のベースロジック契約は財務省として機能します。
• のリスクマネージャー契約は、担保チェックを含むリスク管理の変数と機能を監督します。

コードを分析すると、最小限のガスコストが最優先事項であり、契約間の呼び出しの必要性を排除するモノリシック設計につながっていることが明らかになりました。厳格なテストと監査を通じてセキュリティが確保されました。ロジックのみがさまざまなモジュールに分散され、主にプロキシ コントラクトとして機能するストレージ コントラクトの実装として機能しました。

この統一された設計により、簡単なアップグレードもサポートされます。ストレージの変更が必要ない場合は、モジュールを迅速に交換して機能を修正または導入できます。

Euler は、リリースから 15 か月後、アップグレードによって悪用された脆弱性が導入されてから 6 か月後にハッキングされました。

モノリシック アーキテクチャが資産の流出に関与したとは思いません。むしろ、コード更新の監視が不十分でした。

結論

MakerDAO、Compound、Aave などの初期のイーサリアム アプリケーションは、イーサリアムでの過担保借入の可能性を示しました。これらの概念実証が成功したことが証明されると、焦点は市場シェアを獲得するために新しい機能を組み合わせて導入することに移りました。 Compound と Aave のその後のバージョンでは、イールド ファーミング、コンポーザビリティ、プールされた流動性が導入され、特に強気の市況時に成功しました。

重要な進歩は、Compound v2 のトークン化された融資ポジションの導入であり、これにより、これらのポジションが他のアプリケーションによって標準資産として認識されるようになりました。 Aave v2 と Euler は、トークン化された債務ポジションを実装することでそれをさらに一歩進めましたが、その広範な有用性については依然として議論の対象となっています。

強気相場ではガスコストの高さが大きな懸念事項として浮上し、Yield v2、Aave v2、Euler に見られるようにユーザー エクスペリエンスの変更を促しました。ルーター契約とモノリシック実装により、ユーザーがトランザクションにかかるコストを削減できました。ただし、これにはコードがより複雑になり、その結果リスクが高くなります。

Compound v3 は、財務効率よりも安全性を優先する前例を作ったようです。これは、潜在的なハッキングに対する保護を強化するために、従来の流動性プール モデルから逸脱しています。ガス料金がますます無視できるレベルになりつつある L2 ネットワークの台頭は、将来の担保付き借入アプリケーションの設計を形作ることになるでしょう。

この記事では、イーサリアム上の主要な担保付き借入アプリケーションの包括的な概要を説明しました。各申請を分析するために私が採用したアプローチは、他の担保付き借入申請の複雑さを迅速に把握するためにも適用できます。

ブロックチェーン借入アプリケーションを開発するときは、資産の保管、会計記録の配置、リスクと担保の評価方法を常に考慮してください。これらの考慮事項を検討する際には、以前のアプリケーションの履歴とこの概要から得た洞察を参考にして決定を行ってください。

読んでいただきありがとうございます。ご多幸をお祈りします。

おかげでカルニクスこの記事のレビューと編集をお願いします。