블록체인 합의: 두 판 사이의 차이

IT위키
편집 요약 없음
편집 요약 없음
1번째 줄: 1번째 줄:
[[분류:블록체인]]
;Blockchain Consensus
;Blockchain Consensus
본 문서는 블록체인의 함의 알고리즘, 합의 프로세스에 대해 다룬다.
본 문서는 블록체인의 함의 알고리즘, 합의 프로세스에 대해 다룬다.


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


=== Liveness over Safety ===
;합의 프로토콜은 아래 두 속성을 만족시켜야 한다.
* 잘못된 합의가 이루어질 수 있지만 어떻게든 합의는 한다.
* 예시) 블록체인 PoW: 51% 발생 가능성. Safety는 보장하지 않음


=== Safety over Liveness ===
*Safety: 시스템에 나쁜 일이 발생하지 않는다는 의미이며, 모든 정상적인 참여자는 같은 상태에 동의하여야 하고, 그 상태는 유효해야 함
* 잘못된 가능성이 있다면 블록을 만들지 않는다.
**문제 없는 노드는 잘못된 합의를 하지 않는다.
* 예시) 코스모스 텐더민트: 메시지가 시간안에 도착하지 않으면 블록 생성 안함
*Liveness: 시스템은 항상 살아 있어야 한다는 의미이며, 결국에는 어떤 상태에 동의하여야 하고, 모든 참여자는 동의된 상태에 도달해야 함
**문제 없는 노드는 반드시 합의를 한다.


== 주요 고려사항 ==
===Liveness over Safety===
* Finality Problem
 
* 51% Attack/BTF
*잘못된 합의가 이루어질 수 있지만 어떻게든 합의는 한다.
* Transaction Cost
*예시) '''[[블록체인]] [[작업 증명|PoW]]''': 51% 발생 가능성. Safety는 보장하지 않음


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


=== 퍼블릭 블록체인의 합의 ===
*잘못된 가능성이 있다면 블록을 만들지 않는다.
==== 작업 증명 ====
*예시) '''[[코스모스]] [[텐더민트]]''': 메시지가 시간안에 도착하지 않으면 블록 생성 안함
;PoW; Proof of Work
;높은 컴퓨팅 파워를 가진 노드가 블록을 생성할 확률이 높음
* 51% Attack 가능
* Finality Problem
* 트랜잭션 속도 느림
* 에너지 낭비 많음
* 많은 검증이루어짐
** 안전하다고 판명되었으나 단점도 많이 도출됨


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


==== 위임 지분 증명 ====
*Finality Problem
;DPoS; Delegated Proof of Stake
*51% Attack/BTF
* 일부 위임된 Validator끼리 PoS 수행
*Transaction Cost
* 트랜잭션 속도가 더 빠름
* 신뢰도는 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)수신하면 명령을 실행하고 블록을 등록
* 항상 참가자 전원과 의사소통을 해야 하기 때문에 참가자가 증가하면 통신량이 증가하고 처리량이 저하


==== 권한 검증 ====
{| class="wikitable"
;PoA; Proof of Authority
|+
* 트랜잭션 및 블록의 validator라고 승인된 계정에 의해 유효성이 검사
!
* validator가 될 수 있는 권리를 얻으므로 그들이 얻은 지위를 유지하고자 함
!합의 방식
* 자신의 신원에 부정적인 평판이 생기길 원치 않도록 노력할 것이라 가정
!설명
!장점
!단점
!사용 코인
|-
| rowspan="4" |퍼블릭


==== PAXOS ====
* 비허가형
* BTF를 보장하지 않는다.
* 공개형
* 리더나 참여자가 악의적인 의도를 가진다면 조작될 수 있다.
|[[작업 증명]]
* 신뢰된 네트워크에서만 사용
* Pow
|
* 각 노드의 연산 능력을 증명하여 블록 생성


==== RAFT ====
* 높은 컴퓨팅 파워를 가진 노드가 블록을 생성할 확률이 높음
* 리더를 선정한 후 시스템의 모든 변화를 리더를 통해 결정
* 오랫동안 사용되며 안전성이 검증되었지만 단점도 많이 도출
|
* 오랫동안 검증됨
|
* 51% Attack
* Finality Problem
* 느린 트랜잭션
* 에너지 낭비
|
* 비트코인
* 라이트코인
|-
|[[지분 증명]]
* PoS
|
* 소유 지분 양에 비례하여 블록 생성 권한을 높은 확률로 부여 받음
* 많은 지분을 가진 노드가 블록을 생성할 확률 높음
* 이론적으로 우수하지만 실제 대규모 환경에서 검증 사례가 부족
|
* 51% Attack 내성
* 빠른 트랜잭션
* 에너지 낭비 적음
|
* Finality Problem
* 검증 부족
|
* 퀀텀
* 네오
* 스트라디스
|-
|[[위임 지분 증명]]
* DPoS
|
* 일부 위임된 Validator끼리 PoS 수행
*트랜잭션 속도가 더 빠름
*신뢰도는 Validator의 신뢰도에 종속
|
* 빠른 트랜잭션
* 에너지 낭비 적음
|
* Finality Problem
* 검증 부족
* 탈중앙성 부족
* 보안 취약
|
* 스팀
* 이오스
* 아크
* 라이즈
|-
|[[경과 시간 증명]]
* PoET
|
*경쟁적 연산으로 낭비되는 에너지를 줄이면서 작업 증명과 유사 효과
*[[하이퍼레저]] 쏘투스 레이크(Sawtooth Lake)에서 제안
*[[인텔 SGX]]을 기반으로 블록을 생성하는 리더를 랜덤으로 선정
|
* 검증된 방법의 개선
* 에너지 낭비 적음
|
* 특정 HW 종속
|
* 쏘투스
|-
| rowspan="5" |프라이빗


==== Sieve ====
* 허가형
* IBM에서 고안한 PBFT 확장 알고리즘  
* 컨소시엄
* 실행결과 전송과 집계 결과 전송으로 흐름이 나뉜다.
|[[PBTF]]
|
*참가자 1명이 프라이머리(리더)가 되어 모든 참가자에게 요청 송신
*그 요청에 대한 결과를 집계한 뒤 다수의 값을 사용해 블록을 확정
*부정한 노드 수를 n개라고 하면 노드 수는 3n+1개여야 하며, 확정에는 n+1개 이상의 노드가 필요
*각 노드는 브로드캐스트 된 명령을 받게 되면 Leader를 포함한 모든 노드에 회신
*각 노드는 수신된 명령을 일정 수 이상(2n)수신하면 명령을 실행하고 블록을 등록
|
* Finality Problem 해결
* 빠른 트랜잭션
|
* 참여자 사전 파악 필요
* 참가자 수가 많아지면 성능 하락
|
* 페브릭
|-
|[[권한 증명]]
* 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으로 보는 블록체인]
* [https://blog.seulgi.kim/2018/05/safety-liveness-in-blockchain.html Safety & Liveness - FLP impossibility으로 보는 블록체인]

2020년 3월 8일 (일) 19:53 판

Blockchain Consensus

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

속성

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

Liveness over Safety

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

Safety over Liveness

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

주요 고려사항

  • Finality Problem
  • 51% Attack/BTF
  • Transaction Cost

합의 방식 종류

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


같이 보기