DeFiの融資と清算のメカニズムとその実装原則、リスク、ユースケースについての深い議論

原題：「DeFi融資の概念パート2：清算」

オリジナルコンピレーション: Kxp、BlockBeats

オリジナルコンピレーション: Kxp、BlockBeats

最初のレベルのタイトル

過剰担保と不良債権

前回のブログ投稿で、プロトコル ユーザーはプロトコルに提供した担保の割合に基づいてのみ資産を貸し借りできることを思い出したかもしれません。あなたが借金を返済できなかった場合に、プロトコルはその資産（または同等の価値のある他の資産）をあなたから回収できることを保証する必要があるため、これは理にかなっています。この資産抵当のプロセスは、たとえば今日では、ローン返済のための担保として自分の家やランボルギーニを置くことができる伝統的な金融で始まりました。

住宅ローンは、担保の価格がその価値を維持するという前提条件に依存しています。住宅やランボルギーニの価格は保証されていませんが、それぞれの価値はERC 20やNFTなどの資産よりも比較的変動が少なく、より安定しています。

ほとんどの DeFi 融資プロトコルでは、担保されたローン資産はローンの価値よりも価値がある必要があり、これを過剰担保と呼びます。

融資プロトコルが金融の安定性を維持したい場合は、過剰担保融資のみを許可することが有益です。担保として資産を差し出したところ、その資産の価値がプロトコルから借りた資産の価値よりも突然低くなったと想像してください。現在、担保の価値はプロトコルに対して負っている額よりも低くなり、返済するインセンティブはありません。結局のところ、ローンを返済する過程で、あなたが救済する担保の価値は、ローンを返済するために実際に必要な金額よりも低くなります。このローンは現在支払い不能になっています。

ローンの不履行はすべて、そのローンが締結している契約に悪影響を及ぼします。破産したローンから生じる負債は議定書に不安要素を生み出します。結局のところ、負債の額は貸し手が議定書から回収できない資産の額なのです。これらの不良債権がいかに深刻かを強調するために、もしプロトコル上で伝統的な金融「取り付け騒ぎ」のようなことがあったとしたら、最後にプロトコルから資産を引き出したユーザーは、そうすることができなくなるでしょう。

最初のレベルのタイトル

清算と清算閾値

当社は、ローン担保の価値が借り手の有利子負債よりも低い場合（過少担保とも呼ばれる）、借り手の債務が、それが置かれている貸付契約の健全性に対する脅威となることを確認しました。過少担保の保有額が増加するのを防ぐために、このプロトコルは第三者（必ずしもプロトコルのユーザーではない）が過少担保の（または過少担保に近い）債務を返済できるようにしています。担保以下の債務を返済することにより、清算人として知られるこれらの第三者は、対象債務者の担保を割引価格で返還するよう要求する権利を有します。このプロセスは清算と呼ばれます。

なぜこのプロトコルは不健全なポジションの清算を第三者に依存しているのかと疑問に思われるかもしれません。結局のところ、プロトコルは自動清算メカニズムをコードにエンコードできます。

決済トランザクションの送信コストは非常に高くなります。プロトコルがこれらの高価なトランザクションを自動的に送信すると、結果として生じるガスコストが運用コストを増加させ、それによって利益が減少します。

また、自動清算システムの設計は非常に困難です。プロトコルでは、ポジションを自動的に清算すべきかどうかだけでなく、いつ清算するのか、また市場のボラティリティを反映したレートで清算するのかを考慮する必要があります。献身的な第三者にこれらのポジションを清算するよう奨励することで、プロセスがはるかに簡単になります。

清算は本質的に利益をもたらすものではありません。このプロセスでは、債務者の担保が借りている金額よりも価値がある必要があります。清算人がそのプロセスが利益を生むことを保証しない場合、ポジションを清算しません。

それでは、いつポジションを清算できるのでしょうか?この条件はプロトコルによって決定され、各資産に割り当てられた清算しきい値の関数です。

清算の基準に関しては、タイミングが非常に重要です。ご存知のとおり、ポジションの負債価値が担保価値を超えた場合、これらのポジションを清算することは清算人にとって利益にならず、プロトコルも不良債権に直面することになります。したがって、安全な清算基準値は、清算人が破産状態に達する前にポジションを清算するのに十分な時間を提供します。

最初のレベルのタイトル

複合: 口座流動性

Compound には、Compound の主契約である Comptroller の清算しきい値を計算する AccountLiquidity と呼ばれるパラメーターが含まれます。

Comptroller には、口座の流動性に関する情報を返す getAccountLiquidity() という関数があります。この関数は内部的に getHypotheticalAccountLiquidityInternal() を呼び出します。

ここでは、関数のメイン ロジックのスコープが for ループ内にあることがわかります。これは、アカウントの流動性の計算が、アカウントが参加しているすべての市場を反復処理することによって行われることを示しています。言い換えれば、アカウントの流動性を計算する際には、ユーザーが借りた、または担保として使用したすべての資産が考慮されます。

前回のブログ投稿で、cTokenBalance がユーザーが担保として提供する原資産の金額であることを思い出してください。この例では、getAccountSnapshot() から返された、borrowBalance といくつかの謎の ExchangeRateMantissa も確認できます。

前回のブログ投稿で説明した一般化されたexchangeRate変数では、次のように書きました。

「任意の金利により、鋳造されるトークンの数を増やすことができます。exchangeRate < 1 の場合、トークンの数を減らすことができます。exchangeRate > 1 の場合、トークンの数を増やすことができます。」

これは、cToken と原資産の間の為替レートを表すexchangeRateMantissa にも当てはまります。

この例でわかるように、上記の 3 つのパラメーターを取得した後、監査監査人はまず、現在反復されている特定の市場の CollarateFactor を取得します。このcollarateFactor情報は、ユーザーが担保に対していくら借りられるかを示す指標です。この定義から、各担保預金は異なる借入額で担保できると想定できます。

この金額が資産間で異なる理由は主に、プロトコルの観点から各資産が独自の「リスク」を抱えているためであり、通常は資産の価値が時間の経過とともに変動する程度を指します。

Compound のガバナンスは市場状況に基づいて担保係数を変更しますが、どの時点でも担保係数は 0.9 を超えることはできません。つまり、預けた担保の最大 90% が貸し出されます。

次に、Oracle という外部コントラクトを呼び出す oracle.getUnderlyingPrice(asset) の呼び出しが表示されます。

オラクルは、専用のブログ投稿に値する興味深いメカニズムです (続報をお待ちください)。簡潔にするために、私たちが今説明していることは、オラクルとは、融資プロトコルで資産の価格を取得するために使用される契約であり、通常はプロトコルで使用される何らかの公的通貨（通常はUSD、ETH、またはステーブルコイン）で取得されるということです。プロトコルによって使用されます) を基礎として使用します。

個別市場の健全性に影響を与えるすべての要因をカバーしたので、個別市場の口座流動性を計算する方程式を書き留めます。

注: Compound では、資産価格は米ドル (USD) 建てで表示されます。

これは変数の非常に長いリストですが、「共有トークン」記事の「複合」セクションを覚えてみると、次の式が見つかるでしょう。

これは単にユーザーの cToken の基本資産価値を表します。

さらに、ここでわかるように、borrowBalance_{user} 変数は、未払い利息を含む、ユーザーが借りた資産の合計残高です。

最初のレベルのタイトル

Maker 

担保不足のポジションを清算するためのしきい値を設定するもう 1 つのプロトコルは Maker です。

清算を処理するためにプロトコルが展開する 2 つのコントラクトを調べてみましょう。

Dog: 清算 2.0 (Maker ガバナンスでの呼称) への移行後にデプロイされます。ここでの清算関数は bark() です。

· Cat：liquidations 1.2 ，bite()。 

grab(): VAT コントラクト。cat コントラクトがデプロイされる前に清算する方法として使用されます。

bit() のスニペットを見てみましょう。

bark() からの同様のスニペット:

どちらも同じ安全ではないメッセージを持っていることに気づくかもしれません。したがって、Vault のセキュリティ要件は各清算機能で同じであり、次の方程式で表すことができます。

この方程式を使用して不等式を定義すると、Vault (Maker がポジションに使用する名前) が引き続き安全になります。

最適化します:

読者の皆様には、MakerDAO 用語集にアクセスして、Maker エコシステムのさまざまな変数名や用語について提供する情報をさらに詳しく調べることをお勧めします。

あるいは、ここで概説した内容を信頼することもできます。

• この不等式では、spot_{ilk} は、DAI 建ての担保の価格を担保の清算比率 (ガバナンスによって決定される) で割ったものとして使用されます。

• ink_{urn} はポジションの担保残高です。

• rate_{ilk} は、特定の担保タイプの累積負債です。ポジションごとに借り入れた正規化された負債額である art_{urn} を掛けると、DAI 建ての負債総額が得られます。

Maker の用語を使用せずに、今説明した内容を簡略化するために、次のように表します。

最初のレベルのタイトル

AAVE V2 - ヘルスファクター

AAVE V2 では、独自のしきい値 HealthFactor も定義されています。健康係数の値が H_{f} < 1 のユーザーは強制終了できます。

次のように定義されます。

明らかに、ユーザーに借金がない場合、そのポジションを清算することはできないため、ヘルス係数はデフォルトで type(uint 256).max になります。

それ以外の場合、健康係数は次のように定義されます。

最初のレベルのタイトル

破産状況分析

不良債権の概念について説明したので、その重要性を強調するために実際の例を示します。

これから説明するポジションは、AAVE V2 の次のアカウントです: 0x 227 cAa 7 eF 6 D 955 A 92 F 483 d B2B D 01172997 A 1 a 623 。

getUserAccountData 関数を呼び出して、AAVE V2 貸出プロトコルの現在の状態を調べてみましょう。

では、上記を分解して、この位置がどの程度問題があるかを見てみましょう。

· 合計未払いETH: 17.83508595148699 ETH

· 約束されたETHの合計: 0.013596360502551568 ETH

私たちが知る必要があるのはそれだけです。このポジションは問題に直面しています。担保の価値は借りている金額の何分の１かです。

では、なぜこのポジションが問題に陥ったのでしょうか？

この質問に答えるために、このユーザーが AAVE 上で実行した最新のアクションを確認します。

ブロック 13514857 まではすべて順調に見えましたが、ブロック 13514857 では、ユーザーが AAVE から資産を貸し出しました。彼らが何をするのか見てみましょう:

債務者は 700,000 MANA を借りています。MANA の米ドル価格をざっと見てみると、価格は次のとおりであることがわかります。

MANA ユニットあたり 0.00032838 ETH。

単純な乗算により、このユーザーがプロトコルの負債を 0.00032838 * 700000 = 229.866 ETH 増加させたことがわかります。

このブロックの米ドル価格は $4417.40 であることに言及する価値があります。

上の画像のブロック 13517657 で、借入の数時間後に行われた入金操作に注目してください。市場でユーザーの信頼を揺るがすものがないか見てみましょう。

上記は、指定されたブロック内の 1 MANA ユニットの wei 値を取得するために AAVE V2 価格オラクルに送信される RPC 呼び出しです。

このデータを使用して上記の価格を変換すると、何が起こるかわかります。

0.00033625 * 700000 = 235.375 ETH

わずか数時間で負債は 5.5 ETH (24,000 ドル相当) 増加しました。

このポジションのストーリーの終わりがわかっているので、ある時点で清算可能になることがわかっているので、このユーザー アドレスに関連する LiquidationCall があるかどうかを確認してみましょう。

最初の清算イベントが見つかると、ユーザーが借入後すぐに資産を預ける理由が理解できます。

ここでは、最初の清算がブロック 13520838 で発生したことがわかります。この清算は、ユーザーが資金を入金する前 (入金取引の約 7 分前) に行われます。

その後、ブロック 13520838 から 13522070 の間で一連の小規模な清算が行われ、最終的にはかなりの価値になりました。

これらのブロック間で清算人がユーザーから差し押さえたすべての担保資産タイプを調べてみましょう。

資産は DAI (ステーブルコイン) と ETH の 2 つだけであることがわかります。

そしてその数:

~ 50 ETH 

~ 387663 DAI 

なぜ清算がこれほど小さな部分に分割されるのかと疑問に思う人もいるかもしれません。

このような大規模なポジションが一度に清算されると、市場はそのような大規模な担保の取得をこれらの資産タイプの売りシグナルとして解釈します。覚えておいてください: 清算で取得した資産は、プロトコルの清算報酬ポリシーに従って割引価格で購入されます。

大規模な清算は一連の清算を引き起こし、売り圧力が高まると他の市場参加者も資産を売却し、資産価格のさらなる「暴落」を引き起こす可能性があり、それがプロトコル内の他のポジションのさらなる清算につながります。

そのため、プロトコルは通常、1 回の清算で差し押さえられる資産の量を制限します。 AAVE バージョンの変数としてのこの制限は次のとおりです。

ご覧のとおり、制限パーセンテージは 50% です。これは、1 回の清算でポジションの負債の半分のみを返済できることを意味します。

清算人には、清算をより小さな部分に分割するインセンティブがあります。清算時に担保資産を提供するのに十分な流動性が市場にない場合、清算をより小さな塊に分割することで、清算人は清算された資産を取得し、清算から利益を得る可能性が高くなります。

さらに、債務資産を取得するのに十分な流動性が市場にない場合、そもそも担保不足のユーザーに返済しなければならない債務を取得するために清算人に多額の費用がかかる可能性があります。

最後に、ある種のトークンをそれほど所有せずに大量に清算しようとしていると想像してください。 DEX にアクセスし、このトークンを取得するために WETH またはその他の資産を交換しようとすると、非常に高額なガス手数料が発生する可能性があり、清算が不採算になります。

例に戻ると、チェーン内の一連の清算後にポジション パラメーターを確認するには、getUserAccountData から返されたデータを解析する必要があります。

次に、キャストを使用してチェーンをクエリします。

最終的な解析出力:

ここではポジションに対する清算の影響がわかります。担保はほとんど残っていません (正確には 0.6 ETH)。しかし、借金はどうなるのでしょうか？最大45.26716296709878 ETH。

このブロックの MANA 価格はいくらですか?

0.000862110734985458 ETH。

思い出していただければ、ユーザーはほんの数時間前に MANA を 0.00032838 ETH で借りました。これは、価格が 2.65 倍に上昇した株式の空売りポジションを開くことに相当します。

これらの清算人は、価格が採算が合わない水準まで下落する前にポジション全体を清算することができず、当社には破産ポジションが残されました。

要約する

要約する

ポジションの流動性のしきい値を定義する方程式があるかどうかはわかりませんが、プロトコル間に類似点があることは確かです。

すべてのプロトコルは、しきい値をある種の担保と負債の関数 (比率または差) として定義します。

一部の資産は他の資産よりも不安定であるため、すべてのプロトコルには、変化する市場状況に基づいて各担保リスクパラメーターの値をガバナンスが決定する余地が残されています。

すべてのプロトコルはオラクルを使用して、広く受け入れられている通貨 (ETH、USD、DAI など) で担保と債務の価格を決定します。

元のリンク

元のリンク