하이퍼레저 패브릭(Hyperledger Fabric) 용어 정리 #0 - Key Concept

 

참고 : 하이퍼레적 공식문서 release-2.2 의 참고 
https://hyperledger-fabric.readthedocs.io/

 

용어정리

- Anchor Peer

- Gossip

- ACL(Access Control List)

- Policy

- Blockchain

- Channel

- Configuration Block

- Consortium

- Endorsement

- Endorsement Policy

- Hyperledger Fabric CA

- Leading Peer

- MSP

- Private Data

- Raft알고리즘

용어정리

1) Anchor Peer

조직간의 피어들에 대한 정보 교환의 대리인으로 사용

Gossip*을 사용하여 서로다른 조직(Organization)의의 피어(Peer)가 서로에 대해 알도록 하는데에 사용 

서로에 대한 위치를 알게되어 아무 조직의 피어하나에 Proposal을 보내도 모두에게 적용 가능.

 

- 예제 -

채널 한곳에 A, B, C 조직이 존재(각 조직에도 피어가 존재하고 조직C에 앵커피어 Peer0.orgC가 있다고 가정)

1) Peer1.orgA -> Peer0.orgC 통신

2) Peer1.orgB -> Peer0.orgC 통신

※ Peer1.orgB -> Peer0.orgC 통신할 때, [Peer0.orgC를 통해서 Peer1.orgB는 이전에 통신한 Peer1.orgA에 대해 알게될 것]

3) 그 시점부터 조직 Peer1.orgA (조직A)와 Peer1.orgB(조직B)는 peer0.orgC의 도움 없이 직접 회원 정보를 교환가능

 

- 정리하면 -

 A,B의 조직은 C조직의 앵커피어를 통해서 서로에 대해 알게되고, MSP(Member Service Provider교환) 

조직 간 통신이 작동하려면 가십에 의존하기 때문에 각 채널은 적어도 하나의 앵커피어가 정의되어 있어야함

2) Gossip Protocol

트랜잭션 실행(승인 및 커밋) 피어와 트랜잭션 순서 지정 노드 간에 워크로드를 분할하여 블록체인 네트워크 성능, 보안 및 확장성을 최적화해야 하는데 / 이를 위해서 데이터 무결성을 보장하고 안정적으로 확장 가능한 보급 프로토콜이 필요한데 / 이 요구사항들을 충족하는 것이 'gossip protocol'

 

- 특징- 

a. 피어는 gossip을 활용하여 Ledger 및 Channel에 데이터를 브로드캐스트

b. gossip Messeaging은 지속적이고,  채널의 각 피어는 다른 피어로부터 지속적으로 현재와 일관된 Ledger 데이터를 수신한다.

c. gossip Messeaging에는 서명이 되어있어 위조 메시지를 보낸 참가자를 쉽게 식별가능하고, 원치 않는 대상에
   메시지를 배포하는 것을 방지할 수 있음

 

-기능- 

a. 지속적으로, 사용가능한 피어멤버를 하고 / 오프라인된 피어를 식별 / 즉, 피어식별 및 채널 구성원 자격을 관리 

b. 채널에 있는 모든 피어에게 분산된데이터 배포
    ※ 기화되지 않은 데이터가 있는 모든 피어는 누락된 블록을 식별하고 올바른 데이터를 복사하여 자체적으로 동기화

c. 원장 데이터의 피어 투 피어 전송 업데이트 상태를를 허용하여 연결된 피어의 속도를 높임

3) ACL(Access Control List)

Policy에 따른 특정 피어의 리소스(시스템 Chaincode or Eventservice 같은)접근관리 함

ACL은 채널 구성의 일부로 ACL은 Key-Value쌍으로,
Key는 액세스를 제어하려는 리소스를 식별 / Value는 액세스가 허용된 채널 정책(그룹)을 식별

 

- 예제 -

1) peer/Propose: /Channel/Application/Writers  //  peer에서 chaincode를 인보크하는 정책

2) event/Block: /Channel/Application/Readers  // block 이벤트를 보내는 정책.

3) lscc/GetDeploymentSpec: /Channel/Application/Readers  //  chaincode인 'GetDeploymentSpec'에는 'Readers' 권한을 충족하는 그룹만 접근관리

 

기본 ACL 세트는 configtxgen에서 채널 구성을 빌드하는 데 사용하는 configtx.yaml 파일에 제공

4) Policy

정책은 디지털 ID의 속성으로 구성된 표현 (e.g. 'Org1.peer', 'Org2.peer')

블록체인 네트워크의 리소스(Chaincode or Eventservice같은)에 대한 액세스를 제한하는데 사용

e.g.  채널에서 Reader, Writer 또는 3)ACL(Access Control List)을 통해 특정 체인코드 API를 사용할 수
있는 사람을 지정

피어(Org1)의 정책 - Fabric-sample configx.yaml파일

네트워크에 적합한 기본 Poilicy의 샘플은 configtx.yaml에 포함됨

5) Blockchain

순서가 지정된 트랜잭션 집합으로 이전 블록과 암호 방식으로 연결되고, 차례로 후속 블록으로 연결됨

블록 체인의 첫 번째 블록을 제네시스 블록

Ledger의 체인은 해시를 통해 연결된 트랜잭션 블록으로 구성된 트랜잭션 로그

피어는 'Ordering Service'를 통해 트랜잭션 블록을 수신하고, 승인 정책 및 동시성 위반에 따라 블록의 트랜잭션을
유효 또는 무효로 표시하고, 피어 파일 시스템의 해시 체인에 블록을 추가

체인

6) Channel

기밀성과 데이터 격리를 위한 프라이빗 블록체인 오버레이

채널은 데이터 분리(data isolation)와 기밀화를 가능케 하며, 채널용 장부(channel-specific ledger)는 채널 사용 허가를 받은 멤버들만이 접근가능

채널은 6)Configuration-Block에서 정의된다.

 

7) Configuration-Block

채널 or 전체 블록체인 네트워크에 대한 구성원의 수정(가입 or 탈퇴)에 대해서 새로운 Configuration-block을 기존의 적절한 체인에 추가

즉, 시스템 체인(Ordering Service) or Channel에 대한 구성원 및 정책을 정의하는 데이터를 포함한 블록이 Configuration-Block

 

8) Consortium(컨소시엄)

채널을 형성하고 가입하며 Peer를 소유하고 있는 조직으로, 블록체인 네트워크에는 여러 컨소시엄이 있을 수 있지만 대부분의 블록체인 네트워크에는 단일 컨소시엄이존재.

채널 생성 시 채널에 추가된 모든 조직은 컨소시엄의 일부여야하지만, 컨소시엄안에 정의되지 않은 조직은 기존 채널에 추가할 수 있음

9) Endorsement(보증)

체인코드의 트랜잭션을 실행하고 'Proposal response'를 클라이언트 애플리케이션에 반환하는 프로세스

Proposal response : 체인코드 실행 응답 메시지, 결과, 이벤트, 체인코드 실행을 증명하는 서명 포함

 

Endorsing Peer : 스마트 컨트랙트에 수행될 트랜잭션을 시뮬레이션해보고 그 결과를 클라이언트 어플리케이션에 리턴해주는 피어입니다. 즉, 트랜잭션을 검증하는 역할

10) Endorsement Policy(보증 정책)

트랜잭션이 적절하게 보증되는지 여부를 결정하는 방법을 피어에게 지시하는 데 사용

- 보증 요구 방법 - 

a. 최소 수의 보증 피어,

b. 최소 백분율의 보증 피어 또

c. 특정 체인코드 애플리케이션에 할당된 모든 보증 피어

11) Hyperledger Fabric CA(Certificate Authority)

네트워크 구성원 조직 및 해당 사용자에게 PKI 기반 인증서를 발급하는 기본 인증 기관 구성 요소

하나의 루트 인증서(rootCert)를 Each Member에게 발급하고

하나의 등록 인증서(ECert)를 Authorized User에게 발급

12) Leading Peer

채널내에 존재하는 조직의 여러 피어중 네트워크 Ordering Service와 통신하기 위한 Peer를 Leading Peer라고 함

Ordering Service는 채널의 Leading Peer에게 블록을 전달하고 동일한 조직 내의 다른 피어에게 블록을 배포

13) MSP(Membership Service Provider)

MSP는 패브릭 네트워크내에 참여할 수 있도록 Client 및 Peer에게 자격 증명장(Credintials)을 제공하는 일종의 시스템 요소

Client - 클라이언트는 MSP를 통해 트랜잭션을 인증

Peer - 피어는 MSP를 통해 믿을 수 있는 트랜잭션 처리 결과(Endorsements)를 인증

즉, MSP를 통해 허가된 블록체인에서 사용자의 ID를 인증, 권한, 관리하고 Peers 와 Orderers에서 블록체인 작업을 인증하고 권한을 부여함 

14) Private Data

인증된 각 피어의 개인 데이터베이스에 저장된 기밀 데이터로 / Channel Ledger Data와는 논리적으로 분리되어 있음

15) Raft알고리즘

Hyperledger Fabric v1.4.1이후로 Kafka 기반이 아닌 Raft기반으로 Ordering Service 설정 및 관리가 더 쉽고 조직이 분산 Ordering Service에 기여할 수 있도록 설계됨

...

추후 자세하게 다른글로 정리하고자함

 

 

 

 

Endorsement , Endorsement Policy 좀 더 구체적인 이해가 필요할듯