본문으로 이동
메뉴 여닫기
환경 설정 메뉴 여닫기
개인 메뉴 여닫기
로그인하지 않음
지금 편집한다면 당신의 IP 주소가 공개될 수 있습니다.
Blockchain Consensus

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

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

Liveness over Safety

편집 원본 편집
  • 잘못된 합의가 이루어질 수 있지만 어떻게든 합의는 한다.
  • 예시) 블록체인 PoW: 51% 발생 가능성. Safety는 보장하지 않음

Safety over Liveness

편집 원본 편집
  • 잘못된 가능성이 있다면 블록을 만들지 않는다.
  • 예시) 코스모스 텐더민트: 메시지가 시간안에 도착하지 않으면 블록 생성 안함

주요 고려사항

편집 원본 편집
  • Finality Problem
  • 51% Attack/BTF
  • Transaction Cost

합의 방식 종류

편집 원본 편집
불특정 다수가 참여하는 퍼블릭 블록체인과 신뢰된 소수가 참여하는 프라이빗 블록체인에서 사용하는 합의 방식의 차이 존재
합의 방식 설명 장점 단점 사용 코인
퍼블릭
  • 비허가형
  • 공개형
작업 증명
  • Pow
  • 각 노드의 연산 능력을 증명하여 블록 생성
  • 높은 컴퓨팅 파워를 가진 노드가 블록을 생성할 확률이 높음
  • 오랫동안 사용되며 안전성이 검증되었지만 단점도 많이 도출
  • 오랫동안 검증됨
  • 비트코인
  • 라이트코인
지분 증명
  • PoS
  • 소유 지분 양에 비례하여 블록 생성 권한을 높은 확률로 부여 받음
  • 많은 지분을 가진 노드가 블록을 생성할 확률 높음
  • 이론적으로 우수하지만 실제 대규모 환경에서 검증 사례가 부족
  • 51% Attack 내성
  • 빠른 트랜잭션
  • 에너지 낭비 적음
  • 퀀텀
  • 네오
  • 스트라디스
위임 지분 증명
  • DPoS
  • 일부 위임된 Validator끼리 PoS 수행
  • 트랜잭션 속도가 더 빠름
  • 신뢰도는 Validator의 신뢰도에 종속
  • 빠른 트랜잭션
  • 에너지 낭비 적음
  • 완전성 문제
  • 검증 부족
  • 탈중앙성 부족
  • 보안 취약
  • 스팀
  • 이오스
  • 아크
  • 라이즈
경과 시간 증명
  • PoET
  • 경쟁적 연산으로 낭비되는 에너지를 줄이면서 작업 증명과 유사 효과
  • 하이퍼레저 쏘투스 레이크(Sawtooth Lake)에서 제안
  • 인텔 SGX을 기반으로 블록을 생성하는 리더를 랜덤으로 선정
  • 검증된 방법의 개선
  • 에너지 낭비 적음
  • 특정 HW 종속
  • 쏘투스
프라이빗
  • 허가형
  • 컨소시엄
PBTF
  • 참가자 1명이 프라이머리(리더)가 되어 모든 참가자에게 요청 송신
  • 그 요청에 대한 결과를 집계한 뒤 다수의 값을 사용해 블록을 확정
  • 각 노드는 브로드캐스트 된 명령을 받게 되면 모든 노드에 회신
  • 각 노드는 명령을 일정 수 이상 수신하면 명령을 실행하고 블록을 등록
  • 참여자 사전 파악 필요
  • 참가자 증가 시 성능 하락
  • 페브릭
권한 증명
  • PoA
  • 트랜잭션 및 블록의 Validator라고 승인된 계정에 의해 유효성이 검사
  • Validator의 권리를 얻으므로 그들이 얻은 지위를 유지하고자 함
  • 자신의 신원에 부정적 평판이 생기길 원치 않도록 노력할 거라 가정
PAXOS
  • 트랜잭션 및 블록의 validator라고 승인된 계정에 의해 유효성이 검사
  • validator가 될 수 있는 권리를 얻으므로 그들이 얻은 지위를 유지하고자 함
  • 자신의 신원에 부정적인 평판이 생기길 원치 않도록 노력할 것이라 가정
RAFT
  • 리더를 선정한 후 시스템의 모든 변화를 리더를 통해 결정
  • 신뢰된 네트워크에서만 사용
  • 리더의 조작 가능
  • BTF 보장하지 않음
Sieve
  • IBM에서 고안한 PBFT 확장 알고리즘
  • 실행결과 전송과 집계 결과 전송으로 흐름이 나뉜다.