비잔틴 장애 허용(BFT, Byzantine Fault Tolerance)과 PBFT

1. 개요

가. 정의

비잔틴 장애 허용(Byzantine Fault Tolerance, BFT)이란 분산 시스템의 일부 노드가 단순히 멈추는 수준을 넘어 임의로 잘못된·상충되는·악의적인 메시지를 보내는 상황(비잔틴 장애)에서도, 정상 노드들이 하나의 올바른 값에 합의하고 시스템이 일관되게 동작하도록 보장하는 능력을 말한다. PBFT(Practical Byzantine Fault Tolerance)는 1999년 Castro·Liskov가 제안한, 부분 동기(partial synchrony) 가정 아래 실용적 성능으로 비잔틴 합의를 달성한 대표 알고리즘이다.

BFT는 분산 합의의 가장 강한 형태다. 앞서 Paxos·Raft가 다루는 크래시 장애(Crash Fault)는 노드가 "죽거나 느려질 뿐 거짓말은 하지 않는다"는 전제를 깔지만, BFT는 "노드가 해킹당해 서로 다른 노드에 서로 다른 값을 보내거나, 위조 서명을 시도하거나, 프로토콜을 교묘히 위반할 수 있다"는 적대적 장애 모델까지 가정한다. 그래서 BFT는 신뢰할 수 없는(permissionless·adversarial) 환경—공개 블록체인, 다자간 금융 결제망, 항공·우주 제어장치—의 안전성을 떠받치는 핵심 기반 기술로 자리 잡았다.

나. 등장 배경과 필요성

BFT의 이론적 뿌리는 1982년 Lamport·Shostak·Pease가 정식화한 비잔틴 장군 문제(Byzantine Generals Problem)다. 여러 장군이 각자 부대를 이끌고 적의 성을 포위한 채 "공격"과 "후퇴" 중 하나를 모두 똑같이 선택해야 하는데, 전령(메시지)만으로 소통하며 일부 장군은 배신자여서 거짓 명령을 흘릴 수 있다. 이때 충성스러운 장군들이 반드시 같은 결정에 도달할 수 있는가를 묻는 사고실험으로, 분산 시스템에서 "거짓말하는 노드가 섞여 있어도 합의가 가능한가"를 추상화한 것이다. 이 논문은 구두(서명 없는) 메시지만으로는 배신자가 1명이라도 있으려면 전체 장군이 최소 3배수 이상이어야 한다는, 즉 3f+1 조건을 수학적으로 증명했다.

이 문제가 현실에서 중요한 이유는 명확하다. 단순 장애만 가정하는 Paxos·Raft 계열은 노드 하나가 악의적으로 서로 다른 팔로워에게 모순된 로그를 보내는 공격 앞에서 안전성이 깨진다. 금융 결제, 전자투표, 항공 제어처럼 단 한 번의 잘못된 합의가 치명적인 영역에서는 "노드는 거짓말하지 않는다"는 낙관적 전제를 쓸 수 없다. 특히 2008년 비트코인 이후 상호 불신하는 익명 참여자들이 중앙 관리자 없이 원장 상태에 합의해야 하는 요구가 폭발하면서, 비잔틴 합의는 학계의 난제에서 산업계의 필수 기술로 격상되었다.

다만 초기 BFT 알고리즘은 "이론적으로는 가능하나 성능이 비현실적"이라는 벽에 막혀 있었다. PBFT는 바로 이 지점을 깨뜨렸다. 완전 비동기가 아닌 부분 동기(메시지 지연에 상한이 존재한다는 약한 가정)를 도입하고, 메시지 교환 횟수를 지수에서 다항식 수준으로 낮춰 실제 파일 시스템(BFS)에 적용 가능한 처리량을 입증함으로써 "Practical"이라는 이름을 얻었다.

다. BFT가 보장하는 핵심 성질

합의(Agreement): 모든 정직한 노드는 같은 순번에 동일한 요청을 실행한다. 비잔틴 노드가 서로 다른 값을 유포해도 교차검증으로 걸러진다.
전순서(Total Order): 요청들이 모든 정직한 노드에서 동일한 순서로 적용되어 복제 상태기계의 상태가 발산하지 않는다.
무결성(Integrity): 정직한 클라이언트의 요청만, 정확히 한 번 실행된다(위조·재생 공격 차단).
외부 일관성(Linearizability): 클라이언트 관점에서 시스템이 단일한 올바른 서버처럼 응답한다.
활성(Liveness): 네트워크가 안정되면(부분 동기) 정직한 요청은 반드시 처리된다 — 단, 안전성에 종속되어 보장된다.

2. 비잔틴 장애의 특성과 정족수 원리

비잔틴 장애가 크래시 장애와 근본적으로 다른 점은 장애 노드의 행동에 제약이 없다는 데 있다. 크래시 장애 노드는 "응답하지 않음"이라는 단 하나의 실패 양상만 보이므로, 나머지 노드는 "응답한 값은 정직하다"고 믿을 수 있다. 반면 비잔틴 노드는 응답을 하되 그 내용이 거짓일 수 있고, 수신자에 따라 다른 값을 보내는 이중 행동(equivocation)까지 가능하다. 따라서 BFT는 "들어온 값을 믿는" 대신 "충분히 많은 노드가 동일하게 증언한 값만 믿는" 다중 검증 구조를 택한다.

이 구조의 핵심이 3f+1 정족수 원리다. 전체 노드 N개 중 최대 f개가 비잔틴일 때 안전성을 지키려면 N ≥ 3f+1이어야 한다. 직관적으로 설명하면, 합의에 필요한 정족수는 2f+1인데, 이렇게 해야 두 가지를 동시에 만족한다. 첫째, 비잔틴 노드 f개가 응답을 거부해도 정상 노드 2f+1개 중 f+1개로 정족수를 채울 수 있어 진전(liveness)이 보장된다. 둘째, 서로 다른 두 정족수(각 2f+1)는 N=3f+1 안에서 반드시 f+1개 이상 겹치고, 그 교집합에는 최소 1개 이상의 정직한 노드가 존재하므로 모순된 두 결정이 동시에 확정되는 일이 원천 차단되어 안전성(safety)이 지켜진다. 예컨대 f=1이면 최소 4노드, f=2이면 7노드가 필요하며, 이는 크래시 장애의 2f+1(f=1에 3노드)보다 더 많은 중복을 요구한다.

flowchart TB
    subgraph CFT["크래시 장애 허용 (CFT, N=2f+1)"]
      direction TB
      C1["정상 노드"] --- C2["정상 노드"]
      C2 --- C3["침묵(정지)한 노드"]
      CNOTE["가정: 노드는 멈출 뿐 거짓말하지 않음"]
    end
    subgraph BFT["비잔틴 장애 허용 (BFT, N=3f+1)"]
      direction TB
      B1["정상 노드"] --- B2["정상 노드"]
      B2 --- B3["정상 노드"]
      B3 --- B4["악의적 노드(이중 행동)"]
      BNOTE["가정: 노드는 거짓·모순 메시지를 보낼 수 있음"]
    end
    CFT -->|"위협 모델 강화"| BFT

위 그림은 동일한 f=1을 견디는 데에도 CFT는 3노드, BFT는 4노드가 필요함을 보여준다. 추가된 1개의 중복은 "거짓말 가능성"에 대비하는 비용이며, 이 때문에 BFT는 더 강한 안전성을 제공하는 대신 노드 수·메시지 비용·지연이 커지는 근본적 트레이드오프를 안고 있다. 산업 현장에서 신뢰 도메인 내부(사내 데이터센터)에는 비용이 낮은 CFT를, 상호 불신 환경(공개 블록체인)에는 BFT를 선택하는 분기점이 여기서 갈린다.

한편 비잔틴 장군 문제의 원 논문은 메시지 인증(서명)의 유무가 내결함 한계를 바꾼다는 중요한 통찰을 남겼다. 서명 없는 구두 메시지(oral message) 모델에서는 배신자가 "A에게는 공격, B에게는 후퇴"라고 말한 뒤 이를 추적할 방법이 없어 3f+1개가 반드시 필요하다. 그러나 메시지에 위조 불가능한 디지털 서명을 붙이면, 배신자가 전달 과정에서 내용을 바꾸면 서명이 깨져 즉시 발각되므로 이론적으로는 더 적은 노드로도 합의가 가능해진다. 바로 이 때문에 PBFT를 비롯한 현대 BFT는 예외 없이 모든 프로토콜 메시지에 서명 또는 MAC을 부착하며, 서명은 BFT의 "거짓말 탐지 장치"이자 성능 병목이 동시에 된다. 다만 서명은 이중 행동(equivocation)—같은 서명자가 서로 다른 두 메시지에 각각 정당한 서명을 붙여 보내는 공격—은 막지 못하므로, 결국 3f+1 정족수를 통한 투표 교차검증이 여전히 핵심 안전장치로 남는다.

BFT 설계에서 반드시 구분해야 할 또 다른 축은 안전성(Safety)과 활성(Liveness)이다. 안전성은 "서로 다른 두 정직한 노드가 같은 순번에 다른 값을 확정하지 않는다"(나쁜 일은 절대 일어나지 않는다)이고, 활성은 "요청이 언젠가는 반드시 처리된다"(좋은 일은 결국 일어난다)이다. FLP 불가능성 정리에 따라 완전 비동기 환경에서는 둘을 동시에 결정론적으로 보장할 수 없으므로, PBFT는 안전성을 어떤 경우에도 희생하지 않고 활성만 부분 동기 가정(메시지 지연 상한 존재)에 맡기는 설계를 택했다. 즉 네트워크가 극단적으로 불안정하면 PBFT는 멈출지언정(활성 상실) 결코 모순된 결정을 내리지는 않는다(안전성 유지). 이 "안전성 우선" 철학은 금융·제어처럼 틀린 합의가 치명적인 영역에서 BFT를 신뢰할 수 있게 만드는 근본 원칙이다.

3. PBFT의 3단계 합의 프로토콜

PBFT는 노드들을 프라이머리(primary, 리더)와 백업(backup)으로 나누고, 특정 설정(view)에서 프라이머리가 요청의 순서를 제안하면 백업들이 이를 교차 검증해 확정한다. 정상 작동 구간(normal-case)의 합의는 Pre-prepare → Prepare → Commit의 3단계 메시지 교환으로 이뤄지며, 각 단계는 "충분한 수의 노드가 같은 내용을 봤다"는 증거를 누적한다. 각 단계가 확보하는 보장을 한눈에 정리하면 다음과 같다.

Pre-prepare: 프라이머리가 순번(n)을 제안 → "이 view에서 n번 자리의 요청" 후보를 고정.
Prepare(2f+1 수집): 같은 view·순번에 서로 다른 요청이 prepared될 수 없음을 보장(동일 view 내 순서 합의).
Commit(2f+1 수집): 결정이 view 교체 후에도 유지됨을 보장(뷰 간 확정성) → 실행·응답.

가. Pre-prepare(사전 준비). 클라이언트 요청을 받은 프라이머리는 그 요청에 순번(sequence number) n을 부여하고, 현재 view v·요청 다이제스트와 함께 서명해 모든 백업에 브로드캐스트한다. 이 단계의 목적은 "이 view에서 n번 자리에는 이 요청이 들어간다"는 순서 제안을 고정하는 것이다. 백업은 서명·view·순번 범위의 유효성을 검증해 받아들인다. 프라이머리가 악의적이어도 다음 단계의 교차 검증이 모순을 걸러낸다.

나. Prepare(준비). Pre-prepare를 받아들인 각 백업은 동일한 ⟨v, n, 다이제스트⟩에 대한 Prepare 메시지를 자신의 서명과 함께 모든 노드에 브로드캐스트한다. 한 노드가 자기 자신을 포함해 2f+1개의 일치하는 Prepare(서로 다른 노드가 서명한)를 모으면 "prepared 상태"에 이른다. 이 조건이 성립하면 정직한 노드들 사이에서 같은 view·같은 순번에 서로 다른 요청이 prepared될 수 없음이 보장된다. 즉 Prepare 단계는 "순서에 대한 1차 합의"를 확보하지만, view가 바뀌어도 이 결정이 살아남는지는 아직 보장하지 못한다.

다. Commit(확정). prepared에 도달한 노드는 Commit 메시지를 역시 전체에 브로드캐스트하고, 2f+1개의 일치하는 Commit을 모으면 "committed-local" 상태가 되어 요청을 복제 상태기계에 실행(execute)한 뒤 클라이언트에 응답한다. 클라이언트는 서로 다른 노드로부터 f+1개의 동일한 응답을 받으면 결과를 신뢰한다(f+1 중 최소 1개는 정직하므로). Commit 단계가 추가로 필요한 이유는, Prepare만으로는 view 교체(view change) 시 결정이 뒤집힐 수 있기 때문이다. Commit은 "이 결정은 view가 바뀌어도 유지된다"는 확정성을 부여한다.

sequenceDiagram
    participant C as 클라이언트
    participant P as 프라이머리(노드0)
    participant B1 as 백업1
    participant B2 as 백업2
    participant B3 as 백업3(장애 가능)
    C->>P: 요청(request)
    Note over P,B3: 1) Pre-prepare 단계
    P->>B1: Pre-prepare(v,n,다이제스트)
    P->>B2: Pre-prepare(v,n,다이제스트)
    P->>B3: Pre-prepare(v,n,다이제스트)
    Note over P,B3: 2) Prepare 단계 (2f+1 수집)
    B1->>P: Prepare
    B1->>B2: Prepare
    B2->>P: Prepare
    B2->>B1: Prepare
    Note over P,B3: 3) Commit 단계 (2f+1 수집)
    P->>B1: Commit
    B1->>B2: Commit
    B2->>P: Commit
    Note over P,B2: committed-local 도달 → 실행
    P-->>C: 응답
    B1-->>C: 응답
    B2-->>C: 응답(동일 f+1개 수신 시 신뢰)

라. 체크포인트와 가비지 컬렉션. 합의가 누적되면 각 노드가 보관하는 메시지 로그가 무한히 커지므로, PBFT는 일정 순번마다 체크포인트(checkpoint)를 만들어 상태 스냅샷을 공유하고 그 이전의 로그를 안전하게 폐기한다. 2f+1개 노드가 동일 상태 다이제스트에 서명한 안정 체크포인트(stable checkpoint)가 확보되면, 그 지점까지의 결정은 번복 불가능한 사실로 굳어지고 메모리가 회수된다. 체크포인트는 단순한 성능 최적화가 아니라, 뷰 체인지 시 "어디서부터 이어받아야 하는가"의 기준점이 되는 안전성의 구성 요소이기도 하다.

프라이머리가 응답하지 않거나 잘못된 순서를 강요하면 백업들은 타이머 만료 후 뷰 체인지(View Change)를 발동한다. 2f+1개 노드가 뷰 체인지에 동의하면 다음 프라이머리(v+1 기준 노드)가 선출되고, 직전까지 prepared·committed된 요청을 새 프라이머리가 증거(prepared 증명)와 함께 이어받아 이미 확정된 결정이 손실되지 않도록 보장한다. 이 메커니즘 덕분에 PBFT는 악의적 프라이머리 하나가 전체 진전을 영구히 막지 못한다. 다만 정상 구간 합의가 O(N²)의 메시지 복잡도를 가져(모든 노드가 서로 Prepare·Commit을 교환), 노드 수가 수십을 넘으면 확장성이 급격히 떨어지는 한계가 있다.

4. 합의 모델 비교와 적용 사례

실무에서 "어떤 합의를 쓸 것인가"는 성능 수치가 아니라 신뢰 가정에서 출발하는 설계 결정이다. 같은 분산 합의라도 전제하는 장애 모델이 다르면 필요한 노드 수·메시지량·최종성의 성격이 통째로 달라지기 때문이다. 아래에서는 세 가지 대표 모델을 비교하되, 수치 자체보다 그 수치가 왜 그렇게 결정되는지에 초점을 둔다.

BFT를 올바로 쓰려면 크래시 장애 합의, 그리고 공개 블록체인의 확률적 합의(PoW)와의 차이를 분명히 이해해야 한다. 아래 표는 핵심 차이를 비교하되, 각 차이가 왜 생기는지가 중요하다. CFT가 BFT보다 노드와 지연이 적은 것은 "거짓말 노드를 가정하지 않기" 때문이고, PoW가 BFT보다 참여자 확장성이 큰 대신 최종성(finality)이 확률적인 것은 투표 대신 해시 경쟁으로 합의를 대체했기 때문이다.

구분	크래시 장애(Paxos/Raft)	PBFT(결정론적 BFT)	PoW(확률적 BFT)
장애 모델	정지·지연만	임의·악의(거짓말)	임의·악의(개방형)
내결함 한계	f < N/2 (N=2f+1)	f < N/3 (N=3f+1)	해시파워 < 50%
최종성	즉시(결정적)	즉시(결정적)	확률적(확인 수 누적)
메시지 복잡도	O(N)	O(N²)	낮음(브로드캐스트)
노드 확장성	수~수십	수십(한계 뚜렷)	수천~수만
대표 적용	etcd·ZooKeeper	Hyperledger Fabric·Zilliqa	Bitcoin·초기 Ethereum

정족수 계산을 작은 수치로 구체화하면 차이가 분명해진다. 공개 블록체인처럼 N=100 노드로 운영할 때, BFT는 최대 f=33개(100 ≥ 3×33+1)의 악의적 노드를 견딜 수 있고 모든 결정에 최소 67개(2f+1)의 서명 투표가 필요하다. 반면 CFT라면 같은 100노드로 f=49개의 정지 장애를 견딜 수 있어 내결함 "비율"은 더 높지만, 이는 "악의적 노드가 없다"는 강한 전제 위에서만 성립한다. 즉 BFT는 더 적은 비율(1/3 미만)의 장애만 견디는 대신, 그 장애가 거짓말을 포함한 임의의 행동이어도 안전성을 지킨다는 질적 우위를 제공한다. 설계자는 "얼마나 많은 장애를 견디나"가 아니라 "어떤 종류의 장애를 견뎌야 하나"를 먼저 물어야 한다.

구체 사례로, 허가형(permissioned) 블록체인인 Hyperledger Fabric은 참여 기관 수가 제한적이고 신원이 확인되므로 PBFT 계열(또는 Raft) 오더러를 써 즉시 최종성과 높은 처리량을 얻는다. 반면 공개형인 비트코인은 익명 참여자가 수만에 이르러 O(N²) 투표가 불가능하므로 PoW를 택했고, 그 대가로 블록이 뒤집힐 확률이 시간에 따라 지수적으로 감소하는 "확률적 최종성"을 받아들였다. 한편 항공 분야에서는 보잉 777의 비행 제어 컴퓨터가 삼중 다수결(비잔틴 내성) 구조로 센서·연산 장애에 대비하는 등, BFT 개념이 블록체인 이전부터 안전 필수(safety-critical) 시스템에 실제 적용되어 왔다. 이처럼 "참여자 수·신뢰 가정·요구 최종성"이라는 세 축이 어떤 합의를 쓸지 결정한다.

5. 심화 — 확장형 BFT와 최신 동향

PBFT의 O(N²) 병목은 지난 10여 년간 BFT 연구의 최대 과제였고, 블록체인의 부상과 함께 이를 극복하는 차세대 BFT가 쏟아졌다. 첫째, Tendermint(현 CometBFT)는 PBFT를 단순화해 리더 교체를 매 블록 로테이션하고 즉시 최종성을 제공하며, Cosmos 생태계의 수많은 체인이 이를 합의 엔진으로 채택했다. 둘째, HotStuff(2019)는 메시지 복잡도를 O(N)으로 낮추고 모든 단계를 리더 중심의 선형 통신으로 재구성해, 리더 교체 비용까지 선형화했다. HotStuff는 Meta가 추진했던 Libra/Diem의 LibraBFT(DiemBFT)와 Aptos·Flow 등에 계승되며 현대 지분증명(PoS) 체인의 사실상 표준 설계가 되었다.

대표적인 차세대 BFT 계열을 정리하면 다음과 같다.

Tendermint / CometBFT: PBFT 단순화 + 매 블록 리더 로테이션, 즉시 최종성. Cosmos·Binance Chain 등 채택.
HotStuff / DiemBFT: 선형 통신(O(N))과 리더 교체 선형화, 파이프라이닝으로 처리량 향상. Aptos·Flow·Diem 계승.
Casper FFG + Gasper: 지분증명과 결합한 위원회 샘플링 BFT, 슬래싱으로 악의 행동 억제. Ethereum PoS.
HoneyBadgerBFT / DAG 기반(Narwhal·Bullshark): 타임아웃 가정 없는 비동기 BFT, 네트워크 공격에도 활성 유지.

셋째, 지분증명(PoS) 자체가 BFT와 결합해 확장성 문제를 우회한다. 이더리움의 Casper FFG와 Gasper는 수십만 검증자 중 무작위로 위원회를 뽑아 BFT 투표를 수행하고, 지분(스테이크)을 담보로 악의적 행위에 슬래싱(slashing) 벌칙을 부과해 경제적 비용으로 비잔틴 행동을 억제한다. 이는 "암호학적 투표(BFT) + 경제적 유인(스테이크)"을 결합한 하이브리드로, 전통 BFT의 노드 수 한계를 검증자 샘플링으로 돌파한 사례다. 넷째, 완전 비동기 네트워크에서도 안전·활성을 보장하는 HoneyBadgerBFT 같은 비동기 BFT가 등장해, 타임아웃 가정 없이도 동작하는 강건한 합의가 연구되고 있다. 이러한 흐름은 "신뢰 없는 대규모 참여"와 "즉시 최종성"을 동시에 추구하는 Web3·CBDC(중앙은행 디지털화폐) 설계에서 특히 중요하게 다뤄진다.

6. 고려사항 및 시사점 (기술사 관점)

위협 모델에 맞춘 합의 선택: 신뢰 도메인 내부(사내 클러스터, etcd)에는 비용이 낮은 CFT(Raft)를, 상호 불신·개방 환경(컨소시엄·공개 블록체인)에는 BFT를 선택해야 한다. 과도한 BFT 적용은 불필요한 노드·지연 비용을, 부족한 CFT 적용은 치명적 안전성 붕괴를 낳으므로, 설계 초기에 장애 모델을 명시적으로 문서화하는 것이 핵심 거버넌스 과제다.
확장성-최종성 트레이드오프: PBFT의 O(N²) 특성상 노드가 수십을 넘으면 처리량이 급락한다. 대규모가 필요하면 HotStuff(O(N)) 계열이나 위원회 샘플링(검증자 서브셋 투표)으로 통신량을 줄이되, 샘플링은 안전성이 확률적으로 약화될 수 있으므로 위원회 크기·재선출 주기를 정량적으로 검증해야 한다.
키 관리와 서명 성능: BFT는 모든 메시지에 디지털 서명·MAC을 요구하므로 키 유출이 곧 비잔틴 노드화를 의미한다. HSM·임계서명(threshold signature)·키 로테이션으로 서명 키를 보호하고, BLS 집계 서명 등으로 검증 비용을 상쇄하는 설계가 운영 안정성을 좌우한다.
네트워크 가정과 활성 보장: PBFT의 활성은 부분 동기(지연 상한 존재)에 의존하므로, 지속적 네트워크 공격(지연·분할)은 진전을 멈출 수 있다. DDoS 방어·다중 경로·뷰 체인지 타이머 튜닝으로 활성을 방어하고, 완전 비동기 내성이 필요하면 HoneyBadgerBFT 계열을 검토한다.
경제적 유인과의 결합 전망: PoS 기반 BFT에서는 슬래싱·보상 설계가 안전성의 일부가 된다. 암호학적 안전장치만이 아니라 경제적 인센티브까지 포함한 메커니즘 디자인으로 비잔틴 행동을 억제하는 것이 CBDC·탈중앙 금융의 필수 역량이 될 전망이며, 기술사는 암호·분산·경제 메커니즘을 아우르는 통합 설계 관점을 갖춰야 한다.
단계적 도입과 검증 전략: BFT 전면 도입 전에 혼돈공학(Chaos Engineering)·장애 주입으로 뷰 체인지·악의적 프라이머리 시나리오를 재현해 안전성·활성을 정량 검증하고, 노드 지리적 분산·클럭 스큐·서명 처리량의 병목을 사전에 측정해야 한다. 특히 "정상 구간에서는 빠르지만 공격 구간에서 지연이 폭증"하는 BFT 특성상, 평상시 성능이 아닌 최악 구간(worst-case) 지연을 기준으로 용량을 산정하는 보수적 설계가 안정 운영의 관건이다.

참고자료

Lamport, Shostak, Pease, "The Byzantine Generals Problem", ACM TOPLAS, 1982. https://lamport.azurewebsites.net/pubs/byz.pdf
Castro, Liskov, "Practical Byzantine Fault Tolerance", OSDI, 1999. https://pmg.csail.mit.edu/papers/osdi99.pdf
Yin et al., "HotStuff: BFT Consensus with Linearity and Responsiveness", PODC, 2019. https://arxiv.org/abs/1803.05069
Buchman, "Tendermint: Byzantine Fault Tolerance in the Age of Blockchains", 2016. https://tendermint.com/

한 줄 요약: BFT는 노드가 거짓말·모순 메시지를 보내는 적대적 환경에서도 N≥3f+1 정족수와 다중 교차검증으로 합의를 지키는 가장 강한 내결함 기술이며, PBFT의 Pre-prepare·Prepare·Commit 3단계와 뷰 체인지가 그 실용적 원형으로, 오늘날 HotStuff·PoS로 확장되어 블록체인·CBDC 신뢰의 기반이 된다.