[Blockchain] 하이퍼레저 패브릭(Hyperledger Fabric)

블록체인(Blockchain)

• 분산 원장 기술(DLT: Distributed Ledger Technology), 공유 원장(SLT: Shared Ledger Technology), 공유 원장 기술(SLT: Shared Ledger Technology)
• 2008년 나카모토 사토시가 전 세계의 금융 산업의 붕괴와 함께 P2P 식 전자 결제 시스템을 위한 새로운 프로토콜을 구상
• 신뢰 프로토콜(분산형 신뢰 네트워크) 기반
• 가치의 인터넷(Internet of Value), 금전의 인터넷(Internet of Money) 으로의 전환
• 개방형(Public)과 기업형(Consortium)의 형태로 나눈다.
• 국내 및 해외 기업들은 하이퍼레저 패브릭 기반의 블록체인 서비스를 구축형 혹은 자신들의 클라우드 서버를 활용해 BaaS(Blockchain as a Service) 형태로 제공
• 암호화폐는 블록체인을 통해 만들어진 상품들 중 하나이다.

---

블록체인의 구조

1. 합의를 통한 원장 갱신

• 블록체인은 원장이 분산돼 있기 때문에 내용의 일관성을 어떻게 유지하는가가 중요하다.
• 블록체인은 합의라는 구조를 사용해 분산된 원장의 일관성을 유지한다.
• 어떤 거래(트랜잭션)가 발생하면 그 거래를 원장에 기록해도 될지를 블록체인 참가자가 검증하고, 문제가 없다면 해당 거래 데이터를 블록체인에 저장한다.

2. 블록체인 원장

• 블록체인은 검증된 트랜잭션을 블록이라고 하는 데이터의 집합으로 만들어 기록을 저장한다.
• 각 블록에는 트랜잭션 데이터에 바로 직전에 생성된 블록의 해시 값을 추가해서 저장한다.
• 각 블록은 해시 값을 통해 이전 블록과 연결된 형태이기 때문에 블록체인이라고 부른다.

3. 스마트 계약

• 블록체인 위에서 동작하는 프로그램으로 스마트 계약이 실행되면 그 결과는 변조가 불가능한 형태로 블록체인 원장에 기록된다.
• 신뢰할 수 있는 제3자에게 보증을 받을 필요 없이 프로그램 실행이 가능하며 시간과 비용을 절감할 수 있다.

---

개방형 블록체인

• 블록체인 참가자가 특정되지 않은, 즉 누구나 참가 가능한 블록체인으로 전형적인 예는 비트코인과 이더리움이다.
• 불특정 다수가 참가할 수 있기 때문에 악의적인 참가자가 존재할 수 있다는 것을 전제로 하기 때문에 참가자들은 방대한 계산을 해야 하는 구조인 채굴(Mining)을 도입하고 있다.
• 채굴은 특정 조건을 만족하는 값을 가장 먼저 발견한 참가자가 트랜잭션의 정당성을 검토하고 블록을 추가할 수 있는 권리와 그에 따른 보상인 가상 화폐를 받게 된다.
• 막대한 계산 처리를 거쳐 블록을 추가하는 작업을 작업 증명(PoW: Proof of Work)이라고 하며 악의적인 참가자가 존재하더라도 블록체인을 유지할 수 있게 해준다.

기업형 블록체인

• 공동 사업체에 참가하는 기업이나 조직만이 사용하는 블록체인으로 하이퍼레저 패브릭이 있다.
• PoW와는 다른 경량 합의 방식을 사용하기 때문에 거래 검증 속도를 크게 높일 수 있다.
• 거래 검증을 위한 인센티브가 필요 없다는 장점이 있다.

---

하이퍼레저 패브릭

• 비트코인과 이더리움처럼 누구나 참여할 수 있고 참가자들이 같은 원장을 공유하며, 참여자 모두의 합의를 통해 원장의 정보가 생성되는 개방형은 블록체인의 트릴레마(3가지 딜레마)를 해결하는 것이 가장 어려운 숙제였다.
• 3가지 딜레마는 분산화(Decentralization), 보안성(Security), 확장성(Scalability)을 모두 만족시키기 어렵다는 것을 의미한다.
• 기업형 블록체인중 하나인 하이퍼레저는 참여가 허락된 참여자만 블록체인 네트워크에 참여할 수 있고, 참여한 네트워크에서 작은 조직(Organization)을 만들고 채널(Channel)이라는 논리적인 묶음으로 각기 다른 원장을 공유할 수 있다.
• 하이퍼레저의 하위 프로젝트 중 하나이다.
• 하이퍼레저 패브릭의 원장은 원장의 현재 상태인 월드 스테이트(World state)와 원장의 전체 기록을 의미하는 블록체인(Blockchain)으로 이루어진다.
• 우리나라에서는 삼성, LG, KT 등에서, 해외에서는 IBM, Microsoft, Amazon, Google 등이 하이퍼레저 패브릭 기반의 블록체인 서비스를 구축형 혹은 자신들의 클라우드 서버를 활용해 BaaS(Blockchain as a Service) 형태로 제공하고 있다.

---

하이퍼레저 패브릭의 특징

1. 컨소시엄형 참가 방식

• 특정 조직 간의 비즈니스 네트워크를 구현하기 위해 컨소시엄형 참가 방식을 기반으로 하는 블록체인 네트워크를 형성한다.
• 각 조직 내의 사용자와 노드를 독립적으로 관리하고 블록체인 네트워크에는 허가를 받은 뒤에 참가하는 구조로 여러 조직에서 공동으로 운영하는 신뢰성 높은 블록체인 네트워크를 형성할 수 있다.

2. 가볍고 빠른 합의 방식

• 각 참가 조직이 보유하고 있는 분산 원장을 갱신하기 위해서는 합의와 파이널리티가 필요하다.
• 합의는 분산 원장의 갱신과 트랜잭션의 기록에 대해 합의하는 것을 말하며 트랜잭션의 정당서과 동일성을 확보하는 역할을 한다.
• 파이널리티는 블록의 정당성을 최종 확인한 상태를 말한다.
• 각 참여 기관이 가볍고 빠르게 파이널리티를 확보할 수 있는 합의 방식을 채용하고 있다.

3. 다양한 업무 처리 구현

• 스마트 계약을 체인코드(Chaincode)라는 프로그램을 통해 구현해 자신만의 업무 로직을 만들고 실행할 수 있다.
• 비트코인 등에 채용된 UTXO(Unspent Transaction Output) 방식은 코인이나 토큰의 권리 이전과 같은 특정 트랜잭션만을 처리할 수 있다.

4. 트랜잭션 실행 직후의 상태 보존

• State Database라는 데이터 저장소에 트랜잭션을 실행한 직후의 상태를 저장한다.

5. 채널을 사용한 블록체인 네티워크의 논리적 분할

• 하나의 블록체인 네트워크를 논리적으로 독립된 여러 네트워크로 분할할 수 있다.
• 분할된 네트워크를 채널(Channel)이라고 하고, 분리된 채널 간에는 체인코드와 분산 원장이 공유되지 않는다.
• 컴포넌트 모듈(Module) 단위로 네트워크를 구성하고 플러그인 형태로 사용한다.
• MSP(Membership Service Provider)를 이용해 참여 노드에 역할을 부여하고 인증된 멤버만이 채널을 구성을 하거나 구성한 채널에 노드를 추가하고, 체인코드를 호출할 수 있다.

---

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

1. 클라이언트(Client)

• 블록체인 네트워크에 접근하는 데 필요한 노드
• 피어에게 보내는 트랜잭션을 최초로 만드는 역할
• 클라이언트가 발행하는 트랜잭션은 체인코드를 호출하는 트랜잭션뿐만 아니라 채널을 생성하고, 특정 피어가 채널에 참여하는 특별한 트랜잭션도 포함한다.

2. 피어(Peer)

• 조직 내의 노드를 나타내는 논리적 단위로서 블록체인, State DB, 체인코드를 보유한다.
• Endorser 및 Committer의 역할을 가지지만 성능 측면을 고려해 Committer 역할만 가진 피어만 배치할 수도 있다.

3. 오더러(Orderer)

• 보증된 트랜잭션의 결과를 블록체인과 State DB에 기록하는 순서를 제어한다.
• 네트워크의 모든 트랜잭션을 제어하므로 단일 장애점이 되지 않도록 이중화 구성을 해야 하고, 이를 위해 분산 메시징 기술인 Apache Kafka를 사용할 수 있다.

4. 조직(Organization)

• 네트워크에 참여하는 조직을 나타내는 논리적 단위이며 각 피어와 오더러는 조직에 소속된다.

5. 체인코드(Chaincode)

• 스마트 계약을 구현하기 위한 프로그램으로 전용 컨테이너에서 실행된다.
• 체인코드는 트랜잭션 요청에 따라 실행되며 State DB를 읽고 쓰거나 과거의 상태 DB에 기록된 내역을 조회할 수 있다.
• 용도에 따라 여러 체인코드를 만들 수 있으며 한 체인코드에서 다른 체인코드를 호출할 수도 있다.
• 한 체인코드가 State DB에 저장한 데이터를 다른 체인코드에서 읽을 수 없다는 제약이 있다.

6. State Database

• 트랜잭션을 실행한 결과로 얻을 수 있는 최신 상태를 저장하는 데이터 저장소이다.
• 기본적으로 LevelDB라는 키-값 형식의 DB를 사용하지만 JSON 형식 문서를 기본적으로 저장하는 Apache CouchDB를 이용하기도 한다.

7. MQ 솔루션

• 카프카와 주키퍼를 MQ 솔루션으로 사용

8. MSP(Membership Service Provider)

• 하이퍼레저 패브릭이 표준으로 제공하는 CA 또는 외부 CA와 연계해 사용자 등록 및 Enrollment Certificate 발행을 수행한다. 
• MSP 및 CA는 조직 내에서 중복 구성이 가능하며, 각 조직별로 MSP를 만들 수 있다.
• Global MSP에 Network MSP, Channel MSP가 있고, Local MSP에 Peer MSP, Orderer MSP가 있다.
• cryptogen을 이용한 생성 방법과 하이퍼레저 패브릭 CA를 이용한 생성 방법이 있다.
• 실제 블록체인 환경에서는 블록체인 서비스가 동작하는 중에도 새로운 블록체인 네트워크 참여자(피어, 오더러, 조직 혹은 사용자)가 생길 수 있고, 이러한 새로운 블록체인 참여자들은 네트워크에 동적으로 블록체인 서비스 중단 없이 참여해야 한다. 만약 CA 서버를 사용하지 않고 cryptogen을 이용하게 되면 블록체인 네트워크 관리자는 직접 툴을 사용해 키와 인증서를 생성하고 이를 적절한 위치로 이동시켜야 하는 어려움이 있다.

9. 보증 정책(Endorsement Policy)

• 블록체인 및 State DB를 갱신하기 위해 보증이 필요한 조직에 대한 정책을 규정한다.
• 여러 정책을 규정하고 상황에 맞는 정책을 체인코드에 할당할 수 있다.

10. 채널(Channel)

• 서로 다른 참여 노드를 논리적인 단위로 묶어 비공개(Private) 트랜잭션을 수행할 수 있다.
• 한 개의 네트워크 안에 독립된 여러 채널이 존재하는 것이 가능하다.
• 각 채널은 동일한 분산 원장(State DB와 블록체인)을 보유한다.

---

트랜잭션(Transaction)

• 트랜잭션은 체인코드가 설치되거나 호출되는 경우 발생하며 일반적으로 블록체인 네트워크 상의 이벤트를 의미한다.
• 체인코드를 설치하는 배포 트랜잭션과 체인코드를 호출하는 호출 트랜잭션이 있다.

트랜잭션의 라이프 사이클

1. 전제 조건

• 채널이 이미 생성되어 있고 피어까지 조인된 상태
• 사용자가 생성되어 있고 송금 기능을 갖춘 체인코드가 설치되어 있는 상태
• 체인코드는 초기화 단계를 거쳐 도커 컨테이너에 설치되어 있는 상태
• 보증 정책(Endorsement Policy)에는 모든 피어가 트랜잭션에 대해 검증해야 한다는 내용이 정의되어 있는 상태

2. 클라이언트가 트랜잭션을 요청(Transaction proposal)

• 사용자가 클라이언트에게 요청을 보내고, 클라이언트가 요청을 받게 되면 하이퍼레저 패브릭 SDK에서 제안 트랜잭션을 생성한다.
• 제안 트랜잭션은 SDK에서 제안 트랜잭션과 사용자가 전송하는 트랜잭션이라는 것을 검증할 수 있는 서명(signature)을 함께 gRPC 프로토콜을 통해 엔도싱 피어로 전송한다.

3. 엔도싱 피어가 트랜잭션을 검증 후 반환(Proposal response)

• 엔도싱 피어들은 클라이언트로부터 전달받은 제안 트랜잭션을 검증하고, 검증 완료 후 엔도싱 피어는 request 인자를 이용해 체인코드를 실행한다.
• 체인코드는 State DB에서 시뮬레이션되며 원장에 반영되지 않는다.
• 결괏값, 읽기/쓰기 집합, 엔도싱 피어가 검증을 마쳤다는 서명을 함께 SDK에 다시 반환한다.

4. 트랜잭션을 오더링 서비스에 전달

• 클라이언트에서는 여러 개의 엔도싱 피어에서 전달받은 제안 응답들을 비교해서 모두 동일한지 여부를 검증한다.
• 보증정책이 지켜졌는지 확인하며 확인되지 않은 상태에서 제안 응답을 서비스에 보내면 커미팅 피어가 검증하는 단계에서 트랜잭션이 거절된다.

5. 블록을 각 조직의 앵커 피어에게 전달

• 오더링 서비스에서는 모든 트랜잭션을 시간 순서에 따라 정렬한 뒤 블록을 생성하고, 생성된 블록을 순차적으로 앵커 피어에 전달한다. 개발/테스트 환경에서는 SOLO, 스테이징/프로덕션 환경에서는 Kafka가 사용된다.
• 피어에 장애가 발생해 지연된 분산 원장을 복구하기 위한 동기화 처리에 Gossip 프로토콜이 이용된다.
• 가십 프로토콜의 동기화 처리 방식은 오더러가 모든 커미터와 직접 통신하는 것이 아니라 오더러가 채널 단위로 오직 리더(Leader) 피어하고만 직접 통신을 하며 리더 외의 피어는 리더를 통해 무작위로 버킷 릴레이 형식 데이터 동기화를 한다.
• 리더는 오더러와 직접 연결돼 다른 피어에게 가십 프로토콜 데이터를 전달하는 기점이 되는 피어를 말한다.

6. 앵커 피어가 커미팅 피어에게 블록을 전달

• 모든 커미팅 피어들은 전달받은 블록에 포함된 트랜잭션들이 보증 정책을 준수했는지, 읽기 집합이 현재 상태의 데이터를 조회해온 것인지를 마지막으로 검토하고 검토 결과에 따라 해당 블록의 트랜잭션에는 각각 valid/invalid 태그가 붙는다.
• 모든 과정이 완료되면 피어들은 원장에 블록을 업데이트하게 되고 valid 태그가 붙은 트랜잭션의 쓰기 집합만 State DB에 반영한다.