ERC-4626 토큰 표준이란?

현재 몇 가지 주요 토큰 표준이 존재하지만, 탈중앙화 금융(DeFi) 생태계에는 여전히 토큰화된 vault와 관련해 반복적으로 발생하는 문제가 있습니다. 이로 인해 최신 표준인 ERC-4626이 만들어지게 되었습니다.

이 글에서는 vault가 무엇인지, 개발자들이 vault를 토큰화하면서 마주치는 문제는 무엇인지, 그리고 ERC-4626이 DeFi 개발에서 이 문제를 어떻게 해결하는지 설명합니다. 이어서 이 표준이 가져오는 새로운 변화들을 자세히 살펴보고, 이를 스마트 컨트랙트에 구현하는 방법을 보여드리겠습니다.

vault란 무엇인가?

vault는 암호화폐 같은 자산을 보관하고 관리할 수 있는 다중서명 솔루션 또는 스마트 컨트랙트입니다. 각 vault는 수익의 형태로 생성하는 토큰을 항상 가지고 있습니다. 이렇게 생성된 토큰은 나중에 vault에 원래 예치되어 있던 토큰과 교환할 수 있습니다.

예를 들어, 자동화된 마켓 메이커(AMM)인 Sushiswap에서 Sushi를 스테이킹하면 보상으로 xSushi를 받게 됩니다. 마찬가지로, DeFi 대출 프로토콜인 Compound에서 USDC 스테이블코인을 예치해 이자 농사를 하면 cUSDC를 받게 됩니다.

cUSDC와 xSushi는 수익을 내는 토큰(yield-bearing token)으로, 원래 토큰(이 예시에서는 USDC나 SUSHI)으로 다시 교환할 수 있습니다. 수익을 내는 토큰의 가치는 vault나 풀에 예치된 토큰이 늘어나는 한 계속 상승합니다.

vault는 지갑보다 더 안전하고 우수한 것으로 여겨지며, 이 때문에 많은 DeFi 프로토콜이 자금을 vault에 예치하는 방식을 선택합니다. vault를 사용하는 대표적인 DeFi 프로토콜로는 Sushiswap, Aave, Balancer, Compound 등이 있습니다.

vault를 토큰화할 때 어떤 문제가 있는가?

수익을 내는 토큰과 관련해 개발자가 마주치는 문제는 서로 다른 프로토콜의 토큰을 통합하는 것입니다.

예를 들어, DeFi 앱을 구축하면서 각 프로토콜의 토큰을 통합해야 하는 상황이라면, 각 토큰마다 개별적으로 조사해서 수익이 발생하는 방식을 파악하고, 이를 자신의 코드베이스에 맞게 조정해야 합니다.

Maker DAO의 vDAI, Curve의 stETH 등을 통합하려면, 각 스마트 컨트랙트의 특이한 점을 이해하고 각각을 DeFi 앱에 성공적으로 통합하기 위한 커스텀 솔루션을 만들어야 합니다.

이렇게 서로 다른 수익 토큰을 통합하는 과정이 번거롭고 시간이 많이 걸리는 것은 물론, 잠재적인 오류로 인해 스마트 컨트랙트 리스크도 커집니다.

개발자는 어댑터에 존재할 수 있는 허점을 확인하는 데 더 많은 시간을 써야 하며, 경우에 따라서는 스마트 컨트랙트 감사자에게 외주를 맡겨야 할 수도 있는데, 이는 비용이 상당히 클 수 있습니다. 최근 공격자들이 많은 프로토콜과 DeFi 앱의 무결성을 침해하고 있는 상황을 고려하면 이는 더욱 중요한 문제입니다.

ERC-4626 표준은 누가 만들었는가?

2021년 말경, 서로 다른 수익 토큰을 통합하는 것이 개발자들에게 얼마나 어려운 일인지 발견한 Fei Protocol의 창립자 Joey Santoro는 4명의 다른 Ethereum 개발자들로 구성된 팀을 이끌고 Ethereum Comment Proposal 4626(ERC-4626)을 제출했습니다.

여러 차례의 검토와 논의를 거친 후, Ethereum은 2022년 5월 이 표준을 마침내 승인했습니다.

ERC-4626이 vault에 관해 가져오는 이점은 무엇인가?

ERC-4626의 가장 큰 이점은 토큰화된 vault를 표준화함으로써 프로토콜 통합을 더 쉽고 오류가 덜 발생하도록 만든다는 점입니다.

통합할 수 있는 공통 표준이 존재하므로, 더 이상 별도의 어댑터를 만들 필요가 없습니다. 한마디로 개발 속도를 높이며, 컴포저빌리티(composability)를 극대화합니다.

또한 빌더가 어댑터와 인터페이스에 대해 감사자의 도움을 받을 필요가 없어지므로 비용도 절감됩니다. 무엇보다 ERC-4626은 수익 토큰을 다루는 앱과 수익 애그리게이터의 보안을 강화합니다.

ERC-4626 표준이 도입하는 변화는 무엇인가?

새로운 ERC-4626 토큰을 통해, 이제 개발자가 수익 토큰을 다루는 DeFi 앱을 만들 때 따를 수 있는 표준이 생겼습니다.

한마디로, ERC-4626 표준은 다음과 같은 기능을 구현합니다:

• 이를 통합하려는 개발자를 위한 최적화된 vault 인터페이스
• 예치에 대한 교환으로 share를 지급하며, share는 vault 기초 토큰에 대한 부분적 소유권을 나타냄
• 수익 토큰 컨트랙트를 개발하는 개발자를 위한 일관된 표준
• 검증된 vault 토큰 보안

ERC-4626의 작동 방식: 함수와 이벤트

ERC-4626은 ERC-20 표준의 확장이며 이와 호환됩니다. 따라서 ERC-20 토큰 컨트랙트에 적용되는 일반적인 변수, 이벤트, 함수 대부분이 ERC-4626 vault 표준에서도 그대로 작동합니다.

이 vault 표준은 전체 풀에서 부분적 소유권을 얻는 방법으로 _share_라는 개념을 도입합니다. 이 _share_는 수익 토큰을 가리킵니다.

이제 ERC-4626으로 개발을 시작해봅시다.

Cairo나 Viper 같은 언어를 사용할 수도 있지만, 여기서는 Solidity로 이 컨트랙트를 작성하겠습니다.

1. IDE에 OpenZeppelin 확장 기능 가져오기

IDE를 연 후(Remix를 추천합니다), 컴파일러에게 컨트랙트를 작성할 Solidity 버전을 지정합니다.

여기서는 0.8 버전을 사용한다고 선언합니다. 그다음, ERC-20과 ERC-4626의 OpenZeppelin 확장 기능 두 가지를 가져와야 합니다.

이제 컨트랙트를 만들고 이름을 붙여봅시다.

2. 컨트랙트 생성하기

컨트랙트에 이름을 붙이고, 이것이 ERC-20 토큰과 ERC-4626 둘 다를 기반으로 한다는 점을 명시합니다.

Contract, testingVaults is ERC20, IERC4626 { your entire code here}

3. 표준 구현하기

컨트랙트를 생성한 후에는, 이 표준의 메서드, 함수, 이벤트와 관련해 알아야 할 몇 가지 중요한 변화가 있습니다. 이제 ERC-4626의 메서드와 이벤트 몇 가지를 살펴보겠습니다.

Deposit

사용자가 vault에 자금을 예치하면, deposit 함수가 스마트 컨트랙트를 트리거해 예치자에게 그에 상응하는 양의 share를 발행(mint)합니다. 이벤트로서, 예치가 발생할 때마다 스마트 컨트랙트가 트리거되어야 합니다.

이 함수를 통해 컨트랙트에 vault로 토큰을 예치하고 그 share의 소유권을 호출자에게 부여하도록 지시했습니다. withdrawal 함수도 같은 방식으로 작성할 수 있습니다.

Withdrawal

withdrawal 함수는 소유자가 share를 소각(burn)하고 그 대가로 자산을 받도록 돕습니다. vault에서 인출이 발생하면, withdrawal 이벤트가 발생해야 합니다.

이 이벤트에서 address indexed _from은 vault에 토큰을 예치하도록 승인한 사용자를 나타내며, 예치된 토큰을 인출할 수 있는 사람은 address indexed _to입니다.

Asset와 totalAsset

vault 토큰의 주소는 asset 함수에서 사용되어야 합니다. 스마트 컨트랙트 내 기초 자산의 전체 수량은 totalAssets로 선언되어야 합니다.

convertToShares와 convertToAssets

ERC-4626 표준 하에는 두 가지 변환 함수, convertToShares과 convertToAssets이 있습니다.

자산을 share로 변환해야 할 때는 convertToShares가 적절한 함수인데, 이 함수는 자산 대신 발행할 share의 수량을 담고 있기 때문입니다.

반대로 convertToAssets은 share를 자산으로 변환하는 방식으로 반대 방향으로 작동합니다.

Mint

mint 함수는 예치가 발생하면 receiver를 대상으로 호출됩니다. maxMint는 vault에서 사용자 또는 receiver를 위해 생성할 수 있는 share의 전체 수량입니다. 개발자로서 이를 설정해야 합니다.

Redeem

redeem 함수는 소유자(msg.sender)의 share를 일부 소각하고 자산을 receiver에게 보냅니다. 어떤 이유로든 share를 상환(redeem)할 수 없는 경우, redeem이 되돌려져야(revert) 합니다.

maxRedeem은 소유자가 vault에서 상환할 수 있는 share의 수량입니다.

Preview

preview 메서드를 사용할 때 개발자는 이 메서드가 반환하는 값이 정확하지는 않지만 근사치일 것이라는 점을 염두에 두어야 합니다. 이를 오라클처럼 신뢰해서는 안 됩니다.

preview는 mint, withdraw, redeem, deposit과 같은 다른 메서드와 함께 사용할 수 있습니다.

이것으로 끝입니다. ERC-4626으로 개발을 성공적으로 시작하셨습니다!

마무리 – ERC-4626의 미래

ERC-4626의 등장과 함께 DeFi에 새로운 흐름이 생겼습니다.

표준이 없었기 때문에 DeFi 애그리게이터들은 여러 수익 토큰을 집계하는 것을 항상 번거로워했습니다. 하지만 이제 ERC-4626 덕분에 API 호출 한 번으로 수익 토큰의 세부 정보를 얻는 것이 가능해졌습니다.

수익 토큰을 다루는 DeFi 애플리케이션의 보안을 강화하기 위해 추가로 노력을 기울여야 했던 문제는, 이 검증된 표준을 통해 상당 부분 해결되었습니다.

다양한 DeFi 프로토콜 간의 컴포저빌리티와 상호운용성 활용은 앞으로 몇 년간 더욱 늘어날 것입니다. 심지어 이 표준이 DeFi 생태계에서 완전히 새로운 제품을 만들고 출시하는 발판이 될 가능성도 있습니다.