イーサリアムでの借入: 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 プロトコルのアーキテクチャの進化 を使用した固定金利の概念実証として機能しました。 。このバージョンは、MakerDAO 上に担保付き債務エンジンを構築しました。ただし、Yield v1 は使用コストが高く、新しい機能を追加するのが困難でした。 収量 v1 収量スペース YieldSpace の可能性を認識し、私たちはすぐに開発に移行しました。 。依然として MakerDAO からインスピレーションを得ていますが、現在は完全に独立した Yield v2 ; Yield v2 は、ガスコストの削減とユーザー エクスペリエンスの向上を優先しました。 収量v2 2021年10月発売 すべての会計、リスク管理、担保チェックが 1 つの契約に統合されました。 。 MakerDAO のアプローチを反映して、財務機能を複数の組織に分散しました。 それぞれが特定の資産に特化した契約。 大釜 参加する オラクルの統合を刷新し、価格と金利のオラクルを統合しました。 。 MakerDAO からのオラクル フローを逆にして、Cauldron が 担保チェックに必要な場合。私の知る限り、これは MakerDAO を除くどこでも推奨されるフローです。 共通インターフェース オラクルに相談する MakerDAO のアプローチからのもう 1 つの大きな逸脱は、 。この契約は、ユーザーと Yield の間の唯一の仲介者として機能します。財務と会計を広範囲に制御できます 。 柄杓 が、その代わりに、機能開発に非常に高い柔軟性を提供します 要約すると、Yield v2 での借入は次のように機能します。 各資産には独自の専用の財務契約があり、財務機能の最大限の分散が保証されます。 単一の契約により、会計機能が集中化されます。この契約は、リスク管理措置を監督し、担保チェックも実行します。 担保機能はオラクルに相談して価格と金利を決定します。 価格オラクルと金利オラクルはどちらも統一インターフェイスを共有します。 金利は外部で生成されます。 ユーザーは、1つの契約に対して1回の申し込みで借入が可能です。 複合金融のアーキテクチャの進化 の でした 、イーサリアム上にマネーマーケットが確立できることを示しています。このため、デザインはシンプルさを優先しました。の 契約には、融資を含むすべての機能がカプセル化されています。 コンパウンドの最初のバージョン コンセプトの証明 MoneyMarket.sol 財務、会計、担保チェックなどのリスク管理タスクが 1 つの契約に統合されます。 この契約はオラクルから価格を取得しますが、資産の利用状況に基づいて金利を決定します。 ユーザーはこの契約のみを操作しますが、担保の提供と資産の借入を行うには別の呼び出しを行う必要があります。 コンパウンド v2 、イールドファーミング時代の火付け役となり、無数のフォークを刺激しました。金融市場としても機能し、ユーザーは資産の貸し借りを行うことができました。 Compound v2 は 2019 年 5 月にリリースされました それに基づいて と構造を考慮すると、主要な目標が を使用することでした 。これにより構成可能性が確保され、ユーザーが Compound に融資し、それらの有利なポジションを他のブロックチェーン アプリケーションで使用できるようになりました。 白書 コンパウンド v2 融資ポジションを表すERC20規格 興味深いことに、ホワイトペーパーでは Compound v2 に組み込まれていることを強調していませんでした。 スマートコントラクトに組み込まれます。この省略を考慮すると、この機能の計り知れない影響は予想されていなかったかもしれません。 報酬 各資産には独自の財務契約があり、財務機能の配分が最大化されます。 会計機能も分散されており、各 cToken はユーザーの担保と負債を記録します。 単一の契約である会計監査は、担保チェックを含むリスク管理パラメーターを記録し、施行します。 担保チェックを担当する契約は、価格についてはオラクルを参照し、金利については cToken を参照します。 価格オラクルと金利オラクルは、異なるインターフェースで動作します。 金利は資産の利用状況から内部的に導出されます。 ユーザーは借用するには複数の契約を操作する必要があります。 コンパウンド v3 、 より保守的なリスク管理戦略を採用し、流動性をいくつかのグループに分離します。 借用可能資産ごとに。このデザインからは、使いやすさとガス代についての懸念も明らかになります。 2022年発売 コンパウンド v3 プール このシステムは、必要な呼び出しの数が減るため、開発者とユーザーの両方にとってより直感的です。さらに、単一の契約設計により、契約間の通話が最小限に抑えられ、ガスコストが削減されます。分離された金融市場は、現在大きなセキュリティ上の懸念となっているオラクルベースの攻撃に対する防御手段です。 で言及されているその他の関連機能 含む： リリースノート 完全に刷新されたリスク管理および清算エンジン。この設計により、資金の安全性が強化されると同時に、より借り手に優しいものになります。 リスクを軽減するために、個々の担保資産に対して市場全体で制限を設定します。 収益と借入の金利モデルは現在分離されており、ガバナンスが経済政策を完全に制御しています。 興味深いことに、Compound v3 は、単一のコントラクトで各借入可能資産のすべての機能を処理することで、Compound v1 のアーキテクチャを反映しています。その他の注目すべき機能は次のとおりです。 借りられるのは貸付資産のみです。担保資産はできません。 Compound v3 では、担保は収益をもたらしません。 担保借入の禁止により、担保を預ける者の安全性が高まります。これにより、ガバナンスのエラーや意図的な攻撃によって担保が危険にさらされる可能性が低くなります。 供給された担保の収益がなくなるのは、コンパウンドが v2 で多くの流動性を蓄積できた結果である可能性があります。 Compound v2 では、借入限度額は、ユーザーがアプリケーションに貸与した資産を下回るか、それほど高くないのではないかと直感しました。 v3 でも同様のレベルの流動性を管理すると仮定すると、担保の貸し出しを禁止することでアプリケーションを安全にし、これが v3 の中核目標の 1 つです。 アーキテクチャの観点から: すべての金融市場は、財務、会計、リスク管理との個別の契約です。 各金融市場は、承認されたすべての担保資産トークンとともに借入可能な資産を保持するため、資産がアプリケーション全体に分散されます。 価格フィードは唯一の外部入力です。貸付金利は社内で生成 供給/引き出し/借入/返済などの従来の機能がスマートに統合されています。さて、金融市場から借入可能な資産を引き出すことは借入を意味し、それを供給することはユーザーの借金に基づいた返済または貸付を意味します。 ルーティング コントラクトが統合され、1 回の通話で複数の操作が可能になります Aave のアーキテクチャの進化 だった 、ETHLendの後継。 ETHLend のピアツーピア アプローチの代わりに、Aave v1 では共有流動性プールが導入されました。 Aave v1 2019年10月発売 Yield v2 と同様に、 ビジネスロジックも保持していました。の 会計、リスク管理、財務機能を実装しました。財務を単一の契約にプールすることが Compound v2 との相違点でした。 ルーター契約 レンディングプールコア 担保小切手を残す決定 、アカウンティング コントラクトではなくルーターから呼び出されるのは弱いように思えますが、Aave v2 は v1 のリリースから 2 年後にしかリリースされなかったため、おそらく目的には適していました。 独自の契約 LendingPoolCore 契約は財務と会計を処理します LendingPoolDataProvider は担保チェックを管理し、オラクルと対話します。 LendingPool はユーザーのエントリ ポイントとして機能し、ビジネス ロジックを実装します。 貸借の金利は価格フィードのみに基づいて内部で決定されます。 Aave v2 だった 。 Aave v1 と同様の機能を保持しながら、Aave v1 と Compound v2 の両方に比べて改良され、よりシンプルなアーキテクチャが導入されました。このリリースでは、Aave も導入されました (Compound の cToken に似ています) および 、トークン化された負債を表します。 Aave v2 2021年12月発売 aトークン 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 ネットワークの台頭は、将来の担保付き借入アプリケーションの設計を形作ることになるでしょう。 この記事では、イーサリアム上の主要な担保付き借入アプリケーションの包括的な概要を説明しました。各申請を分析するために私が採用したアプローチは、他の担保付き借入申請の複雑さを迅速に把握するためにも適用できます。 ブロックチェーン借入アプリケーションを開発するときは、資産の保管、会計記録の配置、リスクと担保の評価方法を常に考慮してください。これらの考慮事項を検討する際には、以前のアプリケーションの履歴とこの概要から得た洞察を参考にして決定を行ってください。 読んでいただきありがとうございます。ご多幸をお祈りします。 おかげで カルニクス この記事のレビューと編集をお願いします。 著者は、Yield Protocol の共同創設者およびテクニカル リードです。