재시민

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 - 분산원장

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 : 체인코드 구분