[하이퍼레저 패브릭] Fabtoken의 UTXO 와 계정

@ Token Management Enablement in Hyperledger Fabric
@ Using FabToken

fabtoken 핵심사항

1. 패브릭에서 토큰은 어떤 자산의 형태이다. (달러같은 화폐로써 정의 될 수도 있고, 자동차, 부동산나 가격이 고정되지 않은 게임 아이템이 될 수도..)
2. 패브릭에서 토큰은 체인코드의 로직 기반으로 만들어 진다.
3. 체인코드의 오너쉽 (이더리움에서 owner 처럼) 는 체인코드가 실행 된 후에 결정 된다. 즉 패브릭 네트워크를 이루는 조직들 중에 하나가 오너쉽을 가질 수 도 있으며, 조직들이 합의한 제3의 대표조직이 가질 수도?
4. 프라이버시 및 보안 문제에 대해서도 최고의 지원을 하며 (금융에 관한 사용처에 주요함) 해당 문제가 덜 중요한 곳에서도 설정을 통하여 운용 가능 하다. 프라이버시 부분에 대한 지원레벨을 낮추면 성능은 높아진다.

UTXO 와 계정 

Fabtoken 은 UTXO 식으로 Ledger (정확히는 채널 장부의 상태 데이타베이스 -  트랜잭션 개개의 정보는 블록체인에 로깅된다) 에 저장된다. (패브릭 자체가 account 기반이 아니다 보니, 당연하다 싶다.) 즉 트랜잭션 마다 output 이 생성되며 이것을 “unspent” 상태라고 한다. 그리고 이 "unspent output" 기반으로 새로운 input 을 발생 시킬 수 있으며 input에 사용된 "unspent output" 정보는 줄어드는것이 아닌 삭제되어 새로운 output 정보가 생겨 날 것이다. 이렇게 되면 account 기반에서 철수의 account = 1000 이 있을 경우,  300을 영희에게 전달하는 트랜잭션을 비잔틴이 캡쳐해서 2번 날리면 account = 400 밖에 안남는 문제가 발생하겠지만, UTXO의 경우는 철수-abc = 1000이 삭제되고, 철수-efe = 700이 새롭게 생기기 때문에, 철수-abc를 통한 이중지출은 일어나지 않게 된다. 

자 여기에서 그냥 abc, efe 라고만 한다면 이것들이 철수의 자산이란것은 알 수 없을테고, 철수-abc, 철수-efe라고 Ledger에 저장된다면 개인정보에 취약성을 보이게 될 것이다. 패브릭은 이것을 어떻게 해결 했을까? 

ZK-snarks 

Privacy-preserving implementation using SNARKs, where ZK-snarks are used to offer the privacy properties mentioned before. The difference from the previous case lies on the cryptographic primitives used to achieve the privacy properties and the security assumptions they rely on. SNARK-based implementation of token management is not efficiently compatible with the PKI that Fabric MSPs leverage, but such an implementation can be used to evaluate the performance of implementation (2) on basic token management functionality. 

Schnorr proofs

Privacy-preserving implementation that relies on Schnorr proofs [FIXMEREF]. This implementation will offer confidentiality of token ownership, type, and value, at different combinations and levels. Schnorr proofs rely on standard cryptographic assumptions  and do not require any special setup, and offer a straightforward and efficient combination with the permissioned nature of Fabric.

sideDB

Privacy-preserving implementation using sideDB, where sideDB functionality is leveraged to offer privacy preserving token management. The value and type of the token can be concealed but the current owner of the asset may remain anonymous or not. Privacy properties offered in this case consider a weaker attacker model than the ones in cases (2) and (3). More specifically, such a construction requires that there is a set of parties that can see the full details of each transaction and ascertain their correctness w.r.t. double spending resistance, while tracking when a specific asset is being exchanged is possible.


구체적인 내용은 다음에~