[Klaytn 클레이튼 블록체인 어플리케이션 만들기] 6~7강

합의Consensus

• public 블록체인에서 사용하는 합의 알고리즘 : PoW, PoS 등등
• private 블록체인에서 사용하는 합의 알고리즘 : pBFT, Raft 등등
• public 블록체인이 private 블록체인보다 효율적으로 합의에 도달할 수 있음
• 특히 BFT(비잔티움 결함 허용) 기반 블록체인은 
  • 참여 노드의 수를 제한하여 높은 성능과 효율을 달성할 수 있음
  • 하지만 참여 노드의 수를 제한하는 문제로 인해 분산화를 약화시키고, 합의 결과에 대한 내용이 소규모 그룹에만 공개 되기 때문에 투명성을 저하하여 블록체인 혜택을 의미있게 사용하지 못함
• 클레이튼의 합의 알고리즘 IBFT(클레이튼 합의 알고리즘 - 이스탄불 비잔티움 결함 허용)은
  
  • 강력한 보안 및 투명성 유지
  • 엔터프라이즈급 성능 및 안정성 제공하는 public 블록체인 지향
  • 위 목표를 달성하기 위해 공개를 통한 개인적인 합의 신뢰 모델 채택
    • 합의를 달성하는 소수의 private node들과
    • 바깥에서 블록 생성 결과를 공개적으로 접근하고 검증할 수 있는 node들로 구성 

 

IBFT

• IBFT는 크게 3단계의 합의 단계가 있음
  • pre-prepare
  • prepare
  • commit
• round-robin 방식을 선택해서 매 라운드마다 합의 node들 중 proposer을 뽑음 (propose 단계)
  • 나머지 node들은 validator가 되어 검증을 함
  • 그림의 x표시가 되어있는 Validator3은 검증자로서 제대로 작동을 못하는 상태 - fault (컴퓨터가 고장났거나, 네트워크가 끊어졌거나, 일부러 악의적으로 행동할 경우)
• proposer node가 블록을 만들어서 다른 node들에게 제안을 함 (pre-prepare 단계)
  • 그림에서 proposer가 validator1, validator2, validator3에게 블록과 메시지를 전달
• 검증자 node들이 proposer에게 메시지를 받으면 자신을 제외한 다른 node (prepare 단계)
  • 그림에서 각 node들이 자신을 제외한 다른 node들에게 메시지를 전달
  • validator3 node는 현재 fault가 났기 때문에 다른 node들에게 받기만 함
  • prepare 단계가 끝나면 총 몇개의 node가 유효한지 알 수 있음
  • 이 단계에서 검증자들이 모두 같은 round에 있는지 확인함
• proposer에게 받은 블록을 수락할 것인지 다른 node들과 소통하면서 결정 (commit 단계)
  • 블록이 괜찮다고 생각하는지, 혹은 잘못됐다고 생각하는지 각자 응답을 보냄
  • 2/3 이상이 합의를 했을 경우, 블록 승인
  • 이 단계에서 finality가 결정됨
• 장점 : 합의 node들끼리 통신을 통해 합의를 이끌어내고 그 즉시 완결성을 가짐
• 단점 : 합의 node가 많아질수록 통신양이 기하급수적으로 늘어남

 

클레이튼의 블록 생성 및 전파

클레이튼의 블록 생성 사이클

• 라운드(round) : 블록 생성 사이클(cycle). 각 라운드는 새로운 블록을 생성하고 끝내는 즉시 새로운 라운드가 시작됨
• 블록생성 간격 : 약 1초

클레이튼의 제안자와 위원회 선택

• 각 라운드에서 블록을 생성할 proposer를 무작위(randomly)지만 결정적(deterministically)으로 Governance Council node들 중 뽑음

Governance Council : 합의 노드들

• 각각의 합의 노드가 가장 최근의 블록 헤더에서 파생된 난수를 사용하여 자기가 이 라운드에서 선택되었는지 증명하는 암호화 작업을 하게 됨

블록 제안과 검증

• proposer가 선택이 되면 자신이 그 라운드에서 proposer로 뽑힌 증거를 다른 합의 node들에게 알림
  • 이때 제안자의 공개키를 통해 입증 가능한 암호증명 사용
• 그리고 해당 라운드에서 validator로 뽑힌 합의 node 그룹은 자신들이 왜 validator로 뽑혔는지 증거와 함께 알려줌
• 누가 proposer고 누가 validator로 파악이 되면 proposer가 TX POOL에서 TX를 선택하고 정렬해서 블록을 만들고, 그 후에 validator와 합의하고 새로 생성된 블록에 동의하면 마무리 됨

블록 전파

• 제한된 블록은 성공적으로 완료되기 위해서는 validator의 2/3 이상의 서명을 받아야 함

• validator가 합의에 이르면 새로운 블록이 모든 합의 node들에게 전달이 되고 그 합의 라운드는 끝남

• 그러면 프록시 node를 통해 엔드포인트 node들에게 전달됨