深入探討DeFi借貸清算機制及其實現原理、風險與用例

一級標題

原文編譯：Kxp，BlockBeats

原文編譯：Kxp，BlockBeats

一級標題

過度抵押和壞賬

你可能會從我們之前的博客文章中想起，協議用戶只能對其提供給協議的抵押品的百分比進行資產借貸。這是有道理的，因為協議需要確保如果你無法償還債務，它可以從你那裡收回其資產（或任何其他價值相等的資產）。這種資產抵押的過程始於傳統金融，例如今天，一個人可以把他們的房子或蘭博基尼作為貸款償還的抵押品。

抵押依賴於抵押品價格保持其價值的前提條件——儘管房屋或蘭博基尼的價格無法保證，但它們各自的價值相對不太不穩定，而比起ERC 20 或NFT 等資產來說，更為穩定。

在大多數DeFi 借貸協議中，你的抵押貸款資產必須比你貸款的價值更有價值，也就是所謂的過度抵押。

如果借貸協議想要保持財務穩定，只允許過度抵押的貸款是有利的。想像一下，你提供了一些資產作為抵押品，而這些資產的價值突然低於你從協議中藉到的資產價值。現在，你的抵押品價值低於你欠協議的債務，你就沒有還款的動力。畢竟，在償還貸款的過程中，你將獲救的抵押品現在的價值低於實際償還貸款所需的金額。這種貸款現在已經無力償還。

一級標題

一級標題

清算和清算閾值

我們已經確定，當貸款抵押品價值低於借款人帶利息的債務價值時（也稱為低於抵押），借款人的債務會對其所在的借貸協議的健康狀況構成威脅。為了防止低於抵押的持倉增加，協議允許第三方（不一定是協議的用戶）償還低於抵押（或接近低於抵押）的債務。通過償還低於抵押的債務，這些被稱為清算人的第三方有權以折扣的價格要求歸還其被覆蓋的債務人的抵押品。這個過程被稱為清算。

你可能會想知道：為什麼協議要依賴第三方來清算不健康的持倉？畢竟，協議可以將自動清算機制編碼進其代碼中。

發送清算交易的成本非常高。如果協議自動發送這些昂貴的交易，resulting gas costs 將會增加其運營成本，從而削弱其利潤。

此外，自動清算系統的設計非常困難。協議不僅必須考慮是否應自動清算一個持倉，而且必須考慮何時這樣做，並以反映市場波動率的速率進行清算。通過激勵專門的第三方來清算這些持倉，這個過程要簡單得多。

清算本質上不是有利可圖的——對於這個過程來說，債務人的抵押品必須價值高於他們欠債的金額。如果清算人沒有保證這個過程會有利可圖，他們不會清算一個持倉。

那麼何時一個持倉才能被清算？這個條件由協議決定，是分配給每個資產的清算閾值的函數。

一級標題

一級標題

Compound:賬戶流動性

Compound 涉及到一個名為AccountLiquidity 的參數，計算Compound 主合約Comptroller 中的Liquidation Threshold。

Comptroller 有一個名為getAccountLiquidity() 的函數，返回有關賬戶流動性的信息。在內部，此函數調用getHypotheticalAccountLiquidityInternal()：

我們在這裡看到，該函數的主邏輯被限定在一個for 循環範圍內。這表明計算賬戶流動性是通過迭代所有市場完成的，其中賬戶參與。換句話說，在計算賬戶流動性時，考慮到了用戶借貸或作為抵押品的所有資產。

從我們之前的博客文章中回想一下，cTokenBalance 是用戶為抵押而提供的基礎資產數量。在這個例子中，我們還可以看到borrowBalance 和一些神秘的exchangeRateMantissa，它們都從getAccountSnapshot() 返回。

在我們之前的博客文章中討論的一般化exchangeRate 變量中，我們寫道：

「一個任意的利率可以增加鑄造的Token 數量，如果exchangeRate < 1 ，則可以減少Token 數量，如果exchangeRate > 1 ，則可以增加Token 數量。」

這也適用於exchangeRateMantissa，它表示cToken 與基礎資產之間的匯率。

正如我們在這個例子中看到的，Comptroller 在獲取了上面提到的三個參數之後，將首先獲取當前正在迭代的特定市場的collateralFactor。這個collateralFactor 信息是指用戶可以根據其抵押品藉多少錢的指標。從這個定義中，我們可以假設每個抵押品的存款可以抵押不同的借款金額。

之所以這個金額在不同資產之間有所不同，主要是因為每個資產在協議眼中都有自己的「風險」，通常是指資產價值隨時間波動的程度。

Compound 的治理根據市場狀況改變抵押因素，但在任何時候，他們的抵押因素不能超過0.9 ——最多可以藉出你存入的抵押品的90 ％：

然後，我們看到調用oracle.getUnderlyingPrice(asset)，它調用一個名為Oracle 的外部合約。

Oracle 是一種有趣的機制，值得一篇專門的博客文章（敬請期待）。為了簡潔起見，我們現在所解釋的是，Oracle 是用於在藉貸協議中獲取某個資產價格的合約，價格通常以協議使用的某種公共貨幣（通常是USD、ETH 或協議使用的穩定幣）為基礎。

現在，我們已經涵蓋了影響單個市場健康狀況的所有因素，因此我們將寫下計算單個市場AccountLiquidity 的方程式：

注意：在Compound 中，資產的價格以美元（USD）計價。

這是一個相當長的變量列表，但如果你試著記住我們的「份額Token」文章中的Compound 部分，你會發現以下表達式：

簡單表示了用戶cToken 的基礎資產價值。

一級標題

一級標題

Maker 

另一個設置清算不足抵押頭寸閾值的協議是Maker。

讓我們檢查該協議部署用於處理清算的兩個合約：

· Dog：在遷移到liquidations 2.0 （Maker 治理稱之為）之後部署的。此處的清算函數為bark()。

· Cat：liquidations 1.2 ，bite()。 

· grab()：VAT 合約，用作在部署貓合約之前進行清算的方法。

讓我們看一下bite() 中的片段：

以及從bark() 中的類似片段：

你可能會注意到兩者俱有相同的not-unsafe 消息。因此，對於每個清算函數，Vault 的安全要求都相同，並且可以用以下等式表示：

我們可以使用這個等式來定義一個不等式，以便Vault（Maker 用於頭寸的名稱）仍然是安全的：

優化一下：

我們建議我們的讀者前往MakerDAO 術語表，擴展我們提供的有關Maker 生態系統中不同變量名稱和術語的信息。

或者，你可以相信我們在此概述的內容：

• spot_{ilk} 在這個不等式中用作抵押品的價格，以DAI 計價，除以抵押品的清算比率（由治理決定）

• ink_{urn} 是頭寸的抵押品餘額

• rate_{ilk} 是特定抵押品類型的累計債務。當與art_{urn} 相乘，這是一個頭寸借入的標準化債務金額，我們可以得到以DAI 計價的總債務

AAVE V2——健康因子

一級標題

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 。

讓我們通過在AAVE V2 借貸協議上調用getUserAccountData 函數來調查其當前情況：

現在讓我們分解上面的內容，來看看這個頭寸的情況有多糟糕：

· 總欠債ETH： 17.83508595148699 ETH

· 總抵押ETH： 0.013596360502551568 ETH

這就是我們需要了解的所有內容，這個頭寸有麻煩了——抵押品的價值只是欠款的一小部分。

那麼這個頭寸是如何陷入困境的呢？

為了回答這個問題，我們可以查看該用戶在AAVE 上執行的最新操作：

看起來一切都很好，直到塊13514857 ，在該塊中，用戶從AAVE 借出了一些資產。讓我們看看他們做了什麼：

債務人借了700, 000 MANA，快速查看MANA 的美元價格將揭示該價格為：

每個MANA 單位0.00032838 ETH。

通過簡單的乘法，我們知道該用戶通過以下方式增加了協議的債務： 0.00032838 * 700000 = 229.866 ETH

值得一提的是，在該塊的USD 價格是4417.40 美元。

請注意上圖中發生的存款操作，發生在藉款幾個小時後的塊13517657 。讓我們看看市場上是否有什麼事情動搖了我們用戶的信心：

上面是發送到AAVE V2 價格Oracle 的RPC 調用，以獲取指定塊中1 個MANA 單位的wei 值。

如果我們使用這些數據轉換上述價格，我們可以看到發生了什麼：

0.00033625 * 700000 = 235.375 ETH

在短短幾個小時內，債務增加了5.5 ETH，價值24000 美元。

由於我們知道這個頭寸的故事結局，我們知道它在某個時候是可清算的，因此讓我們檢查是否有涉及該用戶地址的liquidationCall 調用：

一旦我們找到第一個清算事件，我們就可以了解為什麼用戶在藉款後不久就存入資產：

在這裡，我們可以看到第一次清算發生在塊13520838 。這次清算發生在用戶存入資金之前（在存款交易的約7 分鐘之前）。

然後，在13520838-13522070 塊之間發生了一系列小的清算，這些清算最終價值相當高：

讓我們檢查清算人在這些塊之間從用戶處奪取的所有抵押資產類型：

我們可以看到只有2 種資產，DAI（穩定幣）和ETH。

以及它們的數量：

~ 50 ETH 

~ 387663 DAI 

有人可能會問，為什麼清算會分成這麼小的塊？

當像這樣龐大的頭寸被一次性清算時，市場會將這樣大量的抵押品收購解釋為這些資產類型的賣出信號。請記住：根據協議的清算獎勵政策，以折扣購買清算中獲得的資產。

一次大規模的清算會引發一系列清算，隨著賣出壓力的上升，其他市場參與者可能也會賣出其資產，導致資產價格進一步「崩盤」，進而導致協議中其他頭寸的更多清算。

因此，協議通常限制單個清算可以奪取的資產數量。 AAVE 版本的此限制，作為變量，如下所示：

正如我們所看到的，限制百分比為50 ％，這意味著只有頭寸債務的一半被允許在一次清算中償還。

清算人有動機將其清算拆分成較小的塊。如果在清算時市場上沒有足夠的流動性來提供抵押品資產，那麼將清算拆分成較小的塊，清算人更有可能獲得清算資產，並從他們的清算中獲利。

此外，如果市場上沒有足夠的流動性來獲取債務資產，則清算人可能需要花費很多費用來獲得首先要償還未充足抵押的用戶的債務。

最後，想像一下試圖清算大量某種Token，而沒有擁有那麼多。如果你去DEX 並嘗試交換一些WETH 或其他資產以獲得這一Token，你可能會遇到非常高的Gas 費，這會使你的清算變得無利可圖。

回到我們的例子，為了檢查鏈中一系列清算之後的頭寸參數，我們需要解析從getUserAccountData 返回給我們的數據：

然後我們使用cast 查詢鏈：

最後解析輸出：

在這裡，我們看到清算對頭寸的影響：幾乎沒有剩餘的抵押品，精確到0.6 ETH。但是債務呢？高達45.26716296709878 ETH。

這個塊的MANA 價格是多少？

0.000862110734985458 ETH。

如果你還記得，我們的用戶僅僅幾個小時前以0.00032838 ETH 的價格借了MANA。這相當於開了一個股票的空頭頭寸，而這支股票的價格升了2.65 倍。

總結

總結

總結

雖然我們不能確定是否有一個方程來定義頭寸的流動性閾值，但我們肯定可以看到協議之間的相似之處：

· 所有協議都將其閾值定義為某種抵押品與債務的函數（無論是比率還是差異）。

· 所有協議都給治理留下了一些空間，以便根據市場條件的變化決定每種抵押品風險參數的價值，因為有些資產比其他資產更具有波動性。

原文鏈接

原文鏈接

原文鏈接