原文標題：《DeFi Lending Concepts Part 2: Liquidations》
原文作者：Tal
原文編譯：Kxp，BlockBeats
這篇文章是三篇系列文章中的第二篇，討論 DeFi 借貸協議的工作原理——它們的關鍵組成部分、公式和用例。在我們之前的文章中，我們回顧了 DeFi 的核心操作——借貸，以及不同協議如何選擇實現這些操作（還記得「份額 Token」嗎？）。在這篇文章中，我們將重點介紹我們認為最令人興奮的 DeFi 借貸概念之一：清算。
過度抵押和壞賬
你可能會從我們之前的部落格文章中想起，協議使用者只能對其提供給協議的抵押品的百分比進行資產借貸。這是有道理的，因為協議需要確保如果你無法償還債務，它可以從你那裡收回其資產（或任何其他價值相等的資產）。這種資產抵押的過程始於傳統金融，例如今天，一個人可以把他們的房子或蘭博基尼作為貸款償還的抵押品。
抵押依賴於抵押品價格保持其價值的前提條件——儘管房屋或蘭博基尼的價格無法保證，但它們各自的價值相對不太不穩定，而比起 ERC 20 或 NFT 等資產來說，更為穩定。
在大多數 DeFi 借貸協議中，你的抵押貸款資產必須比你貸款的價值更有價值，也就是所謂的過度抵押。
如果借貸協議想要保持財務穩定，只允許過度抵押的貸款是有利的。想象一下，你提供了一些資產作為抵押品，而這些資產的價值突然低於你從協議中借到的資產價值。現在，你的抵押品價值低於你欠協議的債務，你就沒有還款的動力。畢竟，在償還貸款的過程中，你將獲救的抵押品現在的價值低於實際償還貸款所需的金額。這種貸款現在已經無力償還。
每筆無力償還的貸款對其所在的協議都是有害的。從無力償還的貸款中產生的債務會在協議中產生不安全因素，畢竟，債務的數量是借出者無法從協議中收回的資產的數量。為了強調這些壞賬有多糟糕：如果在協議上出現了類似傳統金融「銀行擠兌」的情況，最後一批從協議中提取他們的資產的使用者將無法這樣做。
當然，那些有大量壞賬的協議對使用者的吸引力較小。
清算和清算閾值
我們已經確定，當貸款抵押品價值低於借款人帶利息的債務價值時（也稱為低於抵押），借款人的債務會對其所在的借貸協議的健康狀況構成威脅。為了防止低於抵押的持倉增加，協議允許第三方（不一定是協議的使用者）償還低於抵押（或接近低於抵押）的債務。透過償還低於抵押的債務，這些被稱為清算人的第三方有權以折扣的價格要求歸還其被覆蓋的債務人的抵押品。這個過程被稱為清算。
你可能會想知道：為什麼協議要依賴第三方來清算不健康的持倉？畢竟，協議可以將自動清算機制編碼進其程式碼中。
傳送清算交易的成本非常高。如果協議自動傳送這些昂貴的交易，resulting gas costs 將會增加其運營成本，從而削弱其利潤。
此外，自動清算系統的設計非常困難。協議不僅必須考慮是否應自動清算一個持倉，而且必須考慮何時這樣做，並以反映市場波動率的速率進行清算。透過激勵專門的第三方來清算這些持倉，這個過程要簡單得多。
清算本質上不是有利可圖的——對於這個過程來說，債務人的抵押品必須價值高於他們欠債的金額。如果清算人沒有保證這個過程會有利可圖，他們不會清算一個持倉。
那麼何時一個持倉才能被清算？這個條件由協議決定，是分配給每個資產的清算閾值的函式。
在清算閾值方面，時間非常重要。正如我們所知道的那樣，如果一個持倉的債務價值超過其抵押價值，清算這些持倉對清算人來說是不賺錢的，協議也會面臨壞賬。因此，安全的清算閾值為清算人提供足夠的時間，在持倉達到無法償還的狀態之前清算它們。
現在我們理解了每個參與方保持持倉健康的動機，我們將展示協議實際如何實現這些機制：
我們在這裡看到，該函式的主邏輯被限定在一個 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 方程式的點：
以及從 bark() 中的類似片段：
你可能會注意到兩者具有相同的 not-unsafe 訊息。因此，對於每個清算函式，Vault 的安全要求都相同，並且可以用以下等式表示：
我們可以使用這個等式來定義一個不等式，以便 Vault（Maker 用於頭寸的名稱）仍然是安全的：
最佳化一下：
我們建議我們的讀者前往 MakerDAO 術語表，擴充套件我們提供的有關 Maker 生態系統中不同變數名稱和術語的資訊。
或者，你可以相信我們在此概述的內容：
• spot_{ilk} 在這個不等式中用作抵押品的價格，以 DAI 計價，除以抵押品的清算比率（由治理決定）
• ink_{urn} 是頭寸的抵押品餘額
• rate_{ilk} 是特定抵押品型別的累計債務。當與 art_{urn} 相乘，這是一個頭寸借入的標準化債務金額，我們可以得到以 DAI 計價的總債務
為了簡化我們剛剛涵蓋的內容，不使用 Maker 術語，我們將這樣表示：
注意：Maker 決定將抵押品和債務的價值計價為 DAI——協議的穩定幣。
顯然，當使用者沒有債務時，他們的頭寸無法被清算，因此健康因子預設為 type(uint 256).max。
否則，健康因子被定義為：
當清算閾值由治理獨立定義，目前由 Gauntlet 代表提供協議的所有風險引數，包括 LiquidationThresholds。
現在讓我們分解上面的內容，來看看這個頭寸的情況有多糟糕：
· 總欠債 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 倍。
這些清算人在價格下跌到無法獲利的程度之前無法及時清算完整個頭寸，我們留下了一個破產的頭寸。
現在，我們可以意識到有效的流動性閾值在防止協議產生壞賬方面的重要性。
