Contents

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(Fungible asset) : 대체 가능 자산(토큰 / 코인) - 다른 원장에 복제 할 수 없다.
  • NFA(Non fungible asset) : 대체 불가능한 자산 - 다른 원장에 복제할 수 없다.
  • D(Data) : 다른원장에 복제 할 수 있다.
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 코인에 더 많이 적용되며 암호화폐의 전체 가치가 증가하기 때문에 커뮤니티에 대한 기부가 될 수 있다.

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

  • 자산은 제네시스 블록의 코인베이스(coinbase)/제너레이션(generation) 트랜잭션 주소로 전송된다. 코인베이스/제너레이션 트랜잭션은 블록 채굴에 대해서 보상을 받는 주소로 채굴에 의존하는 모든 체인블록에 있다. 따라서 이것은 제네시스 블록을 채굴한 채굴자의 주소에 있는 토큰 / 코인을 소각하게 된다.
  • 토큰/코인은 사용자 계정 뿐만아니라 선택적으로 총 토큰/코인 공급가치에서도 참감될 수 있다.

Footnotes

  • Cactus는 블록체인의 상태를 증명하기 위해서 canonical validator node 서명을 사용한다. Cactus는 모든 유형의 블록 체인을 통합 할 수 있어야 하므로 머클트리(Merkle Tree) 기반의 접근 방식을 사용 할 수 없다.
  • Networkwide 원장보기는 모든 네트워크 노드가 블록체인의 상태를 도출하기 위해서 고려되어야 함을 의미한다. 즉 단일 블록체인의 노드 상태가 아님을 의미한다.
  • Cactus 의 validator 노드는 신뢰할 수 있는 제 3자 중계자와 유사하다. 신뢰 할 수 있는 제 3자 중개자, 연합체계(federation schemes), 공증체계(notary schemes)라는 용어는 블록체인이 이런 중개자를 통해서 다른 블록체인의 상태를 검색할 때 사용한다. 릴레이(relay)는 체인이 중개자에 의존하지 않고 직접 읽기, 쓰기 또는 이벤트 수신 작업을 통해 다른 블록체인의 상태를 검색 할 수 있는 경우 사용한다. 이 용어는 Polkadot의 중앙 릴레이 체인과 Ethereum 네트워크의 BTCRelay에 사용된다.
  • 다른 원장에 NFA를 복제하려는 사용 사례가 있을 수 있다. 그럼에도 불구하고 NFA는 다른 원장에서 데이터 패키지로 표현될 수 있기 때문에 다른 원장에는 NFA를 복제 할 수 없다는 입장을 고수한다.
  • 데이터의 경우 블록체인 A에서 블록체인 B로 복사 할 수 있다. 복사 후 블록체인 A에서 데이터 객체를 잠그거나 소각 하는 것은 선택사항이다.
  • 블록체인 A의 프로세스와 블록체인 B의 프로세스는 각각 atomic swap 과 원장 상호작용이 동시에 혹은 연속적으로 발생하는 것으로 볼 수 있다.
  • 작업(action)은 블록체인 A에서 수행되는 읽기 트랜잭션, 쓰기 트랜잭션 혹은 이벤트 일 수 있다. 이러한 유형의 원장 상호운용의 예는 아래와 같다.
    • 다른 블록체인에 작용하기 전에 다른 블록체인의 상태를 읽는 스마트계약인 크로스체인오라클.
    • 이벤트가 작동하기 전에 다른 블록체인에서 이벤트가 발생할 때 까지 기다리는 스마트컨트랙트
    • 블록체인 B에서 발생하는 작업에 따라 잠금 해제 조건을 가지는 예산 가집행 스마트 컨트랙트

사용 사례

Ethereum to Quorum Asset Trasnfer

  • Use Case Name : Ethereum to Qurum Escrowed Asset Transfer
  • Use Case 설명 : 사용자 A는 이더리움 레저에 자산을 가지고 있다. 사용자 A는 이더리움 원장에서 지정된 양만큼의 자산을 쿼럼원장으로 전송하기를 원한다.
  • Interworking patterns : 가치 전송(Value transfer)
  • Type of Social Interaction : 에스크로(Escrowed) Asset Transfer
  • Narrative : 사용자 A는 이더리움과 쿼럼에 여러 개의 계정을 가지고 있으며 전환율을 고려하여 이더리움 원장의 일부 자산을 쿼럼 원장으로 보내려고 한다. 이더리움에 전송된 자산은 쿼럼 원장에서 성공적으로 수신한 경우에만 Exchanger에 의해서 완료된다.
  • Actors : 사용자 A. 원장 계정과 이와 관련된 자산의 소유권을 가진 개인 또는 법인.
  • Goals of Actors : 사용자 A는 이더리움에서 전송된 자산의 소유권을 잃지만 쿼럼에서 교환된 자산 가치의 소유권을 갖게 된다.
  • Success Scenario : 전송이 성공된다. 자산은 이더리움 과 쿼룸 원장 모두에서 사용 할 수 있다.
  • Success Criteria : 쿼럼으로 자산이 성공적으로 전송된다.
  • Failure Criteria : 쿼럼으로 자산 전송이 실패한다.
 Cactus 시나리오

Escrowed Sales of Data for Coins

  • Use Case Name : Escrowed Sale of Data for Coins
  • Use Case
    • 사용자 A가 사용자 B에게 에스크로 거래를 제안한다.
    • 사용자 A는 자금을 배치하고 사용자 B는 데이터를 디지털 에스크로 서비스에 배치한다.
    • 그들은 에스크로 서비스에 서로의 자산을 전송하고 이를 관찰하면서 거래를 진행하기로 결정한다.
    • 에스크로 서비스는 이 정보를 거래 당사자 모두에게 공개한다.
  • Type of Social Interaction : Peer to Peer Exchange
  • Narrative
이 시나리오에서 가치를 가진 데이터는 컴퓨터에 저장된 일련의 비트(디지털 자산) 이다. 즉
  • 기계학습 모델
  • 광고 서비스를 위한 데이터베이스
  • 디지털 아트
  • 독점 소스코드 또는 소프트웨어 바이너리
  • 등등등 ...
사용자 A와 사용자 B는 사기 또는 의도하지 않은 시스템 실패로 부터 양쪽의 자산을 보호하기 위해서 에스크로와 Atomic swap 방식으로 Hyperledger Cactus 트랜잭션을 이용해서 데이터와 자금을 거래하려 한다. 트랜잭션 프로토콜의 핸드 셰이크 메커니즘을 통해서 A와 B는 거래를 사전에 동의할 수 있다.
  • 거래를 위한 주소 (원장, 지갑)
  • 양 당사자가 신뢰하는 에스크로 서비스 제공자
  • 가격 및 통화
DLT는 서로를 신뢰 하기 힘든 양 당사자간의 거래를 촉진 할 수 있다.

  • Actors :
    • 사용자 A : 데이터를 구매할 의사가 있는 개인 또는 비즈니스 조직
    • 사용자 B : 판매할 데이터를 가지고 있는 개인 또는 사업체.
  • Goals of Actors
    • 사용자 A : 데이터를 의해서 비즈니스 프로세스를 향상시키기려한다. 이러한 이유로 데이터에 엑세스하고 싶어한다.
    • 사용자 B : 가지고 있는 데이터를 이용해서 수입/이익을 창출하려 한다.
  • Success Scenario : 양 당사자는 에스크로를 이용해서 거래를 하기로 결정했으며, 사전에 정의한대로 거래가 완료됐다.
  • Success Criteria : 사용자 A는 데이터에 접근 할 수 있다. 사용자 B는 수익을 얻었다.
  • Failure Criteria : 양 당사자는 거래를 끝까지 완료하지 못했다.
  • Prerequisites
    • 사용자 A는 구매할 자금이 있다.
    • 사용자 B는 A가 구매할 데이터를 가지고 있다.
    • 사용자 A와 B는 거래를 위한 통화에 동의 할 수 있으며 에스크로 제공자에 대한 합의도 있다.
 BIF

Money Exchanges

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

Stable Coin Pegged to Other Currency

  • Use Case Title : Stable Coin Pegged to Other Currency
  • Use Case
    • 사용자 A가 자신의 렛저를 생성한다.
    • 사용자 A는 이 렛저를 위한 환경을 Hyperledger Cactus에 설정한다.
    • 사용자 A는 거래, 토큰 마이닝 및 소각을 위해서 Hyperledger Cactus에 인터페이스를 구현한다.
  • Type of Social Interaction : Software Implementation Project
  • Narrative : 초당 백만 트랜잭션의 처리 수준을 안정적으로 유지 할 수 있는 "ExampleCoin" 이라는 자체 코인을 유지하고 있는 사업자가 있다. 이들은 코인 에코를 확장하고 싶지만 네트워크를 직접 수정 할 경우 코인 에코에 커다란 영향을 줄 수 있기 때문에 어려움을 겪고 있다. 이들은 이들의 코인이 고정된 수의 비트코인/법정확폐로 교환될 수 있음을 보장하는 비트코인 양방향 페그를 설치하기로 선택한다.
  • Actors : 다른 통화로 안정화(peg) 하려는 원장 및 통화의 소유자 또는 운영자.
  • Goals of Actors
    • 자금을 backed 하여 통화에 대한 신뢰성을 확보한다.
    • 최소한의 상용구 코드로 필요한 소프트웨어를 구현 할 수 있어야 한다.(Hyperledger Cactus에 필요한 API, 라이브러리를 지원해야 함)
  • Success Scenario : 사용자 A는 자체 제작한 플러그인으로 Hyperledger Cactus 배포를 시작했다. 이제 사용자 A가 작성한 플러그인에서 제공하는 기능을 외부에 노출하는 Hyper ledger Cactus REST API를 활용하여 일반 사용자 애플리케이션 개발을 시작할 수 있다.
  • Success Criteria : (커다란)추가적인 개발 노력없이 Hyperledger Cactus 플러그인을 만들었다.
  • Failure Criteria : 개발하는게 너무 어렵다. 차라리 처음부터 개발하는게 나을 것 같다.
  • Prerequisites : 운영중인 원장 혹은 통화. 플러그인을 구현하기 위한 기술지식
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

  • Use Case Title : 의료 데이터의 접근제어
  • Use Case :
    • 사용자 A(환자)가 사용자 B(의료서비스 제공자)와 거래를 한다.
    • 사용자 B는 사용자 A의 디지털로 저장된 의료 기록에 대한 읽기 액세스 권한과 해당 의료 기록에 새로운 항목을 기록하기 위한 쓰기 액세스 권한을 요청한다.
    • 사용자 A는 액세스 권한을 요청하는 메시지를 받고 이를 허용한다.
    • 사용자 B는 원장별 액세스 제어 / 개인 정보보호 기능을 통해 사용자 A의 데이터에 대한 권한을 부여받는다.
  • Type of Social Interaction : Peer to Peer Data Sharing
  • Narrative : 두 의료 제공자가 환자 데이터 관리 시스템을 통합하기 위해서 자체 블록체인시스템을 구축했다고 가정해보자. 사용자는 두 플랫폼에서 개별적으로 데이터를 제어하고 동시에 Hyperledger Cactus를 이용해서 환자 데이터를 통합 할 수 있다. 사용자는 의료 제공자가 동의하는 세분화된 데이터에 대한 접근제어 목록을 정의 할 수 있다.
  • Actors :
    • 사용자 A : 의료제공자와 거래하는 환자
    • 사용자 B : 사용자 A에게 서비스를 제공하는 의료 서비스 제공자. 사용자 A의 이전 병력에 대한 접근권한에 따라 제공 서비스의 범위와 품질이 달라질 수 있다.
  • Goals of Actors
    • 사용자 A : 공유 데이터가 해커의 손이나 회색 데이터 시장에 들어가지 않았으면 한다. 데이터 공유의 혜택이 있어야 한다.
  • Success Scenario : 사용자 B(의료 서비스 제공업체)는 필요한 만큼의 정보에 더 이상 접근 할 수 없다.
  • Success Criteria : 데이터의 무결성에 대한 암호학적 증거가 있다. 공유 프로세스 중 데이터가 손상되지 않는다. 다른 행위자들이 우연히 또는 악의적인 방법을 통해 데이터에 무단 액세스 하지 않는다.
  • Failure Criteria : 사용자 B(의료 서비스 제공 업체)는 필수 데이터에 액세스 할 수 없거나 예상하지 않은 데이터에 액세스 할 수 있다.
  • Prerequisties : 사용자 A와 사용자 B는 개별 데이터 소유권, 액세스 제어 및 공유 기능을 지원하는 단일 원장 또는 두 개의 개별 원장에 등록된다.
 Healthcare Data Sharing with Access Contrl Lists

Integrate Existing Food Traceability Solutions

  • Use Case Title : Food Traceability Integration
  • Use Case :
    • 소비자가 소매점에서 식품을 평가하고 있다.
    • 소비자는 음식 유통을 추적할 수 있는 애플리케이션을 이용해서 유통과정을 추적한다.
    • 소비자는 음식 유통 정보를 기반으로 구매 결정을 내린다.
  • Type of Social Interaction : Software Implementation Project
  • Narrative : 조직 A와 조직 B는 소매업체가 판매하는 식품의 출처를 확인하는 문제를 해결하기 위해서 별도의 서비스를 가지고 있다. 소매 업체가 조직 A에서 식품 추적 솔류션을 구매한 반면 식품 제조업체는 조직 B의 식품 유통 솔류션을 사용하고 있다. 소매 업체는 고객에게 end-to-end 식품 유통 추적 기능을 제공하려고 하지만 솔류션이 서로 달라서 불가능하다. Cactus를 이용하면 사용중인 설류션에 상관 없이, 식품 유통 정보를 접근 할 수 있는 솔류션의 구축이 가능하다.
  • Actors
    • 조직 A, 조직 B : 제품의 생산에서 소매 선반에 배달되기 까지를 관리하고 있다.
    • 고객 : 소매 상품 상점에서 식품을 구매한다. 식품 구매전에 식품 생산에서 배달 까지의 과정을 추적하고 싶다.
  • Goals of Actors :
    • 조직 A, 조직 B : 소비자에게 식품이 배달되는 과정을 추적할 수 있는 방법을 제공한다.
    • 소비자 : 검증된 식품의 구매.
  • Success Scenario : 식품을 신뢰 할 수 있게 되면서 서비스 만족도가 올라간다.
  • Success Criteria : 소비자는 식품을 구매하기 전에 식품의 원산지를 확인 할 수 있다.
  • failure Criteria : 소비자는 식품의 출처를 부분적으로 혹은 완전히 확인 할 수 없다.
  • Prerequisites :
    • 조직 A, 조직 B : 자체적으로 식품 유통 추적 솔류션을 제공한다. Cactus에 통합 할 수 있어야 한다.

End User Wallet Authentication / Authorization

  • Use Case Title : 지갑에 대한 인증/권한
  • Use Case :
    • 사용자 A는 개인/공개키 쌍의 형태로 서로 다른 허가 및 무허가 원장에 대한 별도의 ID를 가지고 있다.
    • 사용자 A는 단일 API 또는 사용자 인터페이스를 통해 소유한 ID를 액세스 / 관리하기 위해서 Cactus를 사용하기로 결정한다.
    • 사용자 A는 신원확인 과정을끝낸다. 이제 Cactus를 활용할 수 있는 애플리케이션을 통해서 해당 ID에 연결된 지갑과 상호작용 할 수 있다.
  • Type of Social Interaction : Identity Management
  • Narrative : 여러 원장의 지갑에 대해서 서로 다른 신원 증명 세트를 보유한 사용자가 이들을 원할하게 통합하여 사용 할 수 있다.
  • Actors : Cacuts 배포내에서 ID를 통합하려는 개인 또는 기업
  • Goals of Actors : 사용자 A는 Cacuts 안에서 여러 ID들을 편리하게 관리 할 수 있다.
  • Success Scenario : 사용자 A는 각 개인키에 개별적으로 액세스하지 않고도 지갑과 상호작용 할 수 있다.
  • Success Criteria : 사용자 A의 자격 증명은 손상될 가능성이 가장 적은 Cactus 키 체인 구성 요소에 안전하게 저장된다.
  • Failure Criteria : 사용자 A가 여러가지 이유로 Cactus에서 ID를 가져올 수 없다.
  • Prerequistes : 사용자 A는 다양한 원장의 ID를 가지고 있어야 하며, 개인 정보에 대한 액세스 권한이 있다.
 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 프레임워크들은 아래와 같다.
  • Hyperledger Indy
  • DIF
  • DID

기능 요구사항

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

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

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

Consortium Management

Working Plicies

아키텍처

Identities, Authentication, Authorization

용어들

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

 머클트리