알기 쉽게 10가지로 정리한 블록체인 합의 알고리즘 ‘비잔틴 장애 허용’(BFT)

블록체인 기술이 인기 있는 가장 큰 이유 중 하나는 ‘신뢰성’이다. 전문가들은 블록체인을 신뢰성이 떨어지고 비용이 많이 들며 사기에도 취약한 기존 시스템의 효율성과 투명성을 개선하기 위한 방법으로 본다. 그렇다면 블록체인은 어떻게 이러한 신뢰성을 제공할 수 있을까? 답은 바로 ‘비잔틴 장애 허용'(Byzantine Fault Tolerance, BFT)에 있다. 이번 안내서에서는 비잔틴 장애 허용의 개념과 블록체인과의 연관성에 대해 알아본다.

블록체인 최신 업데이트 소식을 받고 싶으세요? 텔레그램의 비인크립토 거래 커뮤니티에 가입하면 최고의 블록체인 후기와 암호화폐 프로젝트, 코인에 대한 분석 및 정보를 얻을 수 있습니다. 또한 경험이 풍부한 트레이더와 전문가들이 여러분의 질문에 답해 드립니다. 오늘 바로 참여하세요!

비잔틴 장애 허용(BFT)이란?

비잔틴 장애 허용(BFT)은 잘못된 정보를 식별하고 거부할 수 있는 기능이 탑재된 탈중앙화 퍼미션리스(permissionless, ‘비허가형’라고도 하며 누구나 참여할 수 있다는 뜻) 시스템이다. ‘비잔틴 장군 문제’(Byzantine Generals’ Problem)를 해결하는 시스템은 대체로 비잔틴 장애 허용으로 볼 수 있다. 비잔틴 장군 문제에 대해서는 아래에서 자세하게 다룰 것이다(참고적으로 여기서 ‘비잔틴’은 동로마 제국의 비잔티움을 연상시키나 직접적인 연관성은 없다-역주)

현재는 누구나 탈중앙화된 퍼미션리스 시스템에 침입하여 잘못된 정보를 제공하여 신뢰성을 손상시킬 수 있다. 비잔틴 장애 허용이 중요한 이유는 이 때문이다.

비유로 쉽게 이해하는 ‘비잔틴 장군 문제’

‘비잔틴 장군 문제’(Byzantine Generals’ Problem)는 게임 이론의 하나로서 프로그래밍 분야에서 발생하는 시스템 장애에 대해 알기 쉽게 비유한 것이다. 전문가들은 신뢰할 수 있는 중앙 주체(사령관)에 의존하지 않고 합의에 도달하려 할 때 탈중앙화된 주체들(장군들)이 겪는 어려움을 설명하기 위해 이 비유를 사용한다. 이 게임 이론에서 제기된 문제는 1982년 컴퓨터 과학자 레슬리 램포트(Leslie Lamport), 마셜 피스(Marshall Pease), 로버트 쇼스탁(Robert Shostak)이 해결했다. 

비잔틴 장군 문제는 비잔틴 군대의 여러 부대가 그들이 포위한 도시 밖에서 서로 상당히 떨어진 위치에 진을 치고 있는 상황을 가정한다. 각 부대를 통솔하는 장군은 공격 시점과 후퇴 시점을 알아서 결정해야 한다. 각각의 부대들이 때를 맞춰 유기적으로 공격해야 전쟁에서 승리할 수 있기 때문에 장군들의 결정은 아주 중요하다. 만약 동시에 공격하지 못할 경우 패배로 끝날 확률이 높다. 

문제는 이 전장에 컨트롤타워가 없다는 것이다. 그러나 장군들끼리 (횃불이나 연기 또는 오늘날의 휴대폰처럼) 신호를 맞출 만한 안전한 통신 방법도 없다. 엉뚱한 수단을 사용했다가 아군 사이에 있는 첩자가 장군들 사이에 보내는 신호를 가로채고, 파괴하거나 조작할수도 있고, 보낸 메시지가 중간에 소실될수도 있다. 반면, 메시지가 성공적으로 전달되더라도 다음과 같은 질문이 남아있다. 이 메시지를 신뢰할 수 있을까? 혹시 장군을 속이기 위해 반역자가 전령을 납치한 후 메시지를 바꾼 것은 아닐까? 복잡하다. 그렇다면 각 부대의 장군은 어떻게 대처해야 할까.

이 딜레마를 해결하기 위해서 장군들은 다음의 4가지를 보장할 수 있는 방법을 찾아야 한다.

• 충직한 장군들은 동일한 계획에 동의하고 이를 실행할 것이다.
• 충직한 장군들은 정해진 규칙을 따를 것이다.
• 정직한 장군들은 반역자가 취하기로 한 행동에도 불구하고 합의에 도달해야 한다.
• 충직한 장군들은 반역자인 장군의 영향을 받아 잘못된 계획을 따르지 않을 것이다.

비잔틴 장애 허용과 블록체인의 연관성 

블록체인은 이 딜레마를 해결할 수 있는 신뢰할 수 있는 중앙 기관이 없는 탈중앙화 시스템이다.  블록체인의 노드(nodes) 네트워크는 앞서 설명한 게임 이론 문제의 장군에 해당된다. 노드끼리는 서로 안전하게 소통할 수 있도록 도와줄 신뢰할 수 있는 중앙 기관이 없다. 하지만 네트워크의 원활한 운영을 위해서는 합의에 도달해야 한다. 노드가 동일한 작업 과정에 동의하고 동시에 실행(적을 공격)해야 한다는 점에서 같은 딜레마 상황인 것이다. 

그러다가 2008년 10월 사토시 나카모토가 비트코인 백서를 발표하면서 비잔틴 장군 문제에 대한 해결책을 제시했다. 이 해결책은 작업 증명(Proof-of-Work, PoW) 합의 메커니즘의 형태로 제공됐다. 여기서 네트워크 구성원들은 블록이 해시로 표현된 진정한 PoW가 첨부된 경우 해당 블록의 유효성을 승인한다. 이는 블록체인 네트워크 내의 모든 노드가 합의에 도달했다는 것을 의미한다. 따라서 채굴 노드는 해당 블록을 체인에 추가할 수 있다. 블록은 비트코인 블록체인에서 거래 데이터를 저장하는 곳을 말한다.

PoW 해시는 블록을 생성하기 위해 작업이 수행되었다는 것을 증명한다. 이 작업은 비트코인 채굴자들이 전기 및 장비에 투자해 채굴 작업을 하고 블록을 생산하는 자본 형태다. 이같은 투자의 성격 때문에 네트워크에 대해 악의적으로 행동하지 않게 된다. 비용 집약적인 채굴 과정이 비트코인 블록체인을 아주 안전하고 신뢰할 수 있는 것으로 만든다는 얘기다. 

블록체인마다 각기 다른 합의 알고리즘으로 비잔틴 장군 문제를 해결한다. 예를 들어 이더리움 블록체인은 네트워크 구성원들이 (스테이킹 방식에 따라) 32 ETH를 스테이킹 시키는 방식의 지분증명(Proof-of-Stake, PoS)를 사용하여 네트워크를 방해하는 행동을 막는다. 부정직하게 행동하는 스테이커(스테이킹 보유자)의 경우 32ETH 중 최대 절반까지 손실을 볼 수 있다.

프랙티컬 비잔틴 장애 허용(pBFT)이란?

프랙티컬 비잔틴 장애 허용(practical BFT, pBFT)은 비잔틴 내결함성을 속도 및 실용성 측면에서 개선한 합의 알고리즘을 말한다. 바바라 리스코프(Barbara Liskov)와 미구엘 카스트로(Miguel Castro)가 1999년 ‘프랙티컬 비잔틴 장애 허용’이라는 제목의 학술 논문에서 pBFT를 소개했다. 

pBFT는 이전 BFT 알고리즘을 한 단계 업그레이드한 모델이다. 이 모델은 독립적인 노드 장애가 존재하며, 이 노드가 잘못된 메시지(이전 블록의 해시를 나타냄)를 전달할 수 있다고 가정한다.

프랙티컬 비잔틴 장애 허용(pBFT)의 작동 방식

pBFT에서 노드는 메시지가 특정 피어 노드에서 왔다는 것을 증명해야 한다. 이 알고리즘 규칙에 따르면 노드는 전송 중에 메시지가 변경되지 않았는지 확인해야 한다. 즉, pBFT는 악의적인 노드의 수가 네트워크의 전체 노드 수의 3분의 1 이상이 될 수 없다는 가정 하에 작동한다. 수학적으로 시스템에 노드가 많아지는 경우 결함이 있더라도 전체 노드의 3분의 1(즉, 전체의 33%)이 악의적인 시나리오로 이어질 가능성이 낮아진다. 즉, 합의의 신뢰성이 수학적으로 보장된다는 뜻이다. 

pBFT 기반 시스템에서는 한 노드가 리더 노드(기본 노드)가 되며, 나머지 노드는 보조 노드(백업 노드)다. 사실상 시스템의 모든 노드가 리더 노드가 될 수 있다. 예를 들어 리더 노드에 결함이 발생할 경우 보조 노드가 리더 노드가 된다. 리더 노드는 pBFT 합의 라운드에 따라 변경된다. 또한 대부분의 정직한 노드는 결함이 있는 기존 리더 노드를 제거하고 다음 노드로 교체하기 위해 투표할 수 있다.

pBFT 합의가 이루어지는 방식은 다음과 같다. 

• 클라이언트가 리더 노드에 요청을 보낸다. 
• 리더 노드는 메시지를 백업 노드로 전달한다.
• 모든 노드(리더 및 보조)가 클라이언트 요청을 실행한 뒤 클라이언트에게 응답한다.
• 클라이언트가 “m+1” 응답을 수신하면 요청이 성공한 것이다(여기서 m은 허용되는 결함 노드의 최대 수를 나타냄). 

하이퍼레저 패브릭(Hyperledger Fabric), 질리카(Zilliqa), 텐더민트(Tendermint) 모두 pBFT 합의 알고리즘을 사용하는 블록체인 플랫폼이다. 하이퍼레저 패브릭은 허가형 pBFT을 사용하는 반면, 질리카는 PoW와 pBFT 모두 활용한다. 텐더민트의 경우 위임 지분증명(DPoS) 및 pBFT가 사용된다. 

비잔틴 장애 유형 4가지

비잔틴 장애에는 두 가지 유형이 있다. 첫 번째 유형은 ‘페일-중지’(Fail-stop, 실패-중지라고도 함) 장애로 노드에 장애가 생겨 작동을 멈추는 것을 말한다. 두 번째는 ‘임의 노드’(arbitrary node) 장애로 다음과 같은 4가지 경우에 발생한다. 

• 노드가 잘못된 결과로 응답하는 경우
• 노드가 결과를 가져오지 못하는 경우 
• 노드가 의도적으로 잘못된 결과로 응답하는 경우 
• 노드가 네트워크의 여러 부분에 대해 상이한 결과로 응답하는 경우

프랙티컬 비잔틴 장애 허용(pBFT)의 장점

pBFT는 다른 합의 알고리즘, 특히 PoW와 비교했을 때 크게 3가지 장점이 있다. 

• 트랜잭션 파이널리티: pBFT 모델은 확인을 요구하지 않고 트랜잭션 파이널리티(finality)를 제공한다. 노드가 제안된 블록의 유효성에 동의하면 해당 블록의 트랜잭션이 최종적으로 이루어진다는 얘기다. 이는 채굴 노드가 트랜잭션을 체인에 추가하기 전에 각 노드가 개별적으로 트랜잭션을 확인하는 PoW와 다르다. 예를 들어 비트코인의 경우 노드 수에 따라 블록 확인에 10~60분 정도가 소요된다.
• 전력 사용량 감소: PoW와 달리 pBFT는 복잡한 수학 문제를 풀기 위해 노드를 필요로 하지 않는다. 따라서 전력 소모가 크지 않다. 비트코인 채굴 시에는 PoW 비용 때문에 전기가 필요하기 때문에 전력 소모가 높은 편이다. 
• 균등한 보상 배분: pBFT에서는 모든 노드가 클라이언트 요청을 실행한다. 즉, 모든 노드가 보상을 받는다는 얘기가 된다. 

프랙티컬 비잔틴 장애 허용(pBFT)의 한계점은?

pBFT 기반 블록체인은 노드 간 지속적인 통신으로 인해 확장성이 낮은 편이다.  노드가 많을 수록 네트워크가 클라이언트 요청에 응답하는 데 시간이 오래 걸리기 때문이다. 

또한 pBFT를 기반으로 한 블록체인은 시빌 공격(Sybil attack)에 취약하다. 시빌 공격이란 단일 개체가 네트워크의 합의를 방해하기 위해 수많은 노드를 제어하는 공격을 말한다. 하지만 노드 수가 확장되면 시빌 공격이 발생할 가능성은 낮아진다. 그럼에도 불구하고 질리카 프로젝트의 사례에서 볼 수 있듯 확장성 문제로 개발자들이 pBFT 모델을 다른 합의 메커니즘과 결합해야 하는 일이 있을 수도 있다. 

비잔틴 장애 허용, 왜 중요할까?

비잔틴 장애 허용이 중요한 이유는 일부 노드가 잘못된 정보를 전달하거나 작동을 중단하더라도 블록체인 네트워크가 정상적으로 작동할 수 있기 때문이다. 암호화폐 사용자들의 경우 거래가 얼마나 안전한지 알 수 있다. 따라서 자신이 투자한 코인의 블록체인 BFT를 알아두면 분명 명랑한 크립토 생활의 도움이 될 것이다.

비잔틴 장애 허용(BFT) 합의 알고리즘

블록체인의 비잔틴 장애 허용은 개발자가 사용하기로 한 합의 알고리즘에 따라 달라진다. 다시 말해 블록체인마다 비잔틴 장애 허용이 다를 수 있다는 얘기다. 하지만 가장 일반적인 합의 알고리즘을 정리하면 다음과 같다. 

• 작업 증명(PoW)
• 지분 증명(PoS)
• 위임 지분 증명(DPoS)
• 프랙티컬 비잔틴 내결함성(pBFT)
• 리스 지분 증명(Lease PoS, LPoS)
• 중요도 증명(Proof-of-Importance, PoI)
• 권한 증명(Proof-of-Authority, PoA)
• 방향성 비순환 그래프(Directed Acyclic Graph, DAG)
• 위임된 비잔틴 내결함성(Delegated BFT, dBFT)
• 용량 증명(Proof-of-Capacity, PoC)
• 신원 증명(Proof-of-Identity, PoI)
• 활동 증명(Proof-of-Activity, PoA)
• 경과 시간 증명(Proof-of-Elapsed-Time, PoET)

핵심은 ‘합의 메커니즘’

블록체인 네트워크는 효율적이고 성공적이기 위해 좋은 합의 메커니즘이 필요하다. 시장에는 수많은 합의 알고리즘이 있으며, 작동 방식은 제각기 다르다. 사실상 완벽한 블록체인 네트워크는 없다. 하지만 비잔틴 장군 문제와 같은 딜레마를 해결하기 위한 최상의 시스템이라면 PoW와 PoW BFT를 꼽을 수 있다. 

자주 묻는 질문