[블록체인] - 하이퍼레저 패브릭(Hyperledger fabric) & 관련 용어

jsbak·2021년 7월 20일

Hyperledger fabric 하이퍼레저 패브릭

BlockChain

목록 보기

1/6

Hyperledger fabric 개요

ledger : 회계 용어로 회계 원장이라는 표현

하이퍼 레저 패브릭이란?

Hyperledger Fabric은 엔터프라이즈 컨텍스트에 사용하도록 설계된 오픈 소스 엔터프라이즈급 허가된 분산 원장 기술(DLT) 플랫폼으로 분산 원장과 합의(Consensus)를 비롯해 사용자 ID 발행과 인증, 스마트 계약의 개발과 실행, 기밀성 등의 기능을 제공한다.

하이퍼레저 프로젝트는 가상 화폐 뿐만이 아니라 광범위한 비즈니스 용도의 블록체인 플랫폼을 제공을 목적으로하는 오픈소스 프로젝트이다.

하이퍼레저 패브릭의 특징

컨소시엄형 참가 방식
- 허가형 블록체인 고 신뢰 네트워크 형성
- 조직내 사용자와 노드를 독립적 관리
가볍고 빠른 합의 방식
- 원장 갱신은 합의와 Finality(정당성을 최종 확인한 상태) 동일성 확보
- 허가형 구조로 참가조직기관이 가볍고 빠르게 정당성 동일성 확보
다양한 업무 처리 구현
- 스마트 계약 체인코드를 통해 자신만의 업무 로직을 만들고 실행 가능
트랜잭션 실행 직후의 상태 보존
- State DB(상태 DB)라는 데이터 저장소에 트랜잭션을 실행 직후의 상태를 저장, 이를 통해 모든 블록 체인을 참조할 필요 없이 해당 시점의 상태 확인 가능
채널을 사용한 블록체인 네트워크의 논리적 분할
- 채널 : 분할 네트워크
- 분리된 채널간 체인코드와 분산 원장 공유 불가

하이퍼레저 패브릭 구성요소

Hyperledger Fabric Client SDK
- 하이퍼레저 패브릭 기능을 이용하기 위한 API 제공
- Node.js, Java ... 제공
Organization(조직)
- 네트워크 참여 조직을 나타내는 논리적 단위
- 각 피어와 오더러는 조직에 소속
Peer(피어)
- 조직 내 노드를 나타내는 논리적 단위
- 블록체인, 상태DB, 체인코드 보유
- Endorser(보증인), Commiter역할, 성능을 고려해 커미터역할만 가진 피어만 배치 가능
- Endorser 역할 수행시 클라이언트 요청에 따라 트랜잭션에 대해 Endorsement(보증)한다.
Order
- 보증된 트랜잭션의 결과를 블록체인과 상태 DB에 기록하는 순서를 제어(이중화 구성-단일 장애점 방지, 분산 메시징 기술인 Apache Kafka를 사용할 수 있다.)
Chaincode(체인코드)
- 스마트 계약을 구현하기 위한 프로그램으로 전용 컨테이너에서 실행
- 트랜잭션 요청에 따라 실행(보증되는 순간에 실행되나 상태 DB에는 갱신될 때 저장)
- 상태DB를 읽고 쓰거나 과거의 상태 DB에 기록된 내역(블록 내에 포함)을 조회가능
- 여러 체인코드를 만들 수 있으며 한 체인코드에서 다른 체인 코드를 호출가능
- 체인코드가 상태 DB에 저장한 데이터를 다른 체인코드에서는 읽을 수 없다는 제약이 존재
분산 원장 기술
- 참자가간 원장(동일한 정보)공유
원장(ledger)
- 블록체인 + 상태 DB
블록체인
- 다른 블록체인과 동일한 구조이나, 상태 DB 저장된 내용(RWSet)을 블록안에 저장, 이런 구조덕에 체인코드로 과거에 상태 DB에 저장한 이력을 조회 가능
상태 DB
- 트랜잭션을 실행한 결과로 최신상태를 저장하는 데이터 저장소
- LevelDB(Key-Value)형식을 사용하나 JSON 형식의 Apache CouchDB를 이용하기도 한다.
MSP(Membership Service Provider)
- CA와 연계해 사용자 등록 및 Ecert 발행(사용자 인증서)
Endorsement Policy(보증 정책)
- 정책 규정후 체인 코드에 할당
Channel(논리적 분리 네트워크)
- 한 개의 네트워크안에 독립된 여러 채널이 존재하는 것이 가능(MultiChannel).
- 각 채널은 동일한 분산 원장(상태DB와 블록체인) 보유

트랜잭션 처리 흐름

하이퍼레저 패브릭 네트워크에서 트랜잭션을 실행하기 위해서는 사용자 등록을 해야 한다. 체인코드나 전 단계의 응용 프로그램(웹 응용 프로그램 등) 설계에 따라 조직 단위로 할지 개인 단위로 할지 선택

1. Transaction Proposal
클라이언트로부터 체인 코드 실행 요청을 받는다(트랜잭션제안), 보증정책에 구현된 정책에 따라 대상이 되는 조직 내에서 임의의 보증인(피어)에게 보증요청을 한다.

2. 보증인이 체인 코드를 시뮬레이트 한다.
상태 DB에는 저장 내용이 없고 RWSet(read/write set)을 생성, RWSet은 키항목, 버전번호, 그 버전 정보, 쓸 값을 담고 있다.

3. 보증인이 서명한 RWSet을 클라이언트에게 돌려준다.
해당 트랜잭션은 대상 조직으로부터 보증된 것으로 취급

4. 클라이언트는 여러 조직 내 보증인으로부터 받은 서명된 RWSet을 통해 보증 정책이 충족된 것을 확인
그 정보를 바탕으로 트랜잭션 제어를 오더러에게 요청(제출)

5. 오더러는 트랜잭션 순서제어, 정렬된 트랜잭션(서명된 RWSet)은 커미터(피어)에게 배포
1 블록당 최대 트랜잭션 수 또는 시간 제한에 따라 이루어 지고 가십 Gossip 프로토콜이 이용

6. 커미터가 트랜잭션(서명된 RWSet)을 검증, 검증이 성공하면 블록체인 및 상태 DB를 갱신(Commit)
트랜잭션 검증은 보증 정책이 충족 되었는지 확인함과 동시에 RWSet에 저장돼 있는 키 항목의 버전 번호와 현재 상태 DB 내에 해당하는 키 항목 버전 번호가 일치하는가 검사, 이처럼 버전 번호를 검사해서 최신 데이터가 아닌 내용이 상태 DB에 저장되는 것을 방지하는 "낙관적 배타 제어"를 실현

7. 커미터는 이벤트를 발행해 클라이언트 측에 트랜잭션 검증의 성공과 실패를 통지
검증결과 배타제어 에러가 발생한 경우 이용자가 직접 처음부터 시도하거나 클라이언트(웹 브라우저 등) 자동으로 처음부터 재시도하게끔 해야 한다.