Ethereum에서 차용: MakerDAO, Yield, Aave,Compound 및 Euler의 아키텍처 발전 비교

대출은 이더리움 기반 블록체인 애플리케이션의 초석입니다 . 와 함께 수십억 달러의 자산을 대출받았습니다. , 차용이 어떻게 작동하는지 이해하는 것은 개발자, 건축가 또는 연구원에게 중요합니다.

프로그래밍 패러다임의 진화와 마찬가지로 이러한 DeFi 애플리케이션은 보안에서 효율성 및 사용자 경험에 이르기까지 변화하는 우선순위를 반영하는 다양한 아키텍처 설계를 가지고 있습니다.

이 분석에서는 다음과 같은 애플리케이션의 아키텍처를 살펴봅니다. 메이커다오 , 화합물 , 아베 , 오일러 , 그리고 생산하다 . 미래 대출 애플리케이션 개발에 중요한 교훈이 되는 주요 혁신과 디자인 패턴을 강조하겠습니다.

개발자, 설계자 또는 보안 연구원이라면 이 문서가 도움이 될 것입니다. 결국 여러분은 Ethereum의 새로운 대출 애플리케이션을 쉽게 이해하고 해당 아키텍처를 신속하고 포괄적으로 파악하게 될 것입니다. 이러한 DeFi 거대 기업이 처음부터 어떻게 구축되었는지 살펴보세요.

DeFi에서 대출

대부분의 DeFi 대출은 과잉담보된 . 사용자는 대출금 이상의 가치를 담보로 제공하면 특정 자산을 빌릴 수 있습니다. 기존 대출과 달리 이러한 대출 중 다수에는 정기적인 상환이나 고정 종료 날짜가 없습니다. 본질적으로, 빌릴 수는 있지만 결코 갚을 수는 없습니다.

그러나 문제가 있습니다.

담보 가치는 항상 미리 정해진 마진만큼 대출 가치를 초과해야 합니다 .

담보가치가 이보다 낮을 경우 대출은 청산된 .

청산 중에 다른 사람이 대출금의 일부 또는 전부를 상환하고 그 대가로 담보의 일부 또는 전부를 받습니다.

이 재무 구조를 따르는 모든 차용 애플리케이션에는 동일한 구성 요소가 필요하며, 이는 다양한 방법으로 배열될 수 있습니다.

• 사용자 담보 및 차용 자산을 보관하는 재무부
• 각 사용자의 담보 및 부채를 추적하는 회계 시스템
• 차용자의 이자율을 결정하는 기능
• 일반적으로 외부 가격 오라클을 포함하여 대출이 충분히 담보되어 있는지 확인하는 메커니즘
• 과소담보 대출에 대한 청산 경로
• 총 차용 금액과 글로벌 및 사용자별 차입 한도, 최소 담보 금액, 특정 초과 담보 비율 등 기타 안전 지표를 기록하는 위험 관리 시스템
• 사용자가 담보를 추가 및 제거하고, 차용 및 상환할 수 있는 인터페이스
  

대출과 대출은 별개의 기능으로 생각될 수 있습니다. DeFi에서는 대부분의 대출 애플리케이션에서 두 기능을 모두 찾을 수 있지만 항상 잘 통합되어 있는 것은 아닙니다 .

컴파운드, 에이브(Aave), 오일러(Euler)에서는 . 대출자와 대출자의 이자율은 내부적으로 상관관계가 있습니다. 사실, 이것이 바로 해당 애플리케이션이 최소한의 개입으로 작동하게 만드는 이유입니다.

반면에 MakerDAO와 Yield는 차용자에게 빌려주는 자산의 창시자입니다.

다른 사용자가 빌릴 수 있도록 사용자에게 자산을 제공하도록 요구하지 않습니다 .

이 기사에서는 온체인 차용에 중점을 두고 대출은 대부분 무시할 것입니다. 차용은 담보 요건으로 인해 훨씬 더 복잡하며, 차용 패턴을 이해하면 일반적으로 전체 프로토콜을 더 잘 이해할 수 있습니다.

MakerDAO의 아키텍처 진화

메이커다오 , 이더리움 용어로 고대, 2019년 11월 현재의 형태로 출시되었으며 , 그리고 그것은 유지 담보 49억 5천만 달러 . 모든 기능과 고유한 용어에 대한 고유한 계약을 갖춘 모듈식 아키텍처에도 불구하고 여전히 이해하고 검증하기 쉽습니다.

MakerDAO의 재무 기능은 다음에 의해 관리됩니다. 가입하다 계약.

이있다 별도 계약 담보 자산으로 승인된 각 토큰에 대해.

반면, MakerDAO는 차용 자산인 DAI를 보유하고 있지 않습니다.

대신에 그것은 단지 DAI를 민트로 만들고 태우다 필요에 따라.

회계는 내부에서 처리됩니다. 부가세 .sol 계약. 조인 이 계약을 업데이트하세요 담보가 시스템에 들어오거나 나갈 때. 이용자가 대출을 하면, vat.sol 계약과 직접 상호작용 .

이 작업을 통해 사용자의 부채 잔액이 업데이트되고 DAI 조인 시 DAI를 발행할 수 있습니다.

상환하기 위해 사용자는 DAI Join에서 DAI를 소각합니다. 그런 다음 이 프로세스는 Vat를 업데이트하여 사용자가 대출금을 정산할 수 있도록 합니다 .

또한, vat.sol 계약은 위기 관리 엔진. 글로벌 차입 한도를 유지하고, 사용자당 최소 한도를 설정하고, 담보 비율을 감독합니다.

사용자의 부채나 담보 잔액이 변경되면 vat.sol 계약은 이율과 현물을 모두 평가합니다.

이는 사용된 담보와 일반적인 DAI 대 담보 가격 비율을 기준으로 한 이자율을 나타냅니다. 흥미롭게도 이러한 값은 대부분의 다른 응용 프로그램과 다른 방법인 다른 MakerDAO 계약에 의해 vat.sol 계약에 입력됩니다.

MakerDAO는 설계 단계에서 안전을 최우선으로 생각했습니다. 당시에는 가스 비용과 같은 요소가 부차적 이었고 사용자 경험은 사소한 관심사였으며 경쟁은 미미했습니다.

결과적으로 기발하고 사용 비용이 많이 들고 탐색하기 어려워 보일 수 있습니다.

그러나 회사가 관리하는 방대한 자산과 심각한 위반이 없는 운영 기록은 회사의 강력한 설계와 실행을 강조합니다.

하이라이트:

• 각 자산은 최대로 분산된 재무 기능에서 자체 계약을 갖습니다.
• 회계 기능은 담보 확인을 포함하여 위험 매개변수를 문서화하고 시행하는 단일 계약 내에서 중앙 집중화됩니다.
• 다른 앱과 달리 오라클은 계약을 업데이트하여 담보를 감독합니다.
• 가격 및 이자율 오라클은 별도의 인터페이스를 활용합니다.
• 이자율은 외부에서 발생합니다.
• 대출을 받으려면 사용자는 여러 계약과 상호 작용해야 합니다.

Yield 프로토콜의 구조적 진화

수율 v1 다음을 사용하여 고정 금리에 대한 개념 증명으로 사용되었습니다. 수확량 공간 . 이 버전은 MakerDAO 위에 담보부 부채 엔진을 구축했습니다. 그러나 Yield v1은 사용 비용이 많이 들고 새로운 기능을 추가하기가 어려웠습니다.

YieldSpace의 잠재력을 인식하고 우리는 빠르게 개발 단계로 전환했습니다. 수확량 v2 . 여전히 MakerDAO에서 영감을 얻고 있지만 이제는 완전히 독립적인 Yield v2 2021년 10월 출시 ; Yield v2는 가스 비용 절감과 사용자 경험 향상을 우선시했습니다.

모든 회계, 위험 관리 및 담보 확인이 하나의 계약으로 통합되었습니다. 가마솥 . MakerDAO의 접근 방식을 미러링하여 재무 기능을 전체에 분산했습니다. 가입하다 각각 특정 자산에 전념하는 계약입니다.

우리는 오라클 통합을 개선하여 가격 및 이자율 오라클을 통합했습니다. 공통 인터페이스 . 우리는 Cauldron이 되도록 MakerDAO의 오라클 흐름을 역전시켰습니다. 신탁에 문의하다 담보 확인에 필요한 경우. 내가 아는 바로는 이것이 MakerDAO를 제외한 모든 곳에서 선호되는 흐름입니다.

MakerDAO의 접근 방식에서 또 다른 중요한 차이점은 국자 . 본 계약은 사용자와 Yield 사이의 유일한 중개자 역할을 합니다. 재무 및 회계에 대한 광범위한 제어권을 행사 하지만 그 대가로 기능 개발에 엄청난 유연성을 제공합니다 .

요약하면 Yield v2의 차용은 다음과 같이 작동합니다.

• 각 자산에는 자체 전용 재무 계약이 있어 재무 기능의 최대 분배를 보장합니다.
• 단일 계약은 회계 기능을 중앙 집중화합니다. 이 계약은 또한 위험 관리 조치를 감독하고 담보 확인을 수행합니다.
• 담보 기능은 오라클과 협의하여 가격과 이자율을 결정합니다.
• 가격 및 이자율 오라클은 모두 통합된 인터페이스를 공유합니다.
• 이자율은 외부에서 생성됩니다.
• 사용자는 단 하나의 계약에 대해 단일 요청만으로 대출을 받을 수 있습니다.

복합금융의 구조적 진화

그만큼 컴파운드의 첫 번째 버전 했다 개념의 증거 , 이더리움에 화폐 시장이 설립될 수 있음을 보여줍니다. 이러한 이유로 디자인에서는 단순성을 최우선으로 생각했습니다. 그만큼 머니마켓.sol 계약은 대출을 포함한 모든 기능을 요약합니다.

• 재무, 회계, 담보 확인 등의 위험 관리 업무가 하나의 계약으로 통합됩니다.
• 이 계약은 오라클에서 가격을 검색하지만 자산 활용도에 따라 이자율을 결정합니다.
• 사용자는 이 계약과만 상호 작용하지만 담보 제공 및 자산 차용을 위해 별도의 호출을 수행해야 합니다.

복합 v2

2019년 5월 컴파운드 v2 출시 , 이자 농사 시대를 촉발하고 수많은 포크에 영감을 불어넣었습니다. 이는 사용자가 자산을 빌려주고 빌릴 수 있는 화폐 시장의 역할도 했습니다.

그것을 바탕으로 백지 그리고 구조를 보면, 복합 v2 을 사용하는 것이었다 대출 포지션을 나타내는 ERC20 표준 . 이를 통해 구성 가능성이 보장되어 사용자가 컴파운드에 빌려준 다음 다른 블록체인 애플리케이션에서 이자가 발생하는 위치를 사용할 수 있습니다.

흥미롭게도 백서에는 컴파운드 v2가 통합되었다는 점을 강조하지 않았습니다. 보상 스마트 계약에 포함됩니다. 이러한 누락을 감안할 때 이 기능의 엄청난 영향은 예상되지 않았을 수 있습니다.

• 각 자산에는 자체 재무 계약이 있어 재무 기능의 분배가 극대화됩니다.
• 회계 기능도 분산되어 있으며 각 cToken은 사용자 담보 및 부채를 기록합니다.
• 단일 계약인 감사관은 담보 확인을 포함한 위험 관리 매개변수를 기록하고 시행합니다.
• 담보 확인을 담당하는 계약에서는 가격에 대해서는 오라클을, 이자율에 대해서는 cToken을 참조합니다.
• 가격 및 이자율 오라클은 다양한 인터페이스로 작동합니다.
• 이자율은 자산 활용에서 내부적으로 파생됩니다.
• 사용자는 대출을 위해 여러 계약과 상호 작용해야 합니다.

복합 v3

2022년 출시 , 복합 v3 보다 보수적인 위험 관리 전략을 채택하여 유동성을 여러 그룹으로 분리합니다. 수영장 각 차용 자산에 대해. 디자인은 또한 사용자 친화성과 가스 비용에 대한 우려를 드러냅니다.

필요한 호출 횟수가 줄어들어 개발자와 사용자 모두에게 시스템이 더욱 직관적이 되었습니다. 또한, 단일 계약 설계로 계약 간 통화를 최소화하여 가스 비용을 절감합니다. 분리된 화폐 시장은 현재 주요 보안 문제가 되고 있는 오라클 기반 공격에 대한 방어 수단입니다.

기타 관련 기능은 릴리즈 노트 포함하다:

• 완전히 개선된 위험 관리 및 청산 엔진. 이 디자인은 자금 보안을 강화하는 동시에 차용자 친화적입니다.
• 위험을 완화하기 위해 개별 담보 자산에 대해 시장 전반에 걸쳐 한도를 설정합니다.
• 이제 수입과 차입에 대한 이자율 모델은 분리되어 있으며, 거버넌스는 경제 정책을 완전히 통제합니다.

흥미롭게도, Complex v3는 단일 계약으로 각 차용 자산에 대한 모든 기능을 처리하도록 하여 컴파운드 v1의 아키텍처를 반영합니다. 기타 주목할만한 기능은 다음과 같습니다.

• 빌려준 자산만 빌릴 수 있습니다. 담보자산은 그럴 수 없습니다.
• 담보는 화합물 v3에서 수익을 창출하지 않습니다.

담보차용을 금지함으로써 담보예탁자의 안전성이 강화됩니다. 이를 통해 거버넌스 오류나 의도적인 공격으로 인해 담보가 위험에 빠질 가능성이 줄어듭니다.

제공된 담보에 대한 수익을 없애는 것은 컴파운드가 v2에서 많은 유동성을 축적한 결과일 수 있습니다. 나는 복합 v2에서 차용 한도가 사용자가 애플리케이션에 빌려준 자산보다 낮거나 그리 높지 않다는 직관을 가지고 있습니다.

v3에 대해 비슷한 수준의 유동성을 관리한다고 가정하면 담보 대출을 허용하지 않는 것이 v3의 핵심 목표 중 하나인 애플리케이션을 안전하게 만드는 것입니다.

아키텍처 관점에서 보면:

• 모든 자금 시장은 재무, 회계 및 위험 관리가 포함된 개별 계약입니다.
• 각 머니 마켓은 승인된 모든 담보 자산 토큰과 함께 차용 가능한 자산을 유지하므로 자산이 애플리케이션 전체에 분산됩니다.
• 가격 피드는 유일한 외부 입력입니다. 차입 및 대출에 대한 이자율은 내부적으로 생성됩니다.
• 공급/철수/차입/상환과 같은 기존 기능이 스마트하게 통합되었습니다. 이제 머니마켓에서 빌릴 수 있는 자산을 인출한다는 것은 차용을 의미하고, 이를 공급한다는 것은 사용자의 부채를 기반으로 한 상환 또는 대출을 의미합니다.
• 라우팅 계약이 통합되어 단일 호출로 여러 작업이 가능합니다.

Aave의 건축적 진화

아베 v1 ~였다 2019년 10월 출시 , ETHLend를 계승합니다. ETHLend의 P2P 접근 방식 대신 Aave v1은 공유 유동성 풀을 도입했습니다.

Yield v2에서와 마찬가지로 라우터 계약 비즈니스 로직도 보유했습니다. 그만큼 대출풀코어 회계, 위험 관리 및 재무 기능을 구현했습니다. 단일 계약으로 재무부를 풀링하는 것이 컴파운드 v2와의 차별화 포인트였습니다.

담보 확인을 그대로 두기로 한 결정 자신의 계약 , 라우터에서 호출되고 회계 계약이 아닌 것으로 보이지만 Aave v2는 v1 출시 후 2년 만에 출시되었으므로 목적에 적합했을 것입니다.

• LendingPoolCore 계약은 재무 및 회계를 처리합니다.
• LendingPoolDataProvider는 담보 확인을 관리하고 오라클과 상호 작용합니다.
• LendingPool은 사용자 진입점 역할을 하며 비즈니스 로직을 구현합니다.
• 대출 및 대출에 대한 이자율은 가격 피드에만 의존하여 내부적으로 결정됩니다.

아베 v2

아베 v2 ~였다 2021년 12월 출시 . Aave v1과 유사한 기능을 유지하면서도 Aave v1 및Compound v2에 비해 개선되고 간단한 아키텍처를 도입했습니다. 이번 릴리스에서 Aave는 다음도 도입했습니다. a토큰 (Compound의 cToken과 유사) vToken , 이는 토큰화된 부채를 나타냅니다.

사용이 제한되었던 Aave v1의 특정 기능은 단순화를 위해 생략되었습니다. 발생 이자의 복잡한 표현과 같은 Aave v1의 문제는 Aave v2에서 해결되었습니다.

• LendingPool 계약은 담보 확인과 같은 글로벌 회계 및 위험 관리 기능을 통합합니다. 사용자의 기본 액세스 지점 역할을 합니다.
• aToken은 담보를 의미하며 대출 포지션과 유사합니다. 사용자의 담보는 aToken 보유를 통해 반영되며 재무 기능은 모든 aToken에 분산됩니다.
• vToken은 부채 위치를 나타내는 데 사용됩니다. 사용자의 부채는 그들이 보유한 vToken으로 표시됩니다.

아베 v3

아베 v3 ~였다 2023년 1월 출시 다중 체인 지원 및 기타 기능을 갖추고 있습니다. 이러한 추가 사항은 핵심 아키텍처를 변경하지 않습니다. 이 업데이트는 또한 향상된 위험 관리 및 가스 효율성을 자랑합니다.

많은 발전에도 불구하고 이 연구의 목적에 따라 Aave v3은 Aave v2와 실질적으로 다르지 않습니다. 실제로 Aave v2의 아키텍처가 2023년에도 여전히 견고하다는 것을 시사할 수 있습니다.

오일러의 건축적 진화

오일러 ~였다 2022년 12월 출시 , 무허가 기능과 최소한의 거버넌스를 갖춘 머니 마켓을 제공하는 것을 목표로 합니다.

디자인의 특징은 다이아몬드 같은 무늬. ㅏ 단일 계약은 모든 애플리케이션의 스토리지를 보유합니다. . 이 저장소는 별도의 경로를 통해 액세스할 수 있습니다. 프록시 , 각각은 시스템의 서로 다른 개념적 요소를 관리합니다.

하나의 계약이 모든 자산, 회계 및 위험 관리 데이터를 저장하더라도 Aave v2와 유사하게 담보 및 대출을 위한 eToken과 부채를 위한 dToken이 여전히 있습니다. 그러나 이러한 토큰 계약은 단지 중앙 저장소 계약의 관점일 뿐입니다.

• 그만큼 저장 계약은 회계 변수를 관리합니다.
• 그만큼 베이스로직 계약은 재무부 역할을 합니다.
• 그만큼 위험관리자 계약은 담보 확인을 포함한 위험 관리 변수 및 기능을 감독합니다.

코드 분석에 따르면 가스 비용 최소화가 우선순위였으며 계약 간 호출이 필요 없는 모놀리식 설계로 이어졌습니다. 엄격한 테스트와 감사를 통해 보안이 보장되었습니다. 주로 프록시 계약으로 작동하는 스토리지 계약의 구현 역할을 하는 로직만 다양한 모듈에 분산되었습니다.

이 통합 디자인은 간편한 업그레이드도 지원합니다. 스토리지 변경이 필요하지 않은 경우 모듈을 신속하게 교체하여 기능을 수정하거나 도입할 수 있습니다.

Euler는 출시 후 15개월, 업그레이드 후 6개월 동안 해킹을 당해 취약점이 악용되었습니다.

나는 모놀리식 아키텍처가 자산이 고갈되는 데 영향을 미치지 않았다고 생각합니다. 오히려 코드 업데이트에 대한 감독이 부족했습니다 .

결론

MakerDAO, 컴파운드, Aave와 같은 초기 이더리움 애플리케이션은 이더리움에서 과도한 담보 대출의 가능성을 보여주었습니다. 이러한 개념 증명이 성공적으로 입증된 후에는 시장 점유율을 확보하기 위해 새로운 기능을 혼합하여 도입하는 데 초점이 옮겨졌습니다. 컴파운드와 Aave의 이후 버전에서는 특히 강세 시장 상황에서 번창한 수확량 농업, 결합성 및 공동 유동성을 도입했습니다.

중요한 발전은 컴파운드 v2에서 토큰화된 대출 포지션을 도입한 것인데, 이를 통해 이러한 포지션을 다른 애플리케이션에서 표준 자산으로 인식할 수 있게 되었습니다. Aave v2와 Euler는 토큰화된 부채 위치를 구현하여 한 단계 더 발전했으며, 그 광범위한 유용성은 여전히 논쟁의 대상입니다.

상승장에서 높은 가스 비용이 주요 관심사로 등장하여 Yield v2, Aave v2 및 Euler에서 볼 수 있듯이 사용자 경험 수정이 촉발되었습니다. 라우터 계약과 모놀리식 구현은 사용자가 거래에 발생하는 비용을 줄이는 데 도움이 되었습니다. 그러나 이로 인해 코드가 더 복잡해지고 결과적으로 더 위험해졌습니다.

컴파운드 v3은 재정적 효율성보다 안전을 우선시하는 선례를 세운 것으로 보입니다. 잠재적인 해킹으로부터 더 효과적으로 보호하기 위해 전통적인 유동성 풀 모델에서 벗어났습니다. 가스 비용이 점점 무시할 수 있게 되는 L2 네트워크의 증가는 향후 담보 대출 애플리케이션의 설계를 형성할 가능성이 높습니다.

이 글에서는 이더리움의 주요 담보 대출 애플리케이션에 대한 포괄적인 개요를 제공했습니다. 각 애플리케이션을 분석하기 위해 제가 사용한 접근 방식을 적용하면 다른 담보 대출 애플리케이션의 복잡성을 신속하게 파악할 수도 있습니다.

블록체인 차용 애플리케이션을 개발할 때 항상 자산 보관, 회계 기록 배치, 위험 및 담보 평가 방법을 고려하십시오. 이러한 고려 사항을 검토하면서 이전 애플리케이션 기록과 이 개요의 통찰력을 활용하여 결정을 내리세요.

읽어주셔서 감사합니다. 행운을 빕니다.

덕분에 칼닉스 이 기사를 검토하고 편집해 주셔서 감사합니다.