재시민

OrdererOrgs:
  - Name: OrdererOrg0
    Domain: ordererorg0
    Specs:
      - Hostname: orderer0
// orderer0 이름의 조직생성
// orderer0 이름의 orderer 노드 생성

PeerOrgs:
  - Name: Org0
    Domain: org0
    Template:
      Count: 2
    Users:
      Count: 1
// org0 이름의 조직생성
// peer0, peer1  생성
// User1 클라이언트 생성

  - Name: Org1
    Domain: org1
    Template:
      Count: 2
      Start: 2
    Users:
      Count: 1
//Org1 이름의 조직생성
//peer2, peer3 생성
//User1 클라이언트 생성

위의 crypto-config.yaml 파일을 생성 후 

crypto-config 파일 생성

tree 를 이용해 생성 확인

• 컨소시엄 : 비슷한 목적을 가진 조직들이 협정을 맺는 것
• 하이퍼레저 패브릭에서는 2개 시상의 조직들이 협정을 맺어 네트워크 구축
  
  1. 오더링 서비스 구축
     • 오더링 서비스 노드 구축 및 컨소시엄 참여 조직 정의
       • 컨소시엄 참여 조직 간 협의하에 오더링 서비스 노드 구축
       • 향후 추가될 서비스를 configuration block 을 통해 설정
  2. 채널생성
  3. 채널참여
     • 각 org 의 peer 들을 채널에 참여 시킴
  4. 체인코드/ 분산 어플리케이션 설치
  5. 새로운 조직/ 채널 추가
  6. 새로운 조직의 남은 구성요소 추가
  

1. Endorsment

• DApp 과 peer 간에 작동하는 정책
• 트랜잭션이 블록에 포함되려면 보증 정책에 지정된 peer의 허가를 받아야함
  • 보증이 되지 않을시 invalid tag 를 부여
• 비즈니스의 보안성, 신뢰성 등을 강화
• 예)
  • 보증 그룹의 모든 peer의 디지털 인증서를 획득해야함
  • 보증 그룹의 peer 중 1대의 peer의 디지털 인증서를 획득해야함

2. Organization

• 채널 당 하나씩 분산원장 존재
• 분산원장은 채널에 소속된 peer 간 데이터 공유를 위해 존재
• 위의 사진과 같이 채널 1 에 속한 peer2,3,5,6,8 d을 제외한 peer 들은 분산원장을 소유하지 않음
• 서로 다른 채널의 peer 간에는 정보를 공유할 수 없다
• 예를 들어 peer5 는 채널2의 분산원장 정보를 채널 1에 속한 peer 들에게 전달 불가
• 채널 마다 필요로 하는 각각의 DApp 을 선택할 수 있음

3. Channel

• peer 간의 통신은 채널을 이용해서만 가능
• 하이퍼레저는 일반 퍼블릭 블록체인과는 달리 데이터의 기밀을성을 채널을 통해 제공가능
• 채널 생성은 CSCC 를 이용하여 생성
• 채널 생성시 genesis block 생성
  • Genesis Block
    • 채널의 구성원, 채널 정책, peer 역할

4. Ledger (Distributed Ledger : 분산원장)

은행에서의 원장 : 현재 잔액, 통장개설 시점 부터 현재까지의 입/출금 기록

하이퍼레저의 원장 : 현재상태 : World State, 현재까지의 사용기록 : Block Chain

World State

• 분산원장의 현재 값
• 저장된 데이터는 합의 과정에 의해 블록체인에 포함되기 전까지 체인코드를 조회/변경/삭제 가능
• 합의에 의한 블록체인은 절대 변경 불가능
• 데이터의 기록/수정/읽기가 빈번하기에 데이터베이스로 구축
• LevelDB, CouchDB 중 하나를 사용해 데이터베이스 구축
• {key = 사용자 A, value = Audi} version =3, {key = 사용자 B, value {type = BMW, color = red} version 3
  • key value 데이터베이스 사용 예
  • version 은 world state 가 업데이트 될 때마다 증가
• peer 는 world state 의 version 과 트랜잭션을 비교하여 그 값이 같아야만 업데이트를 한다

Block Chain

• 현재까지의 모든 거래기록
• 데이터 요청이 거의 없고, append-only 방식의 저장 목적이기때문에 파일 시스템 형태로 저장
• 잘못된 데이터가 발견되면 world state 를 적절하게 수정하여 추가해야함
• 블록 헤더에는 현재 헤시값과 이전 헤시값이 들어있어 악의적인 변경이 불가함
• 블록 Header
  1. Header 1
     1. Block Number : 합의 과정에서 블록 생성시마다 1 증가
     2. Current block hash : 현재 해시값
     3. Previous block hash : 이전 해시값
  2. Data1
  3. MeataData1
• 트랜잭션 구조도
  1. Data1
     1. Header : 트랜잭션 version 정보, 체인코드 이름
     2. Signature : 생성자 인증서
     3. Proposal : 트랜잭션 입력값 → 체인코드 실행위함
     4. Response : 처리 결괏값을 Read/Write set 형태로 반환하는 필드
     5. Endorsement : 트랜잭션 보증해준 peer 정보
     6. Chaincode name : 체인코드 구분