📌 HyerLedger 란?

오픈소스

퍼비션드 블록체인?
인터넷뱅킹처럼 인증을 거쳐

디자인 목적
기업환경에서 사용하기 위한 블록체인 기술 개발

📌 HyerLedger Fabric 아키텍처

📝 Client Application

sdk를 통해 transaction 처리된다.

모든 클라이언트는 패브릭 SDK를 사용하여

• 채널을 통해 하나 이상의 피어에 접속
• 채널을 통해 하나 이상의 Orderer에 접속
• 피어로 부터 이벤트 수신
• Local MSP 기능 제공
• 다양한 개발 언어 지원

📝 Peer

구성

• Endorser
• Committer
• Ledger
• Chaincode
• Events

역할

원장 관리 컴포넌트
– 한 개 이상의 채널에 연결됨
– 각 채널에 대해서 한 개 이상의 원장을 관리
– 체인코드는 도커 컨테이너로 분리되어 인스턴스화 됨
– 체인코드는 채널을 통해 공유 됨
– Local MSP (Membership Services Provider) 는 암호화 방식을 제공
– 클라이언트 어플리케이션에 이벤트 발생

📝 Fabric Ledger

• 블록체인과 worldstate를 포함하고 있는 패브릭 원장은 각 피어에 의해 유지 됨
• 피어가 조인하는 각 채널에 대해 별도의 원장이 생성/관리 됨
• 트랜잭션의 Read/Write sets 는 블록 체인에 기록 됨
• 채널의 구성 정보도 블록 체인에 기록 됨 • worldstate는 LevelDB (기본값) 또는 CouchDB 선택 가능함 – LevelDB는 key/value 스토어 – CouchDB는 도큐먼트 스토어
• 스마트 컨트랙트에서 worldstate에 데이터를 입력 함

📝 Ordering Service

트랜잭션들을 블록으로 패키징하여 피어에게 전달하는 역할을 담당함. 채널을 통해 Ordering service와 통신 함.

📝 Channel

채널은 서로 다른 원장간 프라이버시를 제공 함
– 원장은 채널의 범위로 한정 됨
• 피어의 전체 네트워크에서 채널을 공유할 수 있음
• 특정한 참여자 그룹 별로 채널 권한을 부여할 수 있음
– 체인코드는 피어에 설치되며 worldstate에접속할 수있음
– 체인코드 특정 피어에서 인스턴스화 됨
– 피어는 멀티 채널에 참여 할수있음
– 퍼포먼스와 확장성을 고려하여 동시에 실행 가능함

📝 Membership Service Provider

api명세 같은 것. 인증하기 위한 기능 요약

• 다양한 인증 아키텍처(Credential architectures)를 지원하는 플러그 형 인터페이스
• 기본 구현체는 Fabric-CA
• 애플리케이션, 사용자, 피어, 오더러의 인증을 관리
• 제공되는 기능
– 자격 증명(Credential verification)을 포함한 사용자 인증(User authentication)
– 서명 생성 및 검증
– Access control (in system, channel, chaincode)

📝 Fabric-CA

Membership Service 의 인증을 위한 기능 요약 구현한 것

• 패브릭 네트워크에서 Ecerts를 발행하는 CertificateAuthority
• HA를 위한 클러스터링 지원
• 사용자 인증을 위한 LDAP지원
• 보안을 위한 HSM 지원
• Intermediate CA를 위한 설정 가능

📌 애플리케이션과 원장의 호출 관계

cliend application : 블록체인 트랜잭션 발행함
SDK를 통해 스마트컨트랙트 호출

cliend application -> sdk -> smart contract 로직 수행하다 로직중 블록체인의 원장을 불러와야할 경우 get(key). 사용할 때는 put(key-value). 삭제는 delete(실제 삭제가 아닌 삭제 마킹). hash table

스마트컨트렉트 사용에 대한 이력은 Blockchain에 남긴다.

트랜잭션을 비동기로 처리할 수 밖에 없다.

📌 3-Tear

👉 블록체인은 Data Layer에 해당한다.

📌 Hyperledger Fabric 컨센서스

📌 Transaction Step

1. Propose transaction

• 응용 프로그램 거래 제안
  보증 정책 :
  • "E0, E1 및 E2는 서명해야합니다"
  • (P3, P4는 정책의 일부가 아님)

  클라이언트 응용 프로그램은 스마트 계약 A에 대한 거래 제안서를 제출합니다.
  필수 피어 {E0, E1, E2}를 대상으로해야합니다.

2. Execute proposal

• 보증인 실행 제안서 E0, E1 및 E2는 각각 제안 된 거래를 실행합니다.
  이러한 실행 중 어느 것도 원장을 업데이트하지 않습니다
  각 실행은 RW 세트라고하는 읽기 및 쓰기 데이터 세트를 캡처하여 이제 패브릭으로 흐릅니다.
  거래 서명 및 암호화 가능

3. Proposal Response

• 응용 프로그램이 응답을받습니다
  RW 세트는 비동기 적으로 애플리케이션으로 리턴됩니다.
  RW 세트는 각 보증인이 서명하며 각 레코드 버전 번호도 포함합니다.
  (이 정보는 합의 과정에서 훨씬 나중에 확인 될 것입니다)

4. Order Transaction

• 주문 응답 제출
  애플리케이션은 주문할 트랜잭션으로 응답을 제출합니다.
  다른 애플리케이션에서 제출 한 트랜잭션과 동시에 패브릭에서 주문이 발생합니다.

5. Deliver Transaction

• Orderer는 동료 커밋에 제공
  주문 서비스는 커밋 된 피어에게 분배하기 위해 제안 된 블록으로 트랜잭션을 수집합니다.
  피어는 계층 구조의 다른 피어에게 제공 할 수 있습니다 (표시되지 않음).
  사용 가능한 다른 순서 알고리즘 :
  • SOLO (Single node, development)
  • Kafka (Crash fault tolerance)

6. Validate Transaction

• 커밋하는 동료는 거래를 확인합니다.
  모든 커밋 피어는 보증 정책에 대해 유효성을 검사합니다.
  또한 RW 세트가 여전히 현재 세계 상태에 유효한지 확인합니다
  검증 된 거래는 세계 상태에 적용되며 원장에 유지됩니다.
  유효하지 않은 거래도 원장에 유지되지만 세계 상태는 업데이트하지 않습니다

7. Notify Transaction

• 커밋하는 동료에게 응용 프로그램 알림
  트랜잭션이 성공 또는 실패 할 때와 블록이 원장에 추가 될 때 알림을 받도록 애플리케이션을 등록 할 수 있습니다.
  연결된 각 피어가 응용 프로그램에 알림을 보냅니다.