RAFT Meets PBFT: A Hybrid Consensus Architecture for Performance and Byzantine Tolerance

Distributed systems face a persistent design tension: crash fault tolerance (CFT) protocols like Raft are fast but assume all participants are honest, while Byzantine fault tolerance (BFT) protocols like PBFT handle malicious actors but impose substantial communication overhead. A recent proposal by Lee and Seo (2025) presents a hybrid architecture that operates both protocols in a two-stage pipeline, attempting to capture the performance of one and the security guarantees of the other.

The Consensus Dilemma

Consensus protocols ensure that distributed nodes agree on a single sequence of operations despite failures. The nature of failures they tolerate defines their classification.

Crash fault tolerance (CFT) protocols—Raft and Paxos being the most prominent—assume that failed nodes simply stop responding. They cannot handle nodes that actively lie, send conflicting messages, or collude. Raft in particular has gained widespread adoption (etcd, CockroachDB, TiKV) due to its understandability and practical performance: leader election is fast, log replication requires only majority acknowledgment, and throughput scales well within a single shard.

Byzantine fault tolerance (BFT) protocols—PBFT, HotStuff, Tendermint—tolerate nodes that behave arbitrarily, including sending contradictory messages to different peers. The cost is significant: PBFT requires O(n^2) message complexity per consensus round (where n is the number of nodes), compared to O(n) for Raft. HotStuff improved this to O(n) messages through pipelining and threshold signatures, but at the cost of additional latency and cryptographic computation.

For permissioned blockchains, financial platforms, and enterprise distributed databases, the choice between CFT and BFT involves a real tradeoff: Raft-based systems deliver high throughput and low latency but are vulnerable to any compromised node; PBFT-based systems resist compromise but sacrifice performance.

The Two-Stage Pipeline Architecture

Lee and Seo (2025) propose a hybrid approach that structures consensus as a two-stage pipeline:

Stage 1 (Intra-Shard RAFT): The network is partitioned into shards, each running a majority-voting RAFT protocol. Within each shard, a leader collects transactions, replicates them to followers, and achieves a rapid temporary agreement. This stage operates at near-native RAFT throughput because it avoids BFT overhead entirely.

Stage 2 (Inter-Shard PBFT Committee): Representative nodes from each shard form a compact PBFT committee that conducts a global final approval. This committee verifies that shard-level agreements are consistent and that no shard has been compromised by a Byzantine leader. Only this stage incurs BFT communication costs, and because the committee is much smaller than the full network, the O(n^2) message complexity applies to a reduced n.

The architectural insight is that Byzantine behavior within a shard is detected at Stage 2 rather than prevented at Stage 1. Under normal (non-Byzantine) conditions, the system operates essentially at RAFT speed because Stage 2 approvals are fast when inputs are consistent. Only when the PBFT committee detects conflicting shard outputs does the BFT machinery engage fully.

Formal Verification

A notable aspect of this work is the use of formal verification through Z3 and PySMT solvers to confirm that the hybrid protocol satisfies both safety (no two honest nodes finalize conflicting transactions) and liveness (the system continues making progress despite faults within tolerance bounds). Formal verification of consensus protocols remains relatively uncommon in the literature, and its inclusion here strengthens the contribution's credibility.

The verification confirms that safety holds as long as fewer than one-third of PBFT committee members are Byzantine—the standard PBFT assumption—and that liveness is maintained even when individual shards experience leader failures, which Raft handles through its built-in leader election mechanism.

Critical Assessment

The shard boundary is a trust assumption. The security model depends on the PBFT committee being representative and not overwhelmingly colluded. If an adversary controls multiple shard leaders, the committee may receive consistently falsified shard agreements. The paper does not extensively address committee selection mechanisms or rotation strategies.

Sharding introduces coordination costs. Cross-shard transactions—operations that span multiple shards—require additional protocols not fully addressed in this work. In practice, many financial and database workloads involve cross-shard dependencies, and the performance benefits of sharding can erode quickly when cross-shard transaction rates are high.

Comparison baselines are limited. The evaluation compares against standalone RAFT and standalone PBFT, but does not benchmark against more recent BFT protocols like HotStuff-2, Bullshark, or DAG-based consensus systems that have significantly improved BFT performance.

Production readiness is unclear. The formal verification applies to an abstract protocol model. Implementation artifacts—network delays, message serialization, key management, node failure recovery—can introduce behaviors not captured by the formal model.

Related Approaches

Li (2024) proposes a related but distinct architecture combining Raft with multi-pipeline HotStuff and elliptic curve cryptography (ECC), demonstrating that the idea of hybridizing CFT and BFT has gained traction from multiple research groups. The multi-pipeline approach addresses HotStuff's single-leader bottleneck by allowing concurrent proposal streams, potentially improving throughput further.

Tendermint (used in Cosmos) and Hotstuff (used in Meta's now-deprecated Diem/Libra) represent production-grade BFT systems that have made different architectural choices. The hybrid approach positions itself as a middle ground for environments that need BFT guarantees but cannot tolerate the full performance cost.

Open Questions

• How does the two-stage pipeline perform under adversarial conditions where Byzantine nodes strategically target the shard-to-committee interface?
• Can the architecture be extended to handle cross-shard atomic transactions without significant performance degradation?
• What committee rotation and selection mechanisms would be necessary for production deployment in permissioned blockchain networks?
• How does this approach compare quantitatively against recent DAG-based BFT protocols like Narwhal-Tusk?

Closing Reflection

The RAFT-PBFT hybrid architecture represents an interesting design point in the consensus design space: rather than choosing between performance and Byzantine resilience, it layers them. The formal verification adds rigor that is often absent in consensus protocol proposals. Whether this specific architecture sees adoption will depend on how well it handles the practical complexities—cross-shard transactions, committee governance, and real-world adversarial conditions—that the formal model necessarily abstracts away.

분산 시스템은 지속적인 설계상의 긴장을 안고 있다. Raft와 같은 충돌 결함 허용(CFT) 프로토콜은 빠르지만 모든 참여자가 정직하다고 가정하는 반면, PBFT와 같은 비잔틴 결함 허용(BFT) 프로토콜은 악의적인 행위자를 처리할 수 있지만 상당한 통신 오버헤드를 수반한다. Lee and Seo(2025)의 최근 제안은 두 프로토콜을 2단계 파이프라인으로 동시에 운용하는 하이브리드 아키텍처를 제시하며, 하나의 성능과 다른 하나의 보안 보장을 동시에 확보하고자 한다.

합의 딜레마

합의 프로토콜은 장애가 발생하더라도 분산 노드들이 단일한 연산 순서에 동의하도록 보장한다. 허용하는 장애의 성격에 따라 분류 방식이 결정된다.

충돌 결함 허용(CFT) 프로토콜—Raft와 Paxos가 가장 대표적이다—은 장애가 발생한 노드가 단순히 응답을 멈춘다고 가정한다. 이 프로토콜은 노드가 능동적으로 거짓말을 하거나, 상충되는 메시지를 전송하거나, 공모하는 경우를 처리할 수 없다. 특히 Raft는 이해하기 쉽고 실용적인 성능 덕분에 etcd, CockroachDB, TiKV 등에서 널리 채택되었다. 리더 선출이 빠르고, 로그 복제는 과반수 승인만으로 충분하며, 처리량은 단일 샤드 내에서 잘 확장된다.

비잔틴 결함 허용(BFT) 프로토콜—PBFT, HotStuff, Tendermint—은 서로 다른 피어에게 모순된 메시지를 전송하는 것을 포함하여 임의적으로 행동하는 노드를 허용한다. 그 비용은 상당하다. PBFT는 합의 라운드당 O(n^2)의 메시지 복잡도를 요구하는데(n은 노드 수), Raft의 O(n)과 비교된다. HotStuff는 파이프라이닝과 임계값 서명을 통해 이를 O(n) 메시지로 개선했지만, 추가적인 지연 시간과 암호화 연산이라는 비용이 따른다.

허가형 블록체인, 금융 플랫폼, 기업용 분산 데이터베이스에서 CFT와 BFT 간의 선택은 실질적인 트레이드오프를 수반한다. Raft 기반 시스템은 높은 처리량과 낮은 지연 시간을 제공하지만 손상된 노드에 취약하고, PBFT 기반 시스템은 손상에 저항하지만 성능을 희생한다.

2단계 파이프라인 아키텍처

Lee and Seo(2025)는 합의를 2단계 파이프라인으로 구성하는 하이브리드 접근 방식을 제안한다.

1단계(샤드 내부 RAFT): 네트워크는 샤드로 분할되며, 각 샤드는 과반수 투표 RAFT 프로토콜을 운용한다. 각 샤드 내에서 리더는 트랜잭션을 수집하고, 팔로워에게 복제하며, 신속한 임시 합의를 달성한다. 이 단계는 BFT 오버헤드를 완전히 회피하기 때문에 네이티브 RAFT 처리량에 근접하여 동작한다.

2단계(샤드 간 PBFT 위원회): 각 샤드의 대표 노드들이 소규모 PBFT 위원회를 구성하여 전역적인 최종 승인을 수행한다. 이 위원회는 샤드 수준의 합의가 일관되는지, 그리고 어느 샤드도 비잔틴 리더에 의해 손상되지 않았는지 검증한다. BFT 통신 비용은 오직 이 단계에서만 발생하며, 위원회는 전체 네트워크보다 훨씬 작기 때문에 O(n^2) 메시지 복잡도는 축소된 n에만 적용된다.

이 아키텍처의 핵심 통찰은 샤드 내 비잔틴 행동이 1단계에서 예방되는 것이 아니라 2단계에서 감지된다는 점이다. 정상적인(비비잔틴) 조건에서는 입력이 일관될 때 2단계 승인이 빠르게 이루어지기 때문에 시스템은 본질적으로 RAFT 속도로 동작한다. PBFT 위원회가 샤드 출력 간의 충돌을 감지할 때에만 BFT 메커니즘이 완전히 작동한다.

형식 검증

이 연구의 주목할 만한 측면은 Z3 및 PySMT 솔버를 통한 형식 검증을 활용하여 하이브리드 프로토콜이 안전성(두 정직한 노드가 상충되는 트랜잭션을 최종 확정하지 않음)과 활성성(시스템이 허용 범위 내의 결함에도 불구하고 계속 진행됨)을 모두 만족함을 확인한다는 점이다. 합의 프로토콜의 형식 검증은 관련 문헌에서 여전히 상대적으로 드물며, 이를 포함함으로써 본 연구의 기여도에 대한 신뢰성이 강화된다. 검증 결과, PBFT 위원회 구성원의 3분의 1 미만이 Byzantine인 경우—표준 PBFT 가정—안전성이 유지되며, 개별 샤드에서 리더 장애가 발생하더라도 Raft의 내장 리더 선출 메커니즘을 통해 활성성이 유지됨을 확인하였다.

비판적 평가

샤드 경계는 신뢰 가정이다. 보안 모델은 PBFT 위원회가 대표성을 가지며 공모가 압도적으로 이루어지지 않는다는 가정에 의존한다. 공격자가 여러 샤드 리더를 통제할 경우, 위원회는 지속적으로 위조된 샤드 합의를 수신할 수 있다. 논문은 위원회 선정 메커니즘이나 순환 전략을 광범위하게 다루지 않는다.

샤딩은 조정 비용을 유발한다. 여러 샤드에 걸친 연산인 크로스-샤드 트랜잭션은 본 연구에서 충분히 다루지 않은 추가 프로토콜을 필요로 한다. 실제로 많은 금융 및 데이터베이스 워크로드는 크로스-샤드 의존성을 포함하며, 크로스-샤드 트랜잭션 비율이 높을 경우 샤딩의 성능 이점은 빠르게 감소할 수 있다.

비교 기준선이 제한적이다. 평가는 독립형 RAFT 및 독립형 PBFT와의 비교에 그치며, BFT 성능을 크게 향상시킨 HotStuff-2, Bullshark, 또는 DAG 기반 합의 시스템과 같은 최신 BFT 프로토콜과의 벤치마크는 포함되지 않는다.

프로덕션 준비 상태가 불명확하다. 형식 검증은 추상적인 프로토콜 모델에 적용된다. 네트워크 지연, 메시지 직렬화, 키 관리, 노드 장애 복구와 같은 구현 결과물은 형식 모델이 포착하지 못하는 동작을 유발할 수 있다.

관련 연구

Li (2024)는 Raft와 다중 파이프라인 HotStuff 및 타원 곡선 암호화(ECC)를 결합한 관련되지만 구별되는 아키텍처를 제안하며, CFT와 BFT를 혼합하는 아이디어가 여러 연구 그룹에서 주목받고 있음을 보여준다. 다중 파이프라인 방식은 동시 제안 스트림을 허용함으로써 HotStuff의 단일 리더 병목 현상을 해결하여 처리량을 추가적으로 향상시킬 가능성이 있다.

Tendermint(Cosmos에서 사용)와 HotStuff(Meta의 현재 지원 중단된 Diem/Libra에서 사용)는 서로 다른 아키텍처적 선택을 한 프로덕션급 BFT 시스템이다. 하이브리드 방식은 BFT 보장이 필요하지만 전체 성능 비용을 감당할 수 없는 환경을 위한 중간 지점으로 자리매김한다.

미해결 과제

• Byzantine 노드가 샤드-위원회 인터페이스를 전략적으로 공격하는 적대적 조건에서 2단계 파이프라인은 어떻게 작동하는가?
• 아키텍처가 크로스-샤드 원자적 트랜잭션을 상당한 성능 저하 없이 처리하도록 확장될 수 있는가?
• 허가형 블록체인 네트워크의 프로덕션 배포에 필요한 위원회 순환 및 선정 메커니즘은 무엇인가?
• 이 방식은 Narwhal-Tusk와 같은 최신 DAG 기반 BFT 프로토콜과 정량적으로 어떻게 비교되는가?

마무리 고찰

RAFT-PBFT 하이브리드 아키텍처는 합의 설계 공간에서 흥미로운 설계 지점을 나타낸다. 성능과 Byzantine 복원력 중 하나를 선택하는 대신 이를 계층화한다는 점에서 그러하다. 형식 검증은 합의 프로토콜 제안에서 흔히 결여된 엄밀성을 더한다. 이 특정 아키텍처가 채택될지 여부는 형식 모델이 필연적으로 추상화하는 실용적 복잡성—크로스-샤드 트랜잭션, 위원회 거버넌스, 실제 적대적 조건—을 얼마나 잘 처리하느냐에 달려 있다.