출처 : https://blockchain-fabric.blogspot.com/2017/04/hyperledger-fabric-v10-block-structure.html
| 하이퍼레저 아키텍처 : 개념적 이해 (0) | 2018.06.05 |
|---|---|
| Hyperledger의 Peer 종류 (0) | 2018.06.04 |
| Hyperledger 구성요소 정의 및 역할 (0) | 2018.06.04 |
Domain
프로젝트의 최상위 네임 스페이스. 일반적으로 프로젝트명이나 도메인명이 하이퍼레저 도메인명으로 사용됩니다.
Orderer
도메인 아래에는 네트워크의 모든 피어가 트랜잭션을 커밋했는지 확인하는 Orderer(여러개의 인스턴스)가 있을수 있습니다.
Orderer는 하나의 Org에 의존적이지 않습니다. 그래서 연결이 실패하는 상황을 줄이기 위해 여러개의 Orderer를 두는 것이 좋습니다.(Kafka / Zookeeper)
Org
Peer 및 CA의 컨테이너입니다. 각 Org에는 자체 CA 및 Peer들이 있습니다. 일반적으로 Org는 블록체인 네트워크를 분리 하는데 사용됩니다.(기업, 조직등)
CA
CA는 사용자 인증서를 발행하고 관리하는데 사용됩니다. 이는 네트워크에서 소유권을 확인하는데 사용되며 각 CA는 Org에 묶여 있습니다.
Peer
Peer는 클라이언트와 연결되어 있고 World status와 트랜잭션에 대한 책임을 지는 노드입니다. 각 Peer은 couchdb에 자체 트랜잭션의 사본을 가지고 있습니다. 조직은 둘 이상의 Peer을 가질수 있으며 데이터의 손실을 막기 위해 Orderer에 여러개의 Peer을 두는것이 좋지만 4개 이상의 Peer을 두면 대기 시간이 길어 질 수 있습니다.
출처 : https://dev.to/skcript/hyperledger-fabric-architecture-explained-in-detail-32bb
| 블럭 구조(Block structure) (0) | 2018.06.07 |
|---|---|
| Hyperledger의 Peer 종류 (0) | 2018.06.04 |
| Hyperledger 구성요소 정의 및 역할 (0) | 2018.06.04 |
■ 하이퍼레저의 Peer의 유형
|
유형 |
역할 |
비고 |
|
Endorser Peer |
•Application으로 부터 Tx 요청을 수신하고 결과를 Application에 전달하는 역할
•Tx 검증 수행 (Application 인증. 기 처리된 Tx 여부)
•Endorser peer는 항상 Committer Peer |
•Hyperledger에서 임의로 선정
•Org 당 Endorser Peer는 1개 이상 |
|
앵커 피어 |
•Peer들의 State를 확인,
•Leader Peer에서 받은 Valid Tx를 외부 Org의 peer 들에게 Broad casting 해줌 (확인 필요) |
•0 개 이상(없어도 무방함)
•채널 참여시
•선정 개수에 따라 Hyperledger 성능 기하급수적으로 저하됨 |
|
Leader Peer |
•Orderer에서 검증된 블록을 수신해서 Org 내부 Commiter Peer에 Broad casting
•앵커 피어에게 전달 |
•Default는 Hyperledger에서 임의로 선정
•개발자가 임의로 선정가능 |
|
Committer Peer |
•모든 Peer는 committer Peer 임
•원장 관리
•Orderer에게 받은 TX를 수신 받아서 검증한 후 블록체인에 등록 |
•1개의 Peer는 여러가지의 역할을 가질수 있음 |
* 앵커피어의 경우 1.0으로 넘어오면서 역할이 모호해 진것으로 보임. 내용확인이 필요함
| 블럭 구조(Block structure) (0) | 2018.06.07 |
|---|---|
| 하이퍼레저 아키텍처 : 개념적 이해 (0) | 2018.06.05 |
| Hyperledger 구성요소 정의 및 역할 (0) | 2018.06.04 |
|
구성요소 |
설명 |
비고 |
|
Network |
||
|
Channel |
•명시적으로 인가된 특정 Member(Peer와 Application)간 ledger를 공유하기 위한 Private blockchain 가상 network (overlay) |
|
|
CA |
•Hyperledger의 모든 구성요소 인증서 발급 |
|
|
Member |
•BC_NW내의 Peer와 Application의 집합
•Root 인증서를 가진 Entity |
|
|
Organization |
•Peer 를 관리하는 조직 (논리적 단위) |
|
|
MSP |
•회원등록을 위한 규칙 및 Access control 및 권한 부여를 설정할 수 있는 Identity 관리 서비스 |
|
|
Orderers |
•KAFKA와 Zookeeper를 통해서 BC_NW 에서 Streaming 서비스 함 |
|
|
Peer |
•Ledger를 유지하고, 체인코드를 실행할 수 있는 network entity |
|
|
Ledger |
•순차적이고, 변조불가능한 데이터들을 체인 형태로 구성한 개념(공유원장, 분산원장)
•구성요소 : World State와 Transaction Log 구성 , |
|
|
Transaction |
•유형 : Depoly(Install), Invoke (Write) |
|
|
Consensus |
•PBFT 개념을 Hyperledger fabric이 구현한 ABC(Atomic BroadCast) 합의알고리즘 사용
•합의 = Endorsement + Ordering + Validation
•ABC 합의 알고리즘은 KAFKA에서 지원
•KAFKA수행 방법; Permissioned voting based. Leader does ordering. Only in-sync replicas can be voted as leader.
•Consensus 결정되면 설정변경 불가능 |
|
|
Chaincode |
•Ledger상에서 실행되는 소프트웨어로 비즈니스 로직을 포함하고 있음
•ChainCode는 여러 개의 함수를 가질 수 있으며 이를 ChainCode Function이라고 함 |
|
구분 |
소분류 |
설명 |
|
트랜잭션 |
배포 트랜잭션 |
•배포 트랜잭션은 단어 그대로 체인코드를 블록체인의 시스템에 설치하기 위해 실행되며, 배포 트랜잭션이 호출되면 체인코드를 빌드하고 피어에 설치하며 초기값을 파라미터로 받아서 블록에 저장하는 과정을 거친다. |
|
Invoke |
•배포된 체인코드를 기준으로 정의된 함수를 호출하기 위해 실행된다. Invoke트랜잭션을 호출한 결과, 호출이 정상적으로 완료되면 스테이트에 처리 결과가 저장되고 결과는 호출한 클라이언트에 반환된다.
•Invoke Transaction 유형 : Invoke, Query | |
|
블록체인 |
스테이트(State) |
•블록체인에서 최신 State는 버전관리된 키-밸류스토어(KVS : Key Value Store )로 설계되어 있다. KVS에 문자열 타입의 키와 임의의 객체인 밸류로 저장가능하며, 블록체인에서 구동되고 있는 체인코드에서 "PUT", "GET" 동작에 의해 관리 된다. 키-밸류 스토어는 동시에 버전 정보를 함께 저장하고 있어서 동일한 키 값으로 입력되는 밸류에 대해 버전관리가 이루어 진다. 그러므로 모든 트랜잭션 되는 데이터에 대해서는 히스토리 관리가 된다. |
|
원장(Ledger) |
•원장은 블록체인에서 모든 성공 또는 실패한 스테이트의 변경에 대한 검증 가능한 기록을 저장한다. 원장은 Ordering서비스에 의해 완벽하게 순차 처리된 트랜잭션의 해시 체인으로 구성되며, 해시 체인은 원장에 블록의 전체 순서를 지정하며 각 블록에는 순차로 정렬된 트랜잭션 배열이 포함된다.
•원장은 모든 피어와 일부 Orderer에서 저장되고 관리 된다. 피어에는 원장과 스테이트가 관리되는데, 역할에 따라서 Committing Peer와 Endorsing Peer로 구분되며 Endorsing Peer에 의해 검증된 트랜잭션뿐 아니라 검증에 실패한 트랜잭션의 정보도 비트 구분을 통해 함께 관리 한다. Orderer는 결함 허용(Fault-tolerance)정보와 피어의 가용성 정보를 원장으로 관리한다. | |
|
노드(Node) |
•블록체인에서 노드는 통신을 위한 엔티티를 말하며, 같은 유형의 여러 노드가 동일한 서버에서 구동 될 수 있다는 점에서 논리적인 기능으로 구분되는 단위이다. 노드는 크게 세가지로 구분된다.
•클라이언트 : 트랜잭션을 발생시켜 Endorser에게 트랜잭션을 제안(Proposal)하고 Endorsing결과를 받아서 최종적으로 Orderer에게 트랜잭션을 전송하는 역할을 하는 노드
•피어 : 트랜잭션을 커밋하고 원장을 관리가 주된 역할이며, 설정에 의해 Endorser의 역할을 할 수도 있따.
•Ordering 서비스 노드(또는 Orderer): 트랜잭션에 대해 각 피어에게 일관되게 동일한 원장을 관리 할 수 있도록 커뮤니케이션을 보장하는 역할의 노드 |
* 하이퍼레저 표준 문서 등을 기준으로 정리했습니다. 오기 등이 포함되어 있을 수 있습니다.
| 블럭 구조(Block structure) (0) | 2018.06.07 |
|---|---|
| 하이퍼레저 아키텍처 : 개념적 이해 (0) | 2018.06.05 |
| Hyperledger의 Peer 종류 (0) | 2018.06.04 |
