DeFiレンディングの包括的な解釈：構成、公式、ユースケース
原題：「DeFiレンディングの概念パート1：融資と借入」
原作者：タル
オリジナルコンピレーション: Kxp、Blockbeats
最初のレベルのタイトル
融資プール
従来の金融 (TradFi) では、貸し借りは第三者の金融機関によって調整されます。これらの金融機関は、借り手から貸し手への利息支払いを強制すること、および信頼できないとみなされる当事者がこうした活動に関与することを評価して阻止することという 2 つの重要な任務を負っています。
対照的に、分散型金融 (または DeFi) では、サードパーティの借り手や貸し手は信頼できません。この信頼の欠如は、オンチェーンでの融資プロセスを促進するための革新的な設計を生み出しました。
レンディングプールはスマートコントラクトです。 DeFiプロトコルのユーザーは、契約を使用して預けた資産を貸し出す目的で、資産（通常はERC 20トークン）を預けることができます。他のユーザーは融資プールを操作して即時融資を利用できます。つまり、融資プール内の資産を抵当にして借入することができます。
融資プールには、従来の金融手法と比較して、融資に関して次のような大きな利点があります。
· DeFi では、融資は融資資金と借入額が 1 対 1 であるかどうかによって制限されません。代わりに、プロトコルのすべてのユーザーからの資金がプールされ、すぐに融資ニーズを満たすのに十分な大きさのトークン在庫が作成されます。
・DeFiは返済計画を必要としません。融資は以前に預けられた担保に基づいて実行され、ユーザーはいつでも返済を選択できます。
この時点で、あなたはこう考えているかもしれません、「同じ価値の（あるいは過大評価さえある）資産を担保として差し出さなければならないのに、なぜ貸付契約に基づいてその資産を借りたいのでしょう？担保を売って購入すべきではないでしょうか」借りた資産は？」
実際、このDeFi融資プロトコルは完全担保（または超過担保）ローンのみを許可しているようで、レバレッジという興味深い「取引」方法への扉を開いています。
あなたが WBTC に対して非常に強気で、その価値が急騰すると確信しているとしましょう。お気に入りの融資プロトコルに WBTC (1000 ドル相当) を預け、それを使ってステーブルコイン (USDC など) を借り、そのステーブルコインを使って取引所で WBTC をさらに購入することができます (このシナリオでは、最初の入金額の半分を想定します。つまり500ドルです）。この場合、WBTC へのエクスポージャーは 1500 ドルの価値があり、最初のデポジットはわずか 1000 ドルでした。
しかし、USDC をさらに借りるために WBTC 担保の 500 ドルをプロトコルに預けたらどうなるでしょうか?このプロセスはオーバーレバレッジと呼ばれ、借入能力を超えるまでこれを続けることができますが、プロトコルのポリシーによりそれが禁止されます。
最初のレベルのタイトル
共有トークン
従来の金融と同様に、融資プールに資産を預けるユーザーは、資金を長期的に保管し、その預金に対して利子を得る動機が与えられます。利息は時間の経過とともに発生し、プロトコルでのユーザーの入金の割合として計算され、対応する入金ユーザーによって請求されます。ユーザーが融資プールに資産を長く保持するほど、より多くの利息を得ることができます。
プロトコルはプール内の各ユーザーの共有をどのように追跡しますか?ユーザーが資産をプールに預けると、その「シェア」によって全ユーザーのシェアが薄まり、それに応じてプロトコルにこれが反映されます。ただし、各ユーザーのプールシェアを直接追跡して更新する代わりに、このプロトコルは預金者のシェアの変更のみを処理し、他のユーザーが引き出しまたは入金するたびに他のユーザーのシェアを積極的に更新することはありません。
この協定によりケーキを食べられると思うかもしれません。しかし、実際には次のようにはなりません。
このプロトコルは、ローンプールにおける貸し手のシェア（または預金資産の割合）を表す「シェアトークン」と呼ばれるERC 20トークンの鋳造と燃焼によって利息の支払いを処理します。この「株式トークン」の設計は、他の「株主」の株式の希薄化を自動的に調整して、原資産の入出金に比例した「株式」の鋳造と焼却を反映します。
最初のレベルのタイトル
aToken: AAVE の「シェアトークン」
aToken は、資産の入出金時に融資プールによって鋳造および焼却される AAVE の利回り生成トークンです。
aToken は、AAVE プロトコルに統合された ERC 20 に似たトークンであるため、ユーザーがアクセスできる (担保を預ける) それぞれの異なる市場には、対応する aToken があります。
AAVE 融資プール契約を見ると、ユーザーが資産をプールに入金するときに行われる基本的な操作がわかります。
ユーザーが入金したマーケットに対応する aToken が「minting」関数で呼び出されることがわかります。
実際に鋳造される量は次のとおりであることがわかります。
上の画像に示すように、この例では、ユーザーは以前の入金ですでにいくらかの利息を獲得している市場に参加します。上の式は、さまざまな操作 (入金、出金など) で更新されるグローバル インデックスを使用して、すべてのユーザーの利息の発生を計算する方法を示しているため、これを理解するのに役立ちます。
ユーザーが原資産を引き出すとき、liquidityIndex はトランザクションで支払うべきトークンの量を計算するための乗数として使用されます。
以下は、融資プール契約の関連コード スニペットです。
ここで、aToken コントラクトの BalanceOf 関数は少し奇妙です。結局のところ、鋳造された aToken の量が、預けられた原資産の量と同じではないことを確認しただけです。 IAToken(aToken).balanceOf(address(user)) を呼び出すと、ユーザーが引き出しようとしている原資産の金額がどのように計算されますか (関数の下部に表示されているように)。その理由は次のとおりです。
· ユーザーが資産を引き出すと、aToken は破棄されます。これらの焼かれた aToken は、ユーザーの資産が引き出された後、他のユーザーが所有する aToken の合計量をそのシェアに比例して維持します。
· ユーザーが資金を引き出すための市場レートは、引き出しごとに更新されます。
前に述べたように、aToken は ERC 20 に似たトークンです。それらの BalanceOf 関数には独自のプロパティがあるため、これらは ERC 20 トークンに「似ている」ことを強調します。通常の ERC 20 トークンでは、balanceOf 関数はアドレスが所有するトークンの数を返します。
aToken は即時値ではなくプールのシェアを表すため、aToken の BalanceOf 関数は、プロトコルがユーザーのデポジットを補償する義務があるベース トークンの量を返します。
ここで、balanceOf 関数は、継承された aToken コントラクトの BalanceOf 関数をオーバーライドします。その結果、このサンプル ロジックの BalanceOf ロジックは、ユーザー トークン数量の通常の (継承された) マップ検索の代わりに実行されます。
次に、上記のトークンの数に getReserveNormalizedIncome の結果を乗算し、次のロジックを実行します。
ここでブランチを特定できます。
· 予約データがこのブロックで更新されている場合: 更新されたこの市場の流動性インデックス値を返します。
· それ以外の場合: 次のフローを理解するには、calculateLinearInterest で何が起こるかを確認する必要があります。
現在の市場の ReserveData オブジェクトからの currentLiquidityRate と lastUpdateTimestamp がこの関数に渡され、関数の結果は次のようになります。
LinearInterest 値の要点をよりよく理解するために、この方程式の構成要素を分解してみましょう。
currentLiquidityRate: これを市場の年利 (APY) と考えてください。
block_{timestamp} - lastUpdatedTimestamp: 前回の更新からの経過時間
注: getNormalizedIncome で 2 番目のブランチを選択したため、この時点では値が正であることが保証されています。
したがって、この利息発生メカニズムは、各ブロックで複利される単純な利息複利メカニズムとして考えることができます。ユーザーに発生する利息の額を決定したので、必要なのはその値に流動性インデックスを乗算し、balanceOf 関数でユーザーの正規化された収入の乗算を行うことだけです。
aToken の背後にあるロジックは理解できましたが、liquidityIndex がどのように機能するかという謎を解く必要があります。
以下の例では、liquidityIndex は、一定期間にわたって準備金によって蓄積された利息として定義できます。
前に説明した、liquidityRate 変数を思い出してください。ここで、liquidityIndex の計算におけるその使用について説明します。利息は、liquidityRate が 0 より大きい場合にのみ発生します。つまり、利息は、その市場に APY がある場合にのみ発生します。それは理にかなっている。
実際の CalculateLinearInterest の動作を簡単に確認してみましょう。
上記のロジックは次の方程式に変換できます。
DefaultReserveInterestRateStrategy.sol コントラクトでわかるように、liquidityRate は次のように定義されています。
したがって、次のように書くことができます。
全体の借入金利 (overallBorrowRate) は、ここでは次のように定義されます。
これは次のように書くことができます。
使用率 (utilizationRate) は次のように定義できます。
利用状況を定義するときは、準備金の流動性 (現在貸し出されている流動性) と市場の総流動性の比率を考慮する方が簡単で、次のように単純化できます。
これで、これら 2 つの定義を使用して流動性インデックスの方程式を書くことができます。
totalBorrows は分子と分母の両方に存在するため、次のように書くことができます。
最初のレベルのタイトル
cToken: コンパウンドの「共有トークン」
次の融資プロトコルの例である Compound に移りましょう。
Compound は、cToken と呼ばれる「共有トークン」を使用して貸し借りを処理します。このトークンは、複合プロトコルでのユーザー貸付に使用できるすべての資産を記録するために使用されます。
AAVE V2 で説明したのと同様に、Compound の「シェア トークン」は発行され、原資産の償還に使用されます。
Compound は、AAVE V2 の流動性インデックスと同様の為替レートを使用して、鋳造される cToken の数を決定します。為替レートは次のような関数です。
ここで重要な用語を説明しましょう。
·totalCash: cToken アカウントが所有する ERC 20 基本トークンの数。
· totalBorrows: 借り手が市場で借りたERC 20ベーシックトークンの数。
· totalReserves: 一定数の ERC 20 基本トークンが予約されており、ガバナンスを通じて抽出または転送できます。
· totalSupply: cToken の総供給量を返す ERC 20 関数。
このような背景を踏まえると、Compound の為替レート方程式を次のように書くことができます。
ユーザーが ERC 20 トークンを預けると、為替レートによって、見返りに鋳造される cToken の数が決まります。
最初のレベルのタイトル
eToken: オイラーの「シェアトークン」
これらのプロトコル間の類似点をさらに確認するために、別の融資プロトコルであるオイラーを分析し、それが融資をどのように処理するかを見てみましょう。
以下の例では、デポジット機能により、ユーザーは eToken と引き換えに ERC 20 トークンをデポジットできます。
見てわかるように、internalAmount は、この転送のために生成された eToken の量です。
ここでも、Compound の名前と関数exchangeRate と直接重複しています。
為替レートの計算に使用される主要なパラメーターについて説明します。
· poolSize: 原資産を使用する ERC 20 契約において、プール契約アドレスを指定して BalanceOf(address) 関数を呼び出した結果。
· totalBorrows: 現在プールにない、貸し出された ERC 20 ベーシック トークンの合計額。
· totalBalances: すべての eToken 保有者の合計残高。
要約する
要約する
3 つの融資プロトコルについて説明しました。
· AAVE V2
· Compound
· Euler
私たちは、「シェアトークン」がどのように鋳造され、レンディングプールを通じてどのように預金資産と交換されるかを調査しました。
私たちが提案する 3 つの方程式は、単純な方程式にまとめることができます。
為替レートはプロトコルが定義する任意の方法で定義できることに注意してください。これらの任意の為替レートにより、鋳造されるトークンの量が (1 未満の場合) 増加し、1 より大きい場合は減少する可能性があります。
AAVE V2 と Compound では、someRate 変数との類似点がいくつか見られました。 Compound では、someRate は次のようになります。
AAVE V2 の場合、someRate は次のように定義されます。
流動性指数は次のように定義されます。
各プロトコルの為替レートを単一の式に一般化することはできませんが、AAVE 2 と Compound では、為替レートが市場の総流動性の関数であることがわかっています。方程式に戻ると、totalLiquidity が市場の ERC 20 ベース トークンの総量であるとすると、exchangeRate 式の分子と LiquidityRate 式の分母は機能的に同一です。
元のリンク
