借入は、イーサリアムベースのブロックチェーンアプリケーションの基礎です。 何十億もの資産が貸し出されているので、借り入れがどのように機能するかを理解することは、開発者、建築家、または研究者にとって非常に重要です。

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

この分析では、MakerDAO、Compound、Aave、Euler、Yieldなどのアプリケーションのアーキテクチャに注目しています。 将来の融資アプリケーションの開発にとって重要な教訓となる主要なイノベーションと設計パターンに焦点を当てます。

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

DeFiでの借入

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

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

担保の価値は、常に所定の証拠金でローンの価値を上回らなければなりません。

担保価値がこれを下回ると、ローンは 清算されます。

清算中、他の誰かがあなたのローンの一部または全部を返済し、その見返りとしてあなたの担保の一部または全部を受け取ります。

この財務構造に従ったすべての借入申込書には、同じビルディングブロックが必要であり、さまざまな方法で配置できます。

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

MakerDAOでの借入プロセス。 すべてのアプリケーションは、同じ手順と機能を共有します。

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

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

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

他のユーザーが借りられるように、ユーザーが資産を提供する必要はありません。

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

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

MakerDAOロゴ

イーサリアム用語で古代のMakerDAOは、2019年11月に現在の形でローンチされ、$4.95Bの担保を保有しています。すべての機能に個別の契約と独自の用語を備えたモジュール式アーキテクチャにもかかわらず、理解と検証は容易です。

MakerDAOのトレジャリー機能は、 Join コントラクトによって管理されています。

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

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

代わりに、必要に応じて DAIをミントして燃やす だけです。

会計は vat.sol契約内で処理されます。 結合は、担保がシステムに出入りしたときに この契約を更新し ます。 ユーザーが借入する場合、 ユーザーは vat.sol コントラクトと直接やり取りします。

このアクションにより、ユーザーの債務残高が更新され、DAI JoinでDAIをミントできるようになります。

返済のために、ユーザーはDAI結合でDAIを燃やします。 このプロセスにより、VATが更新され、ユーザーがローンを決済できるようになります。

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

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

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

MakerDAOは、 ガス代などの要因が二の次で、ユーザーエクスペリエンスが軽視され、競争がほとんどなかった設計段階で安全性を優先していました。

その結果、風変わりで、使用コストがかかり、ナビゲートするのが難しいように見えるかもしれません。

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

ハイライト：

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

Yield Protocolのアーキテクチャの進化

Yield v1 は、 YieldSpaceを使用した固定レートの概念実証として機能しました。 このバージョンでは、MakerDAOの上に債務担保エンジンが構築されています。 しかし、Yield v1は、使用コストが高く、新機能で補強するのが困難でした。

YieldSpaceの可能性を認識し、すぐに Yield v2の開発に移行しました。 MakerDAOからインスピレーションを得ながらも、完全に独立したYield v2は 、2021年10月にローンチされました。Yield v2は、ガスコストの削減とユーザーエクスペリエンスの向上を優先しました。

MakerDAOの影響を強く受けたYield v2の借入プロセス

会計、リスク管理、担保のチェックはすべて、1つの契約である 大釜に統合されました。 MakerDAOのアプローチを反映して、トレジャリー機能を Join コントラクトに分散し、それぞれが特定の資産に特化しました。

オラクル統合を刷新し、価格と金利のオラクルを 共通のインターフェースに統合しました。 MakerDAOからのオラクルフローを逆にして、Cauldronが担保チェックのために必要に応じて オラクルを参照 するようにしました。 私の知る限り、これはMakerDAO以外のどこでも好ましい流れです。

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

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

• 各資産には専用の財務/資金管理契約があり、財務/資金管理機能の最大限の配分が保証されます。
• 単一の契約により、会計機能が一元化されます。 また、リスク管理措置の監督や担保チェックも行います。
• 担保機能は、オラクルを参照して価格と金利を決定します。
• 価格と金利のオラクルは、統一されたインターフェースを共有しています。
• 金利は外部から生成されます。
• ユーザーは、1つの契約に対して1つのリクエストを行うことで借りることができます。

コンパウンド・ファイナンスのアーキテクチャの進化

Compoundの最初のバージョンは概念実証であり、イーサリアム上にマネーマーケットを確立できることを実証しました。そのため、シンプルさを優先して設計しました。 MoneyMarket.sol 契約は、貸付を含むすべての機能をカプセル化します。

Compound v1 の借用プロセス。 シンプルでありながら効果的です。

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

コンパウンド v2

Compound v2は2019年5月に発売され、イールドファーミングの時代に火をつけ、数え切れないほどのフォークにインスピレーションを与えました。 また、マネーマーケットとして機能し、ユーザーは資産を貸し借りすることができました。

その ホワイトペーパー と構造から、 Compound v2 の主な目標は、 ERC20標準を使用して貸出ポジションを表すことであったことは明らかです。 これにより、コンポーザビリティが保証され、ユーザーはCompoundに貸し出し、その有利子ポジションを他のブロックチェーンアプリケーションで使用することができます。

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

Compound v2 の借用プロセス。 トークン化された貸付ポジションへの最初の進出。

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

コンパウンド v3

2022年にリリースされたCompound v3は、より保守的なリスク管理戦略を採用し、流動性を借入可能な資産ごとにプールに分離します。また、使い勝手の良さやガス代への懸念も浮き彫りになっています。

Compound v3 (Comet) での借用プロセス。 基本に立ち返り、安全に立ち返る。 しかし、UXは向上しています。

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

リリースノートに記載されているその他の関連機能は次のとおりです。

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

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

• 貸与された資産のみ借りることができます。担保資産はできません。
• 担保はコンパウンドv3ではリターンをもたらさない。

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

供給された担保のリターンをなくすのは、Compoundがv2で多くの流動性を蓄積できた結果かもしれません。 Compound v2では、借入限度額は、ユーザーがアプリケーションに貸し出した資産を下回っているか、それほど高くないという直感があります。

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

アーキテクチャの観点からは、次のようになります。

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

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

Aave v1 は 2019 年 10 月にリリースされ、ETHLend の後継製品となりました。 ETHLendのピアツーピアアプローチの代わりに、Aave v1は共有流動性プールを導入しました。

Aave v1 での借用プロセス。 プールされた流動性は、財務的および計算上の効率性を意味しました。

Yield v2 と同様に、 ルーター コントラクト もビジネス ロジックを保持していました。 LendingPoolCoreは、会計、リスク管理、財務機能を実装しました。1つの契約でトレジャリーをプールすることは、Compound v2との差別化ポイントでした。

担保チェックをアカウンティングコントラクトではなく、ルータから呼び出される 独自のコントラクトに残すという決定は弱いように思えますが、Aave v2はv1リリースの2年後にリリースされただけなので、おそらく目的に合っていたのでしょう

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

Aave v2の

Aave v2 は 2021 年 12 月にリリースされました。 Aave v1 と同様の機能を保持しながら、Aave v1 と Compound v2 の両方と比較して、改善されたシンプルなアーキテクチャを導入しました。 このリリースで、Aaveはトークン化された負債を表すaTokens(Compoundの cTokens に類似)と vTokenも導入しました。

Aave v2 は、完全にトークン化された非常にクリーンなアーキテクチャを備えています。

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 つのコントラクトで、アプリケーションのすべてのストレージが保持されます。このストレージには、それぞれがシステムの異なる概念要素を管理する個別の プロキシを介してアクセスできます。

1つの契約にすべての資産、会計、リスク管理データが保存されていますが、Aave v2と同様に、担保と貸付用のeTokenと、債務用のdTokenがあります。 ただし、これらのトークンコントラクトは、中央ストレージコントラクトのビューにすぎません。

• ストレージ コントラクトは、アカウンティング変数を管理します。
• BaseLogicコントラクトはトレジャリーとして機能します。
• RiskManager契約は、担保チェックを含むリスク管理の変数と機能を監督します。

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

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

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

モノリシックなアーキテクチャが資産の枯渇に一役買ったとは思いません。 むしろ、コード更新の監視が不十分だったのです。

結論

大変な作業は終わりました、学んだことを復習しましょう

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

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

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

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

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

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

読んでくれてありがとう、そして幸運を祈ります。

この記事のレビューと編集をしてくれた Calnix に感謝します。

免責事項：

1. この記事は[hackernoon]からの転載です。 すべての著作権は原著作者[alcueca]に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。