블록체인 합의: Difference between revisions
From IT Wiki
No edit summary |
|||
| Line 6: | Line 6: | ||
; 합의 프로토콜은 아래 두 속성을 만족시켜야 한다. | ; 합의 프로토콜은 아래 두 속성을 만족시켜야 한다. | ||
* Safety: 시스템에 나쁜 일이 발생하지 않는다는 의미이며, 모든 정상적인 참여자는 같은 상태에 동의하여야 하고, 그 상태는 유효해야 함 | * Safety: 시스템에 나쁜 일이 발생하지 않는다는 의미이며, 모든 정상적인 참여자는 같은 상태에 동의하여야 하고, 그 상태는 유효해야 함 | ||
** 문제 없는 노드는 잘못된 합의를 하지 않는다. | |||
* Liveness: 시스템은 항상 살아 있어야 한다는 의미이며, 결국에는 어떤 상태에 동의하여야 하고, 모든 참여자는 동의된 상태에 도달해야 함 | * Liveness: 시스템은 항상 살아 있어야 한다는 의미이며, 결국에는 어떤 상태에 동의하여야 하고, 모든 참여자는 동의된 상태에 도달해야 함 | ||
** 문제 없는 노드는 반드시 합의를 한다. | |||
=== Liveness over Safety === | |||
* 잘못된 합의가 이루어질 수 있지만 어떻게든 합의는 한다. | |||
* 예시) 블록체인 PoW: 51% 발생 가능성. Safety는 보장하지 않음 | |||
=== Safety over Liveness === | |||
* 잘못된 가능성이 있다면 블록을 만들지 않는다. | |||
* 예시) 코스모스 텐더민트: 메시지가 시간안에 도착하지 않으면 블록 생성 안함 | |||
== 주요 고려사항 == | == 주요 고려사항 == | ||
| Line 78: | Line 88: | ||
* IBM에서 고안한 PBFT 확장 알고리즘 | * IBM에서 고안한 PBFT 확장 알고리즘 | ||
* 실행결과 전송과 집계 결과 전송으로 흐름이 나뉜다. | * 실행결과 전송과 집계 결과 전송으로 흐름이 나뉜다. | ||
== 같이 보기 == | |||
* [https://blog.seulgi.kim/2018/05/safety-liveness-in-blockchain.html Safety & Liveness - FLP impossibility으로 보는 블록체인] | |||
Revision as of 19:04, 25 January 2020
- Blockchain Consensus
본 문서는 블록체인의 함의 알고리즘, 합의 프로세스에 대해 다룬다.
속성
- 합의 프로토콜은 아래 두 속성을 만족시켜야 한다.
- Safety: 시스템에 나쁜 일이 발생하지 않는다는 의미이며, 모든 정상적인 참여자는 같은 상태에 동의하여야 하고, 그 상태는 유효해야 함
- 문제 없는 노드는 잘못된 합의를 하지 않는다.
- Liveness: 시스템은 항상 살아 있어야 한다는 의미이며, 결국에는 어떤 상태에 동의하여야 하고, 모든 참여자는 동의된 상태에 도달해야 함
- 문제 없는 노드는 반드시 합의를 한다.
Liveness over Safety
- 잘못된 합의가 이루어질 수 있지만 어떻게든 합의는 한다.
- 예시) 블록체인 PoW: 51% 발생 가능성. Safety는 보장하지 않음
Safety over Liveness
- 잘못된 가능성이 있다면 블록을 만들지 않는다.
- 예시) 코스모스 텐더민트: 메시지가 시간안에 도착하지 않으면 블록 생성 안함
주요 고려사항
- Finality Problem
- 51% Attack/BTF
- Transaction Cost
종류
퍼블릭 블록체인의 합의
작업 증명
- PoW; Proof of Work
- 높은 컴퓨팅 파워를 가진 노드가 블록을 생성할 확률이 높음
- 51% Attack 가능
- Finality Problem
- 트랜잭션 속도 느림
- 에너지 낭비 많음
- 많은 검증이루어짐
- 안전하다고 판명되었으나 단점도 많이 도출됨
지분 증명
- PoS; Proof of State
- 높은 지분을 가진 노드가 블록을 생성할 확률이 높음
- 51% Attack 내성
- Finality Problem
- 트랜잭션 속도 빠름
- 에너지 낭비 적음
- 검증 필요
- 도출된 단점이 없고 이론적으로 우수하지만 검증 부족
위임 지분 증명
- DPoS; Delegated Proof of Stake
- 일부 위임된 Validator끼리 PoS 수행
- 트랜잭션 속도가 더 빠름
- 신뢰도는 Validator의 신뢰도에 종속
경과시간 증명
- PoET; Proof of Elapsed Time
- 경쟁적 해싱 연산으로 낭비되는 에너지를 줄이면서 작업 증명(PoW)과 유사한 Security를 보장
- 하이퍼레저 쏘투스 레이크(Sawtooth Lake)에서 제안
- 신뢰할 수 있는 보안 모듈(intel SGX)을 기반으로 블록을 생성하는 리더를 랜덤으로 선정
프라이빗 블록체인 합의
PBTF
- Practical Byzantine Fault Tolerance
- Finality Problem 해결
- 네트워크의 모든 참여자를 미리 알고있어야 함
- 참가자 1명이 프라이머리(리더)가 되어 모든 참가자에게 요청 송신
- 그 요청에 대한 결과를 집계한 뒤 다수의 값을 사용해 블록을 확정
- 부정한 노드 수를 n개라고 하면 노드 수는 3n+1개여야 하며, 확정에는 n+1개 이상의 노드가 필요
- 각 노드는 브로드캐스트 된 명령을 받게 되면 Leader를 포함한 모든 노드에 회신
- 각 노드는 수신된 명령을 일정 수 이상(2n)수신하면 명령을 실행하고 블록을 등록
- 항상 참가자 전원과 의사소통을 해야 하기 때문에 참가자가 증가하면 통신량이 증가하고 처리량이 저하
권한 검증
- PoA; Proof of Authority
- 트랜잭션 및 블록의 validator라고 승인된 계정에 의해 유효성이 검사
- validator가 될 수 있는 권리를 얻으므로 그들이 얻은 지위를 유지하고자 함
- 자신의 신원에 부정적인 평판이 생기길 원치 않도록 노력할 것이라 가정
PAXOS
- BTF를 보장하지 않는다.
- 리더나 참여자가 악의적인 의도를 가진다면 조작될 수 있다.
- 신뢰된 네트워크에서만 사용
RAFT
- 리더를 선정한 후 시스템의 모든 변화를 리더를 통해 결정
Sieve
- IBM에서 고안한 PBFT 확장 알고리즘
- 실행결과 전송과 집계 결과 전송으로 흐름이 나뉜다.
