Hyperledger Fabric Concept 정리

기존의 공개형 블록체인은 누구나 참여하고 검증 가능한 플랫폼이다.

하지만, 블록 생성과 전파에 많은 컴퓨팅 자원과 네트워크 리소스를 필요로 하는 단점도 존재한다.

 

반면에, Permissioned blockchain은 인증 받은 사용자만 접근이 가능하기 때문에 블록 생성과 전파에 대한 코스트가

공개형 블록체인 보다 상대적으로 적고 안정적이다.

Permissioned blockchain의 종류 중 가장 널리 알려져 있는 Hyperledger Fabric에 대한 핵심 내용들에 대해 살펴보자.

 

HyperLedger Fabric 

허가된 사용자만이 블록체인에 참여할 수있는 Permissioned Blockchain.

원장이라는 자원에 접근하여 수행 할 수 있는 동작의 범위도 정할 수 있다.

Hyperledger Fabric에서 핵심이 되는 사안은 인증과 인가를 연계한 원장의 공유이다.

 

 

핵심용어

• 채널(Channel) : 네트워크에서 구성 요소 간 그룹을 나눠 Transaction을 수행해야 할 때 사용한다. Transaction의 접근 권한을 그룹별로 설정하고 관리하는 중요한 Private blockchain 기술 요소이다.

 

• 조직(Organization) : 네트워크는 조직 단위로 구성 되는데, 조직 별로 Peer node 관리 및 권한부여 보증 정책등을 수행하며 네트워크 참여자의 접근 권한도 관리한다.

 

• 피어 노드(Peer Node) : 가장 기본적인 네트워크 구성 요소로, 블록체인 네트워크를 유지하고 transaction의 제안 및  응답을 처리하며 원장과 체인코드를 관리하고 저장하는 역할을 수행한다. Peer노드의 종류에는 1. Endorsing 2. Committing 3. Anchor 4. Leader Peer 5. Ordering Service Node가 있다.

 

• 컨소시움(Consortium) :  블록체인 네트워크 상에 존재하는 non-orderer peer의 모음, 이것들은 채널을 형성하고 Join하는 조직들이고 자신의 Peer를 소유한다. 블록체인 네트워크는 여러 개의 컨소시움을 가질 수 있지만, 대부분 하나만 가진다.채널 생성시에는 채널에 추가된 모든 조직들은 특정 컨소시움에 포함되어 있는 상태여야한다.

 

• World State : Hyperledger fabric 원장의 일종으로, chain transaction 로그에 포함된 모든 key들의 최근 값들을 표현한다. Chain code는 전체 Transaction log를 순회하며 Key를 계산하기 보다는 World State가 이러한 Key의 최신 값에 대한 직접적인 접근을 제공하기 때문에 World-state 을 통해서 Transaction proposal을 실행한다. World state는 key 값들이 수정될 때마다 변화한다. 그렇기 때문에, World state는 Transaction flow에 있어 매우 중요하다. 왜냐하면 key-value 쌍의 현재 상태는 그것이 변경되기 이전에 반드시 알아야하는 값이기 때문이다. 각 Peer들은 유효한 Transaction을 처리한 후 처리 된 블록의 값을 world state 원장에 저장한다.               

+ World State 추가 : 원장의 현재 상태를 말한다. 반면에 블록체인은 거래의 모든 기록을 보관한다. world state를 데이터베이스로 구축하게 되면 사용자들이 데이터를 저장하고 읽어올 때 여러가지 기능을 활용할 수 있다. 패브릭에서는 key-value 타입의 LevelDB와 JSON포맷의 저장 방식을 사용하는 CouchDB 중 하나를 택하여 World state DB를 구축할 수 있다.world state에는 version이라고 하는 필드가 존재하는데, peer는 world state 에 transaction을 업데이트 하기 전 transaction과 world state 의 버전이 맞는지 체크한다. 

 

하이퍼레저 패브릭의 분산원장은 현재 상태를 나타내는 World State, 원장의 생성 시점부터 현재까지의 기록을 저장하는 블록체인 2가지로 구분할 수 있다.

 

World state는 데이터베이스의 형태로 블록체인과 구분 되어 있다.

이와 관련된 특성은 다음과 같다. 

• World state에 저장된 데이터는 합의 과정에 의해 블록체인에 포함되기 전까지 체인코드를 통해 조회/변경/삭제가 가능하다. 
• 합의에 의해 결정된 블록 및 블록체인은 절대 수정할 수 없다. (Non-deterministic, Fork 문제 해결)
• World State는 데이터의 기록, 수정, 읽기 등이 빈번하게 발생하기 때문에, (분산)데이터베이스로 구축되어있다.
• 블록체인(Transaction log)는 데이터 요청이 거의 없고, append-only 방식의 저장이 목적이기 때문에 파일 시스템 형태로 저장되어 있다.

 

 

• State DB: World State의 Data가 state database에 저장된다. (chaincode를 읽어오거나 질의하는 것에 있어 효율적)

참고 : hyperledger-fabric.readthedocs.io/en/latest/glossary.html

특징

1. 사용자 관리(Membership Service)

 인증과 인가를 관리하는 중앙의 CA(Certification Authority)서버를 통해 블록체인 네트워크에 접근 자격이 부여되고

각 사용자는 공인인증서와 같은 인증서를 발급받게 된다. 해당 인증서가 폐기 또는 변조될 경우에는 블록체인 네트워크에 접근 할 수 없다.

블록체인에 블록을 새로 추가하는 경우에 해당 사용자의 전자서명이 블록에 같이 기록이 되기 때문에 누가 어떤 블록을 추가 하였는지 추적도 가능하다.

또한 Channel 과 정책등을 설정하여 블록체인 참여자들 간의 Privacy를 강화할 수 있다.

참고로 하나의 채널에 하나의 원장이 존재하며, 채널 안에 속한 Peer node들은 동일한 원장의 복사본을 가진다.

 

 

2. 분산 원장(Distributed Ledger)

 Hyperledger Fabric은 첫 블록(Genesis block)에 네트워크를 구성하는 시스템의 정보를 기록하고 이 후 몇 개의 블록에는 각 조직의 대표 서버 정보와 스마트 컨트랙트의 구현체인 체인코드 정보를 저장한다.

이러한 기본 정보가 블록체인의 초기 5개 블록에 저장되고 이후 블록부터는 체인코드 수행에 따라 추가된 신규 블록정보가 추가된다.

블록과 블록은 Hash라는 연산을 통하여 계산된 고유의 값으로 연결하여 블록의 위변조를 바로 탐지할 수 있는 형태로 블록체인이 구성된다.

Blockchain과 worldstate를 포함하고 있는 Fabric Ledger는 각 Peer들에 의해 유지된다고 생각하면 된다.

 

 

3. 스마트 컨트랙트 또는 체인 코드(Smart Contract)

 Hyperledger Fabric에서는 스마트 컨트랙트를 구현한 Chain Code가 있으며, 이러한 체인코드는 원장에 블록을 추가하거나 조회하는 일종의 프로그램이다. 체인코드는 Java, Go, js 로 로직을 구현 할 수 있으며 블록체인에 접근하는 외부 프로그램의 요청에 대해 계약서의 요건과 비교 검증하여 이상이 없는 경우 실행 결과를 원장에 기록하도록 동작한다.

 

 

 

Hyperledger Fabric의 동작 방식

Hyperledger fabric은 체인코드를 실행하는 Orderer Peer와 체인코드를 초기화하고 실행할 내용을 검증하는 Peer노드로 구성한다. 추가적으로, 인증과 인가를 담당하는 CA(Certification Authority)서버를 운영하기도 한다.

( 사용자 및 조직 구성이 운영 환경에서 거의 변동이 없는 경우 CA서버를 운영하지 않고 초기에 수동으로 생성한 인증서 정보로만 운영하기도 한다. )

 

<요약>

1. 클라이언트 어플리케이션은 체인 코드 실행을 위해 Peer 에 연결한다. (gRPC 프로토콜을 이용하여 통신)

2. Peer에 체인코드에 실행할 내용을 전달한다. ( 정확하게는 Endorsing Peer라고 하는 Peer )

3. Peer는 어플리케이션으로 부터 전달받은 트랜잭션에 대해 사전 검증하고 검증 결과를 어플리케이션으로 회신한다.( 원장에는 반영되지 않는 시뮬레이션 행위 )

4. 어플리케이션은 사전 검증 결과가 이상 없음을 확인하고 transaction을 수행해 달라는 요청을 Orderer에게 전송한다.

5. Orderer에서 체인코드를 실행하여 원장을 갱신하고 해당 결과를 회신한다.

---

이를 부동산 거래에 쉽게 빗대어 표현해보자.

 

1. 부동산 거래를 위해 매수자와 매도자가 부동산에 방문한다. (매수자 및 매도자 = 클라이언트 어플리케이션, 부동산 : peer)

 

2. 매수자와 매도자 쌍방이 합의하에 부동산 계약서에 특약 등을 기재하고 날인한다. ( 스마트 컨트랙트를 구현한 chaincode )

 

3. 부동산(Peer)은 쌍방이 작성하고 날인한 계약서(chaincode)를 살펴보고 이상 유무를 판단하고 등기부 등본과 비교 검증한다. ( Peer에서의 체인코드 실행을 위한 사전 검증 동작 )

 

4. 계약서에 의거하여 매수자는 정해진 날자에 매수대금을 매도자에게 전달하고 관련 소유권을 이전받기 위해 등기서류와 계약서 등 관련 서류를 등기소(Orderer역할)에 접수한다. 등기소에서는 계약서의 이상 유무를 검토하여 실제 소유권이 이전됨을 확인하고 등기를 발급한다.(최신 블록체인으로 변동하는 역할)

 

 

Transaction Flow

---

1번 과정: Client Application 에서 트랜잭션 요청(Transaction Proposal)

Client Application이 블록체인 네트워크에 트랜잭션을 요청하는 과정

그 Transaction에 대해 승인을 해주어야하는 Peer들이 Endorsement policy 로 정의되어 있는데, 이 단계에서 해당 peer들(= Endorsing peer)에게 Transaction을 요청한다. 

해당 Peer들에게 transaction proposal 이라는 형태로 전송이 되는데, Client의 SDK는 이를 gRPC 프로토콜로 전송할 수 있는 프로토콜 버퍼 형태로 변형한다. 또한 사용자의 신원 정보를 서명 형태로 proposal에 삽입한다.

 

이 과정에서 Client가 이벤트를 발생시키면, Peer들이 Listen하고 있다가 다음 액션을 취하는 것이다.

( 일반적인, pub-sub 구조 ), 다만 pub-sub구조와 차이점은 이벤트가 네트워크 모델 파일(.cto)에서 사전에 정의되어야 하며, 특정한 Transaction에서만 발생할 수 있다는 점이다.

---

 

 

 

 

2번 과정: Endorsing Peer들이 서명을 확인하고 Transaction 실행

Endorsing Peer들은 일단 Transaction을 전달 받으면 1) Transaction에 형식에 맞게 내용이 잘 채워져 있는지 2) 이전에 제출된 적 있었던 Transaction은 아닌지 3) MSP를 통해서 서명이 유효한지 4) Transaction을 제출한 클라이언트가 권한이 있는지를 확인을 한다.

이것이 확인이 된다면, Endorsing peer들은 Transaction proposal 을 인자로 받아서 체인코드를 실행한다.

State DB의 값에 체인코드가 실제로 실행되며 결과 값으로 read/write set을 반환한다. 이 시점에서 원장의 업데이트는 하지 않고, 반환 된 결과 값을 proposal response로 클라이언트 SDK로 전송한다.

< 원장 : State DB + Blockchain(transaction log) > 

---

 

<사진 생략>

 

3번 과정: Proposal Responses 검토

그 후 Client SDK가 Endorsing Peer들의 서명을 확인 한 뒤 각 Peer로 부터 proposal response를 비교하는 작업을 거친다. 단순한 Query같이 Ordering Service가 필요 없는 경우에는 결과 값을 얻고 프로세스가 종료된다.

원장 업데이트와 같은 경우, Client 차원에서의 Endorsement policy에 준하는 proposal response가 왔는지( A,B가 모두 결과를 보냈는지) 검토한다.

< 이 단계에서 endorsement policy를 검토하지 않는다고 해도, Committing 단계에서 각 Peer가 별도로 검사를 하기 때문 >

 

 

 

 

 

---

 

 

4번 과정: Client가 Transaction 전달

검토가 완료되고 나면 Client가 Transaction Message에 Proposal과 Proposal response를 담아서 Ordering Service에 보낸다. 그러면 Transaction에는 read/write set과 Endorsing Peer의 서명과 채널 ID가 포함될 것이다. Orderer은 Transaction 내용에 관계 없이, 모든 채널에서 발생하는 Transaction을 받아서 시간 순서대로 정렬하여 블록을 생성한다.

 

---

 

 

 

5번 과정: Committing Peer에서 Transaction을 검증하고 Commit

Transaction Block이 해당 채널의 모든 Committing peer에게 전달됨. 각각의 Committing Peer는 블록 내의 모든 Transaction이 각각의 Endorsement Policy를 준수하는지, world state 값의 read-set 버전이 맞는지( read-set 버전은 Transaction 이후에만 변경 ) 확인한다. 검사 과정이 끝나면 해당 블록 내의 Transaction에는 valid/invalid 값이 태그된다.

---

6번 과정: Ledger Updated

각 Peer들은 최종 검증을 마친 블록을 채널 내 체인에 붙인다. 그리고 유효한 Transaction일 경우 write-set이 state DB에 입력된다. 일련의 과정이 마무리 되면 이벤트를 발생시켜 클라이언트에게 작업 결과에 대해서 알린다.