재시민

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 를 이용해 생성 확인

1. 트랜잭션 생성
   • 사용자는 DApp 을 통해 다른 사용자게에 송금하는 트랜잭션을 생성 요청
   • DApp 은 트랜잭션 생성 후 Endorsing peer 에게 전송
2. 트랜잭션 보증
   • Endorsing Peer 의 할 일
     1. 체인 코드 시뮬 값으로 나온 결괏값 Read/Write set 이 올바른지 확인
     2. 동일한 트랜잭션이 발생한지 확인 (리플레이 공격방지)
        • 트랜잭션 version 확인
     3. 사용자의 MSP가 유효한지 확인
     4. 사용자가 분산원장 업데이트 권한을 가지고 있는지 확인 (channel MSP 확인)
     5. 이상이 없으면 Read/Write set , 디지털 인증서를 DApp 에 전송
3. 시뮬레이션 결괏값/디지털 인증서 확인
   • DApp 은 자신의 예상 값과 시뮬 결괏값을 확인
   • 디지털 인증서 있는지 확인
4. 최신블록 생성
   • DApp 디지털 인증서, Read/Write set 이 담긴 트랜잭션을 orderer에게 전송
   • Orderer : 정렬에 필요한 Timestamp field 등을 확인 후 블록을 정렬하여 생성
5. 최신블록 검증
   • Orderer : 최신 블록을 Committing peer 로 전달
   • Committing peer : 블록 검증 위해 VSCC 를 실행하여 작업 수행
     1. 보증정책확인 : Endorsing peer 디지털 인증서 존재여부 확인
     2. Read/Write set 확인 : 결괏값 확인 , 버전 일치 확인
     3. 위 작업후 유/무효 태그를 생성
6. 최신블록 업데이트
   • 유효 태그를 가진 블록만이 peer 가 World state 에 업데이트

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

1. Gossip

• peer 들은 스스로 끊임 없이 브로드캐스트 메시지를 생성하여 peer 들의 상태를 확인
• 상태를 업데이트 하지 못한 peer 는 무작위로 보내지는 분산원장을 받을 수 없음
• 각 조직의 peer 들은 orderer 로부터 분산원장을 업데이트 할 수 있는데 한 꺼번에 많이 오면 과부하
  • Leader peer 를 무작위로 선출하여 대표로 orderer와 통신

Leader peer

• peer 들에게 주기적으로 heartbeat 메시지를 보내어 살아있는지 확인
• heartbeat 메시지가 수신되지 않으면 죽은것으로 간주후 채널에서 제

2. Identity

PKI (public key infrastructure)

• peer, orderer, client 가 서로 신원을 확인할 수 있게함
• peer, orderer, client 의 디지털 인증서를 cryptogen, Fabric-CA 를 이용하여 생성가능
• 디지털 인증서를 안전하게 제공/생성/관리하는 기술
• CA (Certificate Authority) 에서 관리
• 디지털인증서, 공개키/비밀키, CA, Certificate Revocation List

디지털인증서

• 국제표준 X.509 인증서 사용
• 인증서 양식
  1. Certificate Format Version : 인증서 버전
  2. Certificate Serial Number : 인증서 시리얼 구분번호
  3. Signature Algorithm Identifier for CA : CA가 사인할 때 사용하는 알고리즘
  4. Issuer Name : CA 정보
  5. Validity Period : 인증서 유효기간의 시작일과 만료일
  6. Subject Name : 인증서 사용자 정보
  7. Subject Public Key Information : 인증서 사용자 공개키
  8. Extension : 인증서의 추가적인 정보와 정책
  9. CA Signature : CA의 디지털 인증서

공개키와 비밀키

• 신원인증과 데이터 암호화
• 인증방식
  1. 사용자A의 비밀키를 이요해 데이터 암호화
  2. 사용자 A의 공개키 획득
  3. 암호화된 파일 전송
  4. 사용자A의 공개키를 이용해 데이터를 복호화
• 데이터 암호화방식
  1. 사용자 A의 공개키 획득
  2. 사용자A의 공개키를 이요해 데이터 암호화
  3. 암호화된 파일 전송
  4. 사용자A의 비밀키를 이용해 데이터 복호화

CA

• 공개키와 비밀키만으로는 보안이 취약하여 나온 인증 노드
• 사용자A의 공개키를 CA 로 부터 받아 사용자 인증

CRL

• 폐기된 인증서에 대한 목록

3. MSP(Mermbership Service Provider)

• Identity 기술을 바탕으로 만든 멤버쉽 관리 기술
• 각 organization 에 맞게 조직을 세분화 할 수 있음

Local MSP

• 하이퍼레저 패브릭 네트워크 노드에 역할을 부여함
• 어떤 노드가 peer, orderer, client 인지 정의
• 노드별 권한 정의
• 모든 네트워크 노드는 하나 이상의 local MSP 정의되어야 함

Channel MSP

• 채널 구성원들에 대한 멤버십 정의와 권한을 부여

• 구성원들은 각자의 local MSP 를 통해 하나의 Channel MSP 를 생성

  • org1, org2 은 각자의 local MSP 를 이용하여 서로 데이터를 공유할 수 있는 channel MSP 를 만듦

  MSP 구조

  1. Root CA : 하이퍼레저 패브릭의 RCA (Root CA) 디지털 인증서
  2. Intermediate CA : 하이퍼레저 패브릭의ICA 디지털 인증서
     1. CA 는 여러개의 CA로 구성될 수 있고 각각의 세분화된 조직마다 ICA를 하나씩 설치하여MSP 관리
  3. Organizational Units(OU) : ICA 를 사용하지 않고 하나의 CA를 이요해서 조직을 세분화하고 싶을 때 사용
  4. Administrators : 조직 운영자의 인증서
  5. Revoked Certificate : 폐기된 인증서
  6. Node Identity : 개인키로 암호화한 인증서를 나타냄
  7. Keystore : 개인키를 나타냄
  8. TLS Root CA : 보안강화를 위해 TLS 기능을 사용할때 Root CA 로부터 발급받은 TLS 인증서를 나타냄
  9. TLS Intermidiate CA : ICA 로 부터 발급받은 TLS 인증서 나타냄

4. Orderer

• 블록을 생성하여 peer 에게 전달

과정

1. 트랜잭션 제출

   • DApp 이 Endorsing peer 에게 트랜잭션을 제출
   • Endorsing peer 는 전달받은 proposal 값을 바탕으로 체인코드를 시뮬레이션
   • 올바른 값이 나오면 Identity 를 이용해 서명한 디지털 인증서와 read/write set을 함께 DApp에 전송
   • 해당 트랜잭션의 체인코드가 실행되는 과정

2. 블록 패키징

   • 제출한 트랜잭션을 orderer가 수집하여 순서대로 정렬한 후 최신 블록을 생성하는 과정
   • Endorsing peer 에게 받은 인증서와 set를 DApp 은 orderer 에게 전달
   • 트랜잭션을 전달받은 orderer은 순서대로 정렬한 후 최신 블록 생성

3. 검증

   • 생성한 블록을 각 조직의 peer 들에게 전달하고 peer 는 해당 블록이 올바르게 생성됐는지 검증
   1. orderer 에게 블록을 전달받은 Leader peer 는 peer 들에게 블록을 전달
   2. peer 들은 블록에 포함된 결괏값이 정상적인지, 각각의 트랜잭션 결괏값이 정책에 부합하는지 검증 작업 거침
   3. 로컬저장소에 블록체인에 최신 블록을 추가하고 World state 데이터 베이스를 업데이트

카프카 클러스터

1. 파티션에 topic 단위의 메시지를 저장
2. 메시지는 여러 파티션에 복사되어 저장
   • 데이터가 손실이 되어도 복구 가능
3. 일정한 메시지가 모이면 consumer 에게 전달

• Producer - orderer
• Consumer - Peer
• Topic - 분산원장