DeFi 대출 및 청산 메커니즘과 구현 원칙, 위험 및 사용 사례에 대한 심층 토론
원래 제목: "DeFi Lending Concepts Part 2: Liquidations"
원본 편집: Kxp, BlockBeats
원본 편집: Kxp, BlockBeats
첫 번째 레벨 제목
과도한 담보와 불량 부채
이전 블로그 게시물에서 프로토콜 사용자는 프로토콜에 제공하는 담보의 비율에 따라 자산을 대출하거나 빌릴 수 있다는 것을 기억할 수 있습니다. 이는 프로토콜이 부채 상환에 실패할 경우 자산(또는 동등한 가치의 다른 자산)을 복구할 수 있도록 보장해야 하기 때문에 의미가 있습니다. 이 자산 담보 프로세스는 예를 들어 오늘날 사람이 대출 상환을 위해 집이나 람보르기니를 담보로 둘 수 있는 전통적인 금융에서 시작되었습니다.
모기지는 담보 가격이 그 가치를 유지한다는 전제 조건에 의존합니다. 집이나 람보르기니의 가격은 보장되지 않지만 각각의 가치는 ERC 20이나 NFT와 같은 자산보다 상대적으로 덜 변동적이고 안정적입니다.
대부분의 DeFi 대출 프로토콜에서 담보 대출 자산은 대출 가치보다 더 가치가 있어야 하며, 이를 과잉 담보라고 합니다.
대출 프로토콜이 금융 안정성을 유지하려는 경우에만 초과 담보 대출을 허용하는 것이 유리합니다. 일부 자산을 담보로 설정했는데 해당 자산의 가치가 프로토콜에서 빌린 자산의 가치보다 갑자기 낮다고 상상해 보십시오. 이제 당신의 담보는 당신이 프로토콜에 빚진 것보다 가치가 적고, 당신은 갚을 동기가 없습니다. 결국, 대출금을 상환하는 과정에서 구제금융을 받게 될 담보는 이제 실제로 대출금을 상환하는 데 필요한 금액보다 가치가 떨어집니다. 이 대출은 현재 파산 상태입니다.
불이행된 모든 대출은 계약에 해를 끼칩니다. 부실 대출로 인해 발생하는 부채는 프로토콜에 불안정한 요소를 만듭니다. 결국 부채 금액은 대출 기관이 프로토콜에서 회수할 수 없는 자산의 양입니다. 이러한 악성 부채가 얼마나 나쁜지 강조하기 위해 프로토콜에 전통적인 금융 "뱅크런"과 같은 것이 있었다면 프로토콜에서 자산을 인출한 마지막 사용자는 그렇게 할 수 없었을 것입니다.
첫 번째 레벨 제목
청산 및 청산 임계값
우리는 대출 담보가 차용인의 이자부 부채보다 가치가 낮을 때(저담보화라고도 함) 차용인의 부채가 해당 대출 계약의 건전성을 위협한다는 사실을 확인했습니다. 담보가 부족한 자산이 증가하는 것을 방지하기 위해 프로토콜은 제3자(반드시 프로토콜 사용자는 아님)가 담보가 부족한(또는 담보가 거의 없는) 부채를 상환할 수 있도록 허용합니다. 담보 이하의 부채를 상환함으로써 청산인으로 알려진 이러한 제3자는 적용 대상 채무자의 담보를 할인된 가격으로 반환하도록 요구할 수 있습니다. 이 과정을 청산이라고 합니다.
궁금하실 수 있습니다. 프로토콜이 건강하지 않은 포지션을 청산하기 위해 제3자에게 의존하는 이유는 무엇입니까? 결국 프로토콜은 자동 청산 메커니즘을 코드에 인코딩할 수 있습니다.
청산 거래를 보내는 비용은 매우 높습니다. 프로토콜이 이러한 값비싼 트랜잭션을 자동으로 전송하면 그에 따른 가스 비용이 운영 비용을 증가시켜 수익을 약화시킵니다.
또한 자동 청산 시스템의 설계가 매우 어렵습니다. 프로토콜은 포지션이 자동으로 청산되어야 하는지 여부뿐만 아니라 언제 청산되어야 하는지, 그리고 시장 변동성을 반영하는 비율로 고려해야 합니다. 전용 제3자에게 이러한 포지션을 청산하도록 장려함으로써 프로세스가 훨씬 간단해집니다.
청산은 본질적으로 수익성이 없습니다. 이 과정에서 채무자의 담보는 빚진 금액보다 더 가치가 있어야 합니다. 청산인이 프로세스의 수익성을 보장하지 않는 경우 포지션을 청산하지 않습니다.
그렇다면 언제 포지션을 청산할 수 있습니까? 이 조건은 프로토콜에 의해 결정되며 각 자산에 할당된 청산 임계값의 함수입니다.
청산 임계값에 관해서는 타이밍이 매우 중요합니다. 아시다시피, 포지션의 부채 가치가 담보 가치를 초과하면 이러한 포지션을 청산하는 것은 청산인에게 이익이 되지 않으며 프로토콜도 불량 부채에 직면하게 됩니다. 따라서 안전한 청산 임계값은 청산인이 파산 상태에 도달하기 전에 포지션을 청산할 수 있는 충분한 시간을 제공합니다.
첫 번째 레벨 제목
복합: 계정 유동성
Compound에는 AccountLiquidity라는 매개 변수가 포함되며, 이는 Compound의 주 계약인 Comptroller에서 청산 임계값을 계산합니다.
Comptroller에는 계정의 유동성에 대한 정보를 반환하는 getAccountLiquidity()라는 함수가 있습니다. 내부적으로 이 함수는 getHypotheticalAccountLiquidityInternal()을 호출합니다.
여기에서 함수의 주요 논리가 for 루프 내에서 범위가 지정되었음을 알 수 있습니다. 이것은 컴퓨팅 계정 유동성이 계정이 참여하는 모든 시장을 반복하여 수행됨을 보여줍니다. 즉, 계정 유동성을 계산할 때 사용자가 차입했거나 담보로 사용한 모든 자산이 고려됩니다.
이전 블로그 게시물에서 cTokenBalance는 사용자가 담보로 제공하는 기본 자산의 양임을 기억하십시오. 이 예에서 우리는 getAccountSnapshot()에서 반환된 빌린 균형과 신비한 exchangeRateMantissa도 볼 수 있습니다.
이전 블로그 게시물에서 논의된 일반화된 exchangeRate 변수에서 다음과 같이 작성했습니다.
"임의의 이자율은 발행되는 토큰 수를 증가시킬 수 있습니다. exchangeRate < 1이면 토큰 수를 줄일 수 있습니다. exchangeRate > 1이면 토큰 수를 늘릴 수 있습니다."
이는 cToken과 기본 자산 간의 환율을 나타내는 exchangeRateMantissa에도 적용됩니다.
이 예에서 볼 수 있듯이 위에서 언급한 세 가지 매개변수를 얻은 후 감사관은 먼저 현재 반복되는 특정 시장의 collateralFactor를 얻습니다. 이 collateralFactor 정보는 사용자가 담보에 대해 빌릴 수 있는 금액을 나타내는 지표입니다. 이 정의에서 우리는 각 담보예금이 다른 차입금액으로 담보될 수 있다고 가정할 수 있습니다.
이 금액이 자산마다 다른 이유는 주로 각 자산이 프로토콜의 관점에서 고유한 "위험"을 수반하기 때문이며, 일반적으로 자산의 가치가 시간이 지남에 따라 변동하는 정도를 나타냅니다.
컴파운드의 거버넌스는 시장 상황에 따라 담보 계수를 변경하지만, 어느 시점에서든 담보 계수는 0.9를 초과할 수 없습니다. 예치한 담보의 최대 90%를 빌려줄 수 있습니다.
그런 다음 Oracle이라는 외부 계약을 호출하는 oracle.getUnderlyingPrice(asset)에 대한 호출을 봅니다.
Oracle은 전용 블로그 게시물이 필요한 흥미로운 메커니즘입니다(계속 지켜봐 주십시오). 간결함을 위해 지금 설명하는 것은 오라클이 일반적으로 프로토콜에서 사용하는 일부 공개 통화(일반적으로 USD, ETH 또는 스테이블 코인)로 대출 프로토콜에서 자산 가격을 얻는 데 사용되는 계약이라는 것입니다. 프로토콜에서 사용)을 기반으로 합니다.
이제 개별 시장의 건전성에 영향을 미치는 모든 요소를 다루었으므로 개별 시장에 대한 AccountLiquidity를 계산하는 방정식을 작성할 것입니다.
참고: Compound에서 자산 가격은 미국 달러(USD)로 표시됩니다.
꽤 긴 변수 목록이지만 "Share Token" 기사의 복합 섹션을 기억하려고 하면 다음 표현식을 찾을 수 있습니다.
단순히 사용자의 cToken의 기본 자산 가치를 나타냅니다.
또한, 여기에서 볼 수 있듯이 borrowBalance_{user} 변수는 발생한 이자를 포함하여 사용자가 빌린 자산의 총 잔액입니다.
첫 번째 레벨 제목
Maker
담보가 부족한 포지션을 청산하기 위한 임계값을 설정하는 또 다른 프로토콜은 Maker입니다.
청산을 처리하기 위해 프로토콜이 배포하는 두 가지 계약을 살펴보겠습니다.
개: 청산 2.0(메이커 거버넌스에서 부르는 것)으로 마이그레이션한 후 배포되었습니다. 여기서 청산 기능은 bark()입니다.
· Cat：liquidations 1.2 ，bite()。
grab(): cat 계약이 전개되기 전에 청산 방법으로 사용되는 VAT 계약.
bite()의 스니펫을 살펴보겠습니다.
및 bark()의 유사한 스니펫:
둘 다 동일한 안전하지 않음 메시지가 있음을 알 수 있습니다. 따라서 Vault의 보안 요구 사항은 각 청산 기능에 대해 동일하며 다음 방정식으로 표현할 수 있습니다.
이 방정식을 사용하여 Vault(메이커가 위치에 사용하는 이름)가 여전히 안전하도록 불평등을 정의할 수 있습니다.
최적화:
Maker 생태계에서 다양한 변수 이름과 용어에 대해 제공하는 정보를 확장하려면 독자들이 MakerDAO Glossary로 이동하는 것이 좋습니다.
또는 여기에 설명된 내용을 신뢰할 수 있습니다.
• 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에서 이 사용자가 수행한 가장 최근 작업을 살펴볼 수 있습니다.
사용자가 AAVE에서 일부 자산을 빌려준 블록 13514857까지는 모든 것이 괜찮아 보였습니다. 그들이 무엇을 하는지 보자:
채무자는 700,000 MANA를 빌렸으며, MANA의 USD 가격을 간략히 살펴보면 가격이 다음과 같음을 알 수 있습니다.
MANA 단위당 0.00032838 ETH.
간단한 곱셈을 통해 이 사용자가 프로토콜 부채를 0.00032838 * 700000 = 229.866 ETH 만큼 늘렸다는 것을 알 수 있습니다.
해당 블록의 USD 가격은 $4417.40입니다.
빌린 후 몇 시간 후에 블록 13517657에서 위 이미지에서 발생한 입금 작업에 유의하십시오. 시장에서 어떤 것이 사용자의 신뢰를 흔들었는지 살펴보겠습니다.
위는 지정된 블록의 1 MANA 단위에 대한 wei 값을 얻기 위해 AAVE V2 가격 오라클로 전송된 RPC 호출입니다.
이 데이터를 사용하여 위의 가격을 변환하면 어떤 일이 발생하는지 확인할 수 있습니다.
0.00033625 * 700000 = 235.375 ETH
불과 몇 시간 만에 부채가 5.5ETH 증가하여 $24,000에 달했습니다.
우리는 이 포지션에 대한 이야기의 끝을 알고 있기 때문에 어느 시점에서 청산 가능하다는 것을 알고 있으므로 이 사용자 주소와 관련된 liquidationCall이 있는지 확인합시다.
첫 번째 청산 이벤트를 찾으면 사용자가 대출 직후 자산을 예치하는 이유를 이해할 수 있습니다.
여기에서 첫 번째 청산이 블록 13520838에서 발생한 것을 볼 수 있습니다. 이 청산은 사용자가 자금을 입금하기 전에 발생합니다(입금 거래 ~7분 전).
그런 다음 블록 13520838-13522070 사이에 일련의 작은 청산이 있었고 결국 상당한 가치가 있었습니다.
다음 블록 사이에서 사용자로부터 청산인이 압류한 모든 담보 자산 유형을 살펴보겠습니다.
자산은 DAI(stablecoin)와 ETH 2개뿐임을 알 수 있습니다.
그리고 그들의 수:
~ 50 ETH
~ 387663 DAI
청산이 왜 그렇게 작은 단위로 나누어져 있는지 물을 수도 있습니다.
이와 같은 대규모 포지션이 한 번에 청산되면 시장은 그러한 대규모 담보 인수를 이러한 자산 유형에 대한 매도 신호로 해석합니다. 참고: 청산으로 획득한 자산은 프로토콜의 청산 보상 정책에 따라 할인된 가격으로 구매됩니다.
대규모 청산은 일련의 청산을 촉발하고 매도 압력이 커지면 다른 시장 참가자도 자산을 매도하여 자산 가격의 추가 "폭락"을 일으켜 프로토콜의 다른 포지션의 더 많은 청산으로 이어집니다.
따라서 프로토콜은 일반적으로 단일 청산으로 압류할 수 있는 자산의 양을 제한합니다. 변수로서 AAVE 버전의 이러한 제한은 다음과 같습니다.
보시다시피 한도 비율은 50%이며, 이는 한 번의 청산으로 포지션 부채의 절반만 상환할 수 있음을 의미합니다.
청산인은 청산을 더 작은 청크로 나눌 인센티브가 있습니다. 청산 시점에 담보 자산을 제공할 수 있는 시장의 유동성이 충분하지 않은 경우 청산을 더 작은 단위로 분할하여 청산인은 청산 자산과 청산으로부터 이익을 얻을 가능성이 더 큽니다.
또한 시장에 부채 자산을 취득할 유동성이 충분하지 않은 경우 청산인이 처음에 담보가 부족한 사용자에게 상환해야 하는 부채를 취득하는 데 많은 비용이 들 수 있습니다.
마지막으로, 많은 양의 토큰을 소유하지 않고 많은 양의 토큰을 청산하려고 한다고 상상해 보십시오. DEX에 가서 이 토큰을 얻기 위해 일부 WETH 또는 다른 자산을 교환하려고 하면 매우 높은 가스 수수료가 발생할 수 있으며 이로 인해 청산이 수익성이 없게 됩니다.
예제로 돌아가서 체인에서 일련의 청산 후 포지션 매개변수를 확인하려면 getUserAccountData에서 반환된 데이터를 구문 분석해야 합니다.
그런 다음 캐스트를 사용하여 체인을 쿼리합니다.
최종 구문 분석 결과:
여기에서 청산이 포지션에 미치는 영향을 볼 수 있습니다. 남은 담보가 거의 없으며 정확히 0.6 ETH입니다. 그러나 부채는 어떻습니까? 최대 45.26716296709878 ETH.
이 블록의 MANA 가격은 얼마입니까?
0.000862110734985458 ETH。
당신이 기억한다면, 우리 사용자는 불과 몇 시간 전에 0.00032838 ETH에 MANA를 빌렸습니다. 이는 가격이 2.65배 상승한 주식에 대해 숏포지션을 여는 것과 같습니다.
이 청산인들은 가격이 수익성 없는 수준으로 떨어지기 전에 전체 포지션을 청산할 수 없었고 우리는 파산 포지션에 남게 되었습니다.
요약하다
요약하다
포지션에 대한 유동성 임계값을 정의하는 방정식이 있는지 확신할 수는 없지만 프로토콜 간의 유사점은 확실히 볼 수 있습니다.
모든 프로토콜은 임계값을 일종의 담보 대 부채(비율 또는 차이)의 함수로 정의합니다.
모든 프로토콜은 일부 자산이 다른 자산보다 변동성이 높기 때문에 변화하는 시장 상황에 따라 각 담보 위험 매개변수의 가치를 결정할 수 있는 거버넌스의 여지를 남겨 둡니다.
모든 프로토콜은 오라클을 사용하여 널리 통용되는 통화(예: ETH, USD, DAI)로 담보 및 부채의 가격을 책정합니다.
원본 링크
