3.블록체인 합의 알고리즘 (PBFT)

PBFT(Practical Byzantine Fault Tolerance)

블록체인에는 PoW, PoS 등 많은 합의 알고리즘들이 존재한다. 비트코인의 자격증명과 이더리움의 자산증명 방식이 대표적인 예이다. 하지만 이 블로그에서 다룰 블록체인 기술은 주로 Hyperledger Fabric 이기에 PBFT에서만 다루도록 하겠다. 

PBFT는 PoW나 PoS와 마찬가지로 Byzantine Fault 모델이지만 PoW와 PoS의 단점인 파이널리티의 불확실성과 성능 문제를 해결한 것이다. 

Hyper ledger Fabric은 다수결로 의사결정을 한 후 블록이 생성되기 때문에 분기가 발생하지 않는다. -> 한번 확정된 블록은 바뀌지 않는다. (Finality 보장)

파이널리티(완결성)

블록체인의 특징중 하나는 Finality라는 것인데 이는 거래는 절대 되돌려질 수 없고 수정될 수 없다는 것이다.

여러 블록체인들에서 걸리는 평균 완결성 시간

암호화폐를 상용화하기 위해 가장 중요한 것은 거래를 결제할 때 걸리는 속도입니다. 그러므로 완결성은 상용화에도 중요한 역할을 합니다. 완결성은 어느정도의 시간을 기다려야 블록체인에 거래내역이 비가역적인 상태가 됩니다. 하지만, 아무도 1시간이나 기다려 블록이 추가될때까지 기다릴 사용자는 없을 것입니다. 그러므로 완결성은 보안의 문제뿐만 아니라 암호화폐를 실제 사용하기 위해서 그만큼 중요한 역할을 하게 됩니다.

• Safety(Finality) & Liveness 관점
• POW
• 문제를 더 빨리 풀 경우 그 체인을 유효한 체인으로 판단한다.
• 즉, 지금 체인보다 더 긴 체인을 만들 수 있을 만한 파워를 가지면 기존의 합의된 블록을 언제든지 바꿀 수 있다 -> Finality가 보장되지 않는다. (Liveness를 위해 Safety를 포기)
• POS
• 서로 합의하는 과정이 있고, 일정 수 이상의 동의가 필요하다.

• 전송한 메시지가 시간 안에 도달하는 것을 보장하지 못 하는 비동기 네트워크에서는 합의가 이루어지지 않아 블록이 생성되지 않을 수 있다.

 

비잔틴 장군 문제의 상황

n개의 비잔틴 부대가 적의 도시를 포위하고 있고, 각 부대는 부대마다 배치된 장군의 명령에 따릅니다. 한명의 장군은 나머지 n-1명의 장군과 통신할 때 각각의 장군에게 전령을 보내는 것으로만 통신 할 수 있습니다.

장군들은 지금 총 공격을 할 지, 조금 더 기다릴 지 합의하여야 합니다. 그러나 장군들 중 배신자가 있을 수 있고, 배신자들은 근거없이 아무 의견이나 제시 할 수 있습니다. 배신한 장군들의 방해를 뚫고 공격 여부를 합의할 방법(알고리즘)이 필요하게 됩니다.

처리 절차

https://steemkr.com/blockchain/@frontalnh/opensource-blockchain-engine-it-chain-01-peer-to-peer-network

우선 클라이언트가 모든 노드에 요청을 브로드캐스트 합니다. Leader가 primary(리더)가 되고 순차적으로 명령을 다른 노드에 전달합니다. 각 노드는 브로드캐스트 된 명령을 받게 되면 Leader를 포함한 모든 노드에 회신을 합니다. 각 노드는 전달된 명령을 일정 수 이상 (2n) 이상 수신하면 Leader를 포함한 모든 노드에 수신한 신호를 재 전송합니다. 각 노드는 수신된 명령을 일정 수 이상(2n)수신하면 명령을 실행하고 블록을 등록해 client에 replay된 메세지를 반환합니다.

PoW나 PoS와는 달리 다수결로 의사결정한 뒤 블록을 만들기 때문에 블록체인의 분기가 발생하지 않습니다. 따라서 한 번 확정된 블록은 변경되지 않기 때문에 파이널리티를 확보할 수 있습니다. 또한 PoW와 같이 조건을 만족시킬 때까지 계산을 반복하지 않아도 되기 때문에 매우 고속으로 동작합니다.

부정 사용을 하고자 해도 과반수를 획득해야 하며 만약 프라이버리가 거짓말을 한다 해도 모든 참가자가 리더의 움직임을 감시해 거짓말이라고 판단한다면 다수결로 리더 교체를 신청할 수 있기 때문에 장애에 매우 강력한 내성을 지닌 알고리즘입니다.

반면 언제나 참가자 전원과 의사소통을 해야 하기 때문에 참가자가 증가하면 통신량이 증가하고 처리량이 저하됩니다. PoW나 PoS는 수천개의 노드를 만들 수 있지만 PBFT는 수십개의 노드가 한계입니다.

 

Hyperledger Fabric의 트랜잭션 사이클: Execute-Order-Validate

출처: https://www.ibm.com/blogs/research/2018/02/architecture-hyperledger-fabric/

이 부분은 단연 Hyperledger fabric 을 다른 블록체인 플랫폼과 구분짓는 차별 포인트입니다. 다른 플랫폼에서는 Order-Execute 처리만 하나의 트랜잭션으로 처리합니다. 그 과정에서 발생할 수 있는 Non-determinism의 문제 — 하나 이상의 값을 리턴하여 값의 신뢰성을 저하시키는 문제 — 는 Solidity와 같은 도메인 특수 언어를 별도로 사용함으로써 해결하고, 소위 합의 알고리즘이 이 트랜잭션에 적용이 되는 겁니다.

이에 반해 Hyperledger fabric 에서는 몇몇 노드들이 먼저 실행하고 결과값을 검증하는 단계, 모든 노드에게 적용하는 단계를 분리하여 처리합니다. Execute 단계에서는 일단 피어들이 실행하고 결과값을 서로 비교하는 작업을 하는 겁니다. 그리고 Order 단계에서 그 순서를 정렬하여 모든 피어에게 전송하죠. 마지막으로 각 피어에서 순서대로 요청 온 내용을 적용하고 Validate 합니다. 이 마지막 단계에서 마침내 원장에 업데이트가 이루어지는 거죠. 이 Execute-Order-Validate 이라는 단계 자체가 합의인 것입니다. 그렇지만 정확히 말하면 우리가 생각하는 블록체인 합의 알고리즘과는 약간 다릅니다. HLF의 합의 알고리즘이라 종종 불리우는 Kafka는 사실 Order 단계에만 사용되기 때문에 정확한 표현이라 할 수 없습니다.

달리 표현해보자면 HLF는 합의가 2중으로 일어나는 구조입니다. Execute, Validate 단계에서는 네트워크에서 정의하고 있는 Endorsement Policy에 따라서 자체적인 Endorse 과정을 거칩니다. 알고리즘으로 수행되는 게 아니라 네트워크에 정의한 ‘정책’에 따라서 합의 여부가 결정되는 겁니다. 그리고 중간의 Order 단계에서, 해당 네트워크에서 지정된 Orderer들이 Kafka 방식으로, 제출된 트랜잭션을 정렬하고 Orderer 간의 합의가 이루어지게 되는거죠.

메시징 시스템인 Kafka를 왜?

출처: https://blog.cloudera.com/blog/2014/09/apache-kafka-for-beginners/

Kafka는 엄밀히 말하면 블록체인 합의 알고리즘이 아닙니다. 그래서 접하기 어렵습니다. Kafka는 Linkedin에서 개발한 분산 메시징 시스템으로, 실시간 대용량 로그 처리에 특화되어 있습니다. 그래서 다른 합의 알고리즘들이 BFT — 전달되는 내용에 대한 검증을 하는 — 인 반면, Kafka는 CFT (Crash Fault Tolerance) 입니다. 순서만 정확히 쌓이도록 해주는 겁니다.

그렇다면 HLF를 과연 진정한 ‘합의’를 기반으로 한 블록체인이라고 할 수 있는 걸까요? 개인적으로 Kafka를 차용한 것은, HLF의 성능 향상을 위한 아키텍처적 고민에서 비롯되었다고 생각합니다. 최초 0.x Hyperledger fabric에서는 PBFT 를 기본으로 장착하고 있었죠. 그렇지만 지속적으로 성능(TPS)에 대한 비판이 제기되었고, Hyperledger fabric개발진들은 이에 대한 대책을 마련해야 했을 겁니다. 여전히 강력하지만 효율적인 합의 방식을 찾게 된 거죠. Kafka는 pub-sub 구조 내에서 빠르게 메시지를 pull 방식으로 전달하여 수신 피어 측의 부담을 최소화하고 속도를 향상시킬 수 있다는 점에서 매력적인 솔루션이었습니다. BFT 적 검증은 할 수 없지만 Permissioned Blockchain의 성격을 적극 활용해 CA 단에 위험을 1차 차단하고, 추가로 endorsement policy로 구멍이 없이 보완하는 방식으로 문제를 해결한 것입니다.