재시민

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. 업데이트 완료 알림