이 글은 https://hyperledger-fabric.readthedocs.io/en/release-2.4/ 를 정리하였습니다.
A Blockchain Platform for the Enterprise — hyperledger-fabricdocs main documentation
Enterprise grade permissioned distributed ledger platform that offers modularity and versatility for a broad set of industry use cases. Note If you have questions not addressed by this documentation, or run into issues with any of the tutorials, please vis
hyperledger-fabric.readthedocs.io
하이퍼 레저 패브릭 탄생 배경
블록체인에 대한 관심도가 높아짐에 따라 이를 사업에 적용하는 데에 대한 관심 또한 높아졌다.
- 참여자를 식별할 수 있어야 한다.
- 네트워크에 권한이 필요하다.
- 트랜잭션 성능이 좋아야 한다.
- 트랙잭션 확인에 지연 시간이 짧아야 한다.
- 비즈니스 거래와 관련된 거래 및 데이터의 개인 정보 보호 및 기밀 유지.
자산
자산은 유형(부동산 및 하드웨어)에서 무형(계약 및 지적 재산)에 이르기까지 다양하다.
Hyperledger Fabric은 체인코드 트랜잭션을 사용하여 자산을 수정할 수 있는 기능을 제공한다.
자산은 Hyperledger Fabric에서 키-값 쌍의 모음으로 표시되며 상태 변경은 채널 원장에 트랜잭션으로 기록된다.
자산은 바이너리 및 JSON형식으로 나타낼 수 있다.
하이퍼 레저 패브릭 특징
- Fabric은 제한된 DSL(Domain-Specific-Language)이 아닌 Java, Go 및 Node.js와 같은 범용 프로그래밍 언어로 작성된 스마트 컨트랙트를 지원하는 최초의 Hyper ledger platform. 따라서 새로언 언어나 DSL을 배우기 위한 추가적인 교육이 필요없다.
- Fabric은 다른 허가가 필요없는 네트워크 들과 다르게, 신뢰성을 참여자들만이 참여할 수 있다. 또한, 이들은 서로를 알고 있지만 서로의 행위에 대해서는 알 수 없다.
- Fabric의 가장 큰 차이점은 pluggable consensus protocol이다. 이는 plug & play 방식을 지원한다. Plug & Play 방식이란 꽂으면 실행된다는 뜻으로, 컴퓨터 실행 중에 주변 장치를 부착해도 별다른 설정 없이 작동함을 뜻한다.(효과적으로 사용자 정의 가능)
- 합의 알고리즘이 정해져 있는 비트코인, 이더리움과 달리 요구사항에 따라 합의 알고리즘을 교체할 수 있다.
- Fabric은 기존이 암호화폐를 연료로 사용하지 않는다.(이로 인해 위험, 공격이 줄고 다른 분산 플랫폼과 거의 동일한 비용으로 배포할 수 있음을 의미한다.)
- Permissionless의 경우 작업 증명 poW 과 같은 프로토콜을 통해 네트워크에 참여할 수 있다.
- 대신, HyperLedger Fabric 네트워크의 구성원은 신뢰할 수 있는 MSP(Member Service Provider)를 통해 등록합니다.
Modularity
Fabric은 모듈식 아키텍처를 갖도록 설계되었다.
- 트랜잭션 순서에 대한 합의를 설정한 다음 블록을 피어에게 브로드캐스트 한다.
- 스마트 컨트랙트(chain code)는 격리를 위해 컨테이너 환경(예: Docker) 내에서 실행된다. 표준 프로그래밍 언어로 작성할 수 있지만 ledger state에 직접 액세스할 수는 없다.
- ledger fabric은 다양한 DBMS를 지원하도록 구성될 수 있다.
- 애플리케이션 별로 독립적으로 보증 및 보증 정책을 구성, 시행할 수 있다.
Permissioned VS Permissionless BlockChain
Hyper Ledger Fabric은 허가형 블록체인이다. 무허가 블록체인에서는 거의 모든 사람이 참여할 수 있으며 모든 참가자는 익명인데에 반해, 일정 수준의 신뢰를 제공하는 거버넌스 모델에서 작동한다.
이러한 참여자의 신뢰성을 바탕으로 값 비싼 채굴이 필요하지 않고 보다 전통적인 CFT(Crash Fault Tolerant) 또는 BFT(Byzantine Fault Tolerant) 합의 프로토콜을 사용할 수 있다.
참가자가 서로를 알고 있으며 트랜잭션, 네트워크 구성 등의 정보가 블록체인에 기록된다. 이로인해 문제에 대한 추적성을 향상시킬 수 있다.
Privacy and Confidentiality
Hyperledger Fabric은 모든 참가자가 ID를 알고 있는 트랜잭션 네트워크를 지원한다.
사업으로써의 블록체인으로 확대하면, PoW를 활용하는 무허가 네트워크에서는 암호화된 데이터가 모든 노드에 존재한다.
충분한 시간과 계산 리소스가 주어지면 암호화가 깨질 수 있고, 정보가 노출될 수 있다.
허가형 플랫폼인 Hyper Ledger Fabric은 채널 아키텍처와 개인 데이터 기능을 통해 기밀성을 유지한다.
하이퍼레저 패브릭은 사적이고 비밀스러운 트랜잭션이 필요한 사용자에게 동일한 허가된 네트워크를 제공한다. 채널 정보를 비롯한 모든 데이터는 해당 채널에 대한 액세스 권한이 명시적으로 부여되지 않은 참여자에게는 보이지 않으며 액세스할 수 없다. 따라서 채널에 참여하는 노드만 스마트 컨트랙트와 거래되는 데이터에 액세스할 수 있다.
채널 생성 기능으로 특정 참여자 그룹이 별도의 transaction ledger를 생성할 수 있다.
일부 참여자가 거래를 원하지 않는 네트워크에 특히 중요한 옵션이다.
예를 들어 두 명의 참여자가 채널을 구성하면 해당 참여자(다른 참여자 없음)는 해당 채널에 대한 ledger 사본을 갖게된다. 합의(consensus)라는 작업을 통해 다른 피어의 사본과 일관성을 유지한다.
디지털 인증서
인증 기관(CA)으로 에서 받은 인증서 발급자를 다른 사람에게 제시하여 자신의 신원을 증명할 수 있다.
인증 기관
다른 참여자들에게 인증서를 배포한다.공개 키는 인증서에 포함되지만 CA나 소비자의 개인 키는 포함하지 않기 때문에 널리 보급될 수 있다.
멤버 서비스 제공 업체(MSP)
MSP는 CA(Cerification Authority)에서 발급한 인증서를 활용해 참여자의 신원을 확인한다.
사용자 블록체인 네트워크 인증 과정
- 신뢰받는 CA에서 ID(인증서, 서명 인증서)를 발급한다.
- ID를 발급받은 사용자의 공개 키(인증서, 서명 인증서)를 조직의 MSP에 추가하여 구성원이 된다.
- MSP를 블록체인 네트워크 or 채널 컨소시엄에 추가한다.
- MSP가 네트워크 Policy에 포함되어 있는지 확인한다.
MSP는 단순히 참여자를 나열하는 것에 그치지 않는다.
노드 또는 채널에 대해 갖는 특정 권한을 식별하여 ID에 따른 역할을 부여한다.
사용자가 Fabric CA에 등록되면 관리자,피어,클라이언트,주문자와 같은 역할이 연결되어야 한다.
뿐만 아니라 해지된 ID의 식별을 허용할 수도 있다.
MSP Domain
- Local MSP(로컬 MSP): 관리 권한이나 참가 권한을 가진 사용자를 로컬 레벨에서 정의한다. ⇒ 모든 사용자나 노드는 정의된 로컬 MSP가 있어야 한다. 노드 당 하나의 로컬 MSP만 존재.
- Channel MSP(채널 MSP): 관리 권한이나 참가 권한을 해당 조직의 구성원이 참여하는 채널 레벨에서 정의한다. ⇒ 채널에는 정의된 채널 MSP가 있어야 한다.
- 로컬 MSP와 채널 MSP는 동작 방식이 아닌 동작 범위의 차이점이 있다.
- 채널에 참여하는 모든 조직에는 해당 채널에 대해 정의된 MSP가 있어야 한다.
- 채널 참여자가 채널에 가입하려는 경우 해당 조직에 대한 신뢰 체인을 통합하는 MSP가 채널 구성에 포함되어 있어야 한다.
정책
정책이란
Hyperledger Fabric에서 정책은 인프라 관리를 위한 메커니즘이다. Fabric 정책은 구성원이 네트워크,채널 또는 스마트 컨트랙트에 대한 변경 사항을 수락하거나 거부하는 데 동의하는 방법을 나타낸다. 정책은 채널이 발전해 감에 따라 수정할 수도 있다.
예를 들어, 채널에서 구성원을 추가 또는 제거하기 위한 기준을 설명하고, 블록이 형성되는 방식을 변경하거나, 스마트 컨트랙트을 승인하는 데 필요한 조직의 수를 지정한다.
정책이 필요한 이유
Hyperledger Fabric은 Ethereum 또는 Bitcoin과 달리 블록체인을 만드는 것 이다.
이러한 시스템에서는 네트워크의 모든 노드에서 트랜잭션을 생성하고 검증할 수 있다.
네트워크를 관리하는 정책은 항상 고정되며, 코드를 관리하는 동일한 코드를 통해서만 변경할 수 있다.
Fabric은 기본 인프라에서 사용자를 인식하는 허가형 블록체인 이기 때문에 해당 사용자는 네트워크가 시작되지 전에 네트워크 거버넌스를 결정하고 실행 중인 네트워크의 거버넌스를 변경할 수 있다.
액세스 제어 목록(ACL - Access control lists)
ACL은 애플리케이션의 채널 구성에 정의되어 있는 정책을 참조하고, 이를 확장시켜 추가 리소스를 제어한다.
네트워크 관리자들은 특히 리소스에 대한 액세스를 구성하기 위해 Fabric의 ACL을 사용하는 것에 관심이 있다.
configtx.yaml 에 Fabric ACL의 기본 세트가 표시되지만 재정의할 수 있고, 재정의 해야 한다.
# ACL policy for chaincode to chaincode innovation
peerChaincodeToChaincode: /Channel/Application/WriterspeerChaincodeToChaincode는 보호되는 리소스를 나타내고 /Channel/Application/Writers는 충족되어야 하는 정책을 나타낸다.
정책을 작성하는 방법
Fabric에서 어떤 것이든 변경하려는 경우, 리소스와 관련된 정책이 누가 승인해야 하는지(개인의 명시적 sign off 나 그룹의 암시적 sign off) 묘사한다.
Hyperledger Fabric에서 정책의 Explicit Sign Off는 Signature구문을 사용하여 표현되고 Implicit Sign Off는 ImplicitMeta구문을 사용하여 표현된다.
- Signature 는 정책을 충족시키기 위해 sign in 해야 하는 특정 타입의 사용자를 정의한다. 구체적인 규칙을 구성할 수 있기 때문에 유리하다.
- Implicit Meta 는 configuration tree에서 계층화된 정책 계층을 기반으로 하는 채널 구성 컨텍스트 에서만 유효하다. signature 정책에 의해 정의되는 configuration tree의 더 깊은 정책 결과를 집계한다.
- Hyperledger Fabric은 시작,개발, 테스트하기에 유용한 Default Policies를 포함한다. Default Policies은 configtx.yaml에 있으며 사용자 정의할 수 있다. Channel configuration policies는 configtx.yaml 에서 기본값인 Readers, Writers, Admins 가 아닌 다른 것으로 확장될 수 있다.
피어(Peer)
피어는 Ledger와 스마트 컨트랙트를 관리하는 블록체인 네트워크의 기본 요소이다.
생성, 시작, 중지, 재구성 및 삭제할 수 있는 유연하고 중복되는 요소이다.
피어는 원장의 인스턴스와 체인코드의 인스턴스를 호스트한다. 왜냐하면 블록체인은 일관된 데이터 복제본과 스마트 컨트랙트를 필요로하기 때문이다.
Hyperledger Fabric v2.4부터 피어는 Fabric Gateway 서비스를 실행하여 트랜잭션 제안 및 보증도 관리한다.
게이트웨이를 통해 트랜잭션 제안(체인코드 호출)을 제출하고, 승인을 요청하고, 이벤트를 수신하고, 승인된 트랜잭션을 주문 서비스로 전달할 수 있다.
게이트웨이의 피어 연결을 통해 애플리케이션은 체인코드를 실행하여 Ledger에 쿼리를 보내거나 Ledger를 업데이트할 수 있다. 쿼리는 간단하게 처리되는 반면 업데이트는 복잡한 과정을 거친다.
Ledger Update Process(with Peer)
피어는 orderer와 함께 채널의 모든 피어에서 원장이 일관되고 최신 상태로 유지되도록 한다.
세 가지 트랜잭션 단계를 거쳐 업데이트된다. 이는 Fabric이 트랜잭션을 관리하는 내부 방법을 설명한다. 그러나 개발자는 Fabric Gateway SDK만 사용하면 된다.
- 거래 제안 및 승인
- 거래 제안 - 클라이언트 애플리케이션이 피어의 게이트웨이 서비스에 연결하여 서명된 거래 제안을 제출한다.
- 트랜잭션 실행 - 게이트웨이 서비스는 요청한 피어 또는 해당 조직(피어의 조직)의 다른 피어를 선택하여 트랜잭션을 실행한다. 제안에 지정된 체인 코드를 실행하고 응답을 생성한다. 응답에 서명하고 게이트웨이로 반환한다.
- 트랜잭션 승인 - 게이트웨이는 승인 정책에서 요구하는 각 조직에 대한 트랜잭션 실행을 반복합니다. 게이트웨이 서비스는 서명된 제안 응답을 수집하고 트랜잭션 봉투를 생성하여 서명을 위해 클라이언트(SDK)로 반환합니다.
- 거래 제출 및 주문
- 트랜잭션 제출 - 클라이언트(SDK)는 서명된 트랜잭션 봉투를 게이트웨이 서비스로 보냅니다. 게이트웨이는 봉투를 주문 노드로 전달하고 클라이언트에 성공 메시지를 반환합니다.
- 트랜잭션 순서 지정 - Orderer는 서명을 확인하고 The Ordering Service는 트랜잭션을 주문하고 다른 순서화된 트랜잭션과 함께 블록으로 패키징한다. 이 후 Ledger에 대한 유효성 검사 및 커밋을 위해 채널의 모든 피어에 블록을 배포한다.
- 거래 검증 및 약정
- 트랜잭션 유효성 검사 - 각 피어는 트랜잭션 봉투의 클라이언트 서명이 원래 트랜잭션 제안의 서명과 일치하는지 확인합니다. 모든 피어의 보증이 일치하고 보증이 보증 정책을 충족하는 지 확인한다. 그런 다음 원장에 각 트랜잭션이 유효한지 무효한지를 표시한다.
- 트랜잭션 커밋 - 각 피어는 채널 Ledger에 주문된 트랜잭션 블록을 커밋한다(이 후 변경 불가능). 유효한 트랜잭션의 경우 채널의 world state에 업데이트 된다.
- 커밋 이벤트 - 원장에 커밋하는 각 피어는 원장 업데이트 증거와 함께 커밋 상태를 클라이언트에 보낸다.
피어와 채널
채널은 Fabric 블록체인 네트워크 내의 구성 요소가 통신하고 거래하는 메커니즘이다.
채널에서 피어는 애플리케이션 혹은 서로 상호작용할 수 있다.(애플리케이션과 피어 간의 통신을 위한 경로)
채널의 구성 요소는 피어 노드, Orderer 노드 및 Application이 포함되며 채널에 가입하여 동일한 Ledger의 사본을 공동으로 관리하고 공유하기 위해 협력하는 데 동의한다.
하나의 피어는 여러 채널에 속할 수 있으며 각 채널에 특정한 Ledger과 체인코드를 유지할 수 있다.
피어와 조직
Fabric 블록체인 네트워크는 단일 조직이 아닌 여러 조직에서 관리한다. 피어는 이러한 조직이 소유하고 있으며 조직의 네트워크 연결 지점이기 때문에 이러한 종류의 분산 네트워크를 구축하는 방법의 핵심이다.
네트워크는 개별 조직에 의존하지 않는다. 조직 구성원이 네트워크의 자체 정의 요구 사항을 충족하는 한 탈퇴에도 불구하고 계속 존재한다. 이 것이 네트워크가 탈중앙화된다는 의미의 핵심이다.
Peer 및 정체성
피어가 Fabric 네트워크 채널에 연결할 때마다 Channel Policy는 피어의 ID를 사용하여 권한을 결정한다.
조직에 대한 ID 매핑은 MSP에서 제공한다. MSP는 피어가 특정 조직의 특정 역할에 할당시키고 이에 따라 리소스에 대한 승인된 액세스 권한을 연결한다.
피어 및 Fabric 네트워크와 상호 작용하는 모든 것들(피어,애플리케이션, 최종 사용자, 관리자 및 주문자)은 디지털 인증서 및 MSP에서 조직 ID를 얻는다.(네트워크와 상호작용하는 데 IS와 관련 MSP가 필요)
동료 및 주문자
애플리케이션과 피어가 채널 전체에서 원장을 최신 상태로 일관성 있게 유지하기 위해 서로 상호 작용하는 메커니즘은 orderers라는 특수 노드에 의해 조정된다.
Orderer 및 Peer의 관점에서 업데이트 과정
- 거래 제안
- 클라이언트에서 선택한 피어는 체인 코드를 호출하여 트랜잭션을 실행한다(Ledger에 영향을 주지 않고 트랜잭션을 실행.함 시뮬레이션 느낌??)
- 게이트웨이 서비스 또한 트랜잭션 제안을 필요한 보증 피어에 전달하며, 그 피어도 트랜잭션을 실행하고 그 결과를 (피어에) 반환한다. 게이트웨이 서비스는 모든 응답을 수집하고, 보증 정책을 집합적으로 충족하는 경우 트랜잭션을 주문 서비스로 전달한다.
- 피어는 디지털 서명을 추가하고 개인 키를 사용하여 전체 페이로드에 서명하여 제안 응답을 보증한다. 이 보증은 이후에 이 조직의 동료가 특정 응답을 생성했음을 증명하는 데 사용할 수 있다.
- 거래 주문
- 주문자 노드에서 실행되는 주문 서비스는 게이트웨이 서비스를 통해 하나 이상의 애플리케이션에서 서명 및 승인된 제안 응답을 포함하는 트랜잭션을 수신하고 트랜잭션을 블록으로 주문 및 패키지 합니다.
- 검증 및 약속
- Orderer에서 피어로 주문된 트랜잭션을 배포한다.
- 각 피어는 올바른 순서로 각 트랜잭션의 유효성을 검사하고 모든 필수 조직에서 일관되게 보증되었는지 확인한다.
- Orderer가 모든 피어에게 블록(복사본) 배포 - 각 피어는 독립적으로 블록을 처리(그러나 채널 내에서 방식이 모두 동일) - 수신하면 블록에 지정된 순서대로 트랜잭션 처리 - 피어는 (필요로 하는)조직이 각 트랜잭션을 승인했는지 확인 - 트랜잭션이 올바른 경우 Ledger에 적용(Ledger의 상태와 호환되는지, 이미 업데이트 되었는 지 등의 이유로 일관성 검사를 수행함) - 블록이 피어의 Ledger에 커밋될 때마다 해당 피어는 이벤트를 생성
- 정리하면 Orderer가 생성한 트랜잭션 블록이 검증되고 지속적으로 Ledger에 적용된다.
Orderer and Consensus
이 전체 트랜잭션 과정을 Consensus(합의)라고 한다. 피어가 주문자의 중재를 통해 트랜잭션의 순서와 내용에 대해 합의에 도달한다. Ledger 업데이트는 합의가 완전히 완료된 경우에 발생한다.
주문자는 피어가 승인하고 원장에 추가하도록 순서를 지정하고 Ledger에 배포하는 노드이다.
Ledger
Hyperledger Fabric에서 Ledger은 world state와 blockchain 두 부분으로 구성된다.
World State - 원장 상태의 현재 값을 보유하는 것이다.
Blockchain - World State의 변경 사항을 기록하는 transaction log이다. 블록체인 데이터 구조는 world state와 달리 immutable 속성을 갖는다.
세계 상태(World State)
고유한 원장 상태로 비즈니스 현재 값을 보유한다.
객체의 현재 값을 위해 전체 블록체인을 찾을 필요 없이 world state에서 가져오기만 하면 된다.
애플리케이션 프로그램은 원장 API를 사용하여 스마트 컨트랙트를 호출할 수 있다(get,put,delete)
World State는 데이터베이스로 구현된다. 데이터베이스가 상태의 효율적인 저장 및 검색을 위한 연산을 제공한다.
요점은 필요한 보증 조직에서 서명한 트랜잭션만 world state로 업데이트 된다. 이 world state의 변경 사항은 원장 블록체인에 커밋된다. 보증되지 않으면 world state가 변경되지 않는다.
state에는 버전 번호가 있으며 시작 버전은 0이다. 버전 번호는 Hyperledger Fabric 내부에서만 사용되며 상태가 변경될 때마다 증가한다. 현재 상태가 보증된 시점의 버전과 일칳는지 확인하기 위해 상태가 업데이트 될 때마다 버전이 확인된다.
원장이 처음 생성될 때 세계 상태는 비어 있다. World state에 대한 유효한 변경을 나타내는 모든 트랜잭션이 블록체인에 기록되기 때문에 언제든지 블록체인에서 world state를 재생성할 수 있다.
블록체인(Blockchain)
블록체인은 상호 연결된 블록의 순차 로그로 구조화되며, 각 블록에는 일련의 트랜잭션이 포함되며 각 트랜잭션은 세계 상태에 대한 쿼리 또는 업데이트를 나타낸다. 블록 순서와 블록 내 트랜잭션 순서는 Ordering Service라는 Hyperledger Fabric 구성 요소에 의해 설정된다.
각 블록의 헤더에는 블록 트랜잭션의 해시와 이전 블록 헤더의 해시가 포함된다. 이러한 방식으로 원장의 모든 트랜잭션은 순서가 지정되고 암호화된 방식으로 연결된다.
데이터 베이스를 사용하는 world state와 달리 블록체인은 항상 파일로 구현된다.(매우 작은 구조이므로)
블록체인의 첫 번째 블록을 genesis block이라고 한다. 사용자 트랜잭션이 포함되어 있지는 않지만 원장의 시작점이다. 대신 네트워크 채널의 초기 상태를 포함하는 구성 트랜잭션을 초함한다.
블록
블록은 3개의 섹션으로 구성되어 있다
- 블록 헤더
- 블록 번호 : 0(제네시스 블록) 에서 시작하는 정수로, 블록이 추가될 때마다 1씩 증가한다.
- 현재 블록 해시 : 현재 블록에 포함된 모든 트랜잭션의 해시이다.
- 이전 블록 헤더 해시 : 이전 블록 헤더의 해시이다.
- 블록 데이터 : 주문 서비스에 의해 작성되며 순서대로 정렬된 트랜잭션 목록이 포함되어 있다.
- 블록 메타데이터 : 네트워크 노드에서 블록을 확인하는 데 사용되는 블록 생성자의 인증서 및 서명이 포함된다. 그 후에 블록 커미터는 상태 포크를 감지하기 위해 모든 트랜잭션에 대한 유효/무효 표시기를 블록 메타데이터에 있는 비트맵에 추가하고 해당 블록까지 누적 상태 업데이트의 해시를 추가한다. 블록 데이터 및 헤더 필드와 달리 이 섹션은 블록 해시 계산에 대한 입력이 아닙니다.
거래(Transaction)
트랜잭션은 world state의 변경 사항을 포착(캡처)한다. 블록 트랜잭션을 포함하는 블록 데이터 구조이다.
- 헤더 : 트랜잭션에 대한 몇 가지 필수 메타데이터(관련 체인코드의 이름 및 해당 버전 등 ..)을 캡처한다.
- 서명 : 클라이언트 애플리케이션에서 생성한 암호화 서명이 포함되어 있다. 트랜잭션 세부 정복 변조되지 않았는지 확인하는 데 사용된다.
- Proposal : 이 필드는 제안된 원장 업데이트를 생성하는 스마트 계약에 애플리케이션이 제공한 입력 매개변수를 인코딩한다. 스마트 컨트랙트가 실행될 때 이 제안은 현재 세계 상태와 함께 새로운 세계 상태를 결정하는 입력 매개변수 세트를 제공한다.
- 응답 : world state의 전 후 값을 Read-Write 세트로 캡처한다. 스마트 컨트랙트의 출력이며 트랜잭션이 성공적으로 검증되면 원장에 적용되어 world state를 업데이트한다.
- Endorsement : 보증 정책을 충족하기에 충분한 각 필수 조직의 서명된 트랜잭션 응답 목록이다. 하나의 트랜잭션 응답만 트랜잭션에 포함되지만 여러 보증이 있음을 알 수 있습니다. 이는 각 보증이 조직의 특정 트랜잭션 응답을 효과적으로 인코딩하기 때문이다. 즉, 유효하지 않은 것으로 거부되고 world state를 업데이트하지 않으므로 충분히 보증되지 않는 트랜잭션 응답을 포함할 필요가 없습니다.
World State Database Options
현재 옵션에는 LevelDB 및 CouchDB가 있다.
LevelDB가 기본 값이며 단순한 key-value pair일 때 적합하다.
CouchDB는 비즈니스 트랜잭션에서 흔히 볼 수 있는 다양한 쿼리와 업데이트를 지원하기 때문에 Ledger 상태가 JSON 구조일 때 적합하다.
LevelDB와 CouchDB는 pluggable하다
관계형 ,그래프, 시간 데이터베이스 어떤 것이더라도 사용될 수 있고 원장 상태 유형에 따라 효율적으로 액세스할 수 있는 유연성을 제공한다.
Namespace
각 체인코드에는 다른 모든 체인코드와 구분되는 고유한 world state가 있다.
World state는 namespace에 있으므로 동일한 체인코드 내의 스마트 컨트랙트만 지정된 namespace에 액세스 할 수 있다.
블록체인은 namespace가 없다. 그러나 다양한 스마트 컨트랙트 namespace의 트랜잭션이 포함된다.
채널
Hyperledger Fabric에서 각 채널에는 완전히 별도의 Ledger이 있다.
이는 블록체인, namespace,world state가 완전히 분리됨을 의미한다.
애플리케이션과 스마트 컨트랙트는 채널 간의 통신을 통해 원장 정보에 액세스할 수 있다.
주문 서비스(Ordering Service)
이더리움 및 비트코인과 같은 많은 분산 블록체인은 허가가 필요하지 않기 때문에 누구나 합의 프로세스에 참여할 수 있다. 이로인해 해당 시스템은 확률적 합의 알고리즘에 의해 원장 일관성을 보장하려 한다.
Hyperledger Fabric은 트랙잭션 주문을 수행하는 orderer라는 노드가 있다. Fabric은 결정적 합의 알고리즘에 의해 검증된 모든 블록이 정확함을 보장한다. 체인코드 실행(피어에서 발생)을 승인하는 것을 Ordering에서 분리하면 성능 및 확장성에 이점이 있으며 동일한 노드에서 실행 및 순서 지정이 수행될 때 발생할 수 있는 병목 현상을 해결할 수 있다.
Orderer nodes and channel configuration
Orderer 또한 채널에 대한 기본 액세스 제어를 수행하여 R/W, 구성 권한을 제한할 수 있다.
채널의 구성 요소를 수정하기 위해서는 관리자가 컨소시엄 또는 채널을 만들 때 설정한 정책의 적용을 받는다. 구성 트랜잭션을 실행하기 위해서는 현재 정책들에 대해 알아야 하기 때문에 Orderer에 의해 처리된다. Orderer는 구성 업데이트를 처리하여 피어에게 적절한 관리 권한이 있는지 확인한다.
정리
- 기존 구성에 대한 업데이트 요청 유효성 검사.
- 새 구성 트랜잭션을 생성
- 채널의 모든 피어에게 연결 되도록 블록을 생성함
Orderer 노드도 피어처럼 조직에 속합니다. 또한 조직의 CA를 사용해야 한다.
Orderers and the transaction flow
- 거래 제안 및 승인
- 클라이언트 애플리케이션은 신뢰할 수 있는 피어를 통해 Fabric gateway 서비스에 트랜잭션 제안을 보낸다.
- 게이트웨이가 승인 정책에서 요구하는 조직의 피어에게 트랜잭션을 전달한다.
- 보증 피어가 전달받은 트랜잭션을 실행하고 게이트웨이 서비스에 트랜잭션 응답을 반환한다.
- 거래 제출 및 주문
- 클라이언트 애플리케이션에서 승인된 응답을 받았다면 게이트웨이 서비스는 트랜잭션을 다른 승인된 트랜잭션과 함께 주문하고 (블록을 생성하는) ordering service로 트랜잭션을 전달한다.
- Ordering service가 블록을 생성한다
- orderer의 ledger에 저장한다.
- Ordering service 노드들은 많은 클라이언트 애플리케이션(게이트웨이를 통해)에서 트랜잭션을 받는다. 이 Ordering service 노드들이 여러 채널에서 공유되는 Ordering sevice를 형성한다.
- 거래 검증 및 약정
- 채널의 모든 피어에게 배포된다.(피어가 다운되거나 나중에 채널에 합류하면 다른 피어에게서 블록을 받는다) - 그러나 모든 피어가 orderer에게 연결될 필요는 없다. (자연스럽게 전파)
- 각 피어는 분산 블록을 독립적으로 검증하여 원장이 일관성을 유지하도록 한다.(필요한 조직에 의해 승인 되었는가, 승인이 일치하는 가,최근에 커밋된 다른 트랜잭션에 의해 무효화되지 않았는가.)
구현
ordering service 노드 간의 트랜잭션 순서를 정하기 위한 구현.
- Raft(권장)
- 추후에 자세히 설명할 예정
- Kafka(deprecated)
- Raft 기반 ordering 과 유사하게 리더 및 팔로워 모델을 사용한다.
- Kafka 클러스터를 관리하는 추가 관리 오버헤드가 발생할 수 있다.
- Solo(deprecated)
- 테스트 전용으로 사용하며 single ordering node 로만 구성된다.
- 더 이상 사용되지 않으며 향후 배포 버전에서 삭제될 수 있다.
Raft
Fabric에서 Raft 프로토콜의 구현은 채널의 주문 노드 중에서 리더가 동적으로 선택되는 리더 및 팔로워 모델을 사용한다. 리더가 팔로워 노드에 메세지를 복제한다. CFT(Crash Fault Tolerance) 구현 방식을 사용하며 이는 어떠한 노드가 충돌(Crash)이 발생한 경우에도 서비스 제공을 위해 시스템이 동작하게 하는 충돌 장애 허용 기법을 이야기한다.
Raft와 Kafka는 둘 다 리더 및 팔로워 디자인을 사용하는 CFT 주문 서비스 이다.
스마트 컨트랙트 개발자나 피어 관리자의 경우 차이점이 없으나 주문 서비스를 관리 부분에서 차이점이 있다.
- Raft가 설정하기 더 쉽다.
- Kafka와 이를 관리하기 위한 Zookeeper 앙상블은 대규모 네트워크에서 실행되도록 설계되지 않았고 사실 상 하나의 조직에서 Kafka 클러스터를 실행해야 한다. 이로 인해 Kafka를 사용하면 ordering nodes를 다른 조직에서 실행하면 노드가 분산되지 않는다. 궁극적으로 모든 노드가 단일 조직의 제어 하에 있는 Kafka 노드로 이동하기 때문이다. Raft를 사용하면 각 조직은 주문 서비스에 참여하는 고유한 주문 노드를 가질 수 있으므로 보다 분산된 시스템으로 이어진댜.
- Raft는 사용자가 어떤 주문 노드를 어떤 채널에 배포할 지 지정할 수 있다.
- Raft는 Fabric의 BFT(Byzantine Fault Tolerant)를 따른다.
Raft의 새로운 개념 또는 기존 개념의 변형
- Log Entry : Raft 주문 서비스의 기본 작업 단위이다.멤버의 과반수가 항목과 순서에 동의하여 로그가 복제되는 경우 로그가 일관성 있는 것으로 간주한다.
- Consenter set(동의 세트) : 순서 지정 노드는 주어진 채널에 대한 합의 메커니즘에 적극적으로 참여하고 채널에 대한 복제된 로그를 수신한다.
- Finite-State Machine(FSM) : Raft의 모든 순서 지정 노드에는 FSM이 있으며 집합적으로 다양한 순서 지정 노드의 로그 순서가 결정적인지 확인하는 데 사용된다.
- Quorum(정족수): 트랜잭션을 주문할 수 있도록 동의자의 최소 수를 뜻한다. 노드 쿼럼을 채우지 못하면 채널에서 R/W, Task, 순서 지정 서비스 클러스터를 사용할 수 없게 되며 새 로그를 커밋할 수 없다.
- leader : Kafka의 리더와 유사하지만 채널의 동의자 집합이 단일 노드를 리더로 선택한다는 점이 다르다. 리더는 새 로그 항목을 수집하고, 이를 추종자 순서 지정 노드에 복제하고, 항목이 커밋된 것으로 간주한다.
- Follower(추종자) : 리더로부터 로그를 수신하고 복제하여 로그의 일관성을 유지한다. 리더가 구성 가능한 시간에 중단되는 경우 추종자는 리더 선출을 시작하고 그 중 한 명이 새 리더로 선출된다.
Raft에서 트랜잭션은 트랜잭션을 수신하는 순서 지정 노드에 의해 해당 채널의 현재 리더에게 자동으로 라우팅된다. 이는 피어와 애플리케이션이 리더가 누구인지 알 필요없이 순서 지정 노드만 알면 된다.
orderer 유효성 검사가 끝나면 트랜잭션이 주문되고 블록으로 생성되어 동의 및 배포된다.
리더 선출
Raft의 노드들은 모두 팔로워, 후보,리더 세 가지 중 하나의 상태에 있다.
처음 생성되면 follow로 시작하며 이 상태에서 리더의 로그 항목을 수락하거나(선택된 경우) 리더에게 투표할 수 있다. 로그 항목이나 하트비트가 수신되지 않으면 노드가 후보 상태로 자동적으로 승격된다.
후보 상태에서 노드는 다른 노드의 투표를 요청한다.
후보자가 투표 정족수를 받으면 리더로 승격된다. 리더는 새 로그 항목을 수락하고 팔로워에게 복제해야 한다.
스마트 컨트랙트 및 체인코드
스마트 컨트래트는 원장과 함께 Hyperledger Fabric에서 핵심 요소이다. 원장이 비즈니스 개체 집합의 현재 및 과거 상태에 대한 사실을 보유하는 반면 스마트 컨트랙트는 원장에 추가되는 새로운 사실을 생성하는 실행 가능한 논리를 정의한다. 체인코드는 일반적으로 관리자가 배포를 위해 관련 스마트 컨트랙트를 그룹화 하는 데 사용하지만 Fabric의 저수준 시스템 프로그래밍 에도 사용할 수 있다.
스마트 컨트랙트
스마트 컨트랙트는 실행 코드에서 서로 다른 조직 간의 규칙을 정의한다. 애플리케이션은 스마트 컨트랙트를 호출하여 원장에 기록될 트랜잭션을 생성한다.
Hyperledger Fabric에서 스마트 컨트랙트와 체인코드
일반적으로 스마트 컨트랙트는 World State에 포함된 비즈니스 개체의 생명 주기를 제어하는 트랜잭션 로직을 정의한다. 그런 다음 블록체인 네트워크에 배포되는 체인코드로 패키징 된다.
스마트 컨트랙트는 거래를 관리하는 것으로 생각되는 반면 체인 코드는 스마트 컨트랙트가 배포를 위해 패키지하는 방식을 관리한다.
스마트 계약은 체인코드 내에서 정의됩니다. 동일한 체인코드 내에서 여러 스마트 계약을 정의할 수 있습니다. 체인코드가 배포되면 그 안에 있는 모든 스마트 계약을 애플리케이션에서 사용할 수 있습니다.
원장
스마트 컨트랙트는 원장의 두 부분에 프로그래밍 방식으로 엑세스 한다.
- 모든 트랜잭션의 이력을 변경할 수 없도록 기록하는 블록체인
- 상태의 현재 값을 저장하는 world state
스마트 컨트랙트는 주로 world state에 상태를 넣고 가져오고 삭제하며 트랜잭션의 변경할 수 없는 블록체인 레코드를 쿼리할 수도 있다.
- get : 정보 검색
- put : 새로운 비즈니스 개체를 생성하거나 원장 world state의 기존 개체를 수정한다.
- delete: 원장의 현재 상태에서 비즈니스 객체의 제거(히스토리에서 제거 되지 않음)
개발
스마트 컨트랙트는 애플리케이션 개발의 초점이며 단일 체인코드 내에서 하나 이상의 스마트 컨트랙트를 정의할 수 있다. 네트워크에 체인코드를 배포하면 해당 네트워크의 조직에서 모든 스마트 컨트랙트를 사용할 수 있다. 관리자만 체인코드에 대해 고려하면 된다. 다른 사람들은 스마트 컨트랙트에 대해서만 고려하게 된다.
Endorsement(보증?)
체인코드에는 그 안에 정의된 모든 스마트 컨트랙트에 적용되는 보증 정책이 연결되어 있다.
보증 정책은 해당 트랜잭션이 유효한 지를 식별하기 전에 먼저 스마트 컨트랙트에 의해 생성된 트랜잭션을 승인해야 하는 조직을 식별한다.
보증 정책에 둘 이상의 조직이 트랜잭션에 서명해야 한다고 지정하는 경우 유효한 트랜잭션이 생성되려면 스마트 컨트랙트가 조직 집합에 의해 실행되어야 한다. (extransfer은 두 사람 모두 실행하고 서명 ORG1해야 ORG2유효한다.)
승인 정책은 hyperledger Fabric 은 이더리움 또는 비트코인과 같은 블록체인과 다르게 만든다.
네트워크 모든 노드에서 유효한 트랜잭션을 생성할 수 있다. 트랜잭션은 네트워크의 신뢰할 수 있는 조직에서 검증해야 한다.
보증 정책은 정책 중의 하나일 뿐이다. 원장을 쿼리 또는 업데이트하거나 네트워크에서 참가자를 추가 또는 제거할 수 있는 사람을 식별하기 위해 다른 정책을 정의할 수 있다. 정책은 확정된 것은 아니지만 블록체인 네트워크의 조직 컨소시엄에서 사전에 합의해야 한다.
거래
스마트 컨트랙트가 실행되면 블록체인 네트워크의 조직이 소유한 피어 노드에서 실행된다.
world state에 대한 변경은 읽은 상태와 트랜잭션이 유효한 경우 기록될 새 상태가 모두 포함된 읽기-쓰기 세트가 포함된 트랜잭션 제안 응답으로 캡처된다. 스마트 컨트랙트가 실행될 때 world state는 업데이트 되지 않는다.
모든 거래에는 일련의 조직에서 서명한 식별자, 제안 및 응답이 있습니다. 유효 여부에 관계없이 모든 거래는 블록체인에 기록되지만 유효한 거래만 세계 상태에 기여합니다.
네트워크의 모든 피어 노드에 배포되는 트랜잭션은 각 피어에 의해 두 단계로 검증된다.
- 거래가 승인 정책에 따라 충분한 조직에서 서명 되었는가
- world state의 현재 값이 승인하는 피어 노드에 의해 서명되었을 때 트랜잭션의 읽기 세트와 일치하는 가
유효 여부와 관계 없이 모든 거래는 블록체인 기록에 추가되지만 유효한 거래만 world state로 업데이트된다.
채널
Hyperledger Fabric을 사용하면 조직이 채널을 통해 여러 개의 개별 블록체인 네트워크에 동시에 참여할 수 있다. 채널은 데이터 및 통신 개인 정보를 유지하면서 인프라를 효율적으로 공유한다. 조직이 서로 다른 상대방과 작업 트래픽을 분리하는 데 도움이 될 만큼 충분히 독립적이지만 필요할 때 독립적인 활동을 조정할 수 있도록 충분히 통합되어 있다.
채널은 조직 집합 간에 완전히 별도의 통신 메커니즘을 제공합니다. 체인코드 정의가 채널에 커밋되면 해당 채널의 애플리케이션에서 체인코드 내의 모든 스마트 계약을 사용할 수 있습니다.
체인 코드 내부의 스마트 컨트랙트는 체인코드 정의에 지정된 보증 정책에 따라 채널 구성원이 실행할 수 있다. 보증 정책은 동일한 체인코드 내에서 정의된 모든 스마트 컨트랙트에 동일하게 적용된다.
Intercommunication
스마트 컨트랙트는 동일한 채널 뿜나 아니라 다른 채널의 다른 스마트 컨트랙트를 호출할 수도 있다.
이런 식으로 스마트 컨트랙트 네임 스페이스로 인해 액세스할 수 없는 world state 데이터를 읽고 쓸 수 있다.
System Chaincode
체인코드 내에 정의된 스마트 컨트랙트는 일련의 블록체인 조직 간에 합의된 비즈니스 프로세스에 대한 도메인 종속 규칙을 인코딩 한다. 그러나 체인 코드는 비즈니스 프로세스에 대한 스마트 컨트랙트와 관련이 없는 도메인 독립 시스템 상호작용에 해단하는 low level 프로그램 코드를 정의할 수도 있다.
Fabric 체인코드 생명 주기
체인 코드란?
Chaincode는 규정된 인터페이스를 구현하는 Go,Node.js 또는 Java로 작성된 프로그램이다. 체인코드는 피어 프로세스를 승인하는 것에서 격리된 보안 Docker 컨테이너에서 실행된다. 체인 코드는 애플리케이션에서 제출한 트랜잭션을 통해 원장 상태를 초기화하고 관리한다.
체인코드로 생성된 원장 업데이트는 해당 체인코드로만 범위가 지정되어 다른 체인코드에서 직접 액세스할 수 없다. 그러나 동일한 네트워크 내에서 적절한 권한이 주어지면 체인코드는 상태에 액세스하기 위해 다른 체인코드를 호출할 수 있다.
체인코드 운영자는 Fabric 체인코드 생명주기를 사용하여 네트워크에서 체인코드를 배포 및 관리하는 방법에 대한 가이드로 사용할 수 있다.
체인 코드 배포
- 체인코드 설치 및 정의
- 체인코드 업그레이드
- 배포 시나리오
- 새로운 Fabric 생명 주기로 마이그레이션
- 체인코드 설치 및 정의
- 체인 코드 패키징
- 피어에 체인코드 설치
- 조직의 체인코드 정의 승인
- 채널에 체인코드 정의 커밋
- 체인코드 업그레이드(체인코드 바이너리 or 체인코드 정책)
- 체인코드 재패키지(체인코드 바이너리를 업데이트 하는 경우만 해당)
- 피어에 새 체인코드 패키지 설치(체인코드 바이너리를 업데이트 하는 경우만 해당)
- 새 체인코드 정의 승인
- 채널에 대한 정의 커밋
- 배포 시나리오
- 채널 가입(정의를 다시 커밋할 필요 없음)
- 보증 정책 업데이트(체인코드 설치 없이 보증 정책을 업데이트)
- 정의 승인
- 새로운 Fabric 생명 주기로 마이그레이션
Private Data
해당 채널의 다른 조직으로 부터 데이터를 비공개로 유지해야 하는 경우 새 채널을 만들 수 있다. 그러나 이러한 방법은 추가 관리 오버헤드가 생길 수 있다. 그러나 Fabric이 제공하는 비공개 데이터 컬렉션 기능을 사용하여 해결할 수 있다.(별도의 채널을 생성하지 않고 비공개 데이터를 보증,커밋,쿼리)
개인 데이터 컬렉션은 체인코드 정의 내에서 명시적으로 정의할 수 있다.
Private Data Collection이란?
두 요소를 합친 것이다.
- 실제 개인 데이터 - read 권한이 있는 조직에 P2P로 전송, 권한이 있는 조직의 피어에 있는 private state 데이터베이스에 저장된다. 주문 서비스는 여기에 관여하지 않으며 볼 수 없다.
- 채널에 있는 모든 피어의 원장에 승인되고, 주문되고, 기록되는 해당 데이터의 해시(트랜잭션의 증거 및상태 유효성 검사에 사용)
주로 사용하는 경우
트랜잭션이 조직 집한 간에 공유되어야 하지만 해당 조직의 하위 집합만 트랜잭션 내 데이터의 일부에 액세스 해야하는 경우
개인 데이터를 사용한 거래
- 클라이언트 애플리케이션이 체인코드 기능을 호출하기 위한 요청
- 보증 피어는 트랜잭션을 시뮬레이션하고 개인 데이터를 임시저장소에 저장, 수집 정책에 따라 개인 데이터를 승인된 피어에게 배포
- 보증 피어는 응답을 대상 피어로 보냄, 공개 데이터와 개인 데이터의 key-value 해시를 포함함.그러나, 개인 데이터는 전송되지 않음
- 대상 피어는 응답 확인 후 서명을 위해 클라이언트로 다시 전송, 대상 피어는 트랜잭션을 주문 서비스에 보냄, 개인 데이터 해시가 있는 트랜잭션은 정상적으로 블록에 포함시킴. 개인 데이터 해시가 있는 블록은 모든 피어에게 배포(이러한 방식으로 채널의 모든 피어는 실제 개인 데이터를 모른채 일관된 방식으로 개인 데이터의 해시를 사용하여 트랜잭션을 검증)
- 승인된 피어는 수집 정책을 사용하여 개인 데이터에 대한 액세스 권한이 있는 지 확인
- 로컬을 확인하여 체인코드 승인 시 개인 데이터를 이미 수신했는 지 확인, 수신하지 않았다면 다른 승인된 피어에서 개인 데이터를 가져옴, 공개 블록 해시에 대해 개인 데이터의 유효성을 검사하고 트랜잭션과 블록을 커밋함, 유효성 검사/커밋 시 개인 데이터는 개인 상태 데이터베이스 및 writeset storage에 저장되고 개인 데이터는 임시 저장소에서 삭제됨.
개인 데이터 공유 패턴
- 공개 상태 추적을 위해 해당 공개 키 사용
- 체인코드 액세스 제어
- 대역 외 개인 데이터 공유다른 컬렉션과 개인 데이터 공유
- 개인 데이터를 다른 컬렉션으로 전송
- 거래 승인을 위한 개인 데이터 사용
- 거래자를 비공개로 유지
- 키 수준 트랜잭션 액세스 제어
- 키 수준 보증 정책
헷갈리는 거
궁금증 정리
어떤 점에서 (non)deterministic을 분류할 수 있을까?
- 어디서 실행하든 결과가 같아야함 solidity에서 해결할 수 있는 이유는 리턴을 여러 개로 보낼 수 있기 때문에 이러한 문제를 명확하게 할 수 있다??
ledger안에 world state와 blockchain(transaction log)가 있다. world state는 namespace에 존재한다는 뜻이 namespace로 world state를 분리하여 구성할 수 있다? namespace라는 것은 world state에만 적용이 된다. namespace를 쓰면 다른 체인코드와 분리해서 쓸 구성할 수 있다. 체인코드에는 스마트 컨트랙트가 있다.
ledger - chaincode - peer
ledger - world state + blockchain(엄밀히 말하면 transaction log)
chaincode = smart contract
world state는 smart contract에서 접근 가능한 데 namespace를 달리하면 world state를 분리하여 구성된다. 이런건가?
Privacy and Confidentiality
Hyperledger Fabric은 모든 참가자가 ID를 알고 있는 트랜잭션 네트워크를 지원한다.
사업으로써의 블록체인으로 확대하면, PoW를 활용하는 무허가 네트워크에서는 암호화된 데이터가 모든 노드에 존재한다. 충분한 시간과 계산 리소스가 주어지면 암호화가 깨질 수 있고, 정보가 노출될 수 있다.
허가형 플랫폼인 Hyper Ledger Fabric은 채널 아키텍처와 개인 데이터 기능을 통해 기밀성을 유지한다.
하이퍼레저 패브릭은 사적이고 비밀스러운 트랜잭션이 필요한 사용자에게 동일한 허가된 네트워크를 제공한다. 채널 정보를 비롯한 모든 데이터는 해당 채널에 대한 액세스 권한이 명시적으로 부여되지 않은 참여자에게는 보이지 않으며 액세스할 수 없다. 따라서 채널에 참여하는 노드만 스마트 컨트랙트와 거래되는 데이터에 액세스할 수 있다.
채널 생성 기능으로 특정 참여자 그룹이 별도의 transaction ledger를 생성할 수 있다.
일부 참여자가 거래를 원하지 않는 네트워크에 특히 중요한 옵션이다.
예를 들어 두 명의 참여자가 채널을 구성하면 해당 참여자(다른 참여자 없음)는 해당 채널에 대한 ledger 사본을 갖게된다. 합의(consensus)라는 작업을 통해 다른 피어의 사본과 일관성을 유지한다.
디지털 인증서
인증 기관(CA)으로 에서 받은 인증서 발급자를 다른 사람에게 제시하여 자신의 신원을 증명할 수 있다.
인증 기관
다른 참여자들에게 인증서를 배포한다.공개 키는 인증서에 포함되지만 CA나 소비자의 개인 키는 포함하지 않기 때문에 널리 보급될 수 있다.
멤버 서비스 제공 업체(MSP)
MSP는 CA(Cerification Authority)에서 발급한 인증서를 활용해 참여자의 신원을 확인한다.
사용자 블록체인 네트워크 인증 과정
- 신뢰받는 CA에서 ID(인증서, 서명 인증서)를 발급한다.
- ID를 발급받은 사용자의 공개 키(인증서, 서명 인증서)를 조직의 MSP에 추가하여 구성원이 된다.
- MSP를 블록체인 네트워크 or 채널 컨소시엄에 추가한다.
- MSP가 네트워크 Policy에 포함되어 있는지 확인한다.
MSP는 단순히 참여자를 나열하는 것에 그치지 않는다. 노드 또는 채널에 대해 갖는 특정 권한을 식별하여 ID에 따른 역할을 부여한다.
사용자가 Fabric CA에 등록되면 관리자,피어,클라이언트,주문자와 같은 역할이 연결되어야 한다.
뿐만 아니라 해지된 ID의 식별을 허용할 수도 있다.
MSP Domain
- Local MSP(로컬 MSP): 관리 권한이나 참가 권한을 가진 사용자를 로컬 레벨에서 정의한다. ⇒ 모든 사용자나 노드는 정의된 로컬 MSP가 있어야 한다./// 노드 당 하나의 로컬 MSP만 존재.
- Channel MSP(채널 MSP): 관리 권한이나 참가 권한을 해당 조직의 구성원이 참여하는 채널 레벨에서 정의한다. ⇒ 채널에는 정의된 채널 MSP가 있어야 한다.
- 로컬 MSP와 채널 MSP는 동작 방식이 아닌 동작 범위의 차이점이 있다.
- 채널에 참여하는 모든 조직에는 해당 채널에 대해 정의된 MSP가 있어야 한다.
정책
정책이란(보증 - transaction, policy - resource ???)
Hyperledger Fabric에서 정책은 인프라 관리를 위한 메커니즘이다. Fabric 정책은 구성원이 네트워크,채널 또는 스마트 컨트랙트에 대한 변경 사항을 수락하거나 거부하는 데 동의하는 방법을 나타낸다. 정책은 채널이 발전해 감에 따라 수정할 수도 있다.
예를 들어, 채널에서 구성원을 추가 또는 제거하기 위한 기준을 설명하고, 블록이 형성되는 방식을 변경하거나, 스마트 컨트랙트을 승인하는 데 필요한 조직의 수를 지정한다.
'블록체인' 카테고리의 다른 글
| 블록체인 해커톤 후기 (0) | 2022.12.02 |
|---|---|
| 프로젝트 - 서버에 파일 업로드, 다운로드 기능 개발 (0) | 2022.10.01 |
| FireFly와 Fabric의 스마트 컨트랙트 배포,실행 비교 (0) | 2022.09.04 |
| Hyperledger Fabric SDK를 활용한 트랜잭션 수행 (0) | 2022.09.04 |
