단면이자농사, 오브스 Nexus를 통해 어떤 DEX에서든 간단하게 참여하기 — Part 3
원문 링크
오브스의 유동성 프로토콜 Nexus는 DeFi에 CeFi의 유동성을 도입시켜줍니다.
이제 SushiSwap이나 PancakeSwap같은 어떤 종류의 DEX이든 ETH/USDC나 BNB/BUSD등 인기있는 풀(pool)을 선택할 수 있습니다.
CeFi의 자본은 USDC, BUSD와 같은 스테이블 코인 측면을 제공하며, DeFi 자본은 ETH, BNB같은 암호화폐를 제공합니다. 이제 양쪽을 함께 이자농사에 참여시켜봅시다.
금고(Vault)를 통한 통상적인 양면 파밍
DeFi의 금고 개념은 연.파이낸스(Yearn.finance) 산하의 Andre Cronje에 의해 대중화되었고 각종 DeFi 커뮤니티에서 즉시 유행을 탔습니다. 아이디어는 간단합니다. 여러 유동성 공급자가 함께 유동성을 공급하면 스마트 컨트렉트가 자동으로 포지션을 관리해 주며 컴파운딩(하루의 보상을 수령하고, 판매한 뒤 최초 제공한 기초 자산을 다시 사들여 복리 이자를 수령)등의 활동을 통해 이자율을 효과적으로 상승시킵니다.
이 이후 등장한 금고 프로젝트 중 주목할 만한 프로젝트는 토큰 이코노미를 통해 아이디어를 확장한 harvest.finance입니다. harvest의 스테이킹 토큰FARM은 농사 수익의 30%를 수수료로 가져가지만, 이를 기본 이자 외의 추가 분배에 사용해 결과적으로 더 많은 사람들이 파밍에 참여해 전체적인 APY를 상승시킵니다.
이자 농사 금고 상품들은 바이낸스 스마트체인 (BSC) 에서도 큰 인기를 끌고 있으며, acryptos 와 autofarm.network 같은 프로젝트는, 이 글을 쓰는 당시 15억 달러 이상의 자산이 예치된(TVL) 선두주자들 입니다.
그렇다면 통상적인 양면 금고는 어떤 방식일까요? Uniswap/SushiSwap/1inch상의 ETH/USDC 유동성 공급 보상을 예로 들어 보겠습니다.
- DeFi (A 타입) 참여자가 ETH 과 USDC를 harvest.finance의 금고 컨트렉트에 입금합니다. 보통 참여자가 직접 LP 토큰을 입금하는 것을 선호하지만 두 가지는 서로 교환이 가능합니다.
- 금고 컨트렉트가 ETH/USDC를 SushiSwap 에 입금 하고, 그 대가로 LP 토큰을 받습니다.
- 예를 들어 SushiSwap의 Masterchef의 LP 파밍 컨트렉트로 입금된 LP 토큰은 SUSHI 보상을 생성하기 시작합니다.
- 주기적으로 금고가 SUSHI 보상을 청구하고, 다시 이 SUSHI를 ETH/USDC로 판매하고 2 번 과정을 반복 합니다.
오브스 Nexus를 통한 단면 이자 농사
해당 포스팅을 시리즈로 연재하면서 저희가 설명하고자 하는 내용은 단면 이자농사(파밍) 이며, 해당 개념을 여러분들에게 효과적으로 소개하기 위해 금고를 예시로 설명드리고자 합니다. 금고는 A 타입 참가자들이 제공한 자산이므로 보상도 A 참가자들 에게만 제공하며(이전 게시물 참조), ETH 측면만을 대표합니다.
반대쪽인, USDC는 타입 B 참가자들이 제공합니다. DeFi를 자주 활용하거나 친숙한 사용자들이 아니기에, 유동성 Nexus 프로토콜을 사용해 시장에 참여시킬 수 있습니다.
어떻게 나타낼 수 있을까보일까요?
- DeFi (A 타입) 참여자는 이더리움을 금고 컨트렉트에 입금합니다. 해당 금고는 이더리움만을 받는 새로운 금고이여야하며 harvest.finance의 기존 금고 중 하나에 기여하고 해당 거버넌스의 승인이 필요합니다.
- CeFi (B 타입) 참여자는 Nexus 컨트렉트를 통해 USDC를 Nexus 프로토콜에 입금합니다. 해당 활동이 단면 이자농사를 가능케하고 이전 글에서 설명드린 논리를 구현할 수 있게 해줍니다.
- 이더리움 금고 컨트렉트는 새로 입금된 이더리움을 Nexus 컨트렉트에서 대기중인 USDC와 매칭 시킵니다. 해당 ETH/USDC 페어는 SushiSwap같은 DEX 페어에 적용되어있는 Nexus 컨트렉트에 의해 동일한 가치 만큼 입금되며, 그 대가로 LP 토큰을 받습니다.
- 예를 들어 SushiSwap의 Masterchef의 LP 파밍 컨트렉트로 입금된 LP 토큰은 SUSHI 보상을 생성하기 시작합니다.
- 주기적으로 금고가 SUSHI 보상을 청구하고, 다시 이 SUSHI를 ETH/USDC로 판매하고 3번 과정을 반복 합니다.
희귀하며 선호되는 이더리움 단일 금고
DeFi에 참여해본 경험이 있으시다면, 이더리움 한쪽만을 가지고 진행하는 전략은 흔하지 않다는 걸 알고 계실 겁니다. 간혹 있다 하더라도, 보상율(APY)가 낮은 경우가 많습니다. 하단은 harvert.finance 상에서 현재 제공하는 이더리움 단일 금고 전략입니다.
보시는대로, 금고 자체의 APY는 0.41%에 불과합니다(나머지 보상은 FARM으로 제공되며, 참여 독려를 위한 인센티브입니다). 이 금고가 채택한 전략은 Compound에 이더리움을 담보로 제공하고 공급 이자와 COMP 보상을 두가지 다 획득하는 것입니다. 이는 역시 이더리움 만을 빌려주는 것에 대한 이자율이(APY)이 왜 상대적으로 낮은지도 설명하고 있습니다.
Nexus 프로토콜을 사용하여, 저희는 훨씬 더 높은 APY를 발생시키는 신규 ETH 단일 전략을 만들 수 있습니다. SushiSwap 상의 ETH/USDC의 양면 농사보다 훨씬 더 높은 APY가 가능합니다. 어떻게 이것이 가능할까요? 그 이유는 ETH 측면이 더 많은 비영구적 손실(IL) 리스크를 가지는 대가로, 보상도 더 많이 제공하는 토크노믹스를 가지고 있기 때문입니다.(Part 2 게시물 참조)
이 결과는 자기 상품의 사용자들에게 가장 높은 APY를 제공할 수 있는 방법을 쫒는 harvest.finance와 같은 기존 금고 프로젝트에 있어 상당히 매력적입니다.
A 타입의 DeFi 참여자에게도 매력적인데, 통상적으로 암호화폐 투자자들이 많이 보유하고 있는 이더리움이라는 자산 한개만을 필요로 하고 유동성 공급만을 위해 같은 가치만큼의 USDC를 따로 보유할 필요가 없기 때문입니다.
마지막으로, B 타입의 CeFi 참여자들에 있어서도, 암호화폐의 높은 변동성에 대한 리스크 없이, USDC만을 필요로 하면서도 동시에 일반적으로 CeFi에 기대할 수 있는 APY보다 훨씬 높은 수준을 기대할 수 있기 때문에 매력적인 상품입니다.
어느 DEX에서도 적용 가능
해당 접근방식의 또 하나의 장점은, 현재 운영 중인 DEX에서 어떤 것도 변경할 필요가 없다는 점입니다. 따라서 현재의 Uniswap, SushiSwap, 1inch, PancakeSwap 등 다양한 DEX에서 즉시 적용 가능합니다.
구현 과정
이제 아키텍처를 이해 했으므로, 구현 과정에 대해 자세히 설명 드리겠습니다. 하단 도표의 노란색 부분, 유동성 Nexus 컨트렉트의 구현입니다.
rekt 리더보드가 가르쳐준 것처럼 금고들은 매우 섬세합니다. 성공적인 금고 상품에는 수백만 달러의 가치가 저장되기 때문에 각종 조작 및 해킹의 대상이 되기도 합니다.
저희의 경험으로 미루어 볼 때 대략 두가지 유형의 악용이 있을 수 있습니다.
- 경제적 공격 — 코드 언어에 관계없이 논리적 문제에서 비롯되는 이슈들. 한 가지 악명높은 예로 harvest.finance 금고에서 250만 달러 상당의 USDC 및 USDT를 훔치기 위해 플래시 대출(Flash loan)을 사용
- 구현 공격 —컨트렉트 작성에 사용되는 특정 언어의 컴파일러 또는 가상 시스템의 구현 뉘앙스에서 비롯되는 문제로 대부분의 컨트렉트가 Solidity로 작성되기 때문에, 이미 알려진 공격 방법을 통해 시도
최근 들어 첫 번째 유형의 공격이 더 성공하는 경향이 있어 많은 구현 과정에서 종종 경제성을 간과하고 있다고 믿게 됩니다. 이에 맞서기 위해, 저희 구현의 첫 단계는 순수하게 경제 시뮬레이션 위주로 진행하려 합니다.
제1단계 — 이코노미 시뮬레이션
깃헙 저장소는 아래와 같습니다:
https://github.com/defi-org-code/single-playground
시뮬레이션이 성공하려면 어떡해야할까요? 무엇보다 먼저 시제품을 빨리 내야합니다. 시뮬레이션을 작성하는 것은 실제 제품을 내는 것보다 빠르고 쉬워야만 합니다.
자바스크립트가 떠오르는군요.
시뮬레이션을 위한 두번째 고려할 점은 우리 주변의 세상을 모델링하는 것입니다. 위 다이어그램에서 노란색 부분(유동성 넥서스 컨트랙트)을 구현해야하기 때문에 다른 부분은 전부 가상으로 구성해야합니다. 뭔가 복잡한 소리같지만 사실은 그렇지 않습니다. 스시스왑을 예로 들어볼까요? 모든 점을 확인하기 위해 진짜 스시를 똑같이 만들 필요없이 대강의 동작만 있으면 됩니다.
여기 있는 짧지만 잘 짜여진 스시네트워크의 시뮬레이션 버전을 살펴보세요 — sushi.js
시뮬레이션의 장점은 다양한 외부 공격에 대한 실험을 할 수 있는 편의도구들을 개발자들이 활용할 수 있다는 것입니다. 앞서 번개대출을 신경써야할 부분으로 말씀드렸습니다. 하지만 우리의 경우 해커는 번개대출과 관련해서 무엇을 공격하려 할까요? 스시의 ETH/USDC 풀에서 ETH 가격을 잠시동안 ETH 가격을 조작하는 방법으로 쓰일 수 있겠습니다. 번개 대출, 이와 연관된 모든 것들을 모델링하는데 몇시간을 쓰는 대신, 시뮬레이션을 활용하여 훨씬 더 간단한 작업을 수행해보도록 하겠습니다 — 공격을 위해 ETH 가격 바꾸기를 만들어 봅시다. 테스트 자동화로 공격벡터를 쉽게 모델링 할 수 있습니다.
코드저장소에서 살펴볼만한 branch를 아래 3가지가 있습니다:
- master — 고전적인 방식으로 직접적인 양면 금고 구현 (단편적 복잡성이 없는 제어부).
- crazy-idea1 — ERC20과 호환되는 금고 공유에 기반한 단편적 금고로 모든 ETH 예치자가 IL을 공유. 이 접근방식은 경제적 이득을 구하는데 개방적이며 테스트에서 볼 수 있습니다
- no-shares — ETH 예치자들 사이에 IL을 분리하는 더 나은 단편적 금고를 구현. 직접적인 방식으로 ETC20과의 호환성을 지원하지 않음 (향후 이에 대한 더 많은 내용 설명 예정)
이 시뮬레이션을 진행하면서 여러 흥미로운 것들이 있었습니다. 이에 대해서는 더 자세한 배경들을 알아야 하기 때문에 다른 별도의 포스팅으로 설명해드릴 예정입니다.
제2단계 — 솔리디티(Solidity)로 구현
깃헙 저장소는 아래와 같습니다:
https://github.com/orbs-network/nexus-sushiswap
경제성 시뮬레이션이 완료되면 1단계의 결과를 통해 경제구조에 대한 더 나은 이해와 명확한 컨트랙트 로직의 사양을 얻을 수 있습니다.
다음 단계는 이 로직을 가지고 솔리디티 언어로 구현하는 것입니다. 이 단계에서는 급하게 코드작성을 하고 싶지 않으므로 조금 느릴 수 있습니다. 상당한 비용을 관리하는 제품 코드이기 때문에 방어적인 코딩 스타일이 권장됩니다.
스시스왑의 ETH/USDC 페어같은 외부 제3의 컨트랙트에 구현된 내용을 실제 메인넷에서 사용해볼 수 있게 되므로 외부 세계와 연결하게 되면 좀 더 쉬워집니다. 더이상 가상으로 지원할 필요없이 테스트도 그냥 하면 됩니다.
이더리움 메인넷에서 직접 테스트를 하기 때문에 이 단계에서는 조금 더 검증이 번거로울 수 있습니다. 검증 시나리오는 구현하는 작업량보다 많지만, 실제 상황에서 검증함으로써 얻는 잇점이 큽니다. 실제 메인넷에 출시될 컨트랙트가 어떤식으로 나타잘지 실제품에 최대한 가깝습니다. 이는 Hardhat에서도 쉽게 사용할 수 있는 Ganache의 메인넷 포크능력 덕분에 가능합니다.
우리팀은 E2E 검증법을 선호합니다 코드가 작동함을 증명하는데는 테스트를 통과하는 것보다 좋은 방법이 없습니다. 광범위 검증 suite를 직접 살펴보세요.
아래 테스트는 지난번 연재해드린 첫번째 전략을 이용한 것을 보여드리는 것입니다. ETH 가격에 변동이 있더라도 처음 공급한 USDC와 같은 수량의 USDC를 인출해내는 모습입니다:
눈썰미가 좋으신 분들은 시뮬레이션에서처럼 구현하기가 쉽지 않기 때문에 여기서 어떻게 changeEthPrice를 처리했는지 궁금하실겁니다. 실제로 원하는 금액이 될때까지 계속해서 스왑하는 방식으로 쉬운 작업은 아닙니다 — 관련 구현내용은 여기에서 확인할 수 있습니다.
더 알아보기
넥서스 유동성 프로토콜 (Liquidity Nexus protocol)에 대한 더 자세한 내용을 하단 링크를 통해 확인해 보세요.
현재 저희가 진행 중인 업무에 대해 궁금하시다면, 언제든지 오브스의 깃허브(Github)를 통해 미발표된 작업물을 확인하실 수 있습니다.
- https://github.com/orbs-network — Orbs 프로젝트 깃허브(Github)
- https://github.com/defi-org-code — DeFi.org 엑셀러레이터 혁신 연구실 (일부 아이디어의 경우, 이곳에 먼저 올라옵니다)
참고사항
해당 문서는 현재 오브스 팀과 생태계 참여자들이 연구 중인 프로젝트에 대한 자세한 설명을 담고 있습니다. 해당 프로젝트는 오브스 팀이 구상하는 상황을 묘사하고 있습니다.
오브스는 커뮤니티 참여에 의해 주도되는 탈중앙형 프로젝트로 본 문서에 자세히 설명되어 있는 제품과 기능은 커뮤니티의 피드백으로부터 수집한 제안으로 구성되며 신규 피드백이 있을 경우 지속적으로 변경될 수 있습니다. 본 문서는 모든 제품, 제품 또는 특정 기능이 완전히 또는 부분적으로 개발된다고 보장하지 않습니다.
본 문서에 포함된 정보는 어떠한 관할권에서도 제공 또는 약속의 기초가 되거나 그와 관련하여 의존해서는 안 됩니다.
다양한 채널을 통해 ORBS와 소통해보세요!
- ORBS 홈페이지 (한글) : https://orbs.com/kr/
- ORBS GitHub : https://github.com/orbs-network
- ORBS 글로벌 텔레그램 그룹 : https://t.me/orbs_network
- ORBS 카카오톡 : https://open.kakao.com/o/giYtuTRb
- ORBS 한국 트위터 : https://twitter.com/orbs_korea
- ORBS 한국 포럼 : https://www.orbskorea.net
- ORBS 코박 포럼 : https://cobak.co.kr/forum/orbs
