영지식 증명을 활용한 프라이버시 토큰(zk-ERC20) 구현
주의 : 코드가 많음
Special Thanks to Carl Park(4000d)
P2P 시스템에서 검증자(Verifier)는 누구?
안녕하세요, 철학자(정순형)입니다.
블록체인 업계는 영지식 증명(Zero Knowledge Proof; ZKP)에 대한 관심이 매우 높습니다. 영지식 증명이라는 기술은 대중에게 “데이터를 상대방에게 보여주지 않고도 해당 내용이 문제가 있는지 없는지”를 알려주는 마법으로 알려져 있습니다(동굴 이야기는 널리 알려진 비유이고, 더하여 국문으로된 많은 자료들에 첨부된 난해한 수식들은 이 기술에 신비감을 더하죠).
이번 포스트는 영지식 증명에 관한 이론에 집중하기보다는, 실제로 블록체인에 만들어서 쓸 수 있는 영지식 증명의 구현과 활용에 조금 더 집중해보고자 합니다. 특히 이번 포스팅은 이더리움 블록체인에 이미 배포되어 거래되는 시총 9조 5천억원(2019.6.4. 기준)에 달하는 이더리움의 ERC20 토큰을 영지식 증명 라이브러리인 Zokrates를 활용해 거래기록을 뒤섞어 토큰 소유자 및 거래 기록을 숨기는 방법에 관한 구현 아이디어를 다루고 있습니다. 영지식 증명 자체에 관한 이론적인 접근을 원하실 경우 아래의 자료를 참조하시면 좋을 것 같습니다.
영어에 익숙하시면 비탈릭의 ZKP시리즈글도 좋습니다.
만약 개발자 혹은 연구자가 아니시라면, 이 글에서 다루는 내용과 서술이 익숙하지 않을 수 있습니다. 그럴 경우 서론의 기본적인 개념만 받아들이신 후마지막에 다루는 향후 연구 및 응용과 *별첨2: 프라이버시 기술의 가치 **항목 문단을 먼저 읽어보시기를 **권장합니다.
이 글에 쓰여진 코드는 지난 2018년 12월 ethsingapore 해커톤에서 발표된 zkDAI 프로젝트를 참조했음을 미리 알립니다.
서론: 트랜잭션 토폴로지 변경
이더리움 블록체인에서 발생하는 토큰 전송(Token Transfer) 트랜잭션은 계정에서 계정으로 토큰의 잔액이 이동하는 매쉬형 토폴로지(meshed topology) 구조를 띄고 있습니다. 얼핏 보기에 이러한 구조는 매우 복잡해 보이지만, 모든 트랜잭션이 공개되기 때문에 사실상 거래 기록의 프라이버시는 없다고 봐도 무방하죠(10조원에 달하는 ERC20토큰의 거래기록은 단 하나도 빠지지 않고 1원 단위까지 이더리움 블록체인에 기록되어 공개됩니다).
익명화된 토큰(zk-ERC20)은 이 “계정-계정” 구조를 믹서(Mixer) 컨트랙트를 중심으로한 “계정-믹서”간 집중형 토폴로지(centralized topology)로 변경시킵니다(어려워도 조금만 참으세요).
Transaction Topology 변경 — 출처 : ZETH
믹서로 들어온 토큰은(그 이름 그대로) 데이터가 뒤섞이면서 “누가 누구에게 얼마의 토큰을 전송했는지 알 수 없는 상태”로 바뀌게 됩니다. 이 개념은 시크릿노트(SecretNote)라는 해시화된 토큰 소유 증서를 통해 구현될 수 있습니다.
노트(Note) : 소유자와 액면가 정보가 기록된 증서
노트, 시크릿노트(Note, SecretNote)
노트(Note)란 소유자 및 해당 소유자가 보유한 토큰의 액면가를 기록한 증서(note)입니다. 그리고 이 증서를 사용하기 위해서는 해당 증서의 소유주임을 증명(verify)해야 합니다. 이러한 방식의 소유자 증명은 블록체인에서 일반적으로 사용하는 공개키 암호화 알고리즘이 활용되죠(노트는 개념은 봤을때, 비트코인의 UTXO와 같습니다). 하지만 노트 자체는 익명화되기 힘듭니다. 그래서 믹서는 익명화를 위해 해시화된 노트만을 기록으로 유지합니다. 그리고 이렇게 해시화된 노트를 시크릿 노트(SecretNote)-비..밀..노트..?-라고 부릅니다.
Note = (소유자, 액면가) = (Public Key, Amount) = (Address, Amount)
SecretNote= hash(Note)
믹서 컨트랙트(블록체인)에는 시크릿 노트와 트랜잭션을 생성한 계정(msg.sender)만 기록됩니다. 예를들면 아래와 같이 저장되는것이죠 .
→Tx(트랜잭션 생성 계정, 시크릿 노트)
Tx(A, 86B273FF34FCE19D6B804EFF5A3F5747ADA4EAA22F1D49C01E52)
Tx(B, D4735E3A265E16EEE03F59718B9B5D03019C07D8B6C51F90DA3A)
Tx(C, 4E07408562BEDB8B60CE05C1DECFE3AD16B72230967DE01F640B)
Tx(D, 4B227777D4DD1FC61C6F884F48641D02B4D121D3FD328CB08B5)
…
해시화된 노트 정보만으로는 누구로부터 누구에게 얼마의 토큰을 전송했는 전혀 알 수 없습니다. 위와 같은 기록은 누군가 계속 노트를 만들었구나 정도밖에 파악이 안되죠. 하지만 어떻게 이러한 최소한의 기록으로 이중지불(Double Speding)등의 기록 조작이 일어나지 않는것을 보장할 수 있을까요?
이때 영지식증명(ZKP)이 쓰입니다. 트랜잭션에 1) 원래 노트의 소유자는 내가 맞고 2)새롭게 발행된 노트는 새로운 소유자에게 귀속되었다는 연산에 관한 영지식 증거(ZK Proof)를 첨부합니다(영지식 알고리즘으로 SNARK등을 활용하면 이 증거의 크기는 매우 간결-succinct-해지기 때문에 연산 능력이 충분치 못한 퍼블릭 블록체인에서 활용하기에 매우 유리합니다). 영지식 증거가 첨부된 트랜잭션을 묘사하면 다음과 같습니다.
→Tx(트랜잭션 생성 계정, 시크릿 노트, 영지식 증거)
Tx(A, 86B273FF34FCE19D6B804EFF5A3F5747ADA4EAA22F1D, Proof*)
Tx(B, D4735E3A265E16EEE03F59718B9B5D03019C07D8B6C5, Proof**)
Tx(C, 4E07408562BEDB8B60CE05C1DECFE3AD16B72230967D, Proof***)
Tx(D, 4B227777D4DD1FC61C6F884F48641D02B4D121D3FD32, Proof**)
…
ZKP의 마법은 간결한 증거(Proof)만 가지고도 해당되는 노트가 문제없이 사용되었다는것을 보장한다는 데에 있습니다. 구체적으로 이러한 증거가 어떻게 만들어지는지 살펴보도록 하겠습니다.
시크릿 노트를 사용할 수 있는 지식(Knowledge of Transfer Value of SecretNote)
구현의 단순화를 위해서 노트의 소유권을 옮기기 위해서는 하나의 노트는 태워 없어져 매번 새롭게 2개의 노트가 만들어지는 모델을 사용합니다. 2개의 노트중 하나는 하나는 당사자에게 귀속시키고, 나머지 하나는 본인이게 돌려줍니다.
PK1소유주는 PK2소유주에게 v’만큼의 토큰을 전송했다
pk는 퍼블릭키(주소)를 뜻하고, v는 노트의 액면가를 뜻합니다. 위와 같은 구조를 만들어 내기 위해서 증명해야하는 지식(Knowledge)은 생각보다 매우 단순합니다. 풀어쓰면 다음과 같죠.
노트 소유자가 노트를 보내기 위해 증명해야 하는 지식(Knowledge)
- 나는(pk1) 시크릿노트1에 대한 소유권자가 확실해!
- v = v’ + change도 확실해!
- 시크릿노트2는 Pk2의 공개키를 통해 만들어졌어!
- 시크릿노트3은 나(pk1)을 통해 만들어졌어!
1을 통해서 노트1의 소유권을 확인하고 2를 통해 이중지불을 방지하며, 3을 통해서 정확한 액면가와 소유권을 이전하고 4를 이용해 남은 잔액을 다시 본인에게 되돌려줍니다.
구체적인 설계를 위해서, 이때 사용되는 연산(지식, knowledge)을 C( )라고 정의하고 여기에 사용되는 파라미터를 구체화하면 다음과 같습니다.
C(oldNote, newNote1, newNote2, sk, v, receiverPk, v’, change)
OldNote : 예전에 소유하던 노트(해시)
newNote1 : 소유권이 옮겨진(전송된) 노트(해시)
newNote2 : 소유권을 옮기고 난(전송된) 후 남은 노트(해시)
sk : 예전 노트(oldNote)의 개인키
v : 예전 노트(oldNote)의 잔액
receivePk : 전송된 노트 소유자의 공개키
v’ : 전송된 노트의 잔액
change : 예전노트 액면가액-전송될노트의액면가액 =되돌려받는액면가
이렇게 정의된 파라미터를 통해서 앞서 정의한 지식(Knowledge)을 의사코드로 표현하면 다음의 형태가 됩니다.
line 2: 전달된 개인키(sk)를 통해서 공개키(pk)를 구합니다.
line 3: 내가 소모하려는 노트(oldNote)가 앞선 과정에서 구한 공개키(pk)와 전달된 액면가(v)를 통해 만들어진 노트인지 확인합니다.
line 4 : 소모하려는 액면 금액(v)이 내가 소유권을 이전하고자(전달하고자) 하는 노트의 액면가(v’)와 되돌려받은 잔액(change)과 같은지 확인합니다.
line 5 : 내가 전달하고자 하는 시크릿노트의 해시값(newNote1)이 hash(받는사람(receiverPk), 전달할 금액(v’))과 일치하는지 확인합니다.
line 6 : 내가 쓰고 남은 시크릿노트의 해시값(newNote2)이 hash(나(Pk), 잔액(v’))과 일치하는지 확인합니다.
line7 : 라인2~6을 문제없이 통과했다면 1을 반환합니다.
zokrates는 이렇게 설계된 C( )라는 함수 연산에 관한 지식(knowledge)에 대한 1)증거(proof)와 이를 **2)검증(verify) **할 수 있는 실질적인 수단을 제공합니다. 앞서의 의사코드를 zokrates language로 구현한 결과는 다음과 같습니다.
고수준 서킷 코드
앞선 설계의 C( )는 에서는 8개의 변수만을 전달받았는데, 실질적인 구현과정에서 16개의 파라미터로 변경되었습니다(이론과 실전은 다릅니다ㅜㅜ 코드를 보시면 알겠지만 1개의 변수를 2개로 쪼개서 쓰고있죠. 그건 zokrates language가 함수의 파라미터를 무려 254비트(?)라는 듣도보도 못한 낮선 크기로 처리하기 때문입니다). ZKP에서는 이렇게 정의된 코드를 서킷(circuit)이라고 부릅니다.-엄밀히 말해서 아직 완벽한 circuit이 구성된건 아닙니다. 컴파일을 해야 circuit이 되죠-
영지식의 세계에 오신걸 환영합니다. 이제 막 지식(knowledge)을 정의할 수 있는 도구를 손에 익히게 되었습니다. 다음으로 해야할 일은 일련의 개념으로부터 시작한 지식(knowledge)에 대한 1)증거(proof)와 2)검증(verify)을 할 수 있는 환경(Trusted Setup → ZCASH의 Trusted Setup 참조)을 갖추는 일입니다. 즉, 시크릿노트를 쓸 수 있는 실행 환경을 갖추는 일이죠. 이러한 실행 환경에서 만들어진 증거(proof)의 실체를 마주하면, 왜 ZK-SNARK의 S(succinctness, 간결함)가 들어간 것인지, Toxic Waste이란 무엇인지에 관한 개념에 대해서 쉽게 이해할 수 있습니다.
Trusted Setup
일단 컴퓨터에 zokrates를 설치합니다. 그리고 설치된 환경에 앞서 제작한 서킷 코드를 옮겨서 다음 명령어를 순서대로 입력합니다.
//out, out.code 파일 생성
$./zokrates compile -i zk-circuit.code
, verification.key파일 생성
$ ./zokrates setup --proving-scheme pghr13
생성
$./zokrates export-verifier --proving-scheme pghr13
- compile : 해당 명령어를 통해서 고수준 언어로 작성된 서킷 로직이 저수준의 바이너리 서킷으로 옮겨집니다. 직접적으로 QAP를 만들어냅니다.
- setup : 만들어진 QAP를 이용해서(컴파일된 서킷을 이용해서) verification.key와 proving.key를 만듭니다. 이 과정에서 toxic waste라는 랜덤값이 사용되는데, 이 값은 사라져야 하며 해당 값이 어딘가에 남아있으면 가짜 증거(fake proof)를 만들어 낼 수 있습니다(이중지불이 가능하게 되죠).
- export-verifier : 정의된 서킷을 검증할 수 있는 솔리디티 컨트랙트 코드를 만들어줍니다. verifier.sol파일이 그것이고, 컨트랙트 호출간 verifyTx()라는 심플한 함수를 사용해 영지식 검증을 수행 합니다.
여기서 유의할 점은 이렇게 만들어진 verifier.sol은 앞에서 설계 및 구현한 서킷에 관한 검증을 수행한다는 점입니다. 그렇게 때문에 새로운 서킷을 설계하고 만들면 방금전 trusted setup절차를 다시 반복해야 합니다. — 그리고 이 결과 만들어진 verifier.sol파일은 전혀 다른 코드가 되겠죠. 지식(knowledge)이 달라지면 해당 지식에 대한 검증(verify)로직도 달라진다는것을 이해하는것이 중요합니다. -
어렵게 만들어진 verifier.sol이지만, 아직 이 컨트랙트는 주어진 증거(Proof)를 바탕으로 그저 노트1개가 노트2개로 나눠질 수 있는 공개키와 액면가 검증이 옳은지 옳지 않은지만 판단합니다. 이 자체가 노트는 아닙니다. verifier.sol을 상속한 mixer.sol(SecretNote를 다루는 컨트랙트)은 별도로 만들어야 하죠. 지금부터는 실질적으로 노트를 기록하고 관리하는 mixer를 살펴보도록 하겠습니다.
Mixer.sol : SecretNote Management Contract
컨트랙트는 객체이고, 객체를 통해 상태(variables)와 행위(function)를 정의할 수 있습니다. 믹서 컨트랙트 앞서 만들어진 verifier를 상속해 시크릿노트에 관한 상태와 행위를 제어합니다.
상태(variables) : State, notes, allNotes, allHashedNotes
노트의 상태값들
상태값들은 직관적이고 단순합니다. 모든 시크릿노트는 리스트(allHashedNotes)형태로 관리되고, 기록된 각각의 시크릿 노트들의 상태는 mapping형태의 notes로 처리하죠. 중요한 것은 노트들의 상태값 flag인 State입니다. 각각의 노트는** Invalid, Created, Spent**상태가 있는데, 노트를 쪼개기 위해서는(사용하기 위해서는) 기록된 노트가 Created 상태여야 합니다. 사용된 노트는 Spent상태로 바뀝니다. 노트 전송이 2번 이루어진 상황을 그림으로 나타내면 다음과 같습니다.
노트1, 노트2가 사용되는 과정에서 Crated → Spent 상태로 변경
구체적으로 노트가 사용되면서 상태값이 변경되는 명령행은 transferNote()함수에 정의되어 있습니다.
상태값 중 특이한 부분은 문자열 배열인 allNotes인데, 이는 향후 노트 소유주가 본인의 노트 정보를 조회할 때 사용합니다. 만약 해당 노트의 소유주라면, allNotes의 요소값을 보유한 private key로 복호화(decrypt)하여 해시화되지 않은 노트정보(액면가 및 소유자)를 알 수 있습니다.
행위(functions) : transferNote( )
앞서 노트는 다양한 상태(Invalid, Created, Spent)를 가질 수 있고, 노트가 쓰이는 과정에서 이러한 상태가 바뀌는것은 이해 했습니다만, 구체적으로 어떠한 코드를 통해 이러한 변화가 이뤄지 살펴보도록 하겠습니다.
Mixer.sol의 transferNote( ) 함수
transferNote( )함수를 호출하기 위해서 유저는 11개의 파라미터(배열 길이까지 하면 27개 파라미터가 되겠네요)를 준비해야합니다. 이중 a~k까지는 ZK Proof이고, input은 종전에 설계한 C( )함수의 퍼블릭 파라미터인 OldNote, newNote1, newNote2의 해시값과 리턴값 입니다(input배열의 길이가 7개인 이유는 노트해시를 2개의 값으로 표현하기 때문입니다).
주목할 점은 이 함수 파라미터들에 관한 검증함수(라인:19)와 노트해시(라인:24)만 통과하면 노트를 사용(라인:29)할 수 있다는 것입니다. 실제로 사용되는 파라미터는 다음과 같습니다.
Proof.json
얼핏 보기에 값이 복잡해 보이지만, Proof 키값인 a~k까지의 값을 자연수로 표기하면 아래와 같은 단순한 5차원 백터값이 됩니다.
[179426333, 181327921, 198492781, 533001793, 334216237]
단순한 숫자 5개처럼 보이지만 이 값은 다음의 복잡한 내용을 간결하게 증명 증명(Succinct Proof)하고 있습니다.
“나는(pk1) 시크릿노트1에 대한 소유권자가 확실하고, 5(원래 노트 액면가)= 3(노트1의 액면가)+ 2(노트2의 액면가)이고, 시크릿노트2는 Pk2의 공개키를 통해 만들어졌고, 시크릿노트3은 나(pk1)을 통해 만들어졌어! ”
5차원 벡터 자체로부터 위의 메시지에 관한 어떠한 내용을 유추할 수 없음에도 불구하고 이를 통해 해당 메시지에 관한 연산이 제대로 수행되었는지는 정확하게 알 수 있습니다. 이처럼 영지식 증명은 그 말처럼 메시지 검증에 어떠한 지식도 요구하지 않죠(Zero Knowledge). 다음은 이 Proof가 어떠한 과정을 통해서 만들어졌는지 살펴보도록 하겠습니다.
연산증명 : witness → Proof.json
witness란 컴파일된 zokrates소스코드(out파일)에 명시된 main() 함수에 파라미터를 전달해 만들어진 영지식 증거(proof)를 뜻합니다. 앞서 구현된 서킷은 16개의 파라미터로 구성되어 있으니, 해당 내용에 맞는 파라미터를 생성해서 zokrates에 전달하면 됩니다. 예를들어 0x65f01a39f2b7e3cb9b0f0f933ae13309e2b814fc 계정(계정0번)이 가진 액면가 5의 노트를 0x23f18f142c93dd1d719eaf67b56973517f6ebcb8 계정(계정1)에게 3만큼 보내는 witness를 계산 할 때는 다음의 명령을 주면 됩니다.
./zokrates compute-witness -a 299336082027245038390806872836251868434 146214785280603262054605348855920364042 1710234169 322627985543346917984603212343009613052 0 5 338680819269871046518773602934504523249 240032092968569212144514626611958402952 603033364 59253784198043682718523328310826417336 0 3 170846492286112848076693656918639323381 285388887744989578963627759440747666135 0 2
시크릿노트를 이용해 가치이전을 하기 위해서는 노트를 2개로 쪼개야 하므로 3개의 노트정보 및 소유자정보가 필요합니다만, 앞서 말씀 드렸다시피 zokrates는 256비트를 2개로 나눠서 입력해줘야 하므로 의사코드에 비해 파라미터 갯수가 많습니다.
만들어진 witness를 json포멧으로 변경을 위해서 다음 명령을 줍니다.
./zokrates generate-proof --proving-scheme pghr13
실행결과 proof.json파일이 생성됩니다.
구현 및 테스트 아키텍처
온더의 깃헙 레포지토리에 앞서 서술한 내용에 관한 테스트를 해볼 수 있는 소스코드와 테스트 스크립트를 첨부해두었습니다. Docker와 ganachi-cli가 필요합니다.
README.md파일에 적힌 setup스크립트를 순서대로 수행하면 로컬에 zokrates 컨테이너와 레포지토리 디렉토리의 zk-related 를 공유해 일련의 명령을 자동으로 수행합니다.
트러플 테스트는 accounts[0] 소유인 액면가 5토큰의 노트를 생성하고, accounts[1]에게 3토큰을 보냅니다.
한계
zkERC20은 매우 단순한 형태의 구현이기 때문에 여러 제약 및 한계가 있으며, 실제 production수준으로 가기 위해서는 이러한 문제들을 해결해야 합니다. 특히나 많은 양의 가스를 소모한다는점으로 인해서 이더리움 메인체인보다는 튜링 완전함을 지원하는 확장성 높은 레이어2(토카막 플라즈마 등)등에서 오히려 활용 가능성이 높습니다.
구현된 스마트 컨트랙트 문제
- 검증 함수(verifyTx) 가 가스를 상당히 많이 소모한다(약 7백만).
- 노트 소유자 잔액 조회 문제 encrypt( hash(pk, v) ).
- 내가 소유한 노트의 정확한 잔액을 알아야만 트랜잭션을 날릴 수 있다.
- 노트를 배열 처리해서 노트가 많아지면 매우 느려진다.
- 노트를 쓰려면 항상 2개로 쪼갠다(튜링 불완전성).
- 모든 금액을 보내는 경우 노트 하나는 잔액이 0이된다.
- 조건부 거래 : 여러명에게, 멀티 시그를 하고 싶을 때는..?
- 충분한 노트가 쌓이지 않으면 프라이버시가 보장 되기 힘들다.
ZKP 구조적 문제
- 이니셜 셋업에 toxic waste를 누가 셋업할 것인가? → MPC 등으로 보완
- witness를 만드는 연산이 클라이언트에게 부담이 적지 않고, 유저는 플라즈마 외에 별도의 클라이언트 혹은 서비스가 필요
실용성의 문제
- zokrates랭귀지가 지원하는 라이브러리가 많지 않음
향후 연구 및 응용
현재까지의 시크릿노트의 구현은 단순 전송을 위해 2개의 노트가 항상 만들어져야 하는 등 구조적으로 유연하지 못하게 설계되어있습니다. 그렇기때문에 다양한 조건부 거래(멀티시그 등의 소유권 이전에 관한 권한을 스마트 컨트랙트에게 부여하는 문제 등)가 어렵고 이에 대한 개선이 필요합니다. 조건부 거래가 가능한 노트의 설계와 이에 근거한 서킷 코드의 정교한 설계가 필요하고, 이렇게 만들어진 코드가 해당 체인에서 동작 가능한지에 관한 실무적인 검토 또한 필요합니다 — Practical한 수준에서 이더리움 메인체인에서 직접 활용은 어렵다고 보는게 맞을 것 같습니다. 스마트 컨트랙트를 지원하는 플라즈마 등 레이어2체인에서 활용 가능성이 높아보입니다 — .
하지만 이러한 난관에도 불구하고 이러한 형태의 조건부 거래가 가능해진다면 이들 거래를 중개할 수 있는 스마트 컨트랙트를 통해서 프라이버시를 완벽하게 보장하는 탈중앙화된 거래소를 만드는 것도 가능합니다.
토카막 플라즈마에 응용된 시크릿노트 거래소
위의 그림은 온더의 토카막 네트워크를 이용한 프라이버시를 보장하는 탈중앙화 거래소에 관한 아키텍쳐를 묘사하고 있습니다. 이더리움 메인체인에 이미 만드어진 ERC20토큰을 Requestable 컨트랙트로 래핑하고 이를 플라즈마로 진입시킨다면 기존 ERC20토큰 보유자들은 본인들의 거래 프라이버시를 보장받은 상태에서 토큰 거래가 가능해지게 됩니다.
조건부 거래는 단순 거래뿐만 아니라 다양한 탈중앙화 금융(DeFi)영역으로 확장될 수 있고, 이는 GDPR등 최근의 개인정보 보호 흐름에 맞춰진 금융솔루션 등 다양한 영역으로 적용 및 확대될 수 있습니다.
하지만 쏟아지는 연구에 비해, 여전히 부족한 라이브러리는 실질적인 개발에 많은 어려움을 주고 있고, 이러한 부분에 대한 커뮤니티의 관심이 필요할 것 같습니다.
긴 글을 끝까지 읽어주셔서 감사합니다.
*별첨1 : zkDAI세미나 영상
프라이버시를 보장하는 스테이블 코인 zk-DAI 깊게 살펴보기(철학자, Onther Inc.)
*별첨2 : 프라이버시 기술의 가치
온더의 ZKP에 관한 리서치와 개발은 단순한 지적 호기심을 충족하기 위해 혹은 엔지니어링 퍼즐의 만족감을 위해 이뤄지는 것은 아닙니다 — 사실 생각보다 많은 연구개발 산출물들이 연구자들의 호기심으로부터 시작해 연구팀만 쓰는 시제품 형태의 장난감으로 남습니다 — . ERC20의 프라이버시를 보장할 수 있는 완벽한 기술이 나온다면 얼마정도의 가치를 가지게 될까요?
이를 합리적으로 추정하기 위해 두개의 데이터를 살폈습니다.
- (프라이버시가 보장되지 않은) ERC20의 시가 총액 규모
- (프라이버시 보장 기능이 갖춰진) 코인의 시총 규모와 비중
ERC20 시가 총액의 규모
- Coinmarketcap.com에 등록된 ERC20토큰의 갯수는 92개
- (2019.6.4 기준)이들 토큰의 시총 합은 9조 5천억원
프라이버시 코인의 시총과 비중
- 3대 프라이버시 코인 : 모네로, 대시, ZCASH
- (2019.6.4)시총 합 : 3조 7천억원(출처 — coinmarketcap.com)
- 전체 코인 시총 중 프라이버시 코인 비중 : 약 1.3%(출처 — coinmarketcap.com)
모네로, DASH, ZCASH 코인의 시총이 전체 시총의 1.3%를 차지하고 있으니, 프라이버시에 대한 수요는 전체 코인 시장의 1.3%라고 합리적으로 추정할 수 있고, 아직 프라이버시가 보장되고 있지 않은 ERC20토큰 9조 5천억원에 1.3%를 곱하면 최소한의 기술가치는 약 1천 2백억원으로 추정할 수 있습니다.
더불어 많은 거래소들이 프라이버시 코인의 자금세탁 가능성으로 인해 프라이버시 코인을 상장폐지하고 있기 때문에 이로 인해 위축된 시총을 고려하면 실질적인 크립토 프라이버시의 기능 수요는 1.3%이상일 수 있고, 더해서 단순 토큰 전송 이외에 다양한 응용(예를 들어 거래소, 각종 금융 기능 등) 기술을 통해 부가가치를 더하는 것도 가능합니다. ERC20 그 자체는 오늘의 포스팅과 같이 별도로 만들지 않는 한 프라이버시 기능이 없기 때문에 상장폐지를 당할 명분도 없죠.
지금까지 논의는 토큰에만 국한되어 말씀을 드렸지만, 프라이버시 영역이 우리가 평소에 사용하는 데이터 전체로 확장된다면 이 기술가치는 산정조차 어려울정도로 커지게 됩니다. 데이터의 내용이 전혀 볼 필요가 없으면서도 다양한 데이터 거래의 안정성이 보장된다는 것은 정말 멋진 일입니다 — 물론 아직은 더 풀어야할 기술적 한계들이 있지만요 — .
엄밀한 마켓 리서칭을 위해서는 1) 경쟁자에 관한 정보 2) 외부적인 위협과 기회 요소 — 제도적, 법적, 기술적 이슈와 동향 — 3) 내부적인 요소 — 보유기술 등 — 등을 더 서술해야 하지만 이러한 내용은 별도로 다루도록 하겠습니다.
철학자(정순형)
Onther Inc Founder. Seoul Ethereum Meetup Co-organizer. Blockchain Engineer. Crypto Lover.
Onther-Tech
Building an Ethereum Blockchain ECO system to Change the World