FBFT Federated Byzantine Fault Tolerance
Federated Byzantine Agreement (FBA), also known as Federated Byzantine Fault Tolerance (FBFT), is a consensus method to decentralize, scale, and secure blockchain networks. It is a novel form of the Practical Byzantine Fault Tolerance (PBFT) consensus mechanism that expands on BFT.
Even in cases when some participating nodes are malfunctioning, compromised, or acting maliciously, FBFT seeks to obtain consensus. It accomplishes this by concentrating on a pre-selected collection of reliable organizations that come together as a “federation” to take part in the consensus-building process. This federation may consist of persons, groups, or institutions. The system is known for its high energy efficiency and instantaneous finality, and it provides enhanced throughput, high network scalability, and reduced transaction costs.
Decentralized Trust and Quorum Slices
FBFT presents the idea that nodes should only communicate and exchange messages with other nodes they explicitly trust, in contrast to PBFT, where all nodes inherently trust one another. The considerable communication that is frequently present in other consensus procedures is addressed by this method.
The core of FBFT relies on ‘quorum slices’
- Individual Trust: Each node creates its own unique “quorum slice” by choosing the other nodes it trusts on its own.
- Network Quorum: In order to obtain a consensus on a transaction, these separate quorum slices from different verifier nodes then link to create a larger quorum for the entire network.
- Quorum Intersection: Quorum intersection is the idea that a single node might be a part of more than one quorum slice.
- Autonomous Configuration: Without a central authority controlling the node list, nodes can create and take part in consensus by establishing their own quorum slices and adding new trustworthy nodes.
Quorum slices must overlap in order for the network to come to an agreement.
Transaction Validation and Fault Tolerance
A transaction needs to be successfully verified by every node in a specific quorum slice in order to be accepted and added to the ledger. Higher-tier groups may be given preference in verification if these quorum slices are arranged hierarchically. FBFT mechanisms, like those of other BFT systems, are designed to work well even in the event that some nodes behave arbitrarily or maliciously. Up to one-third of nodes may act deliberately or erroneously in a typical BFT system and still establish consensus.
According to the FBFT paradigm, consensus can still be reached as long as the majority of federated nodes behave honourably, even if some of them act maliciously. Additionally, if quorums partially overlap and there isn’t a rigid lower limit on quorum size, FBFT is made to allow forking.
Trade-off
Because the consensus process is managed by a federation of trusted nodes, which results in a centralized component, FBFT enhances scalability and transaction speed at the expense of partial decentralization.
Examples of FBFT Implementations
Two well-known blockchains that use FBFT are Stellar and Ripple. In Stellar, for example, nodes choose trusted nodes for communication and transaction verification in order to define their quorum slices.
Harmony’s Fast Byzantine Fault Tolerance (FBFT)
Fast Byzantine Fault Tolerance (FBFT), another name for Harmony’s consensus method, is characterised as an inventive improvement on the well-known PBFT technique. Compared to PBFT, this particular solution is intended to be an order of magnitude faster and more scalable.
Key features of Harmony’s FBFT
- BLS Aggregate Signature: BLS (Boneh–Lynn–Shacham) aggregate signatures are used by Harmony’s FBFT to drastically lower communication costs. This enables a consensus to be reached in less than two seconds by at least 250 validators.
- Consensus Phases: One validator acts as the “leader” for each consensus round, and there are three separate stages:
- Announce Phase: A new block is created by the leader, who then broadcasts its hash to every validator.
- Prepare Phase: After verifying the message’s authenticity, validators sign the block hash using a BLS signature and return it to the leader. When the leader gathers signatures that account for over two-thirds of the voting power (including its own), combines them into an O(1)-sized BLS aggregate signature, and broadcasts it together with the entire block, this phase comes to an end.
- Commit Phase: Validators check the new block and the aggregate signature, making sure it has at least two-thirds of the overall voting power. After receiving the block, they sign it and return their signatures to the leader. Once more, perhaps from different signers than in the preparation phase, the leader gathers signatures with more than two thirds of the vote, combines them into a BLS aggregate signature, and generates a bitmap for each signer. In order to ensure confidence commitment, the leader broadcasts the new block containing these bitmaps and aggregate signatures to all validators and commits it to its local database. On the mainnet, the entire process can be finished in two seconds.
Synchronous View Change
One disadvantage of BFT-based agreement that Harmony’s FBFT solves is the possibility of a malevolent leader slowing down the process. Instead of depending on erratic timeout mechanisms or presuming node liveness, the solution is an enhanced view change protocol that is totally synchronous and based on the local clock.
- A validator’s view ID is determined using each validator’s local clock and the amount of time that has passed since the last successfully committed block’s timestamp, rather than the live consensus progress. As long as more than two thirds of validators keep a reasonably accurate local clock which can be done by occasionally synchronizing with NTP time this will function.
- This enhancement ensures the liveness of the FBFT consensus by making the view change protocol reliable and operational as long as more than two thirds of trustworthy validators are online. The view change protocol additionally uses BLS aggregate signatures to further lower the cost of network transmission, making it a quick and easy operation that only takes a few seconds to finish.