- Hyperledger Fabric2023년 07월 22일 05시 22분 27초에 업로드 된 글입니다.작성자: 각수짱728x90반응형SMALL
Hyperledger 개요
하이퍼레저 프로젝트는 리눅스 재단에서 주도하는 오픈소스 블록체인 기술
프레임워크(Framework)
5개의 프레임워크(Framework)
하이퍼레저 버로우(Hyperledger BURROW), 하이퍼레저 그리드(Hyperledger grid)는 수명주기 종료..- Hyperledger BESU
- Apache 2.0 라이선스로 개발되고 Java로 작성된 오픈 소스 Etereum 클라이언트
- Hyperledger Besu는 EEA (Enterprise Ethereum Alliance) 사양을 구현
Hyperledger BURROW-
허가된 (Apache 2.0) EVM 스마트 컨트랙트 머신 및 비잔틴 결함 허용 원장 프로젝트 -
Tendermint 컨센서스를 사용하고 EVM을 유지하면서 EVM에 대한 새로운 확장 기능을 구현 - Hyperledger FABRIC
- 솔루션 및 응용 프로그램 개발을 위한 엔터프라이즈 급 허가 분산 원장 프레임 워크
- 개인 정보를 보존하면서 규모에 맞게 성능을 구현할 수 있는 합의에 대한 독특한 접근 방식을 제공
- Hyperledger INDY
- 블록체인 또는 기타 분산 원장을 기반으로 하는 디지털 ID를 제공하기 위해 도구, 라이브러리 및 재사용 가능한 구성 요소를 제공하므로 관리 도메인
- 응용 프로그램 및 기타 사일로 간에 상요 운용 가능
- Hyperledger IROHA
- C++ 및 모바일 애플리케이션 개발자가 Hyperledger에 기여할 수 있는 개발 환경을 제공하는 분산 원장 프로그램
- Fabric, Sawtooth 및 기타 잠재적인 프로젝트를 보완하기 위해 다양한 클라이언트 라이브러리와 함께 사용하여 데스크톱 및 모바일 플랫폼 용 애플리케이션을 쉽게 작성할 수 있는 사전 정의된 명령, 권한 및 쿼리 세트가 포함된 프레임워크
- Hyperledger SAWTOOTH
- 분산 원장 (블록체인이라고도 함)을 구축, 배포 및 실행하기 위한 엔터프라이즈 솔루션
- 합의 알고리즘에 의해 조정된 신뢰할 수 없는 당사자 간의 공유 상태에 대한 트랜잭션 기반 업데이트를 구현하기 위한 매우 모듈 식의 유연한 플랫폼을 제공
Hyperledger GRID-
분산 원장 구성가 포함된 공급망 솔루션을 구축하기 위한 플랫폼 -
공급망 스마트 계약 및 클라이언트 인터페이스 개발을 가속화하기 위한 라이브러리, 데이터 모델 및 SDK 세트가 포함
라이브러리
2개의 라이브러리
- Hyperledger ARIES
블록체인 기반의 P2P 상호 작용을 위한 인프라
검증 가능한 디지털 자격 증명을 생성, 전송 및 저장하는데 중점을 둔 이니셔티브 및 솔루션을 위해 설계된 공유 가능하고 상호 운용 가능한 공유 도구 키트를 제공 - Hyperledger ANONCREDS
Hyperledger Indy 프로젝트의 일부로, 사용자가 개인 정보를 최소한으로 공개하면서도 디지털 자격 증명을 검증할 수 있는 기능을 제공
이를 통해 개인정보 보호와 데이터 보안을 강화
도구(Tool)
6개의 툴
- Hyperledger BEVEL
개발자들이 공용 및 사설 클라우드 공급자를 통해 일관되게 제품 준비 단계의 분산 네트워크를 배포할 수 있는 가속기 - Hyperledger CACTI
사용자가 다양한 블록체인을 안전하게 통합할 수 있도록 설계된 블록체인 통합 도구 - Hyperledger CALIPER
사용자가 사전 정의된 사용 사례 집합을 사용하여 특정 블록체인 구현의 성능을 측정할 수 있는 블록체인 벤치 마크 프레임 워크
TPS(Transactions Per Second), 트랜잭션 대기시간, 리소스 활용률 등과 같은 여러 가지 성능 지표를 포함하는 보고서를 작성 - Hyperledger CELLO
베어 메탈, 가상 머신 및 다양한 컨테이너 플랫폼과 같은 다양한 인프라에서 블록체인을 효율적으로 관리하고 실행하기 위한 운영 콘솔을 제공 - Hyperledger FIREFLY
기업이 안전한 Web3 애플리케이션을 구축하고 확장하기 위한 완전한 스택을 제공하는 첫 번째 오픈 소스 슈퍼노드
디지털 자산, 데이터 흐름, 그리고 블록체인 트랜잭션을 위한 FireFly API는 인기 있는 체인과 프로토콜 위에서 제품 준비 단계의 앱을 빠르게 구축하는 데 기여 - Hyperledger SOLANG
Solidity를 기반으로 하는 스마트 컨트랙트를 다른 블록체인 플랫폼에 배포할 수 있도록 해주는 컴파일러
Solang은 다양한 블록체인 플랫폼과 호환되며, 특히Hyperledger Burrow및 Substrate와 잘 작동
패브릭(Fabric)
- 블록체인의 엔진을 만드는 핵심 프로젝트
- 가장 활발하게 활동 중인 하이퍼레저 프로젝트
- 초기 IBM이 제공한 코드를 기반으로 현재 30여 조직에서 개발 참여 중
- 모바일과 웹을 위한 인프라 제공 (IOS, Android, JavaScript 지원)
- MSP (Membership Service Provider) 기반의 Identity 관리와 접근 허가
- 블록체인 원장(ledger)과 현재 상태를 나타내는 World State 보관
- 트랜잭션 블록 정하는 방법으로 'Solo', 'Kafka', SBFT 제공
- Apache 2.0 라이선스 정책을 따름
- 기밀 정보 공유를 위한 채널
- 주문 서비스 (Ordering Service)는 네트워크의 동료와 일관되게 트랜잭션을 전달
- 거래에 대한 승인 정책
- CouchDB world state 광범위한 쿼리를 지원
- 블록체인 비즈니스 네트워크 안에 포함된 특정 사용자만 원장을 확인할 수 있는 권한을 채널 별로 부여
- 멀티플 멤버십 서비스를 지원{양도자(Endorsing Peer), 지시자(Ordering-service-node) 두 가지 역할로 나눠서 수행}
패브릭(Fabric) 아키텍처
Fabric Network 구성요소
- Hyperledger Fabric Client SDK
하이퍼레저 패브릭 기능을 이용하기 위한 API 제공.
이를 통해 하이퍼레저 패브릭 네트워크를 구성하고 트랜잭션을 실행할 수 있음 - Organization(조직)
하이퍼레저 패브릭 네트워크에 참여하는 조직
논리적인 단위이며, 각 피어(peer)와 오더러(Orderer)는 조직(Origanization)에 소속됨 - Peer(피어)
조직 내의 노드를 나타내는 논리적 단위
블록체인, 상태 DB, 체인코드를 보유
Endorser(보증인) 및 Committer(커미터)의 역할
- Endorser 역할 : 응용프로그램(클라이언트)의 요청에 따라 트랜잭션에 의해 Endorsement(보증)함.
- Commuitter 역할 : 트랜잭션과 실행 결과의 타당성을 확인해 블록체인과 상태 DB를 갱신
- Lerder peer
각 조직의 peer는 orderer로부터 분산원장을 업데이트할 수 있는데, 조직의 모든 peer가 orderer에게 분산원장을 요청하면 orderer가 과부하될 가능성 높음
각 조직에서는 모든 peer가 orderer와 통신하는 대신 Leader peer를 대표로 선출하여 orderer와 통신
같은 조직의 peer에게 heartbeat메시지를 주기적으로 보내어 자신이 살아 있음을 증명
하나 이상의 peer가 특정 시간 동안 heartbeat메시지를 수신하지 못한다면 새로운 Leader peer를 선출하게 됨 - Committing peer
독립적을 수신받는 최신 블록에 대한 검증작업 수행
모든 peer는 Committing peer 역할을 수행해야 함 - Anchor peer
조직의 대표 peer 등 중 대표로, 다른 조직에 설치된 peer 간의 통신을 담당하는 peer - Endorsing peer
트랜잭션을 보증한 후 분산 애플리케이션에 전달하면 분산애플리케이션은 orderere에게 해당 트랜잭션을 전송하고 orderer노드는 수신받은 트랜잭션을 수집해 블록 생성
분산 애플리케이션이 Endorsing peer에게 트랜잭션을 제출하면 Endorsing peer는 트랜잭션의 입력값을 이용해 체인코드를 시물레이션함
시뮬레이션 결과값에 문제가 없다면 Endorsing peer는 Read/Write set과 함께 자신의 Identity가 포함된 디지털 인증서를 분산 애플리케이션으로 전송
Read - [{사용자 A, A의 잔액, 현재의 state DB의 레코드 버전(현재 블록체인 높이)};{사용자 B, B의 잔액, 현재 state DB의 레코드버전(현재 블록체인 높이)}]
Write {(사용자 A, A의 잔액 - 1,000원);(사용자 B, B의 잔액 + 1,000원)} - Orderer(오더러)
보증(Endorsement)된 트랜잭션의 결과를 블록체인과 상태 DB에 기록하는 순서를 제어
하이퍼레저 패브릭 네트워크의 모든 트랜잭션을 제어하므로 단일 장애점이 되지 않도록 이중화 구성 필요(Apache Kafka 사용) - Chaincode(체인코드)
하이퍼레저 패브릭에서는 분산원장에 데이터를 기록하거나 읽기 위해서는 체인코드(Chaincode)가 필요한데, 주로 비즈니스 모델에 맞는 분산 애플리케이션(Dapp)과 함께 개발되어 사용
스마트 계약을 구현하기 위한 프로그램
전용컨테이너에서 실행됨
Go Lang, Java, NodeJS
체인코드는 트랜잭션 요청에 따라 실행되며 상태 DB를 읽고 쓰거나, 과거의 상태 DB에 기록된 내역을 조회 가능
다른 체인 코드 호출 가능 (다른 상태 DB 데이터 읽기 불가능) - 시스템 체인코드 : 특수한 체인코드
하이퍼레저 패브릭의 시스템레벨에서 수행되는 체인코드
QSCC, CSCC, LSCC는 CLI 명령어로 실행
ESCC, VSCC는 각각 Endorsing peer와 Committing peer에 의해 실행
- QSCC(Query System ChainCode)
- ESCC(Endorsement System ChainCode)
- VSCC(Validation System ChainCode)
- CSCC(Configuration System ChainCode)
- LSCC(Lifecycle System ChainCode)
- QSCC(Query System ChainCode)
블록체인의 저장된 데이터를 읽어올 때 사용되는 시스템 체인코드
채널 구성원은 CLI명령어를 통해 블록번호, 블록의 해시값, 트랜잭션 ID 등 다양한 입력값을 통해 데이터 읽어올 수 있음 - ESCC(Endorsement System ChainCode)
보증 정책을 담당하는 시스템 체인 코드
Endorsing peer는 ESCC를 통해 사용자의 트랜잭션 실행 결과값을 비교해 보고 결과값이 올바르면 자신의 인증서를 통해 트랜잭션 결과값에 대한 보증을 함 - VSCC(Validation System ChainCode)
블록을 검증할 때 사용되는 시스템 체인 코드
Committing peer는 VSCC를 실행하여 트랜잭션의 Read/Write set과 보증정책에 맞게 Endorsing Peer의 디지털 인증서의 존재 여부를 확인하는 작업을 수행함. - CSCC(Configuration System ChainCode)
채널 설정 시 사용되는 시스템 체인코드
CSCC는 블록에 대한 정보를 읽어 오거나 수정할 수 있으며, peer를 채널에 참여시키는 기능 제공 - LSCC(Lifecycle System ChainCode)
체인코드 설치로부터 인스턴스화까지 모든 일련의 과정을 수행하는 데 사용되는 체인코드 - 분산 원장 기술
하이퍼레저 패브릭 네트워크의 참가자끼리 동일한 정보(원장) 공유하기 위해 사용하는 기술 - 원장
블록체인과 상태 DB로 구성됨 - 상태 DB
트랜잭션을 실행한 결과를 얻을 수 있는 최신 상태를 저장하는 데이터 저장소
LevelDB구조의 키-값(Key-Value) 형식의 DB사용
Json형식 문서를 기본적으로 저장하는 CouchDB도 가능 - MSP(Membership Service Provider)
표준으로 제공하는 CA(Certification Authority 인증가관)또는 외부 CA와 연계해 사용자 등록 및 Ecert 발행을 수행
MSP 및 CA는 조직 내에서 중복 구성 가능(각 조직별 MSP 구성 가능) - Endorsement Policy(보증 정책)
블록체인 및 상태 DB를 갱신하기 위해 보증이 필요한 조직에 대한 정책을 규정
여러 정책을 규정하고 상황에 맞는 정책을 체인코드에 할당 가능 - Channel(채널)
peer 간의 통신은 채널을 통해서만 이루어짐
모든 조직이 채널을 통해 정보를 공유할 수도 있고, 또는 비즈니스 이해관계가 맞는 일부 조직들 간에만 추가로 채널을 생성하여 정보를 공유가능
각 채널마다 하나씩 분산원장이 존재하게 되는데, 채널에 참여한 조직의 구성원만이 해당 채널의 분산원장에 접근가능
채널 생성은 CSCC(Configuration System ChainCode)를 호출하여 생성할 수 있음. 채널 생성 시 해당 채널에서 사용될 분산원장의 genesis block 생성됨
genesis block에는 채널의 구성원, 채널 정책, 각 peer의 역할 등과 같은 설정이 포함되어 있음 - Ledger
현재 상태를 나타내는 World State
원장의 생성 시점부터 현재까지의 사용 기록을 저장하는 Blockchain
- Ledger - World state
World state에 저장된 데이터는 합의 과정에 의해 블록체인에 포함되기 전까지 체인코드를 통해 조회/변경/삭제가 가능함
합의에 의해 결정된 블록 및 블록체인은 절대 수정할 수 없음
World state는 데이터의 기록, 수정, 읽기 등이 빈번하게 발생하기 때문에, 분산데이터베이스로 구축되어 있음(LevelDB, CouchDB 지원) - Ledger - Blockchain
세계 상태에는 일련의 비즈니스 객체의 현재 상태와 관련된 사실이 포함되어 있지만 블록체인은 이러한 객체가 현재 상태에 어떻게 도달했는지에 대한 기록
블록체인은 상호 연결된 블록의 순차적 로그로 구성되며, 각 블록에는 일련의 트랜잭션이 포함되며 각 트랜잭션은 쿼리를 나타내거나 월드 상태로 업데이트됨
중요한 것은 블록 sequencing과 블록 내 트랜잭션 sequencing이 ordering service라는 Hyperledger Fabric 구성 요소에 의해 블록이 처음 만들어질 때 설정되는 것
- Ledger - World state
- Block
- Block Header
Block number, 현재 blockhash, 이전 blockhash - Block Data
이 섹션에는 순서대로 정렬된 거래 목록이 포함 - Block Metadata
이 섹션에는 블록 작성자의 인증서, 공개 키 및 서명뿐만 아니라 블록이 작성된 시간이 포함
- Block Header
- 트랜잭션
트랜잭션은 세계 상태의 변경 사항을 캡처
트랜잭션 구조
- Header
트랜잭션의 version정보와 트랜잭션이 실행되는 체인코드의 이름 등이 명시 - Signature
트랜잭션 생성자의 Identity 관련 디지털 인증서 정보 - Proposal
체인코드에 들어가는 트랜잭션이 입력값이 저장
해당 입력값을 이용해서 체인코드를 실행 - Response
트랜잭션 처리 결과값을 Read/Write set 형태로 변환하는 필드
Read는 트랜잭션의 proposal이 반영되기 전 값
Write는 proposal의 값이 반영된 후의 값 - 이 값은 추후 최신 블록 검증 과정에 사용됨 - Endorsement
트랜잭션을 보증해 준 peer의 Identity 정보가 포함되어 있음
보증정책에 따라서 Endorsemet는 한 개 혹은 여러 개가 될 수 있음 - Chaincode name
트랜잭션이 실행되는 체인코드를 구분하는 데 사용됨
peer가 트랜잭션을 입력받으면 Chaincode name이 가리키는 체인코드를 실행
Fabric 구성요소
Fabric 트랜잭션 처리
트랜잭션 흐름
- 클라이언트(웹 응용프로그램)로부터 체인코드 실행 요청(Transaction Proposal)
- 보증 정책(Endorsement Policy)에 규정된 정책에 따라 대상이 되는 조직 내에서 임의의 보증인(peer)에게 보증 요청
- 보중인이 체인코드를 시뮬레이션
상태 DB에는 내용이 저장되지 않고 대신 RWSet(read/write set)을 생성
RWset은 체인코드를 시뮬레이션할 때 읽어 들일 대상 키 항목과 그 항목의 버전 번호, 쓰기 대상의 키 항목과 그 버전 정보, 입력할 값을 저장 - 보증인이 서명한 RWSet을 클라이언트에 반환
해당 트랜잭션은 대상 조직으로부터 보증된 것으로 취급
여러 조직 내의 보증인으로부터 받은 서명된 RWSet을 통해 보증정책이 충족된 것을 확인 - 이러한 정보를 바탕으로 트랜잭션 제어를 오더러에게 요청(제출)
- 오더러는 트랜잭션 순서를 제어
정렬된 여러 트랜잭션(서명된 RWSet)은 하이퍼레저 패브릭 네트워크 내의 커미터 피어에게 배포
1블록당 최대 트랜잭션 수 도는 시간제한에 따라 배포됨 - 커미터 피어가 트랜잭션(서명된 RWSet)을 검증
검증에 성공하면 블록체인 및 상태 DB를 갱신(commit) - 트랜잭션 검증은 보증 정책이 충족되었는지 확인함과 동시에 RWSet에 저장되어 있는 키 항목의 버전 번호와 현재의 상태 DB 내에 해당하는 키 항목 버전 번호가 일치하는지 검사(최신 데이터가 아닌 내용이 상태 DB에 저장되는 것을 방지)
- 커미터 피어는 이벤트를 발생하여 클라이언트 측에 트랜잭션 검증의 성공과 실패 통지
가십 프로토콜
- 오더러가 트랜잭션을 커미터 피어에게 배포할 ㅐ나 피어에 장애가 발생해 지연된(최신 내용으로 업데이트되지 않음) 분산 원장을 복구하기 위한 동기화 처리 방식
- 오더러는 채널 단위로 오직 리더(Leader) 피어 하고만 직접 통신하며 리더 피어 외의 피어는 리더 피어를 통해 무작위로 버킷 릴레이 형식 데이터 동기화
- 조직 내의 커미터 수에 상관없이 유연한 대응이 가능하며 확장성도 해결
- 리더(Leader) 피어는 오더러와 직접 연결돼 다른 피어에게 가십 프로토콜 데이터를 전달하는 기점이 되는 피어를 말함
특별히 지정하지 않은 한 리더는 조직 내에서 자동으로 결정
MSP(Membership Service Provider)
- 조직(Organization)
구성원의 관리 그룹 - 조직과 MSP 간의 배타적 관계를 통해 대부분의 정책 구성에 적용되는 규칙 인 조직의 이름을 따서 MSP의 이름을 지정
- Identity 기술을 바탕으로 만든 하이퍼레저 패브릭 멤버십 관리 기술
- peer, orderer, Fabric-CA, admin 등 역할과 소속, 권한 등 정의
- local MSP
패브릭 네트워크 노드의 역할을 부여할 때 사용
어떤 노드가 peer, orderer, client 여부 정의
admin, client 등 노드별 권한 정의
모든 네트워크 노드는 하나 이상의 local MSP가 정의되어 있어야 함 - channel MSP
채널 구성원들에 대한 멤버십 정의와 권한 부여
채널에 참여한 구성원들은 local MSP를 이용해서 하나의 Channel MSP를 생성
조직에서 채널에 참여하려 할 때 채널 구성원은 channel MSP를 참고하여 보증 또는 거절, 채널 구성원은 channel MSP에 따라서 역할과 권한 부여받음
- 로컬 MSP는 적용할 노드 또는 사용자의 파일 시스템에서만 정의
- 물리적 및 논리적으로 노드 또는 사용자 당 하나의 로컬 MSP만 있음
- 채널 MSP는 채널의 모든 노드에서 사용할 수 있으므로 채널 구성에서 논리적으로 한번 정의
- 그러나 채널 MSP는 또한 채널에 있는 모든 노드의 파일 시스템에서 인스턴스화되며 컨센서스를 통해 동기화된 상태로 유지
- 모든 노드의 로컬 파일 시스템에 각 채널 MSP의 사본이 있지만 논리적으로 채널 MSP는 채널 또는 네트워크 상주하여 유지 보수됨
- 루트(Root) Cas
- MSP가 나타내는 조직이 신뢰하는 루트 CA의 자체 서명 된 인증서 목록이 포함
- 다른 모든 인증서가 해당 조직의 구성원으로 간주되도록 파생되어야 하는 CA를 식별하기 때문에 가장 중요한 폴더
- 중개(Intermediate) Cas
- 조직에서 신뢰하는 중개 CA의 인증서 목록이 포함
- 각 인증서는 MSP의 루트 CA 중 하나 또는 발급하는 CA 체인이 신뢰할 수 있는 루트 CA로 돌아가는 중간 CA에 의해 서명되어야 함
- 루트 CA 폴더와 마찬가지로 이 폴더는 조직의 구성원으로 간주되기 위해 인중서를 발급해야 하는 CA를 정의
- 선택사항
- OU(organizational unit)
- $FABRIC_CFG_PATH/msp/config.yaml 파일에 나열
- 조직 구성단위 목록이 포함
- 구성단위는 이 MSP가 나타내는 조직의 일부로 간주
- 이 기능은 조직의 구성원을 특정 OU가 있는 ID(MSP 지정 CA 중 하나가 서명한)를 보유한 조직으로 제한하려는 경우에 특히 유용
- 선택사항
- 관리자(Administrators)
- 조직의 관리자 역할을 하는 행위자를 정의하는 ID 목록이 있음
- 해지된 인증서 (Revoked Certificates)
- 행위자의 신원이 해지된 경우, 신원 자체가 아닌 신원에 대한 정보가 이 폴더에 보관
- 인증서를 사용하여 인증서가 사용되지 않았는지 확인할 때마다 확인
- 이 목록은 개념적으로 CA의 CRL(Certificate Revocation List)과 동일하지만 조직의 멤버 자격 취소 와도 관련이 있음
- 결과적으로, MSP, 로컬 또는 채널의 관리자는 발급된 CA의 업데이트된 CRL에 발급된 인증서를 알리면 조직에서 행위자 또는 노드를 신속하게 취소할 수 있음
- 선택사항
- Sign Certificates = 노드 ID
- 노드가 채널 및 네트워크의 다른 참가자에게 보내는 메시지에서 노드를 인증할 수 있도록 한느 암호하 자료가 포함
- 트랜잭션 제안서 응답에 배치한 인증서로, 피어가 이를 승인했음을 나타냄
- 유효성 검사 시 결과 트랜잭션의 보증 정책과 대조하여 확인할 수 있음
- 로컬 MSP에서 필수사항이며 채널 MSP에서는 사용하지 않음
- KeyStore(Private Key)
- 이 폴더는 피어 또는 주문자 노드 (또는 클라이언트의 로컬 MSP)의 로컬 MSP에 대해 정의되며 노드의 서명 키를 포함
- 이 폴더는 로컬 MSP에 필수적이며 정확히 하나의 개인 키를 포함
- 채널 MSP의 구성은 이 폴더를 포함하지 않음
- TLS Root CA
- 이 폴더에는 이 조직에서 TLS 통신을 위해 신뢰하는 루트 CA의 자체 서명된 인증서 목록이 포함
- TLS 중개(Intermediate) CA
- 이 폴더에는 TLS 통신을 위해 이 MSP가 나타내는 조직에서 신뢰하는 중간 CA 인증서 목록이 포함
- 이 폴더는 상업용 CA가 조직의 TLS 인증서에 사용될 때 특히 유용
- 멤버십 중간 CA와 유사하게 중간 TLS CA 지정은 선택사항
Orderer
블록생성
- Leader peer는 Orderer로부터 전달받은 최신 블록을 자신이 속한 채널의 peer들에게 배포
- 최신 블록을 받는 peer들은 블록에 포함된 결과값이 정상적인지, 각각의 트랜잭션 결과값이 보증 정책에 부합하는지 등의 검증 작업 수행한 후 문제가 없을 시 자신의 로컬저장소에 저장된 블록체인에 최신블록 추가하고 world state 데이터베이스 업데이트
오더링 서비스
- orderer는 트랜잭션을 정렬한 후 최신 블록 생성
- orderer의 오더링 서비스 기능은 Kafka(카프카)의 분산 메시징 시스템 이용해 구현
- 트랜잭션을 전달받은 Orderer가 카프카 클러스터를 통해 블록을 생성하는 Producer역할, 그리고 생성된 블록을 전달받는 peer가 Consumer 역할
728x90반응형LIST이전글이 없습니다.댓글