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

這篇文章是三篇系列文章中的第二篇，討論 DeFi 借貸協議的工作原理——它們的關鍵組成部分、公式和用例。在我們之前的文章中，我們回顧了 DeFi 的核心操作——借貸，以及不同協議如何選擇實現這些操作（還記得「市佔率 Token」嗎？）。在這篇文章中，我們將重點介紹我們認為最令人興奮的 DeFi 借貸概念之一：清算。

過度抵押和壞帳

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

抵押依賴於抵押品價格保持其價值的前提條件——儘管房屋或蘭博基尼的價格無法保證，但它們各自的價值相對不太不穩定，而比起 ERC20 或 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 的基礎資產價值。

此外，borrowBalance_{user} 變量，如你在這裡所見，是用戶借用的資產總餘額，包括其中應計利息。

現在，我們已經到達了以下備選 AccountLiquidity 方程式的點：

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 計價的總債務

為了簡化我們剛剛涵蓋的內容，不使用 Maker 術語，我們將這樣表示：

注意：Maker 決定將抵押品和債務的價值計價為 DAI——協議的穩定幣。

AAVE V2——健康因子

AAVE V2 還定義了自己的閾值 HealthFactor。具有 H_{f} 1 的健康因素值的用戶可以被清算。

定義如下：

顯然，當用戶沒有債務時，他們的部位無法被清算，因此健康因子默認為 type(uint256).max。

否則，健康因子被定義為：

當清算閾值由治理獨立定義，目前由 Gauntlet 代表提供協議的所有風險參數，包括 LiquidationThresholds。

破產部位分析

現在我們已經討論了壞帳的概念，接下來我們將提供一個真實世界的例子，以強調其重要性。

我們要討論的部位是 AAVE V2 上的以下帳戶：0x227cAa7eF6D955A92F483dB2BD01172997A1a623。

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

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

· 總欠債 ETH：17.83508595148699ETH 

· 總抵押 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 倍。

這些清算人在價格下跌到無法獲利的程度之前無法及時清算完整個部位，我們留下了一個破產的部位。

現在，我們可以意識到有效的流動性閾值在防止協議產生壞帳方面的重要性。

總結

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

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

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

· 所有協議都使用預言機以一種廣泛接受的貨幣（例如 ETH，USD，DAI）對其抵押品和債務價格進行標價。

我們已經看到 Maker 和 AAVE 選擇使用相同的方程來表示部位的安全性：

原文連結