메뉴

문서정보

목차

Hyperledger Cactus

 Hyperledger Cactus

블록체인 기술의 사용이 증가하고 있지만 블록체인 솔류션, 기술, 서비스의 파편화는 향후 블록체인의 도입과 성장을 방해하는 큰 문제가 될 것이다.

Hyperledger Cactus는 파편화된 이기종의 블록체인 시스템을 연결하는 프로토콜을 제안하기 위해서 만들고 있는 프로토콜이다. (2020년 10월 25일)현재 버전 0.1(Early Draft) 상태로 공개되기 까지 시간이 꽤 시간이 걸릴 것 같지만 개념이 좋은 것 같아서 분석해보기로 했다.

블록체인 상호운용성에 대해서

서로다른 블록체인을 연결할 때 해결해야하는 두 가지의 문제가 있다. Cactus 컨소시엄은 연결된 각 블록체인을 검증 할 수 있는 validator 노드를 운영한다. Validator 노드는 연결된 원장의 상태의 증거를 합의 알고리즘을 통해서 (올바른 증거인지)검증한다. 블록체인의 상태에 대한 증명은 합의 알고리즘의 규칙과 이를 실행하는 여러 validator 노드들에 의해서 생성되고 서명되기 때문에, 블록체인의 상태는 전체 네트워크에서 평가할 수 있다.

Validator 노드는 원장별로 플러그인 방식으로 연결된다. 따라서 연결된 각 블록체인의 스마트컨트렉트를 통해서 원장의 상태를 관찰하고 원장의 상태를 증명하는데 필요한 원장별 기능을 사용 할 수 있다. Validator 노드는 블록체인 네트워크 내부에 둘 수도 있지만, 외부에 독립적으로 두는 것이 좋을 것이다. 외부에 독립적으로 둘 경우 교차되는 블록체인의 상호작용에 대해서 validator 노드의 서명을 사용 할 수 있다. 즉 교차되는 블록체인의 상호작용에 대해서 다양한 블록체인 노드의 서명을 처리 할 필요 없이 Cactus 의 validator 노드만으로 서명 작업을 수행 할 수 있다. 아래 그림을 보자.

 Cactus validator node

V1, V2, V3는 원장 별로 블록체인 네트워크 상태에 대한 증명을 제공하는 validator 노드다. Validator 노드는 원장별 플러그인을 통해서 블록체인 네트워크와 연결된다. V1, V2, V3 는 독립적인 합의 알고리즘을 실행한다.

블록체인 상호운용성 관련 용어들

Ledger 객체(Object) 타입
서로 다른 특성을 가진 블록체인간의 상호운영성을 설명하기 위해서는 원장에 저장된 객체의 유형을 구별해야 한다. 원장에 저장된 객체는 3가지 유형으로 분류 할 수 있다.

FA와 NFA의 차이에 대해서 알아보자.

대체가능한 자산은 동일한 유형의 다른 자산과 교환하여 사용 할 수 있는 자산이다. 통화가 대표적인 예다. 예를 들어 1USD 지폐는 다른 1USD 지폐로 바꿀 수 있다. ETH(Ether), BTC(Bitcoin)과 같은 암호 화폐도 FA다. 대체 불가능한 자산은 고유한 특성으로 인하여 교환할 수 없는 자산을 의미한다. 예를들어 자동차는 색상, 가격, 기능과 같은 고유한 속성을 가지고 있으므로 대체불가능한 자산이다. 크립토키티(CryptoKitties)가 NFA의 예다. FA의 경우 ERC-20, NFA의 경우 ERC-721을 토큰 표준으로 사용한다.

 FA와 NFA

NFA를 보자 T가 같은 T가 아니다. 따라서 교환 할 수 없다. 크립토키티는 고양이를 육성하는 게임이다. 사용자는 고양이를 구매하고 수집하고 교배해서 새로운 고양이를 만들고 육성해서 사고 팔 수 있다. 이들 고양이는 유전적인 속성을 가지고 랜덤하게 만들어지기 때문에 유일한 고양이가 만들어진다. 사용자가 소유한 고양이가 희소성을 가지기 때문에 고양이가 가진 속성에 따라서 큰 가치를 가지는 고양이를 가질 수 있다. 어떤 고양이는 1억이 넘게 판매했다고 한다. 이런 디지털 고양이가 도대체 왜 이런 가치를 가질 수 있는지 의문이라면 아래의 영상을 참고하기 바란다.

자산(FA/NFA)와 data(D)와의 차이점

단일성(unicity)는 FA와 NFA에 적용된다. 즉, 주어진 자산의 유효한 표현이 시스템에 하나만 존재함을 보장한다. 이는 블록체인 안에서 동일한 토큰/코인의 이중 지출을 방지하는 역할을 한다. 동일한 데이터 패키지는 서로 다른 원장에서 여러 표현을 가질 수 있지만 자산(FA, NFA)는 오직 하나의 포현만 활성화 할 수 있다. 즉 자산은 다른 모든 블록체인에서 잠기거나 소각되는 동안 하나의 블록체인에만 존재한다.

블록체인 상호운용성 타입들
블록체인 상호운용성은 아래 타입으로 분류 할 수 있다.

Ledger transfer : 자산은 하나의 블록체인에서 잠기거나 소각되고 동일한 자산의 표현이 다른 블록체인에서 릴리즈(released)된다. 동일한 자산에 대해서 두 가지 표현이 존재하면 안된다. 다만 데이터의 경우 여러 블록체인으로 전송할 수 있으므로 예외다. 자산이 소스 블록체인에서 대상 블록체인으로 전송될 때, 한방향으로만 전송될 수 있는지 혹은 자산이 블록체인 안팎으로 전송될 수 있는지에 따라서 단방향 또는 양방향 원장전송이 있다.

Atomic swap : 두 개의 블록체인에서 자산을 교환 할 경우, 두 개의 트랜잭션이 발생할 건데 이 과정은 원자적이어야 한다. 즉 두 트랜잭션은 모두 성공하거나 모두 실패해야 한다.

Ledger interaction : 블록체인 A에서 발생하는 작업이 블록체인 B의 작업을 유발 할 수 있다. 블록체인 중 하나의 상태에만 영향을 미칠 수 있는지 여부에 따라 단방향 또는 양방향 원장 상호작용이 있을 것이다.

Ledger entry point coordination : 여러개의 블록체인이 운용되는 상황에서 사용자가 제출한 읽기/쓰기 트랜잭션은 해당 블록체인으로 전달이 되어서, 사용자의 블록체인에서 작동해야 한다. 여러 블록체인들이 엮여있는 네트워크에서의 라우팅 역할이라고 보면 되겠다.

블록체인에서 대량의 잠금과 소각(burn)을 사용 할 경우 블록체인 생태계에 큰 영향을 끼칠 수 있다. 잠금과 소각을 통한 블록체인간 원장 전송은 블록체인간 높은 수준의 간섭이 있을 수 있으므로 좋은 방법은 아니다. atomic swap는 모든 자산/데이터가 각각의 블록체인 환경에 남아있기 때문에 블록체인간 간섭을 최소화할 수 있다. Ledger entry point coordination을 이용하면 모든 트랜잭션이 해당 블록체인에 전달되고 실행되기 때문에 블록체인이 분리되어 운영되는 것과 같은 효과를 누릴 수 있다.

2

그림 설명 : One-way ledger transfer

자산의 잠금과 소각
Unicity를 보장하기 위해 FA와 NFA는 다른 블록체인으로 전송되기전에 소각하거나 잠궈야 한다. 잠긴 자산은 자신이 원래 블록체인으로 다시 전송되는 경우 잠금을 해제할 수 있지만, 소각은 되돌릴 수 없다. 원장 전송중에는 자산의 잠금/소각이 발생하지만, 양쪽 모두에 계정이 있는 경우 atomic swap을 사용하여 잠금/소각을 피할 수 있다. 이런 이유로 대부분의 암호화폐 거래소 플랫폼은 FA를 소각하는 대신 atomic swap를 사용한다.

예를들어 비트코인이나 이더리움은 채굴을 해야지만 코인을 생성할 수 있다. 비트코인과 이더리움을 다루는 거래소는 이들 코인을 즉시 생성할 수 없기 때문에 양방향 원장 전송이 아닌 atomic swap에 의존해야 한다. 이와 달리 FA 토큰의 채굴 프로세스를 활용 할 수 있는 경우 자산 소각/잠금도 구현 옵션이 될 수 있다. 자산 소각은 일반적으로 토큰/FA 코인에 더 많이 적용되며 암호화폐의 전체 가치가 증가하기 때문에 커뮤니티에 대한 기부가 될 수 있다.

자산 소각은 아래와 같이 구현 할 수 있다.

Footnotes

사용 사례

Ethereum to Quorum Asset Trasnfer

 Cactus 시나리오

Escrowed Sales of Data for Coins

이 시나리오에서 가치를 가진 데이터는 컴퓨터에 저장된 일련의 비트(디지털 자산) 이다. 즉 사용자 A와 사용자 B는 사기 또는 의도하지 않은 시스템 실패로 부터 양쪽의 자산을 보호하기 위해서 에스크로와 Atomic swap 방식으로 Hyperledger Cactus 트랜잭션을 이용해서 데이터와 자금을 거래하려 한다. 트랜잭션 프로토콜의 핸드 셰이크 메커니즘을 통해서 A와 B는 거래를 사전에 동의할 수 있다. DLT는 서로를 신뢰 하기 힘든 양 당사자간의 거래를 촉진 할 수 있다.

 BIF

Money Exchanges

양 당사자간의 법정화폐 및 가상통화의 거래가 가능하다. 기술적인 레벨에서는 위의 사례와 동일하므로 세부적인 묘사는 생략한다.

Stable Coin Pegged to Other Currency

With Permissionless Ledgers (BTC)
BTC 보유자는 BTC를 ExampleCoin Reserve Wallet으로 전송하여 BTC를 ExampleCoin으로 교환 할 수 있으며 동등한 양의 코인이 다른 네트워크의 ExampleCoin 지갑으로 발행 할 수 있다.

ExampleCoin 보유자는 ExampleCoin 원장에서 소각증명을 받고 ExampleCoin Reserve Wallet에서 BTC 지갑으로 일치하는 양의 BTC를 전송하여 BTC로 자금을 상환 할 수 있다.

 ExampleCoin Pegged to Bitcoin

With Fiat Money (USD)
BTC에 대한 페깅과 매우 유사한 아이디어지만 BTC 지갑이 USD를 보유한 전통적인 은행계좌로 대체된다.

Healthcare Data Sharing with Access Control Lists

 Healthcare Data Sharing with Access Contrl Lists

Integrate Existing Food Traceability Solutions

End User Wallet Authentication / Authorization

 Integrate Existing Food Traceability Solutions

Blockchain Migration

Blockchain data Migraration
Blockchain Smart Contract Migration
Semi-Automatic BlockChain Migration

소프트웨어 디자인

원칙

Wide support
기술과 관계없이 최대한 많은 생태계와 상호연결한다.

Plugin Architecture from all possible aspects
ID, DLT, 서비스 디스커버리 등 모든 영역에서 상호 운용성을 수용 할 수 있도록 한다. 커뮤니티 피드백 / PR을 면밀히 모니터링 하여 Hyperledger Cactus 코드를 플러그인으로 할 수 있도록 한다. 이렇게 하면 향후 추가될 수 있는 사례와 프로토콜들과의 마찰을 최소화할 수 있다.

Prevent Double spending Where Possible
동일한 자산에 대한 두 가지 표현은 그것을 명확히 허용하지 않는 한, 생태계에 존재해서는 안된다.

DLT 기능 포괄
각 DLT에는 다른 DLT가 가지고 있지 않은 고유 특성을 가지고 있다. Hyperledger Cactus는 가능한 DLT의 고유한 기능에 액세스 할 수 있도록 설계되어야 한다. 이렇게 설계한 좋은 모델은 Kubernetes의 핵심 API를 확장 할 수 있도록 개발된 Kubernetes CRD와 연산자들이다.

Low impact
상호운용성의 원리는 생태계의 재정의가 아니라 적응하는데 있다. 거버넌스, 신뢰 모델 및 워크플로는 각 생태계에서 보존되어야 한다. 신뢰모델과 합의는 프로토콜 핸드셰이크의 필수 부분이어야 한다. 그래야 모든 가능한 거래가 투명하게 공개되고 양 당사자가 의도하지 않는 손실 없이 자산과 데이터를 교환 할 수 있다. 이 아이디어는 전통적인 온라인 결제 처리시스템에서 판매자가 거래를 완료하기 전에 허용 가능한 수준의 보증을 지정할 수 있도록 하는 모델에서 비롯된다.(예: PIN 입력, 서명된 영수증 등) 동일한 논리에 따라 거래당사자가 어떤 종류의 합의, 거래 완결성을 요구하는지 지정하도록 허용한다. 여기에는 KYC(Know Your Customer)준수를 요구하는 것을 포함해서 가능한 다양한 옵션을 제공해야 한다.

Transparency
생태계간 transfer 참가자들은 로컬과 글로벌에 영향을 줄 수 있음을 인식한다. 거부와 에러는 모든 참가자에게 적시에 전달되어야 한다. 이러한 투명성은 신뢰 할 수 있는 증거로 보여줘야 한다.

Automated workflows
복잡한 상호 운용성 사례를 지원하기 위해서 각 생태게에는 지원할 수 있는 논리가 존재해야 한다. 생태계간 전송은 이전 전송에 대한 응답으로 자동으로 트리거 될 수 있다. 오류 복구 및 예외 처리와 관련된 자동화 절차는 중단없이 실행되어야 한다.

Transaction Protocol Negotiation
트랜잭션 참여자는 트랜잭션을 실행하는데 사용할 프로토콜의 실행에 동의 하는 핸드쉐이크 메커니즘을 가지고 있어야 한다. 알고리즘은 참가자가 지원하는 알고리즘 목록에서 공통되는 부분을 찾는다.

Avoid modifying the total amount of digital assets on any blockchain whenever possible
디지털 자산의 총량을 늘리거나 줄이는 식으로 자산을 추가하거나 삭제하는 것은 복잡하며, 블록 체인의 보안을 해칠 수 있다.

Provide abstraction for common operations
블록 체인에서의 거래, 운영, 모니터링을 위한 공통 기능을 추상화해서 제공한다.

Integration with Identity Frameworks (Moonshot)
플러그인 아키텍처를 통해서 ID 프레임워크의 지원 목록을 확장 할 수 있도록 하라. 초기 지원시 고려할 ID 프레임워크들은 아래와 같다.

기능 요구사항

New Protocol Integration
커뮤니티가 원하는 기능을 제안, 개발, 테스트, 릴리즈 할 수 있도록 플러그인 아키텍처를 구성해서 새로운 프로토콜을 추가 할 수 있어야 한다.

Proxy/Firewall/NAT compatibility
가능한 경우 프록시 / 방화벽 / NAT를 통해 양방향 통신 채널 설정을 지원한다.

Bi-directional Communications Layers
가능한 경우 프록시/방화벽/NAT를 통해 블록체인의 트랜잭션을 제어하고 모니터링 하기 위한 양방한 통신채널을 사용한다.

Consortium Management

Working Plicies

아키텍처

Identities, Authentication, Authorization

용어들

머클트리(Merkle Tree)는 블록에 포함된 거래 내역을 이진트리 형식으로 요약한 것이다. 이진트리의 구조를 가지기 때문에 거래량이 늘어나도 빠르게(log2(N))으로 찾을 수 있다.

 머클트리