Processing math: 100%

Hyperledger Cactus overview

2023. 6. 14. 10:46ㆍBlockchain/Overview series

728x90
반응형

※ 원글 작성 : 22년 5월 11일

 

블록체인 플랫폼 간의 연동에 항상 관심이 있어서 예전에 이름만 보고 내부 아키텍처 등은 확인하지 않았었던, Hyperledger project들 중 'Cactus'에 대해 알아보며, 어떤 개념인지, 어떤 구조인지 확인해보려 한다.

도입 목적

Cosmos 등 interchain을 위한 블록체인 플랫폼들이 존재하지만, 대다수의 블록체인 플랫폼들은 다른 체인들과 연동에 큰 힘을 쏟지 않고 있기 때문에 Hyperledger 재단에서 이기종 체인간의 연결을 쉽게 하기 위한 'Cactus' 프로젝트를 실시하였다. Hyperledger Cactus는 블록체인 플랫폼에 구애받지 않고 다양한 이기종 블록체인에 배포할 cross-chain 비즈니스 로직을 위한 모듈 아키텍처를 제공한다.

Blockchain Interoperability

Cactus의 overview 전에 Interoperability를 이해하기 위한 사전 필요 지식에 대해 정리한다.

Interoperability mode

Interoperability 솔루션이 지원하는 모드는 크게 3가지로 분류할 수 있다. 해당 모드들이 체인 간 연결의 주요 목적이라고 볼 수 있겠다.

  • Data transfer : 데이터를 한 체인에서 다른 체인으로 복사하는 방식이 있다. Relayer, gateway 등의 middleware를 통한 중간 처리 후 다른 체인으로 데이터가 복사될 수 있다.
  • Asset transfer : 단방향/양방향으로 한 체인에서 다른 체인으로의 자산 이동을 (src DLT network에서 burn/lock을 통한) 뜻한다. 비트코인 블록체인에서 lock 후 이더리움에서 mint하는 방식
  • Asset Exchange : 각각의 체인에서 exchage되며 체인 간 transfer는 발생하지 않는다. Exchage가 발생하기 위해서는 참가자가 두 체인 모두에 있어야한다. e.g. HTLC

유의해야할 점으로, 위의 asset(자산)은 FT만 해당이 되며 NFT는 transfer/exchange를 할 수 없다. 자산은 lock이든 burn이든 하나의 체인에서만 존재해야 하며, 다른 블록체인에서의 동일한 코인/토큰의 이중 지불을 방지해야 한다.

Connection mode

dApp/mdApp이 체인(DLT)에 연결하는 방법은 아래와 같다.

  • DLT node : DLT 프로토콜을 실행하는 SW 시스템
  • DLT proxy/DLT gateway : 애플리케이션과 DLT 노드간의 라우팅 및 로드 밸런싱을 관리한다. 앱 단에서는 DLT node나 DLT proxy와 통신하는 req/res는 거의 동일한 방식이다.

Design pattern

체인 간 디자인 패턴을 위한 확인 전에, 아래 그림들의 legend를 정리한다.

  • Object 1/2
    O1/O2
  • Transaction 시작 시 Obj 상태
    Obegin1/Obegin2
  • Transaction 종료 시 Obj 상태
    Oend1/Oend2
  • 다른 블록체인에서의 Transaction 종료 시 O_1/O_2의 표현
    ¯O1end/¯O2end
  • Transaction 1/2
    T1/T2
  • 다른 블록체인에서의 Transaction 1/2
    ˉT1/ˉT2
  • Event 1
    E1
  • O, T, E에 depend된 event 2
    E2(O1||T1||E1)
  • O, T, E에 depend된 transaction 2
    T2(O1||T1||E1)
  • Ledger transfer

    자산이 한 블록체인 내에 lock/burn 후에 동일한 가치를 지닌 양만큼 다른 블록체인에서 unlock/mint된다. 항상 동일한 자산이 각 블록체인에 따로 표시될 수 없고, 동일한 데이터가 다른 여러 블록체인으로 transfer 될 수 없으므로, 위 interoperability model 중 'Data transfer'는 Ledger transfer design pattern으로 만들지 않는다. Blockchain A에서 B로 한방향(1-way)으로만 가능한지, 두방향 모두(2-way) 가능한지에 따라 ledger transfer 방식이 두가지로 나뉠 수 있다.
  • Atomic swap

    Write Transaction(~=Invoke transaction)이 Blockchain B의 다른 write transaction과 동시에 Blockchain A에서 수행된다. 각 블록체인 env에서 벗어나는 자산/데이터/코인이 없고, 두 블록체인 env는 분리되어 있지만 interoperability 구현으로 인해 두 체인 모두에서 commit 된다.
  • Ledger interaction

    Blockchain A에서 발생하는 'Action'은 B에서도 action을 일으키고 있다. Blockchain A의 상태는 Blockchain B의 상태도 변경시키며, BC 중 하나의 상태만 변경가능한지에 따라 단방향/양방향 원장 interaction이존재한다.
  • Ledger entry point coordination

    단일 entry point에서 각각의 체인에 대한 read/write 권한을 가지는 end user의 wallet으로 transaction을 제출하여 interoperability를 가진다. 클라이언트에서 제출한 모든 read/write transaction은 각 블록체인으로 전달된 다음 블록체인이 자체적으로 commit한다.

단일성(unicity)를 보장하기 위해 위의 예시들처럼 자산은 다른 블록체인으로 전달되기 전에 Burning or Locking되어야 한다. Lock된 자산은 해당 자산의 원래 체인으로 다시 전송될 때 잠금을 해제할 수 있지만 Burn된 자산은 되돌릴 수 없는 프로세스이다. 자산의 lock/burn은 ledger transfer 중에 발생되지만 atomic swap의 경우 양쪽 체인에 wallet이나 계정이 있는 경우 사용가능하기 때문에 lock/burn을 피할 수 있어서 많은 거래소들은 atomic swap을 사용하여 FT 자산을 소각하지 않는다.

Architecture

Cactus의 전체적인 아키텍처는 위 그림과 같다. Execution은 service provider에서 cactus 비즈니스 로직 플러그인으로 제공할 cactus 모듈에서 제어되고, cactus에서 지원하는 블록체인 플랫폼은 새로운 cactus ledger 플러그인을 구현하여 추가할 수 있다. End user가 cactus 프레임워크에 대한 API호출을 요청하면 비즈니스 로직 플러그인이 실행해야할 ledger를 결정하고 서비스를 제공한다.
시스템 아키텍처는 아래 component들로 구성된다.

  • Business Logic Plugin : 비즈니스 로직을 실행하고 블록체인들과 연결된 통합 서비스를 제공한다. 해당 플러그인은 웹 어플리케이션이나 smart contract로 구성된다. Business logic plugin은 단일 플러그인이며 Cactus 어플리케이션을 실행 시 사용된다.
  • Cactus node server : Server는 end user 어플리케이션의 요청을 받고 transaction 상태에 따라 response한다. 새로운 trade가 발생하면 trand ID가 할당된다.
  • End user application : Entity는 비즈니스 로직 플러그인에 의해 ledger에서 transactions를 호출하는 trade를 위해 API를 호출한다.
  • Ledger event listener : 비동기 ledger 작업과 관련된 이벤트(LedgerEvent)를 처리하기 위한 표준 인터페이스이다. LedgerEvent는 비즈니스 로직에의해 통지된다.
  • Ledger plugin : Ledger 및 Business Logic Plugin과 통신하며, validator와 verifier로 구성된다.
  • Service provider application : Ledger plugin을 활성화/비활성화 하거나 종료 시 cmd-api-server를 제어하기 위한 API를 호출한다.
  • Validator : Ledger 상의 트랜잭션을 모니터링하고 트랜잭션 기록에서 결과(성공, 실패, 타임아웃)을 판별한다. Validator는 Verifier가 확인 가능한 Validator key와 함게 signature를 작성하여 결과의 신뢰성을 보장한다.
  • Validator server : 서버는 Validator로부터 connection되며, 서명된 트랜잭션을 발행한다. Ledger를 모니터링하는데 사용가능한 Validator API를 제공하며, LedgerConnector는 ledger와 상호작용하기 위해 구현된다.
  • Verifier : Validator의 전자서명을 검증하여 검증완료된 결과만 수용한다. Verifier는 연결할 Validator와 연결된 VerifierFactory#create 메서드를 호출하여 instance화 한다. 각 Verifier는 일시적으로 활성화/비활성화 가능하다.
  • Verifier registry : 활성 Verifier에 대한 정보를 가지며, VerifierFactory는 이 정보를 통해 Business logic plugin에 대한 verifier를 인스턴스화 한다.

Bootstrapping Cactus application

  1. Start Validator : 사용되는 기술/블록체인 플랫폼(Fabric, Besu, etc.)에 따라 선택된 Ledger plugin의 Validator는 Validator admin으로부터 시작된다. Validator는 initialization process가 종료된 후 Verifier로 부터 connection을 accetp하기 위해 ready 상태가 된다.
  2. Start Business logic plugin implementation : Cactus 어플리케이션 서비스의 admin이 Business logic plugin을 시작한다. Business logic plugin 수행은 먼저 depend된 Ledger plugin(s)의 가용성(availability)을 확인하고, Ledger의 통합을 위해 커스터마이즈된 프로필로 각 Ledger plugin이 enable 시킨다. 이 가용성은 또한 Verifier에서 Validator로의 연결 상태를 결정하는것도 확인한다.각 Ledger의 가용성은 Cactus routing interface에서 등록 및 유지되며, Business logic plugin과 Ledger간의 양방향성 메시지 comm.을 가능하게 한다.

Processing Service API call

Step 1: Application user(s)는 Cactus routing interface로 API call을 제출한다.
Step 2: API call은 associated business logic을 초기화 목적으로 내부적으로 Cactus routing interface에 의해 Business logic plugin으로 라우팅된다.
Step 3: Business logic plugin은 Ledger plugin(s)로 래핑된 (wrapped)Ledger(s)의 동작을 request 하기 위해 API call을 제출한다. 각 API call은 Routing interface에 의해 지정된 Ledger plugin으로 라우팅된다.
Step 4: Ledger plugin은 하위 component Verifier가 Ledger에 요청된 원장 작업과 관련한 이벤트를 감지하면 Cactus routing interface를 통해 Business logic plugin에 이벤트 알림을 보낸다.
Step 5: Business logic plugin은 Ledger plugin으로부터 메시지를 받아 비즈니스 로직의 완료 여부를 판단한다. 비즈니스 로직이 지속적인 작업을 요구할 시 Step 3로 이동하거나 프로세스를 종료한다.

APIs and comm. protocols between Cactus components

Cactus service API overview

Cactus service API는 어플리케이션 user들에게 노출되어 있다. 해당 API는 Business logic plugin으로 실행되는 비즈니스 로직을 초기화하기 위한 request로 사용된다. 또한 비즈니스 로직이 완료될 시 실행 상태 및 최종 결과를 inquery 하는 데에도 사용된다. Cactus service API는 RESTful API에 따라 'trade' 리소스가 연결된 CRUD 작업 중 하나의 request를 mapping할 수 있다.

Open endpoint & Restricted endpoint

Open endpoint는 인증이 필요없다. 'Login' API가 존재한다.

제한된 endpoint들은 request의 헤더에 포함되어 있는 유효한 토큰이 필요하다. 토큰은 위의 Login을 호출함으로써 획득할 수 있다.

현재로써는 이 API의 종류에 관심이 없으므로 종류와 REST API 형식에 대해서는 pass..

Ledger plugin API

Ledger plugin API는 Business logic plugin이 Verifier 및 Validator의 components 뒤에 있는 ledger를 컨트롤 및 모니터링 할 수 있도록 설계되었다.
Validator는 Verifier와 ledger 간의 통신을 추상화하는 기능을 제공한다. Validator는 ledger의 자산을 조작할 권한이 없고, Verifier는 Business logic plugin에서 요청을 수신하고 응답 및 이벤트를 async로 response 가능하다.

Verifier 및 Velidator의 API는 아래 표와 같다.

No. Component API name Input Description
1. Verifier sendAsyncRequest contract(object) method(object) args(object) Validator로 async req를 보냄
2. Verifier sendSyncRequest contract(object) method(object) args(object) Validator로 async req를 보냄
3. Verifier startMonitor id(string) eventListner(VerifierEventListener) ledger 모니터링을 위해 Verifier에 요청
4. Verifier stopMonitor id(string) ledger 모니터링 중지를 위해 Verifier에 요청
5. Validator sendAsyncRequest args(object) Validator가 Verifier로 부터 async operation 요청을 수신할시 called
6. Validator sendSyncRequest args(object) Validator가 Verifier로 부터 sync operation 요청을 수신할시 called
7. Validator startMonitor cb(function) ledger의 모니터링이 필요할 시 called
8. Validator stopMonitor None ledger의 모니터링이 더이상 필요없을 시 called

API의 상세한 정보는 아래에서 확인 가능하다.
packages/cactus-cmd-socketio-server/src/main/typescript/verifier/LedgerPlugin.ts

  • Interface IVerifier
  • interface IVerifier { // BLP -> Verifier sendAsyncRequest(contract: Object, method: Object, args: Object): Promise<void>; sendSyncRequest(contract: Object, method: Object, args: Object): Promise<any>; startMonitor(id: string, options: Object, eventListener: VerifierEventListener): Promise<void>; stopMonitor(id: string): void; }
  • Interface IValidator
  • interface IValidator { // Verifier -> Validator sendAsyncRequest(args: Object): Object; sendSyncRequest(args: Object): Object; startMonitor(cb: function): Promise<void>; stopMonitor(): void; }

Plugin architecture

Cactus 프로젝트에서 가장 궁금했던 플러그인의 아키텍처이다. 어떠한 플러그인이 존재하는지, 해당 플러그인이 어떤 기능을 가지고 다른 체인과 연동을 가능케 하는지 확인해보려 했었다. 하지만, 참고한 글은 whitepaper여서 상세한 기능 동작에 대해서는 설명이 없었다. 어떤 플러그인이 존재하는지 정도만 확인 가능했어서, 다음번에는 Cactus 내부 동작을 분석한 글이 있다면 해당 글을 참고해서 한번 더 작성해보려 한다. 만약 없다면....

Cactus의 목표는 대부분의 ledger를 통합하는 것이기 때문에 유연성을 가지려한다. 이에 Cactus 플러그인을 사용하여 운영자가 원하는대로 구현하는 것을 지원하기 위한 추상화 계층이다.
위 그림에서 보면, end user 'Bob'이 Transaction execution을 요청한다. 요청을 받은 API server node는 FabricConnectorPlugin으로 Transaction execution plugin을 Call을 한다. 이처럼 플러그인은 Tx 실행과 같은 특정 기능들에 대해 정의된 인터페이스가 포함되어 있기 대문에 기능별로 구현하여 유연성을 보장하려 한다.

Ledger connector plugin

Ledger connector plugin의 특성은 다음과 같다.

  • 아직 생겨나지 않은 블록체인 플랫폼에 대해서도 연결을 지원하기 위해서 core 코드 변경 필요 없이 connector plugin만 추가하면 구현할 수 있다.
  • REST API를 사용하는 클라이언트 어플리케이션에 배포된 connector plugin의 수와 특성에 관계 없이 100% 기능을 유지할 수 있다.
  • 다른 ledger의 기능이 매우 다양하기 때문에 plugin 인터페이스에는 callers/client 어플리케이션이 지정된 ledger에 지원되는지 여부를 프로그래밍 방식으로 결정 가능토록 하는 '기능 검사'가 내장되어 있다.
export interface LedgerConnector {
  // method to verify a signature coming from a given ledger that this connector is responsible for connecting to.
  verifySignature(message, signature): Promise<boolean>;

  // used to call methods on smart contracts or to move assets between wallets
  transact(transactions: Transaction[]);

  getPermissionScheme(): Promise<PermissionScheme>;

  getTransactionFinality(): Promise<TransactionFinality>;

  addForeignValidator(): Promise<void>;
}

export enum TransactionFinality {
  GUARANTEED = "GUARANTEED",
  NOT_GUARANTEED = "NOT_GUARANTEED"
}

export enum PermissionScheme {
  PERMISSIONED = "PERMISSIONED",
  PERMISSIONLESS = "PERMISSIONLESS"
}

Ledger connector plugins for Blockchains

Whitepaper에서 확인 가능한 Ledger connector plugin(이하 LC plugin)이 지원하는 블록체인의 종류와, 어떤 기능을 제공할 수 있는지를 확인해본다.

  • LC Besu plugin
    • Bytecode를 통해 smart contract 배포
    • 다른 키 저장소를 활용하여 트랜잭션 build & sign
    • 네트워크에 배포된 smart contract 기능 호출
  • LC Corda
    • 원하는 plugin으로 구성된 Cactus API 서버와 함께 JVM 어플리케이션을 배포
    • 다른 종류의 변수로 contract flow 호출
  • LC Fabric Socketio
    • sendSyncRequest : Ledger에 동기화 유형 요청(e.g. getBalance)
    • sendAsyncRequest : Ledger에 비동기식 유형 요청(e.g. sendTransaction)
    • startMonitor : Ledger에서 블록 모니터링
    • stopMonitor : 모니터링 중지
  • LC Fabric plugin
    • Go기반 chaincode 배포
    • Ledger에서 트랜잭션 실행
    • 네트워크에 배포된 체인코드 기능 호출
  • LC Go-eth Socketio
    • sendSyncRequest : Ledger에 동기화 유형 요청(e.g. getBalance)
    • sendAsyncRequest : Ledger에 비동기식 유횽 요청(e.g. sendTransaction)
    • startMonitor : Ledger에서 블록 모니터링
    • stopMonitor : 블록 모니터링 중지
  • LC Iroha plugin
    • 다양한 Iroha command 및 query 실행
    • 임의의 credential(증명)을 사용하여 트랜잭션 build & sign
  • LC Quorum plugin
    • Bytecode를 통해 smart contract 배포
    • 다른 키 저장소를 활용해 트랜잭션 build & sign
    • 네트워크에 배포된 smart contract 기능 호출
  • LC Sawtooth Socketio plugin
    • startMonitor : Ledger 블록 모니터링
    • stopMonitor : 블록 모니터링 중지
  • LC Xdai plugin
    • Bytecode를 통해 smart contract 배포
    • 다른 키 저장소를 활용하여 트랜잭션 build & sign
    • 네트워크에 배포된 smart contract 기능 호출

HTLC plugin

다양한 블록체인 네트워크에서 사용되고 있는 HTLC(Hash Time Locked Contracts)를 배포하고 interaction 할 수 있는 API를 제공한다.

HTLC plugins for Blockchains

  • HTLC-ETH-Besu plugin
    • Ledger Connector Besu plugin을 사용하여 네트워크에 HTLC를 배포하고 HTLC ETH 스왑 smart contract와 상호작용 가능한 API를 제공
  • HTLC-ETH-ERC20-Besu plugin
    • Ledger Connector Besu plugin을 사용하여 네트워크에 HTLC 및 ERC20 contract를 배포하고 해당 contract들과 상호작용 가능한 API를 제공. HTLC ETH swap contract에서 ERC-20 토큰과 상호작용 가능하다.

Other plugins

Identity Federation plugins / Key/Value storage plugins / Manual consortium plugins 가 존재한다. 상세 내용은 여기 참고

Transaction Signing Models, Key Ownership

Cactus를 사용하는 어플리케이션 개발자는 사용자(users)의 Cactus account로 인증을 통해 복호화하도록 만드는, 멀리 떨어진 Cactus의 pri key를 저장 서버사이드에 private key를 disclosing하는 것 없이 사용자들의 agent 디바이스에서 트랜잭션에 서명 할 수 있게 선택할 수 있다. Transaction signing 방식들은 각각 장단점이 존재하여 시스템 설계시에 고려해야한다.

Plugin 중 키관리 plugin을 통해 key/value를 저장, 검색하는 방식을 개발자가 설정할 수 있다.

Client-side transaction signing

End user가 프라이버시 보호에 더 높은 기대치를 가질 때 사용될 수 있는 방식이다.
  • 장점
    • Cactus 배포가 손상(compromised)될 때 key가 손상되지 않는다.
    • Operator는 Cactus 키 위반 시 책임을 지지 않는다.
    • 서버단의 복잡도가 감소한다.(중앙 키관리 필요 없음)
  • 단점
    • UX는 서버측에서 트랜잭션 서명하는 방식에 비해 좋지 않다.
    • 사용자가 키를 분실하면 영구적으로 접근 권한을 잃는다

Server-side transaction signing

일반적으로 규정 준수, 거버넌스, 내외부 정책 시행 시 엄격한 요구사항이 존재하는 엔터프라이즈 어플리케이션에 적합한 방식이다.

  • 장점
    • End user가 키를 직접 관리해야하는 부담이 없어진다.(더 나은 UX)
  • 단점
    • 서버측 공격으로 인해 키체인에 저장된 암호화된 키가 노출될 수 있다.

Conclusion

Hyperledger 프로젝트는 블록체인 거버넌스의 발전을 위한 다양한 시도를 많이 하고 있는데, 그 중 블록체인 간의 연결을 위한 시도를 Cactus를 통해 하고 있다. Cosmos의 IBC는 내가 관심이 있어서 그런지 사용되는 case를 조금씩 보고 있었는데, Cactus는 적용되고 있는 분야들을 잘 보지 못해서 조금 아쉬운 부분이 존재했다. Github에 나와있는 whitepaper나 readme도 몇년간 변경되는것 없이 그대로 있었어서 많이 진행되지는 않고있구나 했는데,, 글 게시 바로 직전에 Hyperledger Cactus Release 1.0.0을 확인했다. 22년 5월 10일이니 게시 바로 전날이다. 해당 문서에서 build instructions등이 있으니 시간 날 때 다운받아서 테스트도 해보면 좋을것 같다.
Release 문서에도 whitepaper가 들어가있었는데, Ledger connector plugin의 종류는 ethereum, corda, besu, fabric 등 앞서 확인했던 블록체인 외에 추가된 플랫폼은 없어보인다. Local로 Fabric과 ethereum을 띄워놓고 Cactus가 어떻게 connection을 유지하는지 다음 기회에 확인해 봐야 할 것 같다.

참고
https://github.com/hyperledger/cactus/blob/main/whitepaper/whitepaper.md

```

728x90
반응형

'Blockchain > Overview series' 카테고리의 다른 글

Private transaction 전송을 위한 Tessera Overview  (0) 2024.11.08
Oasys Overview  (0) 2023.07.10
BSC(Binance Smart Chain) overview  (0) 2023.06.14
Flow blockchain (w/NBA Top Shot) overview  (0) 2023.06.14
Tendermint Consensus overview  (0) 2023.06.14

티스토리툴바