재시민

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

1. Peer
   1. 분산원장과 스마트컨트랙트를 관리
   2. 참여자는 peer 에 설치된 스마트 컨트랙트(Chain Code)를 호출하여 분산원장에 저장된 정보에 접근 가능
   3. 최소 한개 이상의 체인코드 호스팅 권장
   4. Peer 네트워크 동작방법
      1. A는 Peer1 을 통해 체인코드 1을 통하여 분산원장1을 기록, 읽을 수 있다.
      2. 기록을 하게 된다면 orderer 노더와 함께 합의 과정을 진행 후 분산원장 1을 업데이트
      3. B 도 A 와 같이 Peer 2을 통해 분산원장1, 2를 기록, 읽을 수 있다.

2. ChainCode
   1. 위/변조가 불가능한 분산원장에 기록하거나 읽기 위해서 필요하다
   2. DApp 과 함께 개발되어 사용된다.

• 송금트랜잭션 예시

2.1 하이버레저 패브릭 : 시스템 체인코드

• 하이버레저 패브릭의 시스템레벨에서 수행됨 ( 기존은 어플리케이션 레벨 )

시스템 체인코드

• QSCC
  • CLI 명령어로 실행
  • 블록체인의 저장된 데이터를 읽어올 때 사용
  • 블록번호, 해시값, 트랜잭션 ID 등을 알아냄
• ESCC
  • Endorsing Peer(트랜잭션 보증을 담당)
    • 트랜잭션 실행 결과값을 비교해 보고 결과값이 올바르면 자신의 인증서를 통해 결과값 보증
  • 보증 정책을 담당
• VSCC
  • Committing Peer(블록에 대한 검증을 담당)
  • 블록을 검증할 때 사용
  • Endorsing Peer 의 디지털 인증서의 존재여부를 확인하는 작업을 수행
• CSCC
  • CLI 명령어로 실행
  • 채널 설정 시 사용
  • 블록에 대한 정보를 읽거나 수정, peer 를 채널에 참여시키는 기능
  • 결과값을 반환할 필요가 없음
• LSCC
  • CLI 명령어로 실행
  • 체인코드 설치부터 인스턴스화까지 일련의 과정을 수행

3. DApp

• 분산 애플리케이션
  • 비즈니스 모델에 맞게 개발
  • 분산 환경에서 비즈니스 거래를 편리하게 해주는 기능
• 체인코드를 통한 읽기 과정(5)
  1. 트랜잭션 생성 요청
  2. PEER 와 연결
  3. 체인코드 실행 요청(QUERY)
  4. 체인코드 실행
  5. 결괏값 반환
• 체인코드를 통한 쓰기 과정(9)
  1. 트랜잭션 생성 요청
  2. PEER 와 연결
  3. 체인코드 실행 요청
  4. 체인코드 실행
  5. 보증 허가된 트랜잭션 반환
  6. 보증 허가된 트랜잭션 전달(ORDERER 에게)
  7. 보증 허가된 트랜잭션을 최신 블록에 포함(트랜잭션 정렬)
     1. orderer 는 정렬만! 확인은 안함
  8. 최신블록 전달 (네트워크 내의 PEER 들에게)
  9. 업데이트 완료 알림