[STEP 6] Blockchain Consensus Algorithm (POS, POW, POA, DPOS, BFT, RBFT, IBFT)

Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

yundream
2022-08-06
2022-08-05
2471

## Blockchain Consensus Algorithm
경제 시스템은 거래 시스템이며 거래 시스템을 지탱하는 것은 신뢰다. 이 신뢰는 거래를 기록한 원장에 의해서 유지된다. 원장이야 말로 경제 시스템이 작동하게 하는 기반이 된다. 원장을 조작은 경제 시스템을 근본부터 무너트리는 행위이기 때문에 중대한 범죄로 다른다.

따라서 화폐를 기반으로 하는 일반적인 경제 시스템에서 원장을 만들고, 기록하고 보관하고 검토하는 일은 매우 중요하게 생각하여서 많은 시간, 인력, 돈이 투입된다. 자기가 유리한 방향으로 원장을 조작하려는 동기가 생길 가능성이 매우 매우 높기 때문이다. 또한 실수가 발생 할 수도 있다.

블록체인은 **합의(consensus)** 과정을 통해서 원장의 신뢰를 보증한다. 믿을 만한 방법을 이용해서 합의를 한 원장이니, 이 원장은 믿어도 된다. 라는 것이다. 블록체인 상에서 합의는 컴퓨터 알고리즘을 통해서 이루어지며 이를 **합의 알고리즘(Consensus Algorithm)** 이라고 한다.

- 다수의 참여자들이 통일된 의사결정을 하기 위해 사용하는 [알고리즘](http://wiki.hash.kr/index.php/%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98)을 말한다. **합의 모델**, **합의 방식**, **합의 메커니즘** 또는 **합의 프로토콜** 이라고도 한다. [블록체인](http://wiki.hash.kr/index.php/%EB%B8%94%EB%A1%9D%EC%B2%B4%EC%9D%B8) 시스템의 경우 네트워크에 참여하는 모든 참여자들이 동일한 데이터를 복사하여 분산 저장하기 때문에 원본과 사본의 구별이 없으며, 통일된 의사결정을 내릴 수 있는 권위 있는 중앙(center)이 존재하지 않는다.
- 이런 상황에서 합리적이고 효율적인 의사결정을 내릴 수 있는 다양한 알고리즘‘합의 알고리즘’은 컴퓨터 과학에서 사용하고 있는 일종의 프로세스를 일컫는 것으로 보통 시스템이 분산화 되어 있을 때 **시스템 간의 특정 데이터에 대한 동일한 값을 유지하기 위해 고안된 개념**
- why? 이는 블록체인 개념 자체와 그 이유를 같이 하고 있습니다. 블록체인은 수 많은 노드가 P2P 네트워크로 연결되어 트랜잭션을 처리하고 기록하는 ‘분산 원장 시스템’을 의미합니다. 해당 시스템 내의 모든 분산 원장에는 동일한 거래 기록 내용을 공유해야 합니다. **모든 노드가 동일한 하나의 체인을 가질 수 있도록 특정 메커니즘에 의하여 블록이 생성 및 연결되게 하는 것이다.** 합의 알고리즘은 암호 화폐 네트워크의 무결성과 보안을 유지하기 위해 중요합니다. 합의 알고리즘은 분산화된 노드들이 어떤 버전의 블록체인이 진짜 버전인지 합의할 수 있게 합니다. 디지털 경제 시스템이 제대로 작동하기 위해서는, 현 상태의 블록체인에 합의하는 것이 필수이다.

블록체인은 목적에 따라서 다양한 합의 알고리즘이 존재한다. 주요 합의 알고리즘들을 살펴보자.
<br>

### POW
- 목표값 이하의 해시를 찾는 과정을 무수히 반복함으로써 해당 작업에 참여했음을 증명하는 방식의 알고리즘이다. 채굴을 통해 작업증명을 한다. 비트코인, 이더리움, 라이트코인, 비트코인캐시, 비트코인골드, 모네로, 지캐시, 시아코인, 불웍, 에이치닥 등의 암호화폐에서 작업증명 방식
'작업’이란 ‘채굴’에 이르기까지 연산 과정을 뜻한다. 채굴자들은 컴퓨터로 복잡한 수식을 풀어 조건에 맞는 **해시값을 찾는 과정을 반복**한다. **이 경우 모든 노드들이 찾아낸 해시값을 검증하고 승인하는 과정을 거쳐 블록에 거래 내역을 저장한다.** 따라서 모든 노드들의 승인을 거쳐야 하기 때문에 거래 내역을 속이기가 힘들다는 장점이 있다. 이런 점에서 작업증명 합의 알고리즘은 블록체인이 가지는 탈중앙화라는 본질을 가장 잘 살린 합의 방식이다.
- **맹점**: 그러나 이런 과정 때문에 거래 처리 속도가 늦어진다는 한계가 있다. 또한 채굴에 필요한 에너지 소비가 심하다는 것도 단점이다. 이 때문에 일정 조건에 따라 블록 생성에 참여하는 노드들을 제한하는 지분증명방식이 등장했다.

### POS
- [지분 증명](https://academy.binance.com/ko/articles/proof-of-stake-explained)이 있습니다. 지분 증명은 참여자가 코인을 동결하고(자신의 “지분”), 프로토콜이 특정 간격에 따라 다음 블록을 검증할 이를 임의로 선정하는 것입니다. 일반적으로, 선택될 확률은 코인의 비율과 관련되는데, 더 많은 코인을 동결할 수록 확률은 더 높아집니다. 이처럼 어떤 참여자가 블록을 생성할지는 작업 증명에서처럼 [해시](https://academy.binance.com/ko/articles/what-is-hashing)문제를 해결할 수 있는 능력에 기반하지 않습니다. 그 대신 얼마나 많은 스테이킹 코인을 보유하고 있는지에 따라 결정됩니다.누군가는 스테이킹을 통해 블록을 생성하면 더 높은 수준의 블록체인 [확장성](https://academy.binance.com/ko/articles/blockchain-scalability-sidechains-and-payment-channels)이 가능하다고 주장할 수도 있습니다. 이는 [이더리움](https://academy.binance.com/ko/articles/what-is-ethereum) 네트워크가 [ETH 2.0](https://academy.binance.com/ko/articles/what-is-ethereum#scalability-eth-2-0-and-the-future-of-ethereum)이라 하는 일련의 종합적 기술 업그레이드를 통해 [작업 증명](https://academy.binance.com/ko/articles/proof-of-work-explained)에서 [지분 증명](https://academy.binance.com/ko/articles/proof-of-stake-explained)으로 옮겨 가려는 이유 중 하나입니다.
- 스테이킹은 지분증명(PoS) 알고리즘을 사용하는 블록체인 네트워크에서 구현이 가능하다. 대표적으로 이오스(EOS)·테조스(XYZ)·코스모스(ATOM) 등이 거론된다. **스테이킹은 PoS 알고리즘을 사용하는 가상화폐를 소유한 이가 일정량의 화폐를 예치하면서 시작되며, 이때 예치자는 자신이 기여한 가상화폐의 지분율에 비례해 의사 결정 권한**을 가지게 된다. 이 과정에서 블록체인 네트워크 운영에도 참여하게 된다. 네트워크 운영자는 투자자들의 가상화폐를 활용해 시스템을 운영하게 되고, 이후 추가로 얻어진 가상화폐 수익을 투자자들에게 배분한다.
    
    투자자는 24시간 동안 자신의 컴퓨터에 노드를 운영해 블록 생성을 검증해야 하는데, 이러한 번거로움 때문에 스테이킹은 가상화폐 거래소나 지갑 업체가 대행하는 경우가 많다.
    
- **맹점**: 지분증명 방식은 모든 노드들의 **승인을 거치지 않아도 되니 작업증명 방식보다 거래 처리 속도가 빠르다. 이는 곧 전력소비를 줄일 수 있음**을 의미한다. 이 때문에 이더리움 재단은 기존 합의 방식인 작업증명 방식을 지분증명 방식으로 전환하기 위한 ‘캐스퍼(Casper)’ 프로젝트를 진행 중에 있다. 그러나 지분증명 방식은 **‘평등’을 추구하는 블록체인의 본질에서 벗어나 ‘부익부 빈익빈’을 초래한다는 꼬리표가** 따라다닌다. 많은 코인을 가지고 있을수록 더 많은 보상을 받는 구조이기 때문이다.
- example
    - 블록체인 네트워크 운영자 입장에서는 스테이킹 활동을 통해 시장에 풀린 유동성을 일부 동결함으로써 시세를 용이하게 조정할 수 있다는 장점이 있다. 투자자 또한 스테이킹을 통해 추가 보상을 얻을 수 있다. 다만 일정 지분량을 고정한다는 부담은 투자자가 고려해야 할 지점이다.
    - [이오스](http://wiki.hash.kr/index.php/%EC%9D%B4%EC%98%A4%EC%8A%A4)(EOS)는 다른 코인들과 다르게 독특한 '스테이킹'(staking)과 '[언스테이킹](http://wiki.hash.kr/index.php/%EC%96%B8%EC%8A%A4%ED%85%8C%EC%9D%B4%ED%82%B9) '(unstaking)이라는 개념을 가지고 있다. 언스테이킹은 기본상태라고도 하며 [이오스](http://wiki.hash.kr/index.php/%EC%9D%B4%EC%98%A4%EC%8A%A4)
    (EOS)가 [유동성](http://wiki.hash.kr/index.php/%EC%9C%A0%EB%8F%99%EC%84%B1)을 가지고 있는 상태로 이오스 코인 전송 및 거래가 가능한 상태이다. 스테이킹 상태는 락업 상태라고 하며, 이오스가 유동성을 가지고 있지 않은 상태로, 이오스 코인 전송 및 거래가 불가능하다. 그러나 이오스가 스테이킹된 만큼의 [중앙처리장치](http://wiki.hash.kr/index.php/%EC%A4%91%EC%95%99%EC%B2%98%EB%A6%AC%EC%9E%A5%EC%B9%98)(CPU)와 네트워크 자원을 활용할 수 있고, 1 EOS 당 30개의 [블록생성자](http://wiki.hash.kr/index.php/%EB%B8%94%EB%A1%9D%EC%83%9D%EC%84%B1%EC%9E%90) (BP)에게 투표가 가능하다.[[1]](http://wiki.hash.kr/index.php/%EC%8A%A4%ED%85%8C%EC%9D%B4%ED%82%B9#cite_note-.EC.8A.A4.ED.85.8C.EC.9D.B4.ED.82.B91-1)
- reference
    - [https://news.einfomax.co.kr/news/articleView.html?idxno=4164309](https://news.einfomax.co.kr/news/articleView.html?idxno=4164309)
    - [http://wiki.hash.kr/index.php/스테이킹](http://wiki.hash.kr/index.php/%EC%8A%A4%ED%85%8C%EC%9D%B4%ED%82%B9)

### POA
- 권위증명(PoA, Proof of Authority) 방식은 권위 있는 기관에서 조건에 맞는 노드를 증명해 이들 간 합의를 이루는 방식이다. 두나무 블록체인 서비스(DBS)는 권위증명 방식을 사용한다. 권위증명에서는 블록체인에 참여한 멤버 전원에게 네트워크 운영에 참여할 권리를 주고 전원이 해당 권한 위임에 투표를 진행한다. 참여자들이 다른 참여자의 권한 위임에 투표함으로써 모든 멤버가 지속적으로 합의 알고리즘에 참여할 수 있다. 네트워크 관리자는 순차적이고 투명한 투표 진행으로 네트워크에 대한 권한을 바꿔주기만 하면 된다.

### DPOS
- 
    - 암호화폐 소유자들이 각자의 지분율에 비례하여 투표권을 행사하여 자신의 대표자를 선정하고, 이 대표자들끼리 합의하여 의사결정을 내리는 방식이다. 국민의 대표로 의원을 뽑아 의회를 구성하는 대의 민주주의 제도와 유사하다. 이오스, 스팀, 리스크, 엘프, 라이즈, 아크, 비트셰어, 시프트, 보스코인 등이 위임지분증명 방식을 채택
    **맹점:**  소수의 대표 노드들에게만 거래 내역 승인을 거치면 되니 처리 속도는 훨씬 빨라진다. 이더리움은 평균적으로 초당 20TPS를 처리하는 반면 이오스는 3000TPS를 처리할 수 있어 속도 면에서의 장점은 이미 검증되었다. 그러나 2018년 9월, 이오스 블록 생성을 담당하는 대표 노드 가운데 일부가 블록생성자가 자격을 유지하기 위해 서로에게 투표했다는 의혹이 제기되었다. 이에 따라 위임지분증명 방식에 치명적인 결함이 있다는 사실이 알려졌다. 이처럼 위임지분증명 방식은 일반 노드들의 투표율이 저조할 경우 소수의 대표 노드들에 의해 블록체인 생태계가 좌지우지 될 수 있다는 한계
- example
    - K Stadium SO Proposal and Voting

### Reference

1. [https://blog.naver.com/smbo112/222229158374](https://blog.naver.com/smbo112/222229158374)
2. [https://academy.binance.com/ko/articles/what-is-staking](https://academy.binance.com/ko/articles/what-is-staking) ***
3. [https://academy.binance.com/ko/articles/what-is-a-blockchain-consensus-algorithm](https://academy.binance.com/ko/articles/what-is-a-blockchain-consensus-algorithm) ***
4. 명목 화폐 vs 암호 화폐: [https://academy.binance.com/ko/articles/what-is-fiat-currency](https://academy.binance.com/ko/articles/what-is-fiat-currency)
5. [https://steemit.com/kr/@kblock/44-1-pow-pos](https://steemit.com/kr/@kblock/44-1-pow-pos)***

<br>
## 비잔티움 문제
합의를 이용해서 원장이 올바른지를 확인하고 블록체인에 저장하겠다는 것은 이해할 수 있다. 하지만 합의 주체를 어떻게 신뢰 할 수 있느냐 하는 문제가 있다. 이 문제는 **비잔티움 문제**라고 알려져 있다.

비잔티움 문제 혹은 비잔티움 에러라고도 한다. 한 체계 내에서 연결된 다양한 시스템들이 그 중 일부가 에러 코드, 혹은 잘못된 명령을 수행하는 상황에서 어떻게 시스템들의 기능을 정상으로 유지시키고 체계를 정상작동 시킬 수 있는지 고민하는 일종의 사고 실험이다. 레슬리 램포트와 쇼스탁 파스가 공저한 1982년 논문에 처음 언급됐다.

[비잔티움 제국](https://namu.wiki/w/%EB%B9%84%EC%9E%94%ED%8B%B0%EC%9B%80%20%EC%A0%9C%EA%B5%AD) 의 장군들이 적의 수중에 있는 도시를 포위하려 한다. 전투 준비를 마친 각 장군들은 제국군의 대부분이 한꺼번에 도시를 공성해야지만 이 도시를 함락시킬수 있음을 알고 있다.

그러나 비잔티움의 장군들은 자신들 중 몇몇이 이미 적과 내통하고 있음과 서로에게 연락할 전령들이 도시에서 나온 척후대에게 사로잡힐 수 있음을 이미 알고 있다.

어떤 장군이 황제에게 충성스러운지, 혹은 모반을 하려는지 확실하지 못한 상황에서 충성스러운 장군들은 배신자들이 병력을 물려 공성을 방해하거나 적에게 소식을 넘길수 있다는 상황 때문에 딜레마에 빠진다.

충직한 장군들은 전령들이 보낸 명령을 충실하게 따르며 이 외의 행동은 하지 않는다. 그러나 전체 장군 중 일부인 배신자 장군들은 전령에 얽매이지 않고 마음대로 행동할 수 있다. 이 때 배신자의 존재에도 불구하고 충직한 장군들이 동일한 공격 계획을 세우기 위해서는 충직한 장군들의 수가 얼마나 있어야 하며, 장군들이 어떤 규칙을 따라 교신해야 하는지에 대한 문제가 바로 **비잔티움 장군 문제**다.

![image](https://docs.google.com/drawings/d/e/2PACX-1vS1mUAnMuSkLXjNssUsmCRGx4TUz5QY7K-Sr5iJ8lfUuwIzy8123oA_aHPOsy0FXobDbEbS2y25VzYs/pub?w=1336&h=940)

앞서 소개한 각 합의 알고리즘은 비잔티움 문제를 해결하기 위한 고유의 방법을 제시하고 있다.

**문제 >** 서로 신뢰할 수 없는데 어떻게 공격 시각을 합의 할 수 있는가 ?

- 가정 1 - 모두 한번에 공격할 수 있는 **합의된 시각**에 공격하면 된다.
- 가정 2 - 배신자는 병력을 분산시키려 하므로 이전 장군의 메시지와 다른 시각을 제시한다.
- 가정 3 - 각 장군은 자신의 바로 다음 장군에게만 연락할 수 있다.
- 가정 4 - 배신자도 지정한 시간에 공격에 가담한다.

문제가 생기는 상황

- @장군1이 “9 AM” 공격시각을 적어 서명과 함께 @장군2에게 보냄
- @장군2는 @장군1의 “9 AM” 공격시각을 보고 확인 한 후 @장군3 에게 전달
- 배신자인 @장군3 은 “9 AM” 메시지를 폐기하고 “8 AM”으로 고쳐서 @장군 4에게 전달
- @장군4는 “8 AM”으로 @장군5에게 전달
- 8AM에 @장군3, @장군4, @장군5가 쳐들어가지면 공략 병력 부족으로 패배.

### PoW

**규칙**

1. 장군은 메시지를 보내기 위해서 반드시 특정한 작업을 해야 함.
2. 메시지는 모든 장군의 메시지와 특정한 작업을(10분 동안 작업) 했다는 증거를 포함해야 한다.

**시나리오**

- @장군1 이 "9 AM" 공격시각을 적어 10분간 작업하여 증거와 함께 @장군2 에게 보냄
- @장군2 는 "9 AM" 메시지와 @장군1 의 10분 작업 증거를 보고 확신 후, @장군3 에게 "9 AM" 메시지 보냄
    1. @장군2 도 10분 간 작업 함
    2. @장군1, @장군2 의 메시지와 작업내용 모두를 포함하여 보냄
- @장군3 은 배신자로 "8AM" 으로 메시지를 수정하여 보내고 싶으나 그냥 보낼 수 없음. 아래 중 택 1 해야 함.
    1. 속일 수 있는 유일한 방법
        1. @장군3 은 10분보다 빠르게 작업을 하여 "8 AM" 메시지를 만들어 냄
        2. @장군1, @장군2 의 총 20분 작업에 해당하는 메시지 모두를 남은 시간 내에 만들어 포함 시켜 보냄
    2. 안들키고 있으려면 "9 AM" 으로 보내기
- @장군4, @장군5 모두 동일

**의미**

- 만약 @장군3 이 "8AM" 으로 보냈다면, 모두 장군 3이 거짓임을 알게 됨
- 만약 @장군2 가 배신자였다면 @장군2,3,4,5 모두 9AM 공격 가므로 이기게 됨
- 만약 @장군1 이 배신자였다면 8AM 에 모두 함께 공격 가므로 이기게 됨

### BFT
    
 장애는 반드시 발생한다. 따라서 장애를 발생하지 않도록 하는 것은 의미가 없어서, 장애에 대한 내성을 가지는 방향으로 시스템이 진화했다. 현대적인 시스템은 “분산 시스템”을 그 방향으로 하고 있다.
    
 BFT(Byzantine Fault Tolerance - 비잔틴 장애 허용)은 분산 시스템에서, 시스템을 구성하는 노드에 장애가 생기더라도 **전체 노드의 3분의 1을 넘지 않는다면, 시스템이 정상 작동하도록 허용하는 합의 알고리즘**이다.
    
 가장 단순한 형태로 많은 장군들로 이루어진 군단이 요새를 공격하고 있다고 가정해보자. 이 군단은 요새를 계속 공격할지 후퇴할지를 결정해야 한다. 중요한 것은 모든 장군이 공통의 결정에 동의 해야 한다는 것이다. 소수 장군의 자의적인 공격은 패망으로 이루어질 것이다. 왜냐하면 모두가 함께 퇴각하거나 공격하는 것보다 더 나쁠 것이기 때문이다.
    
 이 문제는 충성스러운 (결함이 없는) 장군이 전략에 대해서 과반수 동의를 한다면 “내결함성”을 달성 하는 것으로 해결 할 수 있을 것이다.

![image](https://docs.google.com/drawings/d/e/2PACX-1vRbZYBBg3erRljAwSOtzeukbOLD3rJmlN4-g9lC8bIN1nvhFdGDCGMEW4SOWjCyGY1_hUdm2jICyLsy/pub?w=1854&h=928)

### BFT와 컴퓨터 네트워크

분산 컴퓨터 네트워크에서 BFT 시스템의 구성요소는 아래와 같다.

1. 컴퓨터 노드 : 비잔틴 장군
2. 네트워크 : 투표를 위한 메시지 전달 수단.

충분한 수의 컴퓨터 노드들이 참여하고 있고, 이들이 서로의 상태를 모니터링 할 수 있다면

1. 분산 시스템을 구성하는 전체 노드를 알 수 있다.
2. 몇 개 노드에 문제가 생겼는지 알수 있다.
3. 3/2 이상의 노드에 장애가 발생하지 않았다면, 일부 노드의 결함에 저항하여 결정을 내릴 수 있다.

### BFT 구현 알고리즘

BFT는 신뢰 할 수 없는 구성요소로 이루어진 네트워크를 신뢰할 수 있는 네트워크로 만들기 위한 합의알고리즘이다.

신뢰할 수 없는 집단을 신뢰 할 수 있는 집단으로 만들기 위해서는 “비용”이 들어가는데, 이 비용은 “신뢰”와 Tradeoff 관계다. 서로가 서로를 시뢰하기 힘들 수록 서로를 확인하는데 많은 시간과 커뮤니케이션(메시지 교환)이 발생하기 때문이다.

1. 신뢰도가 높을 수록 적은 비용이 들어간다.
2. 신뢰도가 낮을 수록 높은 비용이 들어간다.

실 세계에는 다양한 신뢰 관계를 가지는 네트워크가 있다.

1. 익명의 인터넷 : 상대방을 전혀 신뢰 할 수 없다.
2. 은행간 연합 : 데이터 훼손, 데이터 변조와 같은 불안 요소가 있으나 익명의 인터넷에 비해서는 신뢰 할 만 하다.
3. 의료 정보 교환 시스템 : 약국, 병원, 보험사, 피보험자가 참여하는 네트워크는 익명의 인터넷 보다는 신뢰할만 하지만, 은행간 연합 보다는 신뢰성이 떨어진다.

따라서 네트워크 성향에 따라서 성능을 우선하거나 신뢰를 우선하는 식으로 BFT를 구현 할 수 있다.
<br>
### PBFT (Practical Byzantine Fault Tolerance)
![image](https://docs.google.com/drawings/d/e/2PACX-1vTZWqfGPhio_2G4KE0qzbJIspvIR53RWa4tyXP9ZUTXNHziCr_EhT9QLmuv1IxjY5j7jr0cXm6kLKhW/pub?w=1040&h=502)

1. Pre-prepare 단계에서 트랜잭션을 모두 공유 한다.
    1. 이 단계에서 primary peer 가 선택된다. Round robin이 될 수도 있고, 다른 방법이 사용될 수도 있다.
2. Prepare 단계에서 각 peer들이 트랜잭션을 받았다는 것을 알린다.
3. Commit 단계에서 각 peer들은 트랜잭션에 “합의”했다는 것을 동료 peer들에게 알린다.

2/3 이상이 합의하면 통과이고, 2n^2 번의 커뮤니케이션이 필요하다. Peer 숫자가 늘어날 수록 기하급수적으로 늘어난다. 이 BFT는 이론적인 알고리즘으로 성능적인 이슈가 있을 수 있으므로, 네트워크의 규모와 성격에 따라서 다양한 응용이 만들어진다.

### RBFT (Redundant Byzantine Fault Tolerance)
![image](https://docs.google.com/drawings/d/e/2PACX-1vRgQLNh4lV503Rh8URVo48aBFxELqS1dC2i_hKTdZ5ujsHShT5kfGvI2w0gsReHWnVPvVgTGZSXypdq/pub?w=812&h=425)
PBFT는 커뮤니케이션 비용이 너무 커서, “Endorsing - Ording - Validation”로 구성된 합의 알고리즘을 만든다.

1. Client가 모든 endorsing peer에게 transaction을 전달 한다.
2. Endorsing peer가 transaction을 처리하고 결과값에 signing하여 Client에 되돌려준다.
3. Client는 이 값을 orderer 에게 전달한다.
4. orderer는 트랜잭션을 소팅하고 블록으로 완성 후 Validator에게 전달한다.
5. Validator는 signing 결과를 확인하고, 문제가 없으면 블록을 생성한다.

![image](https://docs.google.com/drawings/d/e/2PACX-1vSpWIGj0HhJrRD6SwlCpYNLyx2TfmFpmUNJVtoovEjFoXZkFfhZvLZG839QMYqKWvcb0PCkqO34iRZv/pub?w=733&h=368)

### IBFT(Istanbul Byzantine Fault Tolerance) 1.0

합의알고리즘은 성능과 보안과의 Trade Off 이다. 블록체인의 성능은 일반적으로 트랜잭션 처리량으로 측정된다. PoW를 사용하는 이더리움 메인넷은 보안은 뛰어나지만 성능은 낮다. 반면 PoA(Proof of Authority) 알고리즘을 사용하는 컨소시엄 블록체인 솔류션은 보안을 거의 제공하지 않는 대신 고성능을 제공한다.

- PoA
    
    권위증명(**PoA**, Proof of Authority)이란 권위있는 기관에서 조건에 맞는 노드를 증명해 이들간 합의를 이루는 방식의 합의 **알고리즘** 이다. 포아라고도 읽는다. 두나무 블록체인 서비스(DBS) 플랫폼인 루니버스는 권위증명(**PoA**) 방식을 사용한다.

IBFT의 핵심 동인은 즉각적인 finality를 보장하는 것이다. Finality란, 일단 트랜잭션이 블록체인에 추가된 블록에 포함되면, 항상 블록체인의 일부가 된다는 것을 의미한다. 즉, 포크 또는 체인 재구성이 없다. 악의적인 행위자가 블록체인을 포크할 수 있다면 더 이상 안전하지 않게 된다.

블록체인 합의 알고리즘이 보장해야하는 속성은 2가지다.

- safety : 나쁜일이 일어나지 않을 것이다. 측 트랜잭션을 처리하는 노드는 안전한 노드일 것이라는 것을 보증한다.
- liveness : IBFT가 포함된 모든 합의 알고리즘에 적용될 때, 이는 네트워크에 참여한 모든 트랜잭션이 결국 모든 참여 노드의 블록 체인에 추가됨을 의미한다.

![image](https://docs.google.com/drawings/d/e/2PACX-1vQ4xmGiJmZhXX8udxIId2QeWCIR_q6b91dEya-fPR_jJjVtycZRZm4fr0EZpjVFfdzBpngsewe4FuKA/pub?w=786&h=580)

1. 특정상황에 “비잔틴 제안자”가 있다.
2. 비잔틴 제안자는 두 세트의 “검증자”와 합의에 도달하면 트랜잭션 검증이 완료된 것으로 간주한다.

### IBFT 2.0

- IBFT 2.0에서는 비잔틴 결함 허용을 위해서 4개의 validator가 필요하다.
- Validator의 수가 증가하면 성능이 저하될 수 있다. 성능손실 없는 Validator는 최대 30개이다.
- Round 개념이 추가됐다. 이에 따라서 병렬로 transaction을 처리 할 수 있다.
- HyperLedger besu가 사용하고 있는 합의 알고리즘이다.
    - GroundChain 팀에서 테스트하고 있는게 이 부분.

### Reference @shawn.yoon

- [http://wiki.hash.kr/index.php/비잔틴_장애_허용](http://wiki.hash.kr/index.php/%EB%B9%84%EC%9E%94%ED%8B%B4_%EC%9E%A5%EC%95%A0_%ED%97%88%EC%9A%A9)
- [https://namu.wiki/w/비잔티움 장군 문제](https://namu.wiki/w/%EB%B9%84%EC%9E%94%ED%8B%B0%EC%9B%80%20%EC%9E%A5%EA%B5%B0%20%EB%AC%B8%EC%A0%9C)
- [https://goodjoon.tistory.com/256](https://goodjoon.tistory.com/256)
- [https://blog.naver.com/PostView.nhn?isHttpsRedirect=true&blogId=pcmola&logNo=222090486807&categoryNo=50&parentCategoryNo=0&viewDate=&currentPage=1&postListTopCurrentPage=1&from=postView](https://blog.naver.com/PostView.nhn?isHttpsRedirect=true&blogId=pcmola&logNo=222090486807&categoryNo=50&parentCategoryNo=0&viewDate=&currentPage=1&postListTopCurrentPage=1&from=postView)
- [IBFT 2.0](https://blog.naver.com/PostView.nhn?isHttpsRedirect=true&blogId=pcmola&logNo=222090486807&categoryNo=50&parentCategoryNo=0&viewDate=&currentPage=1&postListTopCurrentPage=1&from=postView)
- [http://wiki.hash.kr/index.php/프랙티컬_비잔틴_장애_허용](http://wiki.hash.kr/index.php/%ED%94%84%EB%9E%99%ED%8B%B0%EC%BB%AC_%EB%B9%84%EC%9E%94%ED%8B%B4_%EC%9E%A5%EC%95%A0_%ED%97%88%EC%9A%A9)
- [RBFT](https://joey-yoonsung.github.io/kr/blockchain/2018/06/06/RBFT-analysis.html)

Search For:

BY TAGS

Recent Posts

Archive Posts

Tags

About

Get in Touch

Categories