| 최신판 |
당신의 편집 |
| 1번째 줄: |
1번째 줄: |
| | [[분류:블록체인]] |
| ;Blockchain Consensus | | ;Blockchain Consensus |
|
| |
| 본 문서는 블록체인의 함의 알고리즘, 합의 프로세스에 대해 다룬다. | | 본 문서는 블록체인의 함의 알고리즘, 합의 프로세스에 대해 다룬다. |
|
| |
|
| ==속성== | | == 종류 == |
| | ; 불특정 다수가 참여하는 [[퍼블릭 블록체인]]과 신뢰된 소수가 참여하는 [[프라이빗 블록체인]]에서 사용하는 합의 방식의 차이 존재 |
|
| |
|
| ;합의 프로토콜은 아래 두 속성을 만족시켜야 한다. | | === 퍼블릭 블록체인의 합의 === |
| | ==== 작업 증명 ==== |
| | ;Proof of Work |
| | ;높은 컴퓨팅 파워를 가진 노드가 블록을 생성할 확률이 높음 |
| | * 51% Attack 가능 |
| | * Finality Problem |
| | * 트랜잭션 속도 느림 |
| | * 에너지 낭비 많음 |
| | * 많은 검증이루어짐 |
| | ** 안전하다고 판명되었으나 단점도 많이 도출됨 |
|
| |
|
| *Safety: 시스템에 나쁜 일이 발생하지 않는다는 의미이며, 모든 정상적인 참여자는 같은 상태에 동의하여야 하고, 그 상태는 유효해야 함 | | ==== 지분 증명 ==== |
| **문제 없는 노드는 잘못된 합의를 하지 않는다. | | ;Proof of State |
| *Liveness: 시스템은 항상 살아 있어야 한다는 의미이며, 결국에는 어떤 상태에 동의하여야 하고, 모든 참여자는 동의된 상태에 도달해야 함 | | ;높은 지분을 가진 노드가 블록을 생성할 확률이 높음 |
| **문제 없는 노드는 반드시 합의를 한다. | | * 51% Attack 내성 |
| | * Finality Problem |
| | * 트랜잭션 속도 빠름 |
| | * 에너지 낭비 적음 |
| | * 검증 필요 |
| | * 도출된 단점이 없고 이론적으로 우수하지만 검증 부족 |
|
| |
|
| ===Liveness over Safety=== | | ==== 위임 지분 증명 ==== |
| | | ;Delegated Proof of Stake |
| *잘못된 합의가 이루어질 수 있지만 어떻게든 합의는 한다.
| | * 일부 위임된 Validator끼리 PoS 수행 |
| *예시) '''[[블록체인]] [[작업 증명|PoW]]''': 51% 발생 가능성. Safety는 보장하지 않음
| | * 트랜잭션 속도가 더 빠름 |
| | | * 신뢰도는 Validator의 신뢰도에 종속 |
| ===Safety over Liveness=== | |
| | |
| *잘못된 가능성이 있다면 블록을 만들지 않는다. | |
| *예시) '''[[코스모스]] [[텐더민트]]''': 메시지가 시간안에 도착하지 않으면 블록 생성 안함 | |
|
| |
|
| ==주요 고려사항== | | ==== PoI ==== |
| | 분산원장의 여러가지 상황을 고려하여 중요도가 높은 노드가 블록을 생성할 확률이 높음 |
|
| |
|
| *Finality Problem
| | ==== PoET ==== |
| *51% Attack/BTF
| |
| *Transaction Cost
| |
|
| |
|
| ==합의 방식 종류== | | === 프라이빗 블록체인 합의 === |
| | ==== PBTF ==== |
| | ;Practical Byzantine Fault Tolerance |
| | * Finality Problem 해결 |
| | * 네트워크의 모든 참여자를 미리 알고있어야 함 |
| | * 참가자 1명이 프라이머리(리더)가 되어 모든 참가자에게 요청 송신 |
| | * 그 요청에 대한 결과를 집계한 뒤 다수의 값을 사용해 블록을 확정 |
| | * 부정한 노드 수를 n개라고 하면 노드 수는 3n+1개여야 하며, 확정에는 n+1개 이상의 노드가 필요 |
| | * 각 노드는 브로드캐스트 된 명령을 받게 되면 Leader를 포함한 모든 노드에 회신 |
| | * 각 노드는 수신된 명령을 일정 수 이상(2n)수신하면 명령을 실행하고 블록을 등록 |
| | * 항상 참가자 전원과 의사소통을 해야 하기 때문에 참가자가 증가하면 통신량이 증가하고 처리량이 저하 |
|
| |
|
| ;불특정 다수가 참여하는 [[퍼블릭 블록체인]]과 신뢰된 소수가 참여하는 [[프라이빗 블록체인]]에서 사용하는 합의 방식의 차이 존재
| | ==== PAXOS ==== |
| | |
| {| class="wikitable"
| |
| |+
| |
| !
| |
| !합의 방식
| |
| !설명
| |
| !장점
| |
| !단점
| |
| !사용 코인
| |
| |-
| |
| | rowspan="4" |퍼블릭
| |
| | |
| * 비허가형
| |
| * 공개형
| |
| |[[작업 증명]]
| |
| * Pow
| |
| |
| |
| * 각 노드의 연산 능력을 증명하여 블록 생성
| |
| | |
| * 높은 컴퓨팅 파워를 가진 노드가 블록을 생성할 확률이 높음
| |
| * 오랫동안 사용되며 안전성이 검증되었지만 단점도 많이 도출
| |
| |
| |
| * 오랫동안 검증됨
| |
| |
| |
| * 51% Attack
| |
| * [[블록체인 완결성|완결성 문제]]
| |
| * 느린 트랜잭션
| |
| * 에너지 낭비
| |
| |
| |
| * 비트코인
| |
| * 라이트코인
| |
| |-
| |
| |[[지분 증명]]
| |
| * PoS
| |
| |
| |
| * 소유 지분 양에 비례하여 블록 생성 권한을 높은 확률로 부여 받음
| |
| * 많은 지분을 가진 노드가 블록을 생성할 확률 높음
| |
| * 이론적으로 우수하지만 실제 대규모 환경에서 검증 사례가 부족
| |
| |
| |
| * 51% Attack 내성
| |
| * 빠른 트랜잭션
| |
| * 에너지 낭비 적음
| |
| |
| |
| * [[블록체인 완결성|완결성 문제]]
| |
| * 검증 부족
| |
| |
| |
| * 퀀텀
| |
| * 네오
| |
| * 스트라디스
| |
| |-
| |
| |[[위임 지분 증명]]
| |
| * DPoS
| |
| |
| |
| * 일부 위임된 Validator끼리 PoS 수행
| |
| *트랜잭션 속도가 더 빠름
| |
| *신뢰도는 Validator의 신뢰도에 종속
| |
| |
| |
| * 빠른 트랜잭션
| |
| * 에너지 낭비 적음
| |
| |
| |
| * 완전성 문제
| |
| * 검증 부족
| |
| * 탈중앙성 부족
| |
| * 보안 취약
| |
| |
| |
| * 스팀
| |
| * 이오스
| |
| * 아크
| |
| * 라이즈
| |
| |-
| |
| |[[경과 시간 증명]]
| |
| * PoET
| |
| |
| |
| *경쟁적 연산으로 낭비되는 에너지를 줄이면서 작업 증명과 유사 효과
| |
| *[[하이퍼레저]] 쏘투스 레이크(Sawtooth Lake)에서 제안
| |
| *[[인텔 SGX]]을 기반으로 블록을 생성하는 리더를 랜덤으로 선정
| |
| |
| |
| * 검증된 방법의 개선
| |
| * 에너지 낭비 적음
| |
| |
| |
| * 특정 HW 종속
| |
| |
| |
| * 쏘투스
| |
| |-
| |
| | rowspan="5" |프라이빗
| |
|
| |
|
| * 허가형
| | ==== RAFT ==== |
| * 컨소시엄
| |
| |[[PBTF]]
| |
| |
| |
| *참가자 1명이 프라이머리(리더)가 되어 모든 참가자에게 요청 송신
| |
| *그 요청에 대한 결과를 집계한 뒤 다수의 값을 사용해 블록을 확정
| |
| *각 노드는 브로드캐스트 된 명령을 받게 되면 모든 노드에 회신
| |
| *각 노드는 명령을 일정 수 이상 수신하면 명령을 실행하고 블록을 등록
| |
| |
| |
| * [[블록체인 완결성|완결성 문제 해결]]
| |
| * 빠른 트랜잭션
| |
| |
| |
| * 참여자 사전 파악 필요
| |
| * 참가자 증가 시 성능 하락
| |
| |
| |
| * 페브릭
| |
| |-
| |
| |[[권한 증명]]
| |
| * PoA
| |
| |
| |
| *트랜잭션 및 블록의 Validator라고 승인된 계정에 의해 유효성이 검사
| |
| *Validator의 권리를 얻으므로 그들이 얻은 지위를 유지하고자 함
| |
| *자신의 신원에 부정적 평판이 생기길 원치 않도록 노력할 거라 가정
| |
| |
| |
| |
| |
| |
| |
| |-
| |
| |[[PAXOS]]
| |
| |
| |
| *트랜잭션 및 블록의 validator라고 승인된 계정에 의해 유효성이 검사
| |
| *validator가 될 수 있는 권리를 얻으므로 그들이 얻은 지위를 유지하고자 함
| |
| *자신의 신원에 부정적인 평판이 생기길 원치 않도록 노력할 것이라 가정
| |
| |
| |
| |
| |
| |
| |
| |-
| |
| |[[RAFT]]
| |
| |
| |
| *리더를 선정한 후 시스템의 모든 변화를 리더를 통해 결정
| |
| *신뢰된 네트워크에서만 사용
| |
| |
| |
| |
| |
| * 리더의 조작 가능
| |
| * BTF 보장하지 않음
| |
| |
| |
| |-
| |
| |[[Sieve]]
| |
| |
| |
| *IBM에서 고안한 PBFT 확장 알고리즘
| |
| *실행결과 전송과 집계 결과 전송으로 흐름이 나뉜다.
| |
| |
| |
| |
| |
| |
| |
| |}
| |
| <br />
| |
|
| |
|
| ==같이 보기== | | ==== Sievie ==== |
|
| |
|
| *[https://blog.seulgi.kim/2018/05/safety-liveness-in-blockchain.html Safety & Liveness - FLP impossibility으로 보는 블록체인] | | == 속성 == |
| | ; 합의 프로토콜은 아래 두 속성을 만족시켜야 한다. |
| | * Safety: 시스템에 나쁜 일이 발생하지 않는다는 의미이며, 모든 정상적인 참여자는 같은 상태에 동의하여야 하고, 그 상태는 유효해야 함 |
| | * Liveness: 시스템은 항상 살아 있어야 한다는 의미이며, 결국에는 어떤 상태에 동의하여야 하고, 모든 참여자는 동의된 상태에 도달해야 함 |
