STO, 이대로 괜찮을까? (하)
Disclaimer: 본 글은 서울대학교 블록체인 학회 디사이퍼(Decipher)의 Weekly Session에서 STO를 주제로 발표한 내용을 기반으로 작성되었습니다. 해당 글은 STO의 제도와 전반적인 내용을 바탕으로 작성자의 주관적인 의견을 포함하여 작성하였으며, 본 글에 포함된 어떠한 내용도 투자 조언이 아님을 명시합니다. 이에 따라 본 글의 어떠한 내용도 투자 조언으로 해석되어서도 안 됩니다.
시리즈
- STO, 이대로 괜찮을까? (상)
- STO, 이대로 괜찮을까? (하)
Author
김상엽 (@0xsangsang), 박순종 of Decipher
Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media) Reviewed By 김동혁, 신성헌
이상적인 STO
앞선 글에서, 국내에 현재 도입되고 있는 STO의 형태에 대해 비판하였습니다. STO의 특성상 중앙화된 주체에 의해 토큰이 관리되어야 한다는 점은 피할 수 없겠으나, 토큰의 기록조차 모두 프라이빗 체인을 사용하여 블록체인의 강점인 투명성과 상호운용성까지 훼손되는 것은 적절치 않아 보입니다. 이에 필자들이 생각하는 이상적인 STO의 형태를 다음과 같이 제언합니다.
“금융당국 혹은 기관에 의해 유통이 직접적으로 관리되지만, 퍼블릭 블록체인에 기록되어 자본의 투명성 및 상호운용성이 보장되는 증권형 토큰”
STO가 이러한 방식으로 구현된다면 더욱 신뢰할 수 있으며, 디파이 등의 활용을 통해 자본 효율성 또한 증진될 수 있습니다. 초기에는 유저들의 쉬운 시장 진입을 위해 현재 국내와 같이 도입하더라도, 앞으로는 위와 같은 형태로 발전하는 것이 STO를 보다 의미 있게 활용하는 길이라 생각합니다.
이더리움 증권형 토큰 표준
오픈소스 형태로 다양한 표준들이 제안되고 채택되는 이더리움 진영에서는 필자들이 제시한 이상적인 형태의 STO와 유사한 토큰 표준들에 대한 논의가 이미 이루어지고 있었습니다. 이런 표준의 예시로는 대표적으로 ERC-1400과 ERC-3643이 있습니다. ERC-1400은 최근에 많은 논의가 이루어지지 않고 있는 것에 비해 ERC-3643은 최근에 이더리움 커뮤니티에서 정식 표준으로 인정받는 등 많은 주목을 받고 있기 때문에 본 글에서는 ERC-3643에 대해 중점적으로 다룰 예정입니다. 먼저, 선행적으로 제시되었던 표준인 ERC-1400에 대해 알아보도록 하겠습니다.
ERC-1400
ERC-1400 [Security Token Standard] 는 2018년 제안된 토큰 표준으로 현재는 많은 논의가 이루어지고 있지는 않습니다. 이더리움의 증권형 토큰의 발행, 유통, 소유권, transfer 제한, 권리 등에 대한 표준 정립을 위해 제안된 토큰 표준이며, ERC-20이나 ERC-777과 같은 기존 토큰 표준들과 호환성을 가지고 있습니다. ERC-1400은 아래 그림과 같이 ERC-1410, ERC-1594, ERC-1643, ERC-1655 모두를 통합하여 활용한 Umbrella Architecture 형태로 구현되었습니다.
- ERC-1410 [Partially Fungible Token Standard]
ERC-1410은 토큰이 partition 단위로 그룹화되며, 각 partition은 식별을 위한 Key와 속한 토큰 개수로 이루어지는 토큰 인터페이스를 제시합니다. 이 표준을 통해 토큰의 각 partition 단위에서 어떤 행위가 이루어지는지 더욱 세분화된 투명성을 제공할 수 있습니다. 예를 들어, 특정 소유자의 토큰을 최초 발행되어 나누어진 토큰과 2차 거래를 통해 구매한 토큰으로 세분화하여 관리할 수 있습니다. ERC-1400에서는 이러한 형태의 토큰을 사용합니다.
- ERC-1594 [Core Security Token Standard]
기존에 많이 사용되는 토큰 표준인 ERC-20의 경우 토큰 transfer 시에 balanceOf 와 allowance 함수를 통해 sender가 충분한 잔액을 가지고 있는지 검증 이후 바로 실행이 이루어집니다. 그러나 증권형 토큰의 경우에는 sender나 receiver의 KYC 여부 등 특수한 검증 절차가 추가적으로 필요합니다. 이를 해결하기 위해 제안된 것이 ERC-1594이며, canTransfer와 canTransferByPartition 두 가지 함수를 통해 해당 기능이 추가되었습니다. 둘 모두 증권형 토큰별로 트랜스퍼 시에 특정한 절차에 대한 검증을 수행하기 위한 함수이며, 더 좋은 사용자 경험을 위해 성공 또는 실패 시에 단지 참거짓이 아닌 EIP-1066 기반 상태 코드 또는 byte32 형태의 Reason Code를 리턴하도록 구현되어 있습니다. 마지막으로, 증권형 토큰 발행에 대한 증명을 위한 서명 같은 오프체인 데이터 또한 트랜스퍼 함수에 사용하는 경우를 위해 _data 파라미터가 추가된 transferWithData와 transferFromWithData 함수도 추가로 구현되어 있습니다.
- ERC-1643 [Document Management Standard]
증권형 토큰에는 일반적으로 KYC에 관한 내용 등 다양한 문서들이 필요합니다. ERC-1643은 이러한 문서들을 스마트 컨트랙트를 통해 생성, 제거, 수정 등을 할 수 있도록 구현된 표준 제안입니다. DocumentUpdated, DocumentRemoved 등의 event를 통해 투자자들이 투자와 관련된 문서의 변동사항에 대해 알 수 있도록 구현되어 있습니다.
- ERC-1644 [Controller Token Operation Standard]
증권형 토큰은 규제 및 법적 감독 대상이기 때문에 특정한 주체(이하 컨트롤러)가 토큰의 전송을 강제할 수 있는 권한이 필요합니다. 또한 이런 컨트롤러를 통한 전송이 가능하다는 사실이 투명하게 공개되어야 합니다. 이를 위한 표준이 ERC-1644입니다. 토큰 강제 전송 기능을 통해 법적 문제가 생겼을 때 컨트롤러를 통해 해결이 가능하며, 투자자의 개인 키 분실에 따른 문제가 발생하였을 때 또한 해결이 가능합니다. 주요한 함수로는 강제 전송을 실행하는 controllerTransfer 와 강제 상환하도록 하는 controllerRedeem 가 있습니다. 이때, 컨트롤러의 모든 행위는 투명하게 공개되어야 하므로 각각 ControllerTransfer, ControllerRedemption event를 발생시킵니다. 컨트롤러를 원하지 않는 ERC-1400 기반 증권형 토큰의 경우에는 isControllable 함수가 항상 False 를 return 하도록 하면 모든 함수 실행에서 revert가 됩니다.
ERC-1400은 위 4가지 표준을 바탕으로 구현되었으며, 주요한 함수로는 operatorTransferByPartition과 operatorRedeemByPartition이 있습니다. 둘 모두 ERC-1644의 컨트롤러를 통한 강제 전송과 상환을 실행하는 함수라고 이해하면 됩니다. ERC-1400에서는 증권형 토큰이 ERC-1410 기반의 partially fungible token 형태입니다. 이러한 토큰 형태에 transfer, transferWithData 등의 오퍼레이션을 행하기 위해서는 어떻게 partition 해야할지 결정해야 하는데 세부적인 구현 방법(fixed list, partitionsOf 함수 사용 등)은 표준이 아닌 사용자에게 맡기고 있습니다. 오프체인에서 전송의 검증을 위해 ERC-1594 기반 core security token 형태를 사용하며, transferByPartition, transferWithData, transferFromWithData, canTransferByPartition, canTransfer 함수들은 transfer 시에 허가된 주체에 의한 서명 검증을 위해 추가적인 _data 파라미터를 가지고 있습니다. Identity의 경우에는 ERC-725, Civic, uPort 등의 표준 사용을 제안하며, KYC를 통해 승인되는 중앙화된 방식 사용도 가능합니다. 이러한 표준들은 이더리움 주소를 key로 가지고 있기 때문에 canTransfer 함수는 security token의 sender와 receiver를 identity 프록시로 사용할 수 있습니다.
ERC-3643
ERC-3643은 T-REX — Token for Regulated EXchanges 라는 이름을 가지고 있으며, 이름에서 알 수 있듯이 기관용 증권형 토큰을 위한 표준입니다. 이 표준은 자동화된 온체인 검증 시스템을 통해 증권형 토큰 관리 및 전송 라이브러리를 제공하고자 하는 목표를 가지고 있습니다. EIP는 Draft, Review, Last Call 등 여러 절차를 통해 최종 확정이 이루어지는데 ERC-3643은 최근 최종 확정 상태를 의미하는 Final 단계가 되며 증권형 토큰 관련 표준 중에서 최초로 이더리움 커뮤니티에 정식으로 인정받은 표준이 되었습니다.
이를 바탕으로 ERC-3643에 대한 관심이 높아지고 있으며, 본 글에서는 해당 표준을 구성하는 주요한 요소들과 간단한 call flow에 대해 설명하고자 합니다.
- Identity
ERC-3643에서는 온체인에서 개인을 증명하는 수단, 즉 Identity Contract로 ONCHAINID라는 시스템을 사용하여 지갑과 연결하는 것을 권장합니다. ONCHAINID는 ERC-734, 735 기반 프로토콜로 블록체인 위에서 개인 및 기업을 증명하기 위해 구현된 시스템입니다. 개개인의 ONCHAINID의 증명서는 허가된 Claim Issuer에 의해 발행되며 그들이 오프체인에서 개인에 대한 데이터 검증을 진행하고 발행하면 검증인이 온체인으로 증명서 검증 및 서명을 하는 형태로 구현되어 있습니다. 이를 통해 개인이 지갑의 프라이빗키를 분실하더라도 T-REX 토큰들을 복구할 수 있습니다.
- Registry
Registry는 IdentityRegistry를 중심으로 IdentityRegistryStorage, ClaimTopicsRegistry, TrustedIssuersRegistry로 이루어져 있습니다.
1.IdentityRegistry
하나의 증권형 토큰당 하나의 IdentityRegistry 를 가지며, 각 Identity의 화이트리스팅 정보가 포함된 IdentityRegistryStorage 와 1:N의 관계로 연결되어 있습니다. Identity의 지갑 주소, Identity 컨트랙트, ISO-3166 표준을 따르는 국가 코드가 저장되어 있습니다. identity 나 investorCountry 등의 함수를 통해 유저의 Identity 컨트랙트, 국가 등을 확인할 수 있으며 증권형 토큰에서는 isVerified 함수를 호출해 특정 유저가 유효한 투자자인지 검증을 수행합니다.
(IdentityRegistry 컨트랙트는 ERC-173 기반의 소유권을 사용하며, 컨트랙트 owner에 의해 임명된 agent가 Identity 등록/제거를 담당합니다.)
2.IdentityRegistryStorage
KYC나 AML 등을 통과한 모든 검증된 투자자들의 Identity 주소를 저장합니다. 하나 이상의 IdentityRegistry 와 연결될 수 있어 여러 증권형 토큰이 스토리지를 공유할 수 있으며, IdentityRegistry 의 함수 및 스펙들과 스토리지 공간을 분리하기 위해 만들어졌습니다.
(IdentityRegistryStorage 컨트랙트는 ERC-173 기반의 소유권을 사용하며, 컨트랙트 owner에 의해 임명된 agent가 Identity 등록/제거를 담당합니다.)
3.ClaimTopicsRegistry
ClaimTopicsRegistry 에는 증권형 토큰의 신뢰 가능한 claim topic들, 즉 개개인이 해당 증권형 토큰을 거래하기 위해 어떠한 증명서들을 필요로 하는지가 저장되어 있습니다. 증권형 토큰 소유자들의 Identity 컨트랙트는 ClaimTopicsRegistry 에 저장된 claim topic들에 대한 claim을 모두 가지고 있어야 하며, 없을 시에는 거래 및 소유가 불가능합니다.
(ClaimTopicsRegistry 컨트랙트는 ERC-173 기반의 소유권을 사용하며, 컨트랙트 owner가 필요한 claim topic 등록/제거를 담당합니다.)
4.TrustedIssuersRegistry
앞서 설명한 claim topic들에 대한 claim을 발행하는 주체들의 주소를 저장하고 있는 컨트랙트입니다. Identity 컨트랙트는 유저가 증권형 토큰을 거래하고 소유하기 위해 이 레지스트리 컨트랙트에 저장된 발행자들의 서명이 필요합니다.
(TrustedIssuersRegistry 컨트랙트는 ERC-173 기반의 소유권을 사용하며, 컨트랙트 owner가 신뢰 가능한 발행자 등록/제거를 담당합니다.)
- Compliance
증권형 토큰 ‘발행’을 위해서는 발행 주체가 다양한 제약 조건을 걸 수 있도록 설계가 되어야 합니다. 이러한 제약 조건으로는 국가별 투자자 수 제한, 투자자별 최대 보유 토큰 개수 제한, 허용 국가 제한 등 다양한 조건이 있습니다. 이러한 제약 조건을 엄격하게 준수하기 위해 존재하는 것이 Compliance 컨트랙트입니다. Compliance 컨트랙트는 발행자의 법적 규제에 따라 처음부터 맞춤형으로 개발되는 방식과 모듈러 형태로 개발되는 방식 2가지가 있습니다. 모듈러 형태로 개발되면 외부 compliance 모듈들을 Compliance 컨트랙트에 추가 또는 제거하는 방식으로 발행자가 제시하는 제약 조건을 맞추게 됩니다. 매 토큰 전송이 이루어질 때마다 이러한 제약 조건이 확인되기 위해 Compliance 컨트랙트의 canTransfer 함수를 호출하게 되고, 전송이 제약 조건을 만족한다면 TRUE 를 반환합니다.
(Compliance 컨트랙트는 ERC-173 기반의 소유권을 사용하며, 컨트랙트 owner가 Compliance 파라미터 세팅과 토큰 컨트랙트에 Compliance를 연결하는 권한을 가집니다.)
- Security Token
Security Token 컨트랙트(ERC3643 컨트랙트)는 기본적으로 ERC-20 표준을 바탕으로 구현되어 호환성을 가지도록 설계되었습니다. 위 그림에서 볼 수 있듯이, ERC-20 토큰과 가장 큰 차이점은 토큰 거래가 일어날 때 검증인이 앞서 설명한 Identity나 Compliance 컨트랙트 등을 통해 조건을 확인하고 이를 만족할 때만 거래가 가능하다는 점입니다. 또한 증권형 토큰의 특성상 관리자에 의해 철저히 관리되기 위한 장치들이 필요합니다. 이를 위해 특정 지갑이 소유한 토큰을 freeze 할 수 있는 freezePartialTokens 함수나, 토큰의 모든 거래를 일시적으로 중단할 수 있는 pause 함수가 구현되어 있습니다. 그리고 프라이빗키 분실이나 지갑 해킹 등을 당한 투자자들을 위한 recovery 장치 역시 recoveryAddress 함수로 구현되어 있습니다.
Call Flow
이어서 ERC-3643의 주요한 작동들의 call flow를 간단하게 살펴보겠습니다.
- On-Chain Identity 생성
ERC-3643에서 On-Chain Identity를 생성하려는 주체는 일반적인 투자자와, 앞서 설명한 TrustedIssuersRegistry 컨트랙트에 등록되며 증명서를 발행해주는 발행자 2가지로 나뉩니다.
ERC-3643의 경우에는 ONCHAINID를 사용하여 Identity를 생성하는 것을 권장하지만, 다른 오프체인 플랫폼을 거쳐 생성할수도 있습니다. 이러한 2가지 방법을 사용하여 Identity를 관리하는 dApp에 Identity를 추가하면 ERC-734 컨트랙트가 배포되고 관리 키를 추가하며 Identity 생성이 마무리됩니다. 일반적인 투자자가 아닌 발행자 같은 경우에는 관리 키 추가 이후에 추가적으로 자신의 Claim에 해당하는 키를 추가하고 마무리됩니다.
- Trusted Claim Issuers / Trusted Claim Topics 업데이트
앞서 Components 파트에서 설명하였듯이, ClaimTopicsRegistry 와 TrustedIssuersRegistry 는 ERC-173 기반의 소유권을 통해 관리됩니다. 따라서, Claim Topic 및 Claim Issuer의 등록에 대한 전권을 각 Registry의 소유자가 가지게 되며, 위 그림에서 볼 수 있듯이 ClaimTopicsRegistry 의 addClaimTopic, removeClaimTopic, updateIssuerClaimTopics 함수들과 TrustedIssuersRegistry 의 addTrustedIssuer, removeTrustedIssuer 함수들을 호출해 업데이트 할 수 있습니다.
- Claim 발행
유저에게 Claim Issuer가 claim을 발행해 주는 방법으로는 누가 먼저 요청하는지와 누가 최종적으로 claim을 등록하는지에 따라 3가지 방법이 있습니다. 첫번째로 Indirect Hybrid 방식은 Claim Issuer가 오프체인에서 claim을 확인한 뒤, 서명한 데이터를 ONCHAINID 소유자에게 보내면 소유자가 직접 등록하는 방식입니다. 두번째 Direct onchain 방식의 경우에는 ONCHAINID 소유자가 Identity 컨트랙트에 Claim Issuer의 키를 추가하면 해당 Claim Issuer가 확인 후 claim을 등록해 주는 방식입니다. 마지막으로 Indirect onchain 방식은 Claim Issuer가 먼저 투자자를 확인 후, ONCHAINID 소유자에게 claim 추가 요청을 보내면 소유자가 해당 요청을 허가하여 실행되는 방식입니다.
- Transfer
마지막으로 토큰의 transfer입니다. Transfer가 일어날 때, 가장 먼저 해당 주소의 토큰이 frozen되지 않았는지를 확인합니다. 이후, IdentityRegistry 에 isVerified 함수를 호출해 해당 지갑 주소가 등록이 되었는지를 확인하고, IdentityRegistry 는 ClaimTopicsRegistry 로부터 검증을 해야 하는 claim topic들을 모두 가져옵니다. 가져온 모든 claim topic들에 대해 Identity의 개별적인 claim을 IdentityRegistryStorage 로부터 가져오고, TrustedIssuersRegistry 로 보내 해당 claim들의 서명이 발행자의 서명과 일치하는지를 검증합니다. 이 과정을 통과하면 Compliance 컨트랙트에 canTransfer 함수를 호출하여 거래가 해당 증권형 토큰의 제약 사항들을 위반하지는 않는지를 확인하고, 문제가 없다면 transfer를 진행합니다. Transfer가 완료되면 마지막으로 Compliance 컨트랙트에 기록을 한 뒤 마무리가 됩니다.
이렇게 ERC-3643을 구성하는 요소들과 기본적인 작동 원리에 대해 알아보았습니다. 해당 표준이 Final state가 된 이후, ERC-3643 Organization은 더욱 적극적으로 이를 알리기 위해 노력하고 있으며 최근에는 ERC-20과 ERC-3643 기반 토큰들에 모두 호환되는 디파이 프로토콜의 UI 컴포넌트들을 오픈소스로 공개하기도 하였습니다. 이 디파이에서는 ERC-3643 토큰의 거래에 필수적인 Compliance 컨트랙트 체크 등이 모두 구현되어 있습니다. 앞으로 이더리움 진영에서 ERC-3643을 바탕으로 더 많은 RWA 및 STO 토큰들이 활발하게 거래가 되지 않을까 하는 기대가 됩니다.
마무리
앞서 (상)편에서 이야기하였듯이, 국내에서는 현재 바람직하지 않은 형태로 STO가 도입되고 있다고 생각합니다. 본 글에서는 이상적인 STO의 형태로 “금융당국 혹은 기관에 의해 유통이 직접적으로 관리되지만, 퍼블릭 블록체인에 기록되어 자본의 투명성 및 상호운용성이 보장되는 증권형 토큰”을 제시하였고, 국내에서도 이와 같은 방향으로 정책이 도입되어야 한다고 주장합니다. 이러한 방식으로 현재 이더리움 오픈소스 커뮤니티에서는 ERC-1400, ERC-3643 등과 같은 증권형 토큰 표준들이 활발하게 제시, 논의되고 있습니다. 이러한 표준들에 대해 더 널리 알리기 위해 기술적인 부분들을 보다 자세하게 설명하는 글을 작성하였습니다. 다양한 시도가 이루어지고 있는 만큼, STO에서 실질적인 효용을 창출할 수 있도록 블록체인 기술이 적절하게 도입되기를 기원합니다.
