It’s not easy to achieve consensus in distributed systems. This problem is generally called “The Byzantine General’s’ problem.” Byzantine failures are common failures in software design, process, quality, and applications in software. Blockchain applications, starting with Bitcoin’s Proof-of-Work consensus method, are today proposing solutions to this challenge.
The Byzantine Fault Tolerance (BFT) is a proposed alternative consensus algorithm to the better known Proof-of-Work and Proof-of-Stake algorithms. Notable blockchain projects like Ripple, Stellar, Hyperledger and Antshares are investigating versions of BFT systems for their blockchain-enabled products. Byzantine fault-tolerant algorithms could be increasingly important in the future due to their ability to minimize attacks and software errors which lead to faulty nodes and arbitrary behavior.
Byzantine agreements work to ensure consensus despite non-rational behavior by a fraction of nodes participating in a distributed system. Generally, membership in Byzantine agreement systems is set by a central authority or closed negotiation. Notably, Ripple tried to decentralize admission in BFT systems by publishing a “starter” membership so participants can edit a blockchain themselves.
Detractors lament that this design winds up with a concentration of power in the hands of the system’s maintainer. (i.e. the organization overseeing admission membership)
MIT researchers contend BFT incorporates optimizations that “improve the response time of previous algorithms by more than an order of magnitude.” Byzantine Fault Tolerance can contain misbehaving nodes and mute their messages. BFT algorithms manage relationships between blockchain nodes, making the network resilient to the Byzantine General’s problem. BFT systems, to be sure, are known to be prone to Sybil attacks. There are a few blockchain-enabled platforms employing this consensus method already.
Practical Byzantine Fault Tolerance
PBFT is used by Hyperledger, an open-source blockchain collaborative effort led by IBM and the Linux Foundation, and is likely the best known variant of BFT. “Practical Byzantine Fault Tolerance” is incorporated into Hyperledger Fabric.
Hyperledger Fabric provides solutions for validating peers; smart contracts (called “chaincode”) represent transactions; membership services; pluggable consensus and other aspects. PBFT transactions offer low latency, high-speed file storage solutions and many other technical solutions.
Delegated Byzantine Fault Tolerance (dBFT)
Antshares, a decentralized smart contract platform, employs Delegated Byzantine Fault Tolerance (dBFT). It features two blockchain participants: professional node operators, called bookkeeping nodes, who run nodes to make money, and users. Proponents claim dBTF offers better security in blockchains.
dBFT’s on-chain voting process dynamically votes in/out transaction validators and allows for universal consensus mechanism on public/permissionless and private/permissioned blockchains.
“Specialized bookkeeping nodes” achieve consensus in a dBFT blockchain thanks to “delegated voting.” Two-thirds approval is needed among nodes to approve a new version of the blockchain. This system, proponents say, protects against forking events, radical changes to the implementation of a blockchain system that can undermine participant confidence.
“After investigating and studying the crypto-industry and blockchain technologies for several years, we came to the conclusion that the delegated Byzantine Fault Tolerance alternative (or dBFT) is best suited for such a system,” Erik Iz, co-founder and core developer at Antshares, stated. “It provides swift transaction verification times, de-incentivises most attack vectors and upholds a single blockchain version with no risk of forks or alternative blockchain records emerging – regardless of how much computing power, or coins an attacker possesses.”
Federated Byzantine Agreement (FBA)
Stellar introduced Federal Byzantine Agreements in its white paper.
“Like nonfederated Byzantine agreement, FBA addresses the problem of updating replicated state, such as a transaction ledger or certificate tree,” the blockchain project states. “By agreeing on what updates to apply, nodes avoid contradictory, irreconcilable states. We identify each update by a unique slot from which inter-update dependencies can be inferred. For instance, slots may be consecutively numbered positions in a sequentially applied log. An FBA system runs a consensus protocol that ensures nodes agree on slot contents.”
The project highlights the benefits: “A node can safely apply update in slot when it has safely applied updates in all slots upon which depends and, additionally, it believes all correctly functioning nodes will eventually agree on for slot. At this point, we say has externalized for slot. The outside world may react to externalized values in irreversible ways, so a node cannot later change its mind about them.”
Malicious parties could join an FBA multiple times and outnumber honest nodes, according to researchers. FBA boasts greater ranges of settings than other consensus methods.
Did we miss any Byzantine consensus methods? Let us know in the comments.
Image from Pixabay.