Extending Hyperledger Fabric Orderer with Tendermint PBFT Consensus
This article explains how to augment Hyperledger Fabric's orderer service by integrating Tendermint's ABCI to implement a PBFT consensus mechanism, detailing the limitations of solo and Kafka ordering, the motivation for decentralized ordering, and the step‑by‑step implementation approach.
Introduction HyperLedger Fabric is a flexible enterprise‑grade blockchain platform increasingly adopted in production. After previously sharing experiences with Fabric on Ctrip's blockchain service platform, this article focuses on extending the Fabric ordering service.
Analysis of Fabric Orderer Service The article first examines the simplest solo ordering type, describing how an orderer node initializes a solo consenter, creates a chain object for the system channel (testchainid), and processes configuration and transaction ordering through a sendChan and block cutter. It then notes that Fabric 1.4 recommends the more stable Kafka ordering, which supports multiple orderer nodes and uses a Kafka cluster for high availability.
Why Implement PBFT Ordering The authors argue that Kafka ordering, while suitable for basic consortium chains, centralizes the ordering service and does not fit scenarios where multiple enterprises should each host ordering nodes. They propose a PBFT‑based solution that allows orderer nodes to be deployed across different organizations.
Implementing PBFT Ordering with Tendermint ABCI Tendermint provides a high‑performance BFT consensus engine with an ABCI interface that enables custom integration without modifying Tendermint source code. The implementation creates a new package that satisfies Fabric's consensus interface; on each channel creation, it starts a Tendermint node. Incoming transactions are serialized to byte arrays and submitted to Tendermint's mempool via Mempool.checkTx . After Tendermint reaches consensus, the ABCI DeliverTx and Commit methods are used to invoke Fabric's CreateNextBlock and WriteBlock to record the block.
Handling Multi‑Channel Compatibility Because Fabric supports multiple channels while Tendermint maintains a single ledger, the solution writes blocks to both the Fabric channel ledger and a separate Tendermint LevelDB ledger. This dual‑ledger approach enables block chasing: if an orderer’s Tendermint height lags, it fetches missing blocks from peers and writes them to both ledgers.
Current Status and Limitations The prototype code (available at https://github.com/hxmhlt/fabric/tree/develop-1.4-tmpbft ) is not yet production‑ready; features such as dynamic validator addition, automatic Tendermint configuration generation, and performance optimizations remain incomplete.
References The article links to related posts on HyperLedger Fabric applications, Ctrip's hybrid cloud Kubernetes deployment, and other engineering practices.
Ctrip Technology
Official Ctrip Technology account, sharing and discussing growth.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.