[강좌] 박승철의 정보통신과블록체인 : 하이퍼레저 패브릭

블로그 : https://blog.naver.com/scpark640303/221289061343

유튜브 : https://youtu.be/hh9NXQQRtx4

---

• 특징
• 
  
  • 1) 허가형 블록체인 : (X.509인증서 PKI기반) MSP를 통해, 허가된 사용자만 참여.
  • 2) 일반 프로그래밍 언어
    • : (이더리움의 Solidity와 달리~) 일반적인 언어를 사용함.
    • : 블록체인의 분산컴퓨팅 환경에서는 동일한 처리결과를 보장해야 하기 떄문에...
    • : Deterministic한 프로그램만을 하는 제약이 있는데...
    • : 이를 해결 할 수 있는, Non-Deterministic한 메커니즘이 제공 됨. (실행시 항상 동일하게 리턴)
  • 3) 내부 가상통화 부재
    • : 장점? 수수료가 없다. 단점? 수수료가 없어서... DoS 공격 가능성. (그래서 방어로직구조) 
    • : 이더리움 경우, 작업증명(PoW) 방식의 합의로~ 채굴 전체 시스템이 D'App 버그에 영향을 받음.
    • : 하레패 경우, 특정 chaincode는 일부 endorser-peer에서만 실행되고 보증 받음.
  • 4) 높은 성능
    • : 초당 1만 transaction 이상을 목표.
    • : 병렬처리에 따른 Non-Deterministic함 -> 전체 Ledger 동기화를 위해, Key의 Version을 관리.
  • 5) 교체 가능한 모듈 구조
    • : 타 블록체인 경우, "합의 프로토콜" 등을 바꾸기 위해서, "하드포크"를 하곤 하는데...
    • : 하레패 경우, 필요에 따라 교체 가능. (예 : SOLO, Kafka, BFT, Raft, ... )
  • 6) 멀티 블록체인 지원 : channel 단위로 여러게 가능.
• 네트워크 구조
• 
  
  • client-node : transaction 및 proposal 제출
  • peer-node(endorser,committer) : 선실행 보증 및 최종 반영.
  • orderer-node : 합의 프로토콜 처리
  • MSP : 신원확인(node identity) 및 네트워크 권한을 표식하는 자격증명 발급.
• 블록체인 구성
• 
  
  • world-state
    • : 글로벌 현재상태의 정보.
    • : Version으로 관리되는 Key-Value 구조. (transaction이 발생하면서, 특정 Key의 Value가 바뀌고~ Version기록 됨)
    • : 즉, (transaction이 접근하는) Key와 그에대한 현재 Value 및 그동안의 Version.
  • ledger
    • : 전체 transaction 히스토리를 hash-chain 형태로 저장함.
    • : 하나의 block은 여러게의 transaction으로 구성됨. (block크기 == transaction갯수. 조절 가능.)
• 거래(transaction) 처리방식
• 
  
  • 타 블록체인 시스템
    • : ORDER(순서화) -> EXECUTE(실행)
    • : 예) "참가자들이 transaction발생" -> "채굴자들이 block에 transaction순서정함" -> "전체노드에서 block실행"
    • : 모두 동일한 block을 Deterministic한 Solidity 프로그램으로, 순차적 처리를 하는식... (비효율적)
  • 하이퍼레저 패브릭
    • : EXECUTE(실행) -> ORDER(순서화) -> VALIDATE&COMMIT(검증&반영)
    • : 예) "client서 transaction발생" -> "endoser서 보증실행" -> "orderer서 순서화" -> "committer서 검증 및 반영)
    • : 보증실행은 '별도의 자료구조'(Read-Set,Write-Set)으로 리턴 함. (world-state의 특정 K:Ver의 V를 R/W함)
    • : 보증실행 결과취합에서, 비결정적으로 값이 다를수있고~ 이는 client에서 정책적으로 결정하면 됨.
    • : (시스템 timestamp를 찍는 chaincode은 -> 각기 다른 보증실행 값을 -> 취합하여 평균값으로 결정!)
    • : 순서화는 "transaction과 + 그 실행 결과값"을 가지고, block에 '순서화 합의'하는 consensus!이다.
    • : 각자가 받은 block을 Non-Deterministic한 프로그램으로, 병렬적 처리를 할 수 있는 구조. (각 단계가 독립적)
    • 
• MSP 구조
• 
  
  • PKI 기반구조
    • RootCA : 인증서를 발행하는 기관. (예 : 금융결제원 등)
    • 인증서 : 어떤 public-key가 특정 사용자의 신원(identity)의 것이 맞다는 것을 공인된 문서로 인증 정리한 것.
  • 하레패의 PKI 구성
    • ECA(Enrollment CA)
      • : '등록된 참여자'가 맞다는 인증서를 발행 하는 곳. (이 인증서로 참여한것이 맞다는 것을 증명)
      • : 참가자의 신원(identity) 확인후, ECert를 발급. (public-key 및 private-key 생성)
      • : 신원확인은 RA(Registretion Authority)에게 위임할수있음.
    • TCA(Transaction CA)
      • : 참가자가 매번 ECert를 기반으로 transaction을 이르키면, 그 활동이 모니터링되니~ 사용하지 않음.
      • : 따라서, transaction 전용의 인증서 여러게를 발행 하는곳. (ECert에 근거하여, 충분한 TCert를 발급.)
      • : 기밀성 유지를 위해서, 매 transaction 마다~ 다른 인증서를 사용할수있음.
      • : 모든 transaction에 TCert를 기반으로 서명을 하게되고, 결과적으로 해당 참가자 신원까지 인증됨.
      • : 당연히, TCert <-> ECert 간의 상관관계는 추론못하도록 해야 함.
    • TLS CA
      • 참가자들간 '보안통신' 용도의 인증서를 발행하는 곳.
    • 
• 거래(transaction) 유형
• 
  
  • 거래(transaction) : 블록체인에 chaincode를 설치하고, chaincode 실행을 위해 호출하는 동작.
  • 유형
    • deploy transaction : chaincode 및 보증정책을 설치함.
    • invoke transaction :  chaincode의 특정 함수를 호출함.
• 거래(transaction) 처리과정
• 
  
  • 1) endording 단계 : ...
    • 
    • 
    • 보증정책 예시
      • ...
      • T1,T2,T3,T4,T5 으로 순서화된 block을 처리하는 과정에서, 동일한 Key에 R/W가 충돌하면~
      • 순서에 따라 invalid transaction은 반영되지 않고 나가리 된다.
      • (??? 나가리된 invalid transaction은 다시 도돌리 됨 ???) -> (물론이지, 다음 block에서 처리되지)
      • (아마도 다음 block에서도 순서가 밀여서... 계속 지연됨을 방지하기 위해! priority 관리가 되겠지?)
  • 2) ordering 단계 : transaction을 block에 순서화 합의하는 consensus.
    • SOLO : 1개의 node만으로 구성. (테스트 개발용)
    • Kafka : 2f+1개 이상의 node로 구성하여, f개의 node가 Crash Fault되어도, Tolerance을 가짐.
    • PBFT : 3f+1개 이상의 node로 구성하여, f개의 node가 Byzantine Fault되어도, Tolerance을 가짐.
    • Raft : ...
  • 3) committing 단계 : ..

-끝-