하이퍼레저 패브릭 - 기본 개념

Hyperledger fabric 기본 개념

하이퍼레저 패브릭

• 엔터프라이즈 컨텍스트에서 사용하도록 설계된 오픈소스 엔터프라이즈급 응용 분산 원장 기술 플랫폼

• 하이퍼레저 내의 블록체인 프로젝트 중 하나로, 스마트 계약을 사용하여 참가자가 거래를 관리하는 시스템

• 비공개이며, 권한이 있다는 것
• 작업 증명을 요구하는 기존 개방형 권한 없는 시스템과 달리, 하이퍼레저 패브릭의 구성원은 신뢰할 수 있는 멤버십 서비스 공급자(MSP)를 통해 등록함
• 또, 채널을 만들 수 있는 기능을 제공하여 참가자 그룹이 별도의 거래 ledger(장부)을 만들 수 있도록 함.
 

하이퍼레저를 사용하는 이유

• 하이퍼렛저는 프라이빗 블록체인 중에 가장 유명한 기술이다. 기업이 블록체인을 사용하는 이유는 기업간에 거래를 하는데 많은 비용이 발생하고 있기 때문에 이것을 줄이기 위해 프라이빗 블록체인을 사용하고자 한다.

• 이를테면 중앙에 신용 보증 기관 등이 있는데 이 신용보증 기관에 돈을 많이 쓴다는 것이다. 그런데 블록체인을 이용하면 신용보증기관이 없어도 되기 때문에 신용 보증 기관으로 나가는 비용이 줄어든다.

• 리눅스 재단에 의해 설립

• 매우 모듈식이며, 구성 가능한 아키텍처를 통해 광범위한 산업 사용, 최적화 지원

• 범용 프로그래밍 언어로 작성된 스마트 계약을 지원하는 최초의 분산 원장 플랫폼

• 연결 가능한 합의 프로토콜에 대한 지원

Shared ledger

• 하이퍼레저 패브릭에는 world ledger와 transaction log라는 두 가지 하위 시스템을 가지고 있음.
• ledger은 변하지 않는 연속된 레코드를 블록에 저장하는 블록체인('체인')과 현재 패브릭 상태를 유지하기 위한 상태 데이터베이스로 구성된다.
• world ledger은 주어진 시점에서 ledger의 상태를 설명함 -> ledger의 데이터베이스
• transaction log는 world state의 현재 값을 초래한 모든 트랜잭션을 기록함
• 채널당 하나의 ledger가 있고, 각 peer는 자신이 속한 각 채널의 ledger 사본을 유지 관리한다.

Chaincode

• 하이퍼레저 패브릭 스마트 계약은 체인코드로 작성되며, 해당 어플리케이션이 ledger와 상호작용 해야 할 때블록체인 외부 애플리케이션에 의해 호출됨

• 대부분의 경우 체인코드는 world state와만 상호작용함.

• 체인코드는 키-값 쌍 또는 기타 상태 데이터베이스 정보를 읽거나 변경하기 위한 규칙을 시행
• 체인코드 기능은 원장의 현재 상태 데이터베이스에 대해 실행되며 트랜잭션 제안을 통해 시작된다.
• 체인코드를 실행하면 네트워크에 제출하고 모든 peer의 ledger에 적용할 수 있는 key-value write set이 생성된다.

consensus(합의)

• 트랜잭션은 네트워크 내의 서로다른 참가자 집합 사이에 있을지라도, 발생하는 순서대로 ledger에 기록되야 함.

• ledger에 잘못, 혹은 악의적으로 입력된 거래를 거부할 수 있어야 함
• ex) PBFT를 이용하여 일관성을 유지할 수 있는 매커니즘을 제공해야 함

• 합의는 블록을 구성하는 일련의 트랜잭션의 정확성에 대한 검증으로 정의된다.
• 합의는 궁극적으로 블록 트랜잭션의 순서와 결과가 명시적 정책 기준 확인을 충족할 때 달성됨
• 이러한 견제와 균형은 트랜잭션의 수명 주기 동안 발생하며 특정 구성원이 특정 트랜잭션 클래스를 승인해야 하는지 지시하는 승인 정책의 사용과 이러한 정책이 시행되고 유지되도록 보장하는 시스템 체인코드를 포함함
• peer은 이러한 시스템 체인코드를 사용하여 충분한 보증이 존재하고 적절한 엔터티에서 파생되었는지 확인

하이퍼레저 패브릭 모델

클라이언트

• 블록체인에 접근하기 위해 필요한 노드

• 피어에게 보내는 거래(트랜잭션)을 만든다.

• 보통 도커 이미지를 이용해 제공되는 클라이언트 어플리케이션을 이용하거나, 별도의 어플리케이션을 통해 블록체인 네트워크와 통신을 한다.
→클라이언트는 트랜잭션을 생성하여 피어 노드의 endorser(보증)에 보내는 일을 한다. 이후, 거래 보증응답이 오면 거래 제안을 생성하여 Orderer에게 보낸다.

피어(peer) → ledger의 상태와 체인코드를 관리하는 네트워크 노드

• 피어는 ledger을 가진 패브릭에서 가장 기본이 되는 노드이다.(체인코드도 여기에 들어있다.)

• 자신에게 요청된 트랜잭션을 검증하고 전파한다.

• orderer에게 트랜잭션을 받으면(클라이언트가 orderer에게 보낸 트랜잭션) ledger을 갱신하고, ledger가 업데이트 된 것을 클라이언트에게 알려준다.

• 앵커(Anchor)는 조직에 속한 다른 피어들을 검색가능하게 해준다.

• endorser은 트랜잭션을 수행하고 승인한다.

• Commiter은 블록을 전달받아 블록 내의 모든 트랜잭션을 검사하고 블록을 체인에 연결 후 ledger을 업데이트한다.

OSN(Ordering Servuce Node, Orderer)

• 검증된 트랜잭션들을 이용해 최종적으로 블록을 만든다.

• 합의 알고리즘에 따라 클라이언트부터 오는 거래들을 순서화시켜 피어 노드에게 전달한다.

체인코드

• 하이퍼래저 패브릭에서의 스마트 컨트랙트를 체인코드라고 한다.

• 블록체인 내트워크 외부의 클라이언트 응용 프로그램에 의해 호출된다.

• 키-값 쌍에 대한 접근 및 수정을 관리한다.

Organization(조직)

• 노드들을 특징 목적에 따라 구분한 논리 집합(채널과 유사)

• MSP(Membership service provider)을 통해 Organization을 네트워크에 가입시킨다.

• Organization 내에서 트랜잭션 끝에는 peer가 존재한다.

컨소시엄(Consortium, 협회)

• Organization의 집합을 컨소시엄이라고 한다. (네트워크당 보통 한 개 존재)

1. 클라이언트 어플리케이션이 피어에 연결합니다.

2. 연결이 되면 트랜잭션을 생성(transaction proposal)해서 피어의 endorser에 보냅니다.

3. 피어는 받은 거래제안(transaction proposal)에 대하여 체인코드를 확인합니다.

4. 체인코드는 원장에대한 쿼리 거래(ledger query transaction)의 경우 즉시 결과를 반환합니다.

5. update와 같은 원장(ledger)에 대한 변경이 있는 거래 제안이었을 경우 피어는 받은 거래 제안에 대한 응답(response)을 합니다.

6. 응답을 받은 클라이언트는 해당 거래를 오더러(OSN)에 보냅니다.

7. 오더러는 합의 알고리즘에 의거해서 블록을 생성하고 이를 피어로 보냅니다.

8. 피어의 앵커(anchor)는 오더러로 부터 받은 거래블록(transaction block)을 받고 커미터(committer)가 트랜잭션을 확정합니다. 또한 이를 이용해서 피어는 원장을 업데이트 합니다. 이후 클라이언트에게 업데이트 이벤트를 보냅니다.

9. 클라이언트는 업데이트 이벤트를 받게되고 트랜잭션 과정이 끝납니다.

CA와 MSP

요약

하이퍼패브릭 네트워크 만들기

• Ordering service는 블록 안의 트랜잭션 순서를 정하고 노드들에게 전달한다. First come - first serve 방식에 의해 결정됨

• 패브릭을 사용하는 조직은 합의 방식을 선택할 수 있음 -> 교체 가능한 합의 프로토콜
• 패브릭은 기본적으로 Solo, Kafka방식을 지원하고 PBFT도 지원할 예정이다.
• (2.2부터 solo는 만료, etcdraft 지원)

• 프라이빗 블록체인에서는 그룹 별로 네트워크 자원에 접근할 수 있는 권한이 관리자에 의해 정해져 network config 저장된다.

• CA는 디지털 증명서를 발급하는 기관으로, 패브릭에 참여하는 모든 그룹들은 모두 개별 CA를 이용하게 된다.

• 처음 네트워크를 구성하면 아래 순서로 동작한다.
• 1. Ordering service 구동 (Default)
• 2. Network Configuration 설정
• 3. Certificate Authority 설정

컨소시엄 구성

• 하이퍼레저 패브릭에서는 조직들이 하나의 컨소시엄을 구성하면, 그 조직들은 트랜잭션 내역을 공유할 수 있다.

• 하나의 네트워크에는 여러 컨소시엄이 존재할 수 있다. 하지만 보통 네트워크당 한 개 존재

• 컨소시엄이 이용하는 채널 만들기
• 채널은 컨소시엄 내 그룹간 커뮤니케이션 매커니즘이다.
Ledger(장부)란 변경불가능한 데이터베이스이다. 한 채널이 한 ledger를 가진다. 이 ledger를 호스팅하는 노드들은 peer라고 불린다.
• 채널은 데이터 분리와 기밀화를 가능하게 하고, 채널용 장부는 채널 사용 허가를 받은 컨소시엄 멤버들만이 접근 가능하다.
• 채널 설정에는 채널 운영에 필요한 모든 정보를 담고 있다. 채널 설정 정보는 블록에 담겨 장부에 기록된다.
• peer들은 각자 ledger의 복사본을 가진다. ledger 업데이트는 peer들의 합의(consensus)를 통해 이루어지기 때문에 일관성을 유지할 수 있다.
• peer는 ledger를 물리적으로 호스팅하고, 체인코드를 저장하고 있는 entity이다. ca로부터 권한을 받아 채널에 참여할 수 있다.
• 보증정책(endorsing.policies)란 어떤 체인코드가 장부를 업데이트 하기 위해 몇 개의 서명이 필요한지를 명시해 놓은 조건이다.

• 체인코드 적용하기
• 스마트 컨트랙트(Smart contract)는 장부에 저장된 상태(state)를 업데이트 하는 코드(code)이다.
• 하이퍼레져 패브릭에서는 체인코드(Chaincode)라고도 불리며, 패브릭은 체인코드 언어로 현재 Go와 node.js, java를 지원한다.
• 하이퍼레져 패브릭에서 체인코드를 사용하려면, 우선 피어 노드에 체인코드가 설치(install)되어야 한다.
• 하지만 체인코드가 어떤 피어에 설치되었다고 바로 사용할 수는 없다. 채널에 연결된 다른 구성 요소들은 체인코드가 설치된 사실을 알 수 없다.
• 이때 인스턴스화(Instantiated)를 통해, 해당 체인코드의 인터페이스를 다른 피어들에게 알리므로 체인코드를 사용할 수 있다.
• 일부 노드에만 체인코드 구현 로직을 설치한다는 것은 기존의 퍼블릭 블록체인과 구분되는 차이점이다.
• 패브릭은 일부 노드에서만 체인코드를 실행하므로, 병렬적으로 트랜잭션을 처리할 수 있다는 장점도 있다.
 

전체 트랜잭션 처리 과정

1. 클라이언트 어플리케이션에서 SDK를 통해 트랜잭션 제안(transaction proposal)을 발생시킨다.

2. 체인코드의 보증 정책(endorsing policy)에 명시된 노드들(endorsing peers)은 체인코드를 실행한다.

3. 각 결과값은 클라이언트 어플리케이션에 전달된다.

4. 결과값이 보증 정책을 만족시키면, 결과값은 오더링 서비스(ordering service)에 전달된다.

5. 오더링 서비스는 먼저 도착한 순으로 블록을 만들어 채널의 모든 피어들에게 전달한다. 6.모든 피어는 도착한 블록이 보증 정책을 만족시키는지, 장부 상태(ledger state)가 트랜잭션이 일어나는 동안 바뀌지 않았는지 확인한다.

6. 각 피어들은 블록을 채널의 체인에 덧붙이며, 장부의 상태를 업데이트 한다.

• Membership services provider 인터페이스의 디폴트 구현

• Ecerts(long-term identity)와 Tcerts(disposable certificate) 발행

• HA를 위한 클러스터링 지원

• User authentication을 위한 LDAP 지원

• HSM 지원

• 트랜잭션 수신 및 블록 전달

• 네트워크 정책 (readers, writers, admins) 설정을 위한 구성 트랜잭션 (configuration transactions)을 수행

• 트랜잭션 순서임무를 수행하는 pluggable trust engine (예, CFT, BFT) 관리

• Endorser는 항상 committer가 됨

• Endorser는 transactions을 수행하고 승인

• Committer는 endorsements를 검증하고 트랜잭션 결과의 유효성을 체크한

• CouchDB (external option)

• 키 쿼리, 복합 키 쿼리, 키 범위 쿼리 및 전체 데이터 리치 쿼리 (1.0 베타)를 지원

• Transaction이 관련자 에게만 보이도록 관리하는 데이터 파티션 방법. Consensus는 channel안에서 channel멤버의 의해 수행된다.

• 외부의 멤버는 channel에 접근할 수 없고 chennal의 트랜잭션을 볼 수 없다. chaincode는 여러 channels에 전개(deploy)되고, 각각의 인스턴스는 channel안에서 독립적이다.

• chaincode는 다른 chaincode를 쿼리 할 수 있음 (ACL 준수시)

• Ordering service를 제어하는 Members(MSPs)를 결정한다. 각각의 멤버에 대하여 MSP configuration 셋업하고.(root certs, signing certs, key, admins) 네트워크를 관리하는 정책을 셋업한다. (config 수정, 채널 생성 권한) Orderers 시작 (configuration 참고)

• 각각의 멤버는 참여하는 peer의 수를 결정한다. 각각의 peer는 peer identity발행 (local MSP configuration)과 수행 시작

• 이상에서 peers와 orderers네트워크가 생성된다. peer들은 orderers 그리고 서로 연결되어 있지는 않음