조주임의 저녁

#10. 유져 관리(1)

ㅇ서명 & 블록 & 유져 간의 상호작용

ㅇ패브릭의 유저관리

1) MSP, CA

 -MSP : 패브릭 제공의 멤버쉽 관리. PKI (공개키-개인키) 사용.

 -CA : 네트워크 셋업시, 오더러 피어 어드민 유져 등에게 개인키 제공, 컴포넌트에 필요한 인증서를 만들어 크립토 컨피           그에 넣어서 , 각 노드들이 서로를 인식할 수 있게 해줌. CA 인증서와 개인키 발급을 도움.

2) Chaincode

 -체인코드 내부에서 PKI를 새로이 구현하여 또다른 유져관리가 가능해짐.

※ 서비스에 따른 유져관리 선택

ㅁ유저생성

 ㅇ비트코인과 이더리움은 회원가입의 개념이 없음. 오프라인상에서도 직접 개인키와 주소생성 가능.

 ㅇ패브릭은 특정기관(회사서버. CA)을 통해서 개인키와 인증서 발급을 받아야 함.(서비스 프로바이더는 회사).

#11. 유져 관리(2)

 ㅁ패브릭 네트워크에서 유져가 상호작용하는 3가지 방법.

 1. Delegated 방식 (위임하는 방식)

 ㅇBalance-Transfer 모델.

 ㅇ서버가 모든 유저의 키를 관리. (키를 모두 "위임")

 ㅇ회원 관리하는 서버가 유저 ID(token)과 인증서를 매칭하여 트랜잭션 생성.

 ㅇFabric CA를 통해 유저 생성(sign up).

 2. Decentralized 방식 (분산하는 방식)

 ㅇdApp 모델(탈중앙화 모델로 서버를 배제함.).

 ㅇ모바일에서 유저의 키를 관리. (키를 모두 "분산")

  -유저가 인터액션을 진행하고, 그 키를 모바일 클라이언트가 소지함.

 ㅇFabric CA를 통해 유저 생성(sign up).

 3. Chaincode Level user

 ㅇ서버는 어드민 키만 소유.

  -체인코드 레벨에서 PKI를 도입해서 이용. 체인코드 내에서 유저를 인식.

 ㅇ크립토연산의 중복

 ㅇFabric CA 불필요.

ㅁ자산관리

 ㅇUTXO와 Account 모델은 서로 상반됨- 

 ㅇUTXO 모델

  -비트코인.

  -자산우선 . 자산에 이름표를 부착함. 이름표(public key) - signature

  -fabtokken : utxo

  (1) 보안: 트랜잭션은 항상 고유한 UTXO와 연관돼 있어 높은 보안성 유지하며 리플레이 어택 방지가능.

  (2) 확장: 트랜잭션을 병렬 처리 가능하여 동시에 많은 트랜잭션을 처리가능.

  (3) 프라이버시: UTXO 시스템의 비상태(Stateless) 저장환경은 사용자들이 각 거래에 서로 다른 주소를 사용토록 함.

 ㅇ어카운트 모델

  -이더리움, 기존 시스템

  -명단우선 . 회원명단이 데이터베이스에 있고, 회원이름에 소유한 자산을 표시.

  (1) 단순: 계좌 모델의 전반적인 스마트 컨트랙트 기능과 DApp 실행가능.

  (2) 효율: 요청자의 계좌가 정확한지 파악하는 것으로만 유효성 검증 by TX.

  (3) 확장:  UTXO모델에선 UTXO갯수가 트랜잭션에 직접 영향 미치지만, 계좌 모델은 단지 단일 참조에만 영향받음.

#9. 패브릭 이벤트

ㅇ블록체인 상에서 발생한 사건들(블록생성, 스마트컨트랙트의 액션발생 시)을 외부로 전달가능함.

ㅇ다른 네트워크의 이벤트

  -이더리움 : 웹소켓 사용하여 이벤트를 주기적 전달 받거나, RPC콜로 이벤트 질문 가능.

  -비트코인 : 자신의 지갑주소로 돈이 들어왔을 때 알림 기능 등 서버에서 SDK 사용 등.

ㅁ이벤트. “ 블록이 새로 생겼다? ”

 ㅇ다양한 레벨의 이벤트 수신 가능 , SDK 이용 PEER로 부터 이벤트를 수신하며-

  -grpc를 통해서 가능한 것임. “해쉬넷grpc”

https://developer.ibm.com/kr/cloud/blockchain/blockchain-special-series/2018/11/11/hyperledger-fabric-architecture-5-%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98%EA%B3%BC-grpc/

  -(예) fabric-samples - balance transfer - artifacts - docker-compose.yaml

  ㆍ 두 개의 포트가 열려있음. ports : 7051:7051(오더러와 소통) , 7053:7053(외부 앱과의 소통)

  -(예) fabric-samples - balance transfer - artifacts - network-config.yaml

  ㆍ my channel - peers : 각 피어 별로 설정 가능 부분. EventSource 가 true 면,

  ㆍ SDK에서 해당 .yaml 을 갖고 사용할 때에 해당 피어는 이벤트를 수여 가능하다고 보고 만들기 가능.

  ㆍ 그럼 해당 peer의 eventURL 을 가지고 설정 하는 함. : 이것이 grpc를 통해서 이벤트 푸쉬 받는 것임.

 ㅇ이벤트 기능

  -이벤트 받을 때, 시작 블록 끝 블록 설정 혹은 블록 넘버지정으로 이벤트를 요청가능.

  ㆍ 놓친 이벤트도 ‘replay’ 기능으로 가져올 수 있다.
  ㆍ block from ~ to 가능(replay도 가능)

  -1.1 이후, ‘ Channel based event ’ 추가: SDK에서 해당 채널에 관련된 정보주면 채널 관련 이벤트만 SDK가 받아올 수 있음. 유져입장에서 유용한 기능이 추가된 것.

    (1.0 까지는 이벤트 허브로 이벤트 서비스를 제공해서- 채널 상관없이 블락을 정렬없이 받았음-)

 ㅇ엔터프라이즈 블록체인의 아키텍쳐(보통)

 ㅇ패브릭 이벤트의 종류

  -블록 이벤트: 블록 새로 생성 됐을 때, 이벤트 발생. SDK에서 생성된 채널.

  ㆍ Full block : 전체 내용을 가지고 옴.

  ㆍ Filtered block : event에 있는 payload를 안가지고 옴.

  -TX 이벤트: 유져가 트랜잭션 제출 했을 때, 해당 트랜잭션이 커밋 가능한 지에 대한 여부 확인.

  -체인코드 이벤트: 체인코드 내부에서 셋 이벤트 사용 가능.

  ㆍ chainCode 내 SetEvent(eventname, payload) : 이벤트 네임 찍고, 그것이 발생했을 때에 무엇을 할 것인지.

       ※이벤트 네임을 특수하게 짓든지, 식별자를 두어야 함.

#8. 패브릭 가십 프로토콜

ㅁ구성요소들 간 커뮤니케이션 : 가십 프로토콜.

 ㅇ피어 간 블록 송수신 관련.

  -헤더를 다 받고 헤싱으로-

  -인증서 기반으로 소통을 함(일반 퍼블릭 블록체인과 다른 점).

  -커미터 : 모든 피어. 블록체인(레져) 소유. execute, validate 하는 역할.

  -앵커 : 자신이 속한 organization의 네트워크 정보 소유 및 전달 역할.

  -리더 : 오더러로 부터 블록받아옴. 주는 것만 받는 게 아닌 필요할 때 자신이 땡겨올 수도 있음(시간설정).

           ※리더 선정 : 어드민의 지정 혹은 자기들끼리의 선택.

ㅁ피어(앵커)

 ㅇ초기 블록체인 네트워크 설정시 오더러, 피어 간 위치 확인해야 함.

 ㅇ(cli 이용해서) 채널을 만들 때, 오더러 옵션 부여 가능하므로 이때 특정 피어 존재를 알리게 됨.

 ㅇ앵커피어 트랜잭션을 통해 네트워크에 알리기 가능.

       ※크립토 관련 재료 제작 시, 채널관련 트랜잭션, 앵커피어 트랜잭션(이 그룹의 앵커피어가 누군지 알리는) 등 제작.

ㅁ리더피어

 ㅇ어드민이 정의 : 환경변수 or core.yaml.을 통해 정의

          예) docker-compose-node3.yaml - org2peer0 - enviroment

          예) - CORE_PEER_GOSSIP_USELEADERLECTION : false

          예) - CORE_PEER_GOSSIP_ORGLEADER : true

 ㅇ다이나믹으로 선언 :

  -한 명의 리더 , 나머지는 팔로워. 피어들은 항상 서로에게 heart beats를 날리며

  -리더의 heart beats가 안오면 리더 선출이 시작되며 ID가 높은 peer가 리더가 됨.

ㅁ오더러 연결

 ㅇconfig 통해서 연결 : genesis.block

  -초기 네트워크 셋업시 - 크립토 관련 모듈 제작 - conifg TX gen으로 config TX 파일 소모해

  -관련 제네시스 블록 생성.

  -오더러는 처음 시스템 채널에 자신의 제네시스 블록을 갖고 있게 됨.

  - (예) ‘Raft’의 환경설정을 보면 (configtx-original.yaml 내의 SampleMultiNodetcdRaft)

  - host, port, ClientTLSCert 등등 정보가 들어가 있음.

  - configtxGen 파일이 위의 정보를 소모해서 genesis.block을 생성.

  - 그래서 제네시스 블록 안에 오더러들의 인증서들이 입력되어 있음.

#7. 패브릭 채널

ㅁ패브릭이 프라이빗 블록체인으로서 가장 큰 특징 : 채널. 특정 노드들 간의 소통.

ㅁ채널.

 ㅇ네트워크 멤버들 간 서브넷(하위 네트워크).

  -특정멤버들(피어, 유져, org) 끼리만 블록체인(렛져)과 스마트컨트랙트(체인코드) 공유 가능.

  ㆍA, B 만의 채널 형성 가능.

  -다른 채널 데이터에 접근 불가.

  ㆍA피어가 ‘사과’, ‘포도’채널에 둘 다 가입돼 있으면, 둘 다 접근 가능.

  ㆍ채널링(채널설정)할 때에 각 과들을 관리하는 부장(피어)을 멀티채널 가입하도록 가능.

 ㅇMSP, identity에 의해 식별가능.

 ㅇ채널 별 블록체인 따로 존재.

  -채널 1개에 레져 1개임. 그래서 레져가 2개라면 채널도 2개임.(스마트컨트랙트는 설치를 해야 소유)

  -채널 제작 시, genesis block에 채널정보가 있는 트랜잭션으로 시작함. (채널의 생성과 시작은 genesis block)

  ㆍ각 피어들이 블락정보를 가지고 채널에 join하는 방식.

  -채널에 피어들이 블록 공유시.

  ㆍ리더피어 : 오더러와 연결해서 블록을 가져오는 기능(타 피어들보다 최우선, 가장 먼저 수령)

    · 채널마다 리더 피어가 있으며 이들이 채널 내 피어들에게 블록배분, 그 후 각자 validating 하는 구조.

  ㆍ앵커링피어 : 네트워크 관련 정보를 공유.

    · 서로 다른 채널에 있는 앵커링 피어들은 비즈니스 로직과는 무관하게 네트워크에 있는 피어를 찾아줌.

 ㅇ동일채널의 체인코드들은 체인코드의 정보(이름, 번호)를 알고 있을 경우, 상호작용 가능. 읽/쓰기 호출가능.

 ㅇL1-S1과 L2-S1은 서로 읽을 수는 있지만 쓰기 못하고, 값을 변화 시킬 수 없음.

  - 피어는 모든 체인코드를 들고 있기에 읽을수 있지만, P2는 L2의 S1이나 S2를 읽기 불가.

  - L2-S1이 L1의 내용을 불러 와서 작성불가.

ㅁ오더링 서비스와 피어를 통한 블록의 이동

 ㅇ색으로 채널의 구분하며 피어들이 가진 블록들이 쌓이는 과정.

 ㅇ피어가 레져를 들고 있고, 레져는 채널 별로 관리됨.

 ㅇ다른 채널의 체인코드는 호출불가. 가입되어 있으면 읽기만 가능.

#5. 패브릭 아이덴티티(1)

ㅁ아이덴티티(Identity)

ㅇPKI 인증서 기반의 시스템

-패브릭 구성요소인 오더러 피어 유져는 각각의 공개키, 개인키, 인증서가 있기 때문에

-유져는 개인키로 서명.

-피어를 엔도스 해서 트랜잭션을 검증한 후 개인키로 서명.

-오더러 또한 피어에게 배포할 블록을 생성한 후 개인키로 서명.

ㅇPKI

-공개키 암호화

ㆍ개인키+공개키. 둘 중 하나의 키로 암호화한 데이터는 나머지 키로 복호화 가능.

ㆍ개인키는 만든 이 소유. 절대 비밀 개인키는 데이터 서명에 사용.

ㆍ공개키는 타인에게 알려주는 용도.

ㅇ전자서명(Signiture)

-데이터가 위/변조 되지 않았음을 PKI 시스템에서 알려주기 위한 시스템.

ㆍ(1) 원본의 digest(원본해쉬)를 만듬.

ㆍ(2) 개인키로 digest를 서명 후 원본에 붙임.

ㆍ(3) 공개키로 해당 digest를 복호화 함.

ㆍ(4) 원본을 통해서 만든 digest와 비교하여 검증.

ㆍ피어와 오더러, 블록 안에 각자의 전자서명이 들어있음.

ㆍmsg digest (메시지 다이제스트 , 원본의 해쉬값) -> 개인키로 암호화 -> 암호화된 digest

ㅇ인증서(X.509)

-PKI에서 사용하는 인증서 포맷이 X.509. 공개키를 기본적으로 포함하는 것이 특징.

-인증서에는 발행자, ‘나’, 도메인, root ca에 대한 정보(root ca로 부터 받은 게 아닌 경우).

-Fabric 인증서

ㆍ인증서 위치 : OrdererOganization 의 하위 폴더에 걸맞는 인증정보들이 들어가 있음.

ㆍcryptogen을 사용하여 yaml파일을 소모해서 크립토 관련 메테리얼 만들면 crypto-config 폴더에 들어감.

ㆍ패브릭 샘플스 - 베이직 네트워크 - crypto config - OrdererOganization - example.com - ca - ca.example.com-cert.pem 의 전체내용을 복사하여 https://www.sslshopper.com/certificate-decoder.html 에 올리면 certificate 정보를 볼 수 있음.

ㆍkeystore- 개인키들. signcerts- 인증서들.

#6. 패브릭 아이덴티티(2)

ㅁMSP(Membership Service Provider)

ㅇ패브릭에서의 권한

-ex) 일반적인 웹커뮤니티 까페에서의 유저 레벨에 따른 게시판 권한을 설정해 주는 기능.

-패브릭에서 노드/유저/채널 등등 서로간의 인증, 권한 관리를 해주는 기본적 개념(서비스)

-노드(피어, 오더러, 유져)는 msp 폴더 내 인증서를 가지고 함.

-채널/네트워크는 크립토젠 등과 같은 여러 가지 방법을 통한 멤버쉽 관리.

-' docker-compoese.yaml ’ 파일 내 노드들의 상태, 어떤 폴더를 가지고 가는 지 있음.

-노드들 서로 간의 인증과 권한 등을 제공해 줌.

-실제로 노드들은 msp폴더를 직접 가지고 있어야함.

-피어들이 도커로 띄어질 때 프로세스로 띄어질 때 msp 폴더를 들고 (도커 안으로) 들어가야 함.(도커 안으로)

-예) (밸런스 트랜스퍼 예제 중) artifacts - docker-compoese.yaml - “volumes: ~ ” 내용이 가리키는 폴더가

-“ : ” 의 우측 주소(도커) 안으로 들어가는 것임. [ volumes: -(msp위치) : (도커위치) ]

- msp 폴더를 peer가 들고 있게 되는 것임.

※ 제이슨포맷 보기 좋게 바꿔주는 사이트 : https://jsonformatter.org/

#4. 패브릭 네트워크 세팅 가이드(이론)

ㅁ블록체인 구성.

ㅁ패브릭 구성요소 관련 설명

ㅇ권한 관련. 인증서 기반(X.509를 이용해서 서로의 권한을 확인).

-각 구성요소들을 해당하는 CA에서 발급해주고 발급, 재발급, 갱신, 폐기 등으로 관리함(Fabric CA 컴포넌트)

-멤버십 서비스 프로바이더(MSP) 기능 등이 제공 가능 해짐.

ㅇ채널 관련.

-동일채널 내 피어들은 서로 스마트컨트랙트, 블록체인 데이터 공유가능(해당 채널 내에 있는)

-피어들은 채널 가입 가능.

-P1이 1채널과 2채널에 동시에 가입되어 있더라도 타 채널 내용을 공유 불가능.

ㅁ블록체인 네트워크(순서대로 작업)

1) 크립토 관련 ( Fabric-ca, cryptogen )

ㅇ크립토 관련 인증서, 프라이빗 키 등을 생성해 주는 실행파일을 패브릭에서 제공하고 있음.

ㅇ그것을 통해 패브릭 네트워크 구성 기반 마련.

2) Orderer, Peer 생성

3) Kafka, ZooKeeper 생성

ㅇ기능: 서로의 연결, 선과 실선 (블록을 오더러가 피어에게 전달, 오더링 서비스에서 데이터 공유 등)

4) 채널 생성 및 피어 조인, App, CA 배치.

ㅇ오더러 셋업, 피어 조인 기능은 크립토 관련 기반하여 가능(CA, X.509)

#2. 패브릭 Write& Read

ㅁ패브릭의 사용방식

ㅇKVS. 키밸류스토어 방식. 키-값 한쌍으로- 키를 기반해서 값을 저장가능.

ㅇLevelDB(속도), CouchDB(복잡성) 사용

ㅇChaincode : 한 블록 내에서 하나의 키 값을 여러 번 읽고 수정 불가

ㅁRead Set, Write Set

ㅇ한 블락에서 한번 수정 가능. ( 한 블록 내에서 ) 한번 Write 한 키에 대해서는 Read를 하면 실패한다.

ㅇpeer가 시뮬레이팅 하는데 블록생성 않기 때문에 블록을 오더러 에게 받기 전에는 잘못된 값을 불러온다.

ㅇ일반적인 상황에서는 굉장히 불편하게 만드는 제약

ㅁ그래서 패브릭이 선택한 방법은 Fabric - high through put network.

ㅇ태그를 사용하여 여러 번의 읽고 수정해도 값이 제대로 나올 수 있도록 하는 기능

ㅇUTXO를 사용하기도 함

#3. 패브릭 스터디 가이드

“어디서 부터 시작해야 하나-”

1. 패브릭 read the doc. ( https://hyperledger-fabric.readthedocs.io/en/release-1.4/whatis.html )

1) key concepts

2) Architecture Reference

3) Writing Your First Application

4) Building Your First Network (BYFN) : 로그 확인

-운영자 과정(operation Guides)과 개발자 과정이 있으니 필요따라-

2. 패브릭 samples

ㅇmarbles, balance-transfer, high-throughput, unit test… 등

ㅇ퍼스트 네트워크, 밸런스 트랜스퍼 예제 순으로 진행

ㅇBalance Transfer : 패브릭 SDK사용하여 체인코드 접근하는 예제

ㅇhigh-throughput : 패브릭에서의 고성능 체인코드 작성 위한 기능

3. 하이퍼렛져 프로젝트

ㅇ패브릭이 가장 많이 사용되긴 하지만.

ㅇ버로우(이더리움 기반. 쿼럼), 그리드(웹어셈블리), 인디(DID), 이로하(활발..), 캘리퍼(TPS 측정), 첼로(배포)

ㅇ패브릭 블락 익스플로어(block explorer) : 이더스캔 같은 기능 하는 듯.

ㅇ컴포져(composer) : 패브릭보다 간소화한 블록체인 툴. 패브릭 기반의 완전히 다른 아키텍쳐.

- 컴포져(composer) : 온라인의 플레이 그라운드 라는 풀 제공중. 바나나파일의 기능 사용하여 프로젝트 가능.

ㅇ툴. Kubernetes : IBM에서 만들고 있는. 구글의 네트워크 관리(배포).

#1. 패브릭 구조 (https://youtu.be/d9EmSrNFDY8)

ㅁ기존 블록체인들과의 차이.

ㅇ패브릭은 구성요소들이 각 역할이 분배됨.(블록생성자!=SC처리노드): 오더러(블록생성), 피어(시뮬레이팅, 저장).

cf)기존 비트와 이더는 노드 하나가 모든 것을 처리.(블록생성자=SC처리노드): 마이닝. 지갑. 월드스테이트 등.

ㅇ패브릭은 인증서 기반. 중간관리자 존재(FCA_Fabric Certificate Authority).

cf)비트와 이더는 개인키 기반

ㅇ패브릭은 하나의 키 값을 한 블록 내에서 여러 번 읽고 수정 불가.

ㅁ구성요소

1) Peer(피어)

- Ledger(블록체인, 블록저장). World State(in Ledger, 최신버전의 데이터)

- Simulating.(트랜잭션을 연산)

2) Orderer(오더러)

- 블록생성(배포용도), 유저로 부터 받은 거래를 검사하지 않고 바로 블록생성.

- Ordering Service(오더러들이 모인 곳)이 생성된 블록을 피어들에게 배포해줌.

3) App(유저)

- 거래생성 및 거래 확인요청(‘제안’의 형태로 피어에게 전송)

- 확인, 검사받은 거래를 오더러에게 전송.

- Check Endorsement Polices : 확인, 검사하는 방식에 대한 규정.

ㅇ합의

- BFT 방식, 투표 (3명중 2명만 확인하면 통과)

ㅇLedger

- 구성 : 블록체인, World state

- 오직 피어 만이 활용가능한 Ledger(블록)를 갖고 있음.

- 오더러 또한 Ledger(블록)을 갖고 있기는 하지만 활용하지 못하고, 오로지 배포만 가능함.