"위임 프랙티컬 비잔틴 장애 허용"의 두 판 사이의 차이
leejia1222 (토론 | 기여) (→사용) |
leejia1222 (토론 | 기여) |
||
1번째 줄: | 1번째 줄: | ||
'''위임 프랙티컬 비잔틴 장애 허용'''('''dPBFT'''; delegated PBFT; delegated Practical Byzantine Fault Tolerance)은 기존의 [[프랙티컬 비잔틴 장애 허용]](PBFT) 알고리즘에 [[북키퍼]](bookkeeper) 개념을 추가한 [[합의 알고리즘]]이다. 간략히 '''위임 비잔틴 장애 허용'''(DBFT; Delegated Byzantine Fault Tolerance)이라고 한다. 중국의 이더리움으로 불리는 '''[[네오]]'''(NEO)가 이 방식을 사용하고 있다. | '''위임 프랙티컬 비잔틴 장애 허용'''('''dPBFT'''; delegated PBFT; delegated Practical Byzantine Fault Tolerance)은 기존의 [[프랙티컬 비잔틴 장애 허용]](PBFT) 알고리즘에 [[북키퍼]](bookkeeper) 개념을 추가한 [[합의 알고리즘]]이다. 간략히 '''위임 비잔틴 장애 허용'''(DBFT; Delegated Byzantine Fault Tolerance)이라고 한다. 중국의 이더리움으로 불리는 '''[[네오]]'''(NEO)가 이 방식을 사용하고 있다. | ||
+ | |||
+ | == 장점 == | ||
+ | 위임 프랙티컬 비잔틴 장애 허용의 장점은 속도와 완료성이다. 네트워크에 참여하는 수많은 사람들이 다 검증에 참여하는 것이 아니라, 소수의 대표들끼리 합의를 통해 결정하기 때문에 블록 생성 과정이 훨씬 단순해지고 빨라진다. 현재 네오의 초당 거래 처리량은 평균 1000 TPS이다. 이더리움이 평균 15 TPS임을 볼 때 속도에 있어서는 큰 우위를 가진다. | ||
+ | |||
+ | 또한 포크(fork)가 일어나지 않는다. 포크란 네트워크의 노드들이 의견이 일치하지 않을 때 블록체인이 여러 개로 갈라지는 현상을 말한다. 작업증명이나 지분증명 방식에서는 일시적으로 진본이 두 개 이상일 때가 있다. 이 경우에 동시에 서로 다른 유효한 블록이 생길 수 있다. 하지만 결국에는 가장 긴 체인이 진본으로 인정된다. 이런 일시적인 포크는 금방 사라지기는 하지만 거래가 블록체인에 연결되더라도 일정 시간이 지나기 전까지 그 거래가 확정되었다고 100% 확정지을 수 없다.또 아예 의도적으로 네트워크의 일부 참가자들이 하드포크(hard fork)를 일으킬 수도 있다. 그러면 네트워크는 두 개로 분리된다. | ||
+ | |||
+ | 블록이 생성되는 즉시 확정되는 것을 완료성이라고 한다. 완료성이 중요한 이유는 역시나 제조권에 도입되기 위해서이다. 완려성은 주식시장, 은행업무 등 복잡하고 규제가 많은 금융 산업에 반드시 필요하다. 어떤한 답이 일시적이라고 하더라도 복수가 존재할 수 있다는 사실은 시스템에 심각한 오류나 실수를 일으킬 수 있기 때문이다. 따라서 기업과 정부 기관의 입장에서는 결정성을 보장하지 않는 이더리움보다 결정성을 가진 네오를 선호할 가능성이 더 높다. | ||
+ | |||
+ | 다만 위임 프랙티컬 비잔틴 장애 허용에서는 권력이 특정 노드들에게 집중된다는 문제점이 있다. 수십 개 정도의 노드들이 전체를 대표하는 권한을 가지면 의사결정은 빨라진다. 하지만 담합을 통해 자신들 마음대로 잘못된 거래를 인증할 가능성도 생긴다. 위임 프랙티컬 비잔틴 장애 허용 방식은 속도와 완료성이라는 큰 장점을 가지고 있지만 여전히 검증 노드에 대한 어느정도의 신뢰를 필요로 한다는 한계 또한 내포하고 있다. | ||
== 사용 == | == 사용 == |
2019년 4월 10일 (수) 10:50 판
위임 프랙티컬 비잔틴 장애 허용(dPBFT; delegated PBFT; delegated Practical Byzantine Fault Tolerance)은 기존의 프랙티컬 비잔틴 장애 허용(PBFT) 알고리즘에 북키퍼(bookkeeper) 개념을 추가한 합의 알고리즘이다. 간략히 위임 비잔틴 장애 허용(DBFT; Delegated Byzantine Fault Tolerance)이라고 한다. 중국의 이더리움으로 불리는 네오(NEO)가 이 방식을 사용하고 있다.
장점
위임 프랙티컬 비잔틴 장애 허용의 장점은 속도와 완료성이다. 네트워크에 참여하는 수많은 사람들이 다 검증에 참여하는 것이 아니라, 소수의 대표들끼리 합의를 통해 결정하기 때문에 블록 생성 과정이 훨씬 단순해지고 빨라진다. 현재 네오의 초당 거래 처리량은 평균 1000 TPS이다. 이더리움이 평균 15 TPS임을 볼 때 속도에 있어서는 큰 우위를 가진다.
또한 포크(fork)가 일어나지 않는다. 포크란 네트워크의 노드들이 의견이 일치하지 않을 때 블록체인이 여러 개로 갈라지는 현상을 말한다. 작업증명이나 지분증명 방식에서는 일시적으로 진본이 두 개 이상일 때가 있다. 이 경우에 동시에 서로 다른 유효한 블록이 생길 수 있다. 하지만 결국에는 가장 긴 체인이 진본으로 인정된다. 이런 일시적인 포크는 금방 사라지기는 하지만 거래가 블록체인에 연결되더라도 일정 시간이 지나기 전까지 그 거래가 확정되었다고 100% 확정지을 수 없다.또 아예 의도적으로 네트워크의 일부 참가자들이 하드포크(hard fork)를 일으킬 수도 있다. 그러면 네트워크는 두 개로 분리된다.
블록이 생성되는 즉시 확정되는 것을 완료성이라고 한다. 완료성이 중요한 이유는 역시나 제조권에 도입되기 위해서이다. 완려성은 주식시장, 은행업무 등 복잡하고 규제가 많은 금융 산업에 반드시 필요하다. 어떤한 답이 일시적이라고 하더라도 복수가 존재할 수 있다는 사실은 시스템에 심각한 오류나 실수를 일으킬 수 있기 때문이다. 따라서 기업과 정부 기관의 입장에서는 결정성을 보장하지 않는 이더리움보다 결정성을 가진 네오를 선호할 가능성이 더 높다.
다만 위임 프랙티컬 비잔틴 장애 허용에서는 권력이 특정 노드들에게 집중된다는 문제점이 있다. 수십 개 정도의 노드들이 전체를 대표하는 권한을 가지면 의사결정은 빨라진다. 하지만 담합을 통해 자신들 마음대로 잘못된 거래를 인증할 가능성도 생긴다. 위임 프랙티컬 비잔틴 장애 허용 방식은 속도와 완료성이라는 큰 장점을 가지고 있지만 여전히 검증 노드에 대한 어느정도의 신뢰를 필요로 한다는 한계 또한 내포하고 있다.
사용
- 네오
- 네오(NEO)가 사용하는 위임 프랙티컬 비잔틴 장애 허용 합의 알고리즘은 네오 코인 소유자들로부터 위임을 받은 대리인들이 투표를 통해 합의에 대규모로 참여할 수 있게 하는 메커니즘이다. 노드를 운영하는 북키퍼의 60% 이상이 동의할 경우에만 합의가 이루어지는 방식이다. 이를 위해 먼저 네오 코인 사용자들은 투표를 통해서 대표자인 북키퍼를 선출한다. 위임 프랙티컬 비잔틴 장애 허용 방식을 통해 선출된 북키퍼들은 블록을 검증할 때마다 랜덤으로 그 중에서 다시 블록 생성자(BP)들이 결정되고, 이 중 3분의 2 이상의 북키퍼들이 검증에 동의하여 합의가 이루어지면, 새로운 블록이 생성된다.
- 위임 비잔틴 장애 허용 방식을 통해 네오는 높은 효율성과 빠른 속도라는 장점을 취할 수 있다. 투표는 특정한 시간에만 이루어지는 것이 아니라, 실시간으로 계속 진행된다. 위임 비잔틴 장애 허용 알고리즘에서는 새로운 블록을 생성하는 데 약 15~20초 정도가 소요되며, 트랜잭션 처리량은 1초에 최대 1,000건까지 가능하다. 적절한 최적화를 통해 앞으로 네오는 10,000 TPS에 도달할 수 있을 것으로 예상하고 있으며, 이를 기반으로 대규모 상업용 디앱을 지원하려고 한다.
- 위임 비잔틴 장애 허용 알고리즘은 디지털 아이디 기술과 결합되어 있기 때문에, 북키퍼는 개인 또는 기관의 실명으로 활동이 가능하다. 따라서 사법적 결정으로 인한 동결, 취소, 상속, 회수 및 소유권 이전이 가능하다. 이것은 네오 네트워크에서 컴플라이언스 금융 자산의 등록을 용이하게 한다. 즉, 네오는 디지털 아이디 등 법 규제를 준수하게끔 만드는 컴플라이언스 솔루션을 갖추고 있어, 실물 자산을 블록체인에 등록하고 거래하기 적합하다.[1] 네오에 대해 자세히 보기
각주
- ↑ "NEO White Paper - A distributed network for the Smart Economy", NEO Documentation
같이 보기
|