블록체인 합의

IT위키
ITPMaster (토론 | 기여)님의 2020년 1월 4일 (토) 23:45 판
Blockchain Consensus

본 문서는 블록체인의 함의 알고리즘, 합의 프로세스에 대해 다룬다.

종류

불특정 다수가 참여하는 퍼블릭 블록체인과 신뢰된 소수가 참여하는 프라이빗 블록체인에서 사용하는 합의 방식의 차이 존재

퍼블릭 블록체인의 합의

작업 증명

Proof of Work
높은 컴퓨팅 파워를 가진 노드가 블록을 생성할 확률이 높음
  • 51% Attack 가능
  • Finality Problem
  • 트랜잭션 속도 느림
  • 에너지 낭비 많음
  • 많은 검증이루어짐
    • 안전하다고 판명되었으나 단점도 많이 도출됨

지분 증명

Proof of State
높은 지분을 가진 노드가 블록을 생성할 확률이 높음
  • 51% Attack 내성
  • Finality Problem
  • 트랜잭션 속도 빠름
  • 에너지 낭비 적음
  • 검증 필요
  • 도출된 단점이 없고 이론적으로 우수하지만 검증 부족

위임 지분 증명

Delegated Proof of Stake
  • 일부 위임된 Validator끼리 PoS 수행
  • 트랜잭션 속도가 더 빠름
  • 신뢰도는 Validator의 신뢰도에 종속

PoI

분산원장의 여러가지 상황을 고려하여 중요도가 높은 노드가 블록을 생성할 확률이 높음

PoET

프라이빗 블록체인 합의

PBTF

Practical Byzantine Fault Tolerance
  • Finality Problem 해결
  • 네트워크의 모든 참여자를 미리 알고있어야 함
  • 참가자 1명이 프라이머리(리더)가 되어 모든 참가자에게 요청 송신
  • 그 요청에 대한 결과를 집계한 뒤 다수의 값을 사용해 블록을 확정
  • 부정한 노드 수를 n개라고 하면 노드 수는 3n+1개여야 하며, 확정에는 n+1개 이상의 노드가 필요
  • 각 노드는 브로드캐스트 된 명령을 받게 되면 Leader를 포함한 모든 노드에 회신
  • 각 노드는 수신된 명령을 일정 수 이상(2n)수신하면 명령을 실행하고 블록을 등록
  • 항상 참가자 전원과 의사소통을 해야 하기 때문에 참가자가 증가하면 통신량이 증가하고 처리량이 저하

PAXOS

RAFT

Sievie

속성

합의 프로토콜은 아래 두 속성을 만족시켜야 한다.
  • Safety: 시스템에 나쁜 일이 발생하지 않는다는 의미이며, 모든 정상적인 참여자는 같은 상태에 동의하여야 하고, 그 상태는 유효해야 함
  • Liveness: 시스템은 항상 살아 있어야 한다는 의미이며, 결국에는 어떤 상태에 동의하여야 하고, 모든 참여자는 동의된 상태에 도달해야 함