하이퍼레저 패브릭 구조 정리
참고 : 하이퍼레적 공식문서의 Key Concept을 참고
https://hyperledger-fabric.readthedocs.io/
1) Peers
피어(Peer)는 블록체인에서 '노드'와 유사한 역할로 Ledger와 Chain코드를 관리하는 역할
패브릭 네트워크는 피어노드로 구성되어 있는데, / 각각 블록체인 네트워크 내의 Distributed Ledger와 Chaincode(Smart Contract)사본을 복사하여 보유
※ P1, P2, P3에 같은 Chaincode 'S1'을 사용해서 Distributed Ledger 'L1'에 복사
2) Ledger & Chaincode
- Ledger(레저)는 패브릭 네트워크에서 생성되어 실행되는 모든 트랜잭션을 기록하는 객체
피어(Peer)는 원장(Ledger) & 체인코드(Chaincode)의 호스트로 애플리케이션과 관리자가 접근하려면 피어와 상호작용이 필요함
※ Peer가 처음 생성될 때 Ledger & Chaincode는 없이생성되므로 이후에 생성하는 과정이 필요함
- Chaincode는 키-값을 생성/업데이트 하기 위해서 클라이언트가 어플리케이션을 통해 실항할 수 있도록 하는 코드,
즉, 정의한 트랜잭션 논리를 패키징해서 블록체인 네트워크에 배포함
이더리움의 스마트컨트랙트는 트랜잭션을 관리하는 역할이지만, 패브릭의 체인코드는 스마트 컨트랙트를 패키지화하는 방식을 관리하는 약간의 차이가 있음(스마트 컨트랙트가 체인코드내에 정의됨)
다중원장 & 다중체인코드
Peer는 많은 체인코드와 많은 원장을 사용할 수 있습니다
Peer가 가지고 있는 원장의 수와 해당 원장에 액세스할 수 있는 체인코드의 수는 고정되지 않음
※ 공식문서에서 "가장 간단한 구성은 피어가 단일 원장이지만 필요한 경우 Peer가 두 개 이상의 원장을 호스트하는 것이 절대적으로 적합"이라함
3) 패브릭 애플리케이션 Peer와 통신흐름
Application이 Ledger와 Peer에 액세스하기 위해서는 항상 Peer에 먼저 연결해야함(API를 통해 Peer와 먼저 연결)
- Application 통신흐름 -
1. API를 통한 Peer와 연결
2.1 체인코드 호출(S1호출)
2.2 체인코드를 통한 새로운 쿼리 생성 or 업데이트후 원장(Ledger)에 기록
3. 2.2에서 제안한 Proposal 응답 수신
4. 업데이트의 경우 A는 모든 응답에서 트랜잭션을 작성하고 오더러(O1)에전송
※ 합의 알고리즘에 따라 Application or Client오는 Transaction Proposal들을 순서화시켜 피어 노드에 전달
4.1 오더러(O1)는 네트워크를 통해 트랜잭션을 블록으로 수집하고 이를 Peer1을 포함한 모든 피어에 전달
4.2 원장L1(Ledger1)에 커밋하기 전에 트랜잭션의 유효성을 검사후 원장L1(Ledger1)에 업데이트
5. Peer1이 수신을 완료한 이벤트 Application에 전달
4) Peer와 Channel
채널은 네트워크 구성요소 집한간 개인적으로 통신하고 거래하기 위해서만든 매커니즘
Peer가 채널에 가입하여 해당 채널과 연결된 원장의 복사본을 집합적으로 공유하고 관리하기 위해 협력함
- 채널의 사용이유 -
채널을 사용함으로 특정 피어 및 애플리케이션 세트가 블록체인 네트워크 내에서 서로 통신할 수 있음
아래그림에서 애플리케이션A는 채널C를 사용하여 피어 P1 및 P2와 직접 통신
※ 각 그룹은 일종의 "규칙"이 있는 고유한 개체
결국 채널을 물리적 피어의 모음으로 구성된 논리적 구조로 생각하는 것이 더 적절(이말이 제일 적절한듯)
5) Peer와 Organizations
Peer를 Organizations이 소유하고 있으며 이러한 이유는, 블록체인 네트워크에 분산 네트워크를 구축하는 방법의 핵심
- 아래 그림 해석 -
총 8개의 Peer / 4개의 조직 / 1개의 채널C 존재
채널에서 Peer까지 Peer1, Peer3, Peer5, Peer7, Peer8 에만 연결(각 조직에 1개 이상 채널에 가입필요)
※ 조직이 피어를 제공하지 않으면 네트워크연결은 존재하지 않을 것
- 다른 조직의 Application(A1, A2, A3, A4)이 같을 수도 있고 아닐 수도 있음.
- Application이 동료의 원장 사본을 처리하는 방법은 전적으로 조직에 달려 있기때문에 해당 피어가 정확히 동일한
원장(Ledger) 데이터를 호스팅하더라도 Application로직이 조직마다 다를 수 있음
- Application은 필요한 원장(Ledger) 상호 작용의 특성에 따라 조직의 피어 또는 다른 조직의 피어에 연결
6) Peers and Identity
나중에 공부하고 작성계획
7) Peers and Orderers
나중에 공부하고 작성계획
999) 이외 중요한 것
World-State - 현재 특정 키에 대응하는 값의 최신 상태(키-값을 위의 예로 쉽게 설명하면 키는 계좌주소, 값은 잔액)가 저장되어 있는 데이터베이스 / 블록체인은 모든 원장들의 기록을 의미 / 키 - 값으로 전체 블록체인을 뒤질 필요없이 현재 값을 얻을 수 있음
LevelDB - 키-값 데이터 베이스로 특정 원소에 대한 조회기능 제공하지 않음
Couch DB - Json형태의 값 제공으로 특정 원소에 대한 조회제공
블록체인(Current State?)- 그동안의 모든 거래기록이 담긴 블록체인
'보안 및 블록체인 > 블록체인' 카테고리의 다른 글
하이퍼레저 패브릭(Hyperledger Fabric) 용어 정리 #0 - Key Concept (0) | 2022.05.09 |
---|---|
하이퍼레저 패브릭(Hyperledger Fabric) 구성 정리 Ledger #2 - Key Concept (0) | 2022.05.06 |
솔리디티(Solidity) 기본 언어/문법 정리 #3, 이더리움 Dapp개발을 위해 - [블록체인] (0) | 2022.01.21 |
블록체인 채굴 / 작업 증명 알고리즘 원리 및 개념정리- [블록체인] (0) | 2022.01.18 |
솔리디티(Solidity) 기본 언어/문법 정리 #2, 이더리움 Dapp개발을 위해 - [블록체인] (0) | 2022.01.12 |