조주임의 저녁

[9/4 프로젝트]

9/4

주제는 이더리움 테스트넷 오라클 기술 이용한 매크로 프로젝트 시행.

포셋사이트(https://faucet.rinkeby.io) 이더요청시 ‘로봇이 아닙니다’ 기능 때문에 진행불가.

ㅁUML(Unified Modeling Language) : 시스템을 모델로 표현해주는 대표적 모델링 언어

 ㅇUML 작성도구 : http://staruml.io/   , https://www.umlet.com/   (단순 PPT로 제작가능)

  ※개념설명 : https://gmlwjd9405.github.io/2018/07/04/class-diagram.html

ㅁ프로젝트 아이디어 재구성.

 1-1) 이더리움 실습용 사이트 제작(안).

 ㅇ한글화, 단계별 설명, 모듈화(기능마다 나눠진 카테고리 구성)

 ㅇ코딩 실습사이트 아님. 버튼식 기능실행으로 알아보는 이더리움 네트워크.

 ㅇ사이트 관련

  -CMD터미널 창 없이 웹사이트에서 구동 : 계좌생성, 채굴 등.

  -기능 :ㆍ블록현황(상태) 관련 : 이더스캔 기능. ㆍ암호화폐(보상) 관련 : 계정만들기, 지갑기능실행(송금).

  -기능 :ㆍ분산원장(저장) 관련 : 스마트컨트랙트 생성.

 1-2) 강사님피드백.

 ㅇ커뮤니티 게시판 사이트 그누보드 이용, 코인 관련 기능 추가.

  -기존 웹프레임워크(부트스트랩) 가입인증 하는 것만 떼와서, 모듈기준 진행가능한 웹프레임워크 찾는 것 우선.

  -제로보드. 네이버에서 관리하는 오픈소스 CMS. GNU보드. 코인판 사이트 게시판.

  -권한. 프레임워크 설정. 오픈소스 이용.

 ㅇ권한관련. 상대방 컴퓨터를 명령하기 위한 것.

  - 간단한 ‘데몬’ 만듬. (내가 명령을 날리고, 쟤가 명령을 받기 위해서는 쟤 컴퓨터에 데몬이 설치되어야 함).

  - 방식1) 서버에 올라온 명령을 읽는 폴링방식. // 방식2) 노티파이 이벤트 방식(모바일 푸쉬알림 같은 류).

 2) 이더리움 활용 리워드 적용 교육용 사이트 제작(안)

 ㅇ링크바이 이더리움 이용 고유토큰 제작 및 사용.

 ㅇ로컬 네트워크를 메타마스크로 연결하여 지갑으로 사용.

 ㅇ디앱은 그누보드, 제로보드 등 오픈 소스 이용한 교육용사이트이며 커뮤니티 및 이더스캔 기능 확보.

 ㅇ기타 논의 내용.

  -디앱(사이트)에 가입하면 자동으로 메타 마스크 연결함.

   ㆍ개인네트워크용 지갑으로 메타마스크를 이용하는 것.

  -ERC20 기준으로 토큰 생성.

   ㆍ제이슨 코인베이스 최초의 돈설정을 많이많이.

  -디앱상에서 토큰으로 연결.

   ㆍ현재 투표댑, 과일가게 만드는 댑. 등을 보면서 디앱구실 및 방법 찾는 중

  -회원 간 송금 : 수수료(링크바이의 가스)는 관리자가 제공.

ㅁ(강사님피셜)메타마스크는 매번 개인키로 접속을 한다.

 ㅇ매번 로그인 하지 않고, 개인키로 명령을 보내는 것과 같다.

  -여느 사이트 처럼 서버 DB에 접속하는 것이 아니다.

 ㅇ메타마스크는 크롬의 확장프로그램이며, 크롬은 보안storage 를 제공한다.

 ㅇ메타마스크 최초 접속시 인풋한 개인키를 보안스토리지에 저장한다.

 ㅇ메타마스크가 가지고 있는 노드들(목록)로 RPC를 보내면,

  -이 때의 노드들(목록)이 부트노드 설정시의 ‘이노드’ 기능과 비슷하다고 볼 수 있다.

  -이더리움 네트워크의 노드들로 부터 프록시를 제공받는다(RPC에 대응. 응답 프록시)

 ㅇ메타마스크는 커맨드라인 인터페이스로 터미널CMD과 같은 역할하는 webApp.

[9/3 프로젝트]

9/3

블록체인 클래스 인원 6명이 모여 브레인스토밍(8/30).

이를 통해 추출된 아이데이션의 문서화 및 문서통합.

주제는 이더리움 테스트넷 오라클 기술 이용한 매크로 프로젝트 시행.

1. 배경

 ㅁ암호화폐 계좌 간 이더(eth) 전송, 트랜잭션 발생 등 이더리움 테스트넷 이용중 테스트넷 이더가 필요(교육용).

2. 문제

 ㅁ이더가뭄현상 : 이더리움 테스트넷(rinkeby, ropsten 등) 이더 부족으로 진행 어려움.

 ㅁ연속신청불가 : 최초 신청 후 다음 신청 까지 최소 8시간(3TH) 최대 3일(18.75ETH) 대기시간 필요.

 ㅁ이용단계복잡 (최소 6단계)

  ㅇ공개키 복사 - 트위터 로그인 - 게시글 작성 - 해당 게시글 URL 복사 - 테스트넷 포셋 접속 - 게시글 URL 붙여넣기

3. 해결

 3-1. [N회 이더 신청] 기능 마련.

  ㅇ내용 : 포셋사이트(https://faucet.rinkeby.io)에 8N시간마다 게시글URL(사전준비)로 신청

  ㅇ필요기술 및 방안 마련 :

   - 스마트컨트랙트 입력 : “트위터게시글(URL)”을 “포셋사이트”에 8N시간마다 붙여넣기.

   - 이더리움 오라클 문제 해결을 위한 방안마련.

     참고1) https://verticalplatform.kr/archives/10000

     참고2) http://wiki.hash.kr/index.php/%EC%98%A4%EB%9D%BC%ED%81%B4_%EB%AC%B8%EC%A0%9C

 3-2. [트위터 로그인, 게시글 작성, N회 이더 신청] 셋트 기능 마련.

  ㅇ내용 : 1) (사전준비)트위터 아이디, 비밀번호, 테스트넷 공개키.

  ㅇ내용 : 2) 위 내용 입력하면, 트위터 글생성 및 포셋사이트에 8N시간마다 이더신청.

  ㅇ필요기술 및 방안 마련 :

   - 트위터 ‘자동’ 로그인 및 게시글 작성 API 구하거나 제작하며 솔리디티 스마트컨트랙트로 구현.

   - 해당 게시글의 URL 복사하여 “포셋사이트”에 8N시간마다 붙여넣기.

   - 위 “3-1. 의 필요기술 및 방안 마련” 내용 포함.

 ※ 스마트컨트랙트 회당/최대 N회 가능 한 지 여부(가스비, 논스).

   *확인된 내용에 따라 프로그램 실행시점 “부팅 시 실행”/ 주기 “매주 월요일”/ 등등 설정가능.

 4. 결과

 ㅁ충분한 테스트넷 이더 보급으로 시간지연 방지, 교육흐름 유지 등 원활한 교육 가능.

 ㅁ주기적인 반복신청과 이더신청단계를 크게 줄임으로써 시간절약 및  효과.

 ㅁ(환경변화, 파급에 따른 수익 가능성)

 ㅁ(효과보는 대상층, 수요자)

 5. 추가(안)

 ㅁ클래스 내 달란트 시스템 도입 : 교육 동기부여. 보상시스템 개선. ‘매크로로 받은’ 이더를 리워드로-…

 ㅁ(위 내용 토대로 유사한 기술구현 가능: 웹사이트 매크로)

#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)