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