EIP-5528: Refundable Fungible Token Standard (에스크로 표준 제안)

EIP-5528: Refundable Fungible Token Standard (에스크로 표준 제안)

이번 포스팅은 22.08.23에 제안된 EIP로 근래 커뮤니티에서 제안된 EIP 중 가장 흥미롭게 읽어 공유드립니다.

한줄요약: ERC-20 에스크로 거래 표준 제안

원문은 다음 링크를 참고해주세요.

EIP-5528: Refundable Fungible Token Standard
pull request: https://github.com/ethereum/EIPs/pull/5528 Abstract This standard is an extension of EIP-20. This specification provides a type of escrow service in the blockchain ecosystem, which includes the following capabilities. The issuer issues tokens. The issuer creates an escrow smart con…

1️⃣ Motivation

  • 익명성을 보장하는 암호화폐의 특성상 거래는 비가역적
  • 이런 문제를 해결하기 위해 현실에는 에스크로(Escrow) 서비스 존재
  • 허나 탈중앙화된 암호화폐 생태계에서는 제3의 중재자가 조정하는 에스크로 서비스 구현이 어려움
  • 이를 해결하기 위한 표준을 제안
  • 에스크로 스마트 컨트랙트는 판매자와 구매자가 특정 조건이 충족될 때까지 돈을 보유

2️⃣ Specification

  • Buyer Contract: 구매자는 판매자 토큰과 교환을 위해 에스크로 계정에 지불
  • Seller Contract: 판매자는 구매자 토큰과 교환을 위해 에스크로 계정에 지불
  • Escrow Contract: 판매자에 의해 계약 생성. [Seller Token, Buyer Token]으로 매핑되어 있음.

3️⃣ Rationale

내부에는 다음과 같은 내용이 구현될 수 있습니다.

  • Locked 기간
  • 최대(최소) 투자자 수
  • 자금 조달 최대(최소) 토큰 수
  • 판매자/구매자 환율비
  • KYC 인증 (추가적인 인터페이스가 필요할 수 있음)

구매자/판매자 컨트랙트에 대한 제약이 없으며, 에스크로 컨트랙트 구현은 다음과 같은 함수를 제안합니다.

  1. constructor: 에스크로 성공/실패 조건 정의
  2. escrowFund: 구매자와 판매자에 따른 입금 형태
  3. escrowRefund: 구매자는 성공/실패 이전에 환불 요청 가능하도록 설정. 앞선 Fund 과정의 역과정
  4. escrowWithdraw: 에스크로 조건 성공시 각자 토큰 인출

4️⃣ Backward Compatibility

EIP-5528은 ERC-20 토큰 표준에 완벽하게 호환됩니다.

5️⃣ Security Considerations

에스크로 계약 자체는 분명 취약점이 존재할 수 있습니다. 이에 따라 예기치 않은 문제가 발생할 수 있습니다.

마치며

저는 이 표준의 취지나 문서화가 상당히 마음에 듭니다. 커뮤니티 내 조회수도 높고 반응 자체는 긍정적이라 더 마음에 드네요. 앞으로 안전한 거래에 대한 논의가 더 많아지면 좋겠습니다.



(21/10/22 추가)

EIP-5528이 아쉽게 Final 직전에 Review로 가버렸습니다.
해당 EIP가 Review 상태가 된 이유는 다음과 같습니다.

  • Payable Contract과 Escrow Contract의 설명이 충분하지 않으며 IERC5528 구현체가 다르게 행동함
  • 추가적 policy 추가 가능 여부에 대한 설명 추가 필요
  • 컨트랙트 구현 설명의 모호함. 예제 코드 추가하여 명확한 사용 지침 제안
  • _transfer와 transfer의 사용이 겹침
  • Rational(근거) 부분의 (영어) 문법적 오류
  • policy 부분이 constructor로 기술되어 있는데, 이것이 constructor에서 정의되어야 하는 것인지 그냥 실수 인지 더 명확한 설명 필요

해당 표준 제안자는 바로 수정을 올리긴 했으니 곧 다시 Last Call 상태로 갈 것 같긴 합니다. 수정본을 보면 확실히 더 깔끔해지긴 했습니다.