7) Peers

원서 : https://hyperledger-fabric.readthedocs.io/en/release-1.4/peers/peers.html

• (What's) Peers
  • blockchain-network는 'peer-node의 집합'(peers)이 주가되어 이루어 집니다. 그래서 (ledger 와 chaincode를 호스팅 하는) peers가 blockchain-network의 기초 이라고 할 수 있습니다. 왜냐면, chaincode으로 생성되는 모든 transaction이 ledger에 불변기록 되고~ peer의 ledger 와 chaincode가 blockchain-network의 '프로세스 와 정보데이터'를 캡슐화 하는데 사용된다는 점을 생각하면 말이죠~ㅎ 

  • 

    blockchain-network은 ledger 와 chaincode 의 사본을 공유하는 peer로 이루어져있습니다. P123은 각자 동일한S1으로 분산L1를 자체관리 합니다.

  • peers는 생성, 시작, 중지, 재설정, 제거 등이 될 수 있습니다. administrators and applications 과 상호작용 할 수 있는 API가 제공됩니다.
• Ledgers and Chaincode
  • peer는 기본적으로 ledger 와 chaincode의 인스턴스를 호스팅합니다. 각각의 peer에는 호스팅 되는 다양한 ledger 및 chaincode가 있을 수 있습니다. fabric에서는 싱글포인트 실패를 피하기 위해~ 일부러 의도를 하는데, 암튼 나중에 다시 분산 및 탈중앙을 공부해 봐요.
  • peer가 처음 생성될때에는 ledger 와 chaincode 다 없는데~ 추후에 이것들이 어떻게 인스톨 되는지? 알아 보겠습니다.
• Multiple Ledgers
  
  • peer는 복수개의 ledger를 가질 수 있는데, 이건 시스템을 좀더 유연하게 디자인 할 수 있습니다. 각 ledger는 0개 이상의 각 chaincode 으로 접근가능합니다. 물론 ledger에 접근하는 chaincode 를 0개로 해서... 해당 ledger 호스팅만 할 수 는 있는데~ 보통 이렇지는 않겠죠?ㅎ 또 peer는 자체적으로 특별한 system-chaincode 는 가지고있기는 한데, 이것도 나중에 알아보죠.
• Multiple Chaincodes
  
  • 뭐, peer의 ledger 및 chaincode 갯수에 특별한 제약은 없습니다. 그냥 가지고 싶은데로 가지면 됩니다. 이런점은 channel의 개념에 아주 중요함니다.
• Applications and Peers
  
  • 그럼... application이 peer와 어떻게 상호작용하는지? 함 보까요? 'ledger 단순쿼리'는 기본적으로 3-단계로 이루어 지고, 'ledger 업데이트'는 2-단계를 더 수반합니다. 최대한 'ledger 단순쿼리' 및 'ledger 업데이트' 의 절차를 잘 이해 하세용.
  • application은 fabric sdk를 활용해서 peer에게 접속을 합니다. API으로 'peer 접속', 'chaincode 실행 및 transaction생성', '순자적으로 ledger에 반영되는 transaction 제출', 'transaction 제출완료 이벤트감지' 등이 제공 됩니다.
  • 참고로 'ledger 단순쿼리' 는 즉각적인 리턴이 되는데, 'ledger 업데이트' 는 application, peer, orderer 사이에서 좀더 상호작용을 해서 비동기적으로 처리합니다.

  • 

    peer는 orderer와 함께 ledger가 최신상태를 유지하도록 합니다. 

  • peer의 'ledger 인스턴스(로컬사본)'에는 'ledger 단순쿼리'에 필요한 모든 정보가 있음으로~ 즉각적인 리턴이 되는것 입니다. (다른 peer의 눈치를 볼 필요가 없는거죠) 반면, application는 분산협업을 원하거나 최신데이터 확신을 위해서 다수개의 peer에게 접근 할 수 도있습니다. 이런 과정이 아시다시피 3-단계으로 이루어 집니다.
  • 'ledger 업데이트'는 추가적인 2-단계를 더 수반해야 합니다. 'chaincode 실행'은 마찬가지로 하는데~ peer는 딱 이시점에 ledger를 업데이트 할 수 는 없습니다. 왜냐면 다른 peer의 눈치(동의)를 받아야 하기 때문입니다. 이것이 바로 그 유명한 "블록체인 consensus" 라는것 입니다. 
  • 다시돌아와서 peer는 application에 마찬가지로 ('proposed 업테이트'를) 리턴 한 이후에... 
  • 2-단계의 첫번째 과정으로, blockchain-network 전체 peer의 각 ledger에 'proposed 업데이트'를 반영되는 하게 됩니다. 이 과정은 'application에서 orderer에게 요청' -> 'orderer는 transaction을 block으로 package' -> 'blockchain-network 전체 peer으로 분배' -> 'peer는 검증 및 ledger 반영' 으로 됩니다. 
  • 2-단계의 두번째는, 이 결과를 application에게 비동기 이벤트통보 하는것 입니다. 참~ 쉽죠?
• Peers and Channels
  
  • channel을 통해서 peer가 application과 어떻게 상호작용하는지? 알아두는건 중요합니다. (channel은 blockchain-network 에서 특정 component들끼리 private하게 통신을 할 수 있게하는 메터니즘이라 볼 수 있죠) 
  • component는 통상적으로 peer, orderer, application 등을 의미합니다. 이것들이 channel을 통해서~ 공통적인 ledger를 공유하고 관리하는것 이죠. (channel을 친구들간 카톡방 정도로 이해해도 됩니다.) 뭐... 여러분류의 다양한 카톡방을 가질 수 있듯이 channel도 여러게 만들 수 있고~ 각각의 channel은 독립적으로 rule를 설정 할 수 있다고 이해하면 될것 같습니다.

  • 

    A가 blockchain-network의 한 channel을 통해서 P1,P2 와 통신하는거

  • peer가 물리적인 node으로써 존재한다면, channel을 논리적인 구조라 생각하면 됩니다.
  • 그리고 channel에서 peer란? 접근하고 관리되는 하나의 제어지점 으로 이해될수있습니다. 잘~ 아시겟죠?
• Peers and Organizations
  
  • 이제 peer와 ledger, chaincode, channel의 관계에 대해서 다 이시겠죠? 그러다면 이제~ blockchain-network에 참여하는 각각의 organization들을 알아봅시다! 
  • blockchain-network는 여러게의 organization가 참여하고 총괄를 한다고 볼 수 있습니다. 이렇게 organization에 의해 소유되는 분산네트워크 인것이고, organization에서도 핵심은 peer 입니다.

  • 

    peers으로 각각의 organization이 구성된다. 그리고 blockchain-network는 서로다른 organization의해 구축 된다. P1,P3,P5,P7,P8 은 channel에 연결되어있고~ 다른 peer는 안되있이만... 통상적으로 최소 하나의 channel에는 참여한다. 각 application은 보통 그들의 organization에 peer와 통신한다.

  • blockchain-network의 핵심은 서로다른 organization에서 구축한 리소스를 기반으로 구성되고 관리된다는 점 입니다. 즉, 각자의 organization의 알아서 기여하는 과정에서 네트워크의 확장 이나 축소가 이루어 지는것 입니다. 
  • 중앙집중적인 성격의 리소스가 없음이 보이시죠? 바꿔말하면, blockchain-network는 특정 개별적인 organization에게 의존하지 않는다는 것! 입니다. (뭐 마지막 하나의 organization가 남을때까지, blockchain-network는 정상적으로 유지되는 것이죠) 이거시 바로 그 유명한 탈중앙화! 라는것 입니다.
  • 각각의 organization에서 사용하는 application은 똑같은 필요 없습니다. 각자가 알아서 잘 개발하면 됩니다. application이 어떻게 peer의 'ledger 인스턴스(로컬사본)'을 처리하느냐?는 전적으로 organization에 달려 있습니다. 그래서 모든 peer의 ledger가 동일해도... organization간 application 로직이 다르면~ 달라질수도있습니다.
  • application은 그들의 peer에 접속하기도 하고, 타 organization의 peer에 접속 할 수 도 있습니다. 'ledger 단순쿼리' 경우, 통상적으로 자신의 peer에 접속하고~ 'ledger 업데이트' 경우는, 모든 organization의 '대표 peer'에서 '보증'을 해줘야 하기때문에~ 타 peer와 접속을 해야 합니다.
• Peers and Identity
  
  • 서로다른 organization이 어떻게 blockchain-network를 이루는지? 아시겠죠? 그러면, administrator에 의해서 peer가 organization으로 어떻게 할당되는지? 잠깐 공부하시죠! 중요한 부분입니다.
  • peer은 특정 CA가 발급한 'X.509 인증서'를 통해서~ 'digital identity'를 갖춘다고 설명 했었습니다. 'X.509 인증서'를 단순히 peer의 많은 정보가 적혀있는 'ID card' 라고 생각하면 쉽습니다. organization의 administrator가 peer에게 'X.509 인증서'를 할당 하는것입니다.

  • 

    peer가 channel에 접속을 하면, 그의 'X.509 인증서'에 소속 organization가 파악된다. P1,P2에는 CA1가 발급한 것이 있고~ channel MSP의 ORG1.MSP 에는 CA1은 ORG1이라 정했기 때문...

  • peer가 blockchain-network속 channel으로 접속을 했을때, 'channel 정책'은 peer의 권리를 판단하기 위해서~ 'digital identity'를 사용한다. 바로 MSP으로 해당 'digital identity'의 소속 organization가 제공되고, organization에서의 특별한 role이라던지~ 그에맞는 적절한 리소스접근 이라던지~ 가 결정 되는것이다. (peer는 단일 organization 소속이고, 단일 MSP이다) 즉, MSP가 blockchain-network상 각 개별의 'digital identity' 와 특정 'organization role'간의 연결을 제공 할 수 있다는 것이다.
  • (잠깐 주제를 벗어나서, blockchain-network 상에서 상호작용하는 모든것들은 'X.509 인증서' 및 MSP으로 그들의 'organization identity' 를 취득 할 수 있다. peer, orderer, application, end-user, administrator 등등이 모두 MSP와 연계된 'X.509 인증서'를 가지고 있어야 한다. 즉, blockchain-network상의 모든 principal(주체)는 이름을 가질 수 있다! (어쩌라고;;) principal에 관해서는 다음에 더 알아보자.)
  • 아무튼... peer는 물리적으로 존재하는 것이고, 그의 'digital identity'는 특정 organization에 소속되어 있음을 명심하자! 
• Peers and Orderers
  
  • peer 와 application 간 상호작용 하면서... 모든 ledger가 일괄적으로 유지되게 하기 위해서는~ orderer가는 특별한 node가 필요합니다. 한번 알아볼까요? 
  • 'ledger 업데이트'는 하나의 peer으로는 처리할수없기에, 'ledger 단순쿼리' 처럼 동작 할 수는 없습니다. 업데이트는 blockchain-network 속 다른 peer의 동의를 받아야만 되는거, 당연하겟죠? 네~ 이것이 바로 블록체인에서 말하는 consensus라는것 입니다. 
  • 모든 ledger를 일괄적으로 유지하는 메커니즘을... 일단먼저 간단히 요약드리자면, 3단계로 설명하기 쉽습니다.
    • 1) 'application'이 --('proposed transaction'을)--> 몇몇 'endorsing peers'에게 요청, 및 보증받기
    • 2) 보증받은 'proposed transaction' 응답을 -> transaction으로써 수집하여 -> block으로 패키지화
    • 3) 각각의 해당 block을 (transaction 검증을 한 그~) peer들에게 다시 재분배 -> 각 peer의 ledger에 반영
  • 이러한 과정에서 orderer가 아주 핵심입니다. 한번 더 자세히 알아 보아용~
    • Phase 1: Proposal
      
      • 1단계는 application 과 몇몇 peers간에 일어나는 일입니다. 타 organization들의 'endorsing peers'에게 'proposed transaction'의 결과를 허락받는것 이죠.
      • 더 상세히 말씀드리면,  application이 ('endorsing peers'에게 보증받을 수 있는) 'proposed transaction'을 생성합니다.
      • 그후, 각각의 'endorsing peers'는 독립적으로 'proposed transaction'으로 chaincode 실행을 합니다.
      • 물론 해당결과를 ledger에 바로 반영하지는 않고, 간단히 '보증서명'을 한뒤~ 'proposed transaction' 응답을 합니다.
      • 이러게, application에서 충분히 ('보증서명'된) 'proposed transaction' 응답을 받으면~ 1단계는 정상적으로 마무리 됩니다.

      • 

      • 처음에 application가 'endorsing peers'을 선택을 하는데, 어떤 peer들이 선택 되는지? 궁금하시죠? 그건 바로 해당 chaincode의 '보증 정책'을 따름니다. 그리고 이건 blockchain-network상에서 합의한 organization들로 정하면 되겠죠? 말그대로 합의를 달성하는 것입니다. 당연히 주요 organization에서는 '보증 정책'의 합의에 관여하면 되는것 입니다. 
      • 또 각각의 'endorsing peers'는 '보증서명'을 private key으로 하는데, 이것으로 각 해당 organization의 peer가 보증을 했음이 입증되는것 입니다. (조직 담당자에게 도장 받은거죠ㅎ) 
      • 끝으로 application가 ('보증서명'된) 'proposed transaction' 응답을 받는데, 각각의 peer으로 부터~ 서로다른 응답을 받을 수 있음을 명심 해야 합니다. 각각의 peer는 서로다른 시간에, 서로다른 ledger상태에서 처리를 하는것 임으로~ 충분히 이럴수 있습니다. chaincode는 non-deterministic하니까요. ('비결정적'이라는 용어를 아시나요? 모르시면~ 위키에서 찾아봐!) 그리고 Non-determinism는 blockchain-network에서 아주 까다로운 이슈이죠... (그래서 이더리움은 굳이 솔리디티 같은 deterministic한 랭귀지를 쓰게 된것입니다.) 그래서 이 까다로운 이슈를 어떻게 해결하는지는~ 다음섹션에서 알아봐요.
      • 아무튼 application는 비일관적인 'proposed transaction' 응답은 그냥 버릴 수 있습니다. 어차피 설사 application에서 비일관적 결과를 ledger에 반영 하려고 시도해도, 그건 거부됩니다.
    • Phase 2: Ordering and packaging transactions into blocks
      
      • 2단계는 한마디로 패키징 이라 볼 수 있습니다. 바로 이 과정에서 orderer가 핵심이 됩니다. orderer는 수많은 application들로부터 '보증된 proposed transaction 결과'를 받에 됩니다. 그리고 순차적으로 패키징 하여~ 한 block을 만듭니다. 음... 일단 ordering and packaging 의 상세설명은~ "The Ordering Service" 시간에서 보아요.
    • Phase 3: Validation and commit
      
      • 3단계는 orderer로 부터 -> peer으로 분배 및 재검증 입니다. 특히, 각각의 peer에서는 block속의 transaction이 주요 organization으로부터 일관되게 보증받았는지? 검증합니다. 이 과정에서 실패된 transaction은 (추후 감사를 위해~) 보관은 되겠지만, ledger에 반영은 되지 않습니다.

      • 

        block을 peer에게 분배하는것도, orderer의 주요업무 입니다. 

      • orderer는 연결된 모든 peer에게 block을 분배하는데, 새로운 block이 생성되면, 연결괸 모든 peer는 그 사본 block를 받게되는것 입니다. 각각의 peer는 독립적이지만 똑같은 방식으로 이 block을 처리 합니다. 이런식으로 모든 ledger의 일관성을 유지 할 수 있는것 입니다. 그런데 blockchain-network상의 모든 peer가 orderer와 연결될 필요는 없습니다. 왜냐면, peer는 'gossip 프로토콜'으로 타peer에게 종속(cascade)되는 기능이 있기 때문입니다.
      • 참고로 peer는 block을 받으면, 순차적으로 내부 transaction을 처리 하는데~ peer는 각 transaction을 발생시킨 해당 chaincode의 '보증 정책'에 따라~ 그에맞는 organization의 보증을 받았는지? 검증합니다. (transaction마다 '보증 정책'이 다른것이겠죠? transaction마다 이해관계의 organization이 다를테니~) 또 이 검증과정에서는 모든 organization의 보증이 동일한 결과값인지? 검증합니다.
      • 이 과정은 1단계에서 알려드린 그 검증과는 다른것 입니다. 만약 1단계 때, application이 '보증 정책'과 다른 잘못된 transaction을 보냈었었더라도...  해당 peer는 이 3단계 검증을 통해~ 해당 transaction을 거부할 수 있습니다.
      • transaction의 보증에 관한 검증이 통과되면, ledger에 반영하면 되는데~ 이때에도 peer는 해당 반영이 현 ledger상태 와 호환이 되는지? 확인해야합니다. 가끔씩 완벽한 보증에도... 호환이 안될 수 있기 때문입니다. 예를들면, 어떤 transaction이 ledger의 동일한 자산을 같이 업데이트하여~ 유효하지 않게 할 수 있기 때문입니다. 이렇게 동일한 rule를 똑같이 따르면서 전체 ledger의 일관성을 유지하는 거죠.
      • 최종적으로 검증 '성공or실패' 된 transaction은 (추후 감사를 위해~) 모두 block으로 보관이 되는데, 이는 orderer에서 받은 block에서 (각 transaction '성공or실패' 만 추가된) 거의 동일한 block이라 볼수있습니다. 
      • 또... 주목할만한 점이 있습니다. 3단계에서는 (1단계 처럼) chaincode 실행은 하지 않는다는 점 입니다. 이말은 chaincode는 blockchain-network 전체가 아닌, 'endorsing peers'에서만 사용한다는 것 입니다. 이 점은 각 보증 organization의 내부코드 기밀유지에 좋고, 또한 'proposed transaction 결과'는 모든 peer에게도 공유되는 식이기 때문에~ 스케일 확장에도 좋습니다.
      • 마지막으로 peer가 block을 ledger에 반영할때마다, 여러가지 event를 발생시킴니다. 'block event'는 block의 모든내용을 포함하고, 'block transaction event' 는 각 transaction이 검증 '성공or실패' 요약만 포함 합니다. 'chaincode event'는 chaincode 실행으로 생성된것 입니다. application은 각각의 event를 등록하여, 감지할수있습니다. 이런 event 통보가 이 3단계의 끝 입니다.
      • 이제 orderer에서 생성된 block이 어떻게 일관되게 ledger에 반여되는지? 아시겠죠? 이 엄격한 transaction ordering을 통해서 각각의 peer이 blockchain-network 일관성을 유지 하는것 이랍니다. 
• Orderers and Consensus
  
  • 이 transaction 처리의 과정을 consensus 라 볼 수 있습니다. 왜냐면 모든 peer가 orderer의 중재하에서 반영할 transaction의 순서 및 내용에 관해서 동의를 했기 때문입니다. consensus는 여러단계의 과정으로 진행되고, application은 완료가 되면, 통보 받을 뿐입니다. 
  • 그럼 다음시간에 또만나요~ 안뇽~

 

-끝-