Hello. I design and build blockchain solutions. I like to make the complex simple.
Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.
This story contains new, firsthand information uncovered by the writer.
The writer was physically present in relevant location(s) to this story. The location is also a prevalent aspect of this story be it news or otherwise.
대출은 이더리움 기반 블록체인 애플리케이션의 초석입니다 . 와 함께
프로그래밍 패러다임의 진화와 마찬가지로 이러한 DeFi 애플리케이션은 보안에서 효율성 및 사용자 경험에 이르기까지 변화하는 우선순위를 반영하는 다양한 아키텍처 설계를 가지고 있습니다.
이 분석에서는 다음과 같은 애플리케이션의 아키텍처를 살펴봅니다.
개발자, 설계자 또는 보안 연구원이라면 이 문서가 도움이 될 것입니다. 결국 여러분은 Ethereum의 새로운 대출 애플리케이션을 쉽게 이해하고 해당 아키텍처를 신속하고 포괄적으로 파악하게 될 것입니다. 이러한 DeFi 거대 기업이 처음부터 어떻게 구축되었는지 살펴보세요.
대부분의 DeFi 대출은
그러나 문제가 있습니다.
담보 가치는 항상 미리 정해진 마진만큼 대출 가치를 초과해야 합니다 .
담보가치가 이보다 낮을 경우 대출은
청산 중에 다른 사람이 대출금의 일부 또는 전부를 상환하고 그 대가로 담보의 일부 또는 전부를 받습니다.
이 재무 구조를 따르는 모든 차용 애플리케이션에는 동일한 구성 요소가 필요하며, 이는 다양한 방법으로 배열될 수 있습니다.
MakerDAO의 대출 프로세스. 모든 애플리케이션은 동일한 단계와 기능을 공유합니다.
대출과 대출은 별개의 기능으로 생각될 수 있습니다. DeFi에서는 대부분의 대출 애플리케이션에서 두 기능을 모두 찾을 수 있지만 항상 잘 통합되어 있는 것은 아닙니다 .
컴파운드, 에이브(Aave), 오일러(Euler)에서는 . 대출자와 대출자의 이자율은 내부적으로 상관관계가 있습니다. 사실, 이것이 바로 해당 애플리케이션이 최소한의 개입으로 작동하게 만드는 이유입니다.
반면에 MakerDAO와 Yield는 차용자에게 빌려주는 자산의 창시자입니다.
다른 사용자가 빌릴 수 있도록 사용자에게 자산을 제공하도록 요구하지 않습니다 .
이 기사에서는 온체인 차용에 중점을 두고 대출은 대부분 무시할 것입니다. 차용은 담보 요건으로 인해 훨씬 더 복잡하며, 차용 패턴을 이해하면 일반적으로 전체 프로토콜을 더 잘 이해할 수 있습니다.
메이커DAO 로고
MakerDAO의 재무 기능은 다음에 의해 관리됩니다.
이있다
반면, MakerDAO는 차용 자산인 DAI를 보유하고 있지 않습니다.
대신에 그것은 단지
회계는 내부에서 처리됩니다.
이 작업을 통해 사용자의 부채 잔액이 업데이트되고 DAI 조인 시 DAI를 발행할 수 있습니다.
상환하기 위해 사용자는 DAI Join에서 DAI를 소각합니다. 그런 다음 이 프로세스는 Vat를 업데이트하여 사용자가 대출금을 정산할 수 있도록 합니다 .
또한, vat.sol
계약은
사용자의 부채나 담보 잔액이 변경되면 vat.sol 계약은 이율과 현물을 모두 평가합니다.
이는 사용된 담보와 일반적인 DAI 대 담보 가격 비율을 기준으로 한 이자율을 나타냅니다. 흥미롭게도 이러한 값은 대부분의 다른 응용 프로그램과 다른 방법인 다른 MakerDAO 계약에 의해 vat.sol 계약에 입력됩니다.
MakerDAO는 설계 단계에서 안전을 최우선으로 생각했습니다. 당시에는 가스 비용과 같은 요소가 부차적 이었고 사용자 경험은 사소한 관심사였으며 경쟁은 미미했습니다.
결과적으로 기발하고 사용 비용이 많이 들고 탐색하기 어려워 보일 수 있습니다.
그러나 회사가 관리하는 방대한 자산과 심각한 위반이 없는 운영 기록은 회사의 강력한 설계와 실행을 강조합니다.
하이라이트:
YieldSpace의 잠재력을 인식하고 우리는 빠르게 개발 단계로 전환했습니다.
MakerDAO의 영향을 많이 받은 Yield v2의 대출 프로세스
모든 회계, 위험 관리 및 담보 확인이 하나의 계약으로 통합되었습니다.
우리는 오라클 통합을 개선하여 가격 및 이자율 오라클을 통합했습니다.
MakerDAO의 접근 방식에서 또 다른 중요한 차이점은
요약하면 Yield v2의 차용은 다음과 같이 작동합니다.
그만큼
컴파운드 v1의 차용 프로세스. 간단하면서도 효과적입니다.
그것을 바탕으로
흥미롭게도 백서에는 컴파운드 v2가 통합되었다는 점을 강조하지 않았습니다.
컴파운드 v2의 차용 프로세스. 토큰화된 대출 포지션에 대한 첫 번째 진출.
컴파운드 v3(Comet)의 차용 프로세스. 기본으로 돌아가, 안전으로 돌아가세요. 하지만 더 나은 UX가 있습니다.
필요한 호출 횟수가 줄어들어 개발자와 사용자 모두에게 시스템이 더욱 직관적이 되었습니다. 또한, 단일 계약 설계로 계약 간 통화를 최소화하여 가스 비용을 절감합니다. 분리된 화폐 시장은 현재 주요 보안 문제가 되고 있는 오라클 기반 공격에 대한 방어 수단입니다.
기타 관련 기능은
흥미롭게도, Complex v3는 단일 계약으로 각 차용 자산에 대한 모든 기능을 처리하도록 하여 컴파운드 v1의 아키텍처를 반영합니다. 기타 주목할만한 기능은 다음과 같습니다.
담보차용을 금지함으로써 담보예탁자의 안전성이 강화됩니다. 이를 통해 거버넌스 오류나 의도적인 공격으로 인해 담보가 위험에 빠질 가능성이 줄어듭니다.
제공된 담보에 대한 수익을 없애는 것은 컴파운드가 v2에서 많은 유동성을 축적한 결과일 수 있습니다. 나는 복합 v2에서 차용 한도가 사용자가 애플리케이션에 빌려준 자산보다 낮거나 그리 높지 않다는 직관을 가지고 있습니다.
v3에 대해 비슷한 수준의 유동성을 관리한다고 가정하면 담보 대출을 허용하지 않는 것이 v3의 핵심 목표 중 하나인 애플리케이션을 안전하게 만드는 것입니다.
아키텍처 관점에서 보면:
Aave v1의 대출 프로세스. 풀링된 유동성은 재무 및 계산 효율성을 의미했습니다.
Yield v2에서와 마찬가지로
담보 확인을 그대로 두기로 한 결정
Aave v2는 완전히 토큰화된 매우 깔끔한 아키텍처를 가지고 있습니다.
사용이 제한되었던 Aave v1의 특정 기능은 단순화를 위해 생략되었습니다. 발생 이자의 복잡한 표현과 같은 Aave v1의 문제는 Aave v2에서 해결되었습니다.
많은 발전에도 불구하고 이 연구의 목적에 따라 Aave v3은 Aave v2와 실질적으로 다르지 않습니다. 실제로 Aave v2의 아키텍처가 2023년에도 여전히 견고하다는 것을 시사할 수 있습니다.
디자인의 특징은
하나의 계약이 모든 자산, 회계 및 위험 관리 데이터를 저장하더라도 Aave v2와 유사하게 담보 및 대출을 위한 eToken과 부채를 위한 dToken이 여전히 있습니다. 그러나 이러한 토큰 계약은 단지 중앙 저장소 계약의 관점일 뿐입니다.
코드 분석에 따르면 가스 비용 최소화가 우선순위였으며 계약 간 호출이 필요 없는 모놀리식 설계로 이어졌습니다. 엄격한 테스트와 감사를 통해 보안이 보장되었습니다. 주로 프록시 계약으로 작동하는 스토리지 계약의 구현 역할을 하는 로직만 다양한 모듈에 분산되었습니다.
이 통합 디자인은 간편한 업그레이드도 지원합니다. 스토리지 변경이 필요하지 않은 경우 모듈을 신속하게 교체하여 기능을 수정하거나 도입할 수 있습니다.
Euler는 출시 후 15개월, 업그레이드 후 6개월 동안 해킹을 당해 취약점이 악용되었습니다.
나는 모놀리식 아키텍처가 자산이 고갈되는 데 영향을 미치지 않았다고 생각합니다. 오히려 코드 업데이트에 대한 감독이 부족했습니다 .
힘든 작업이 완료되었습니다. 배운 내용을 복습해 보겠습니다.
MakerDAO, 컴파운드, Aave와 같은 초기 이더리움 애플리케이션은 이더리움에서 과도한 담보 대출의 가능성을 보여주었습니다. 이러한 개념 증명이 성공적으로 입증된 후에는 시장 점유율을 확보하기 위해 새로운 기능을 혼합하여 도입하는 데 초점이 옮겨졌습니다. 컴파운드와 Aave의 이후 버전에서는 특히 강세 시장 상황에서 번창한 수확량 농업, 결합성 및 공동 유동성을 도입했습니다.
중요한 발전은 컴파운드 v2에서 토큰화된 대출 포지션을 도입한 것인데, 이를 통해 이러한 포지션을 다른 애플리케이션에서 표준 자산으로 인식할 수 있게 되었습니다. Aave v2와 Euler는 토큰화된 부채 위치를 구현하여 한 단계 더 발전했으며, 그 광범위한 유용성은 여전히 논쟁의 대상입니다.
상승장에서 높은 가스 비용이 주요 관심사로 등장하여 Yield v2, Aave v2 및 Euler에서 볼 수 있듯이 사용자 경험 수정이 촉발되었습니다. 라우터 계약과 모놀리식 구현은 사용자가 거래에 발생하는 비용을 줄이는 데 도움이 되었습니다. 그러나 이로 인해 코드가 더 복잡해지고 결과적으로 더 위험해졌습니다.
컴파운드 v3은 재정적 효율성보다 안전을 우선시하는 선례를 세운 것으로 보입니다. 잠재적인 해킹으로부터 더 효과적으로 보호하기 위해 전통적인 유동성 풀 모델에서 벗어났습니다. 가스 비용이 점점 무시할 수 있게 되는 L2 네트워크의 증가는 향후 담보 대출 애플리케이션의 설계를 형성할 가능성이 높습니다.
이 글에서는 이더리움의 주요 담보 대출 애플리케이션에 대한 포괄적인 개요를 제공했습니다. 각 애플리케이션을 분석하기 위해 제가 사용한 접근 방식을 적용하면 다른 담보 대출 애플리케이션의 복잡성을 신속하게 파악할 수도 있습니다.
블록체인 차용 애플리케이션을 개발할 때 항상 자산 보관, 회계 기록 배치, 위험 및 담보 평가 방법을 고려하십시오. 이러한 고려 사항을 검토하면서 이전 애플리케이션 기록과 이 개요의 통찰력을 활용하여 결정을 내리세요.
읽어주셔서 감사합니다. 행운을 빕니다.
덕분에
저자는 Yield Protocol의 공동 창립자이자 기술 책임자입니다.