Asynchronous Byzantine fault tolerance (ABFT) is a property of a consensus algorithm that allows the nodes on a network to agree on the order and timing of transactions.
After reading this, you'll understand:
Asynchronous byzantine fault tolerance (ABFT) is a property of consensus algorithm that enables honest nodes of a network to be guaranteed to agree on the timing and order of a set of transactions fairly and securely.
To get a deeper understanding of this, let’s begin by looking at what it means to be Byzantine fault tolerant. The term Byzantine fault tolerance is derived from a hypothetical scenario called the “Byzantine Generals Problem.”
This hypothetical scenario was developed to describe a problem that faces distributed ledger technology: how to reach a consensus without a central authority. In order to avoid the failure of a distributed system, the system's actors must agree on a concerted strategy (reach consensus), when some of these actors are unreliable.
The “Byzantine Generals Problem” illustrates this by looking at four Byzantine generals trying to coordinate an attack on an enemy city. These generals and their armies each occupy a different side of the city and so are totally separated from each other. Direct, coordinated communication is impossible. To plan their attack — or retreat — they must use their messengers to handle communication and so each sends his messengers to share his plan with the others.
But there are serious flaws in this approach. There are questions about the trustworthiness of the messages shared, such as: What happens if any of the messengers are captured and replaced with enemy messengers, who then provide intentionally false information? What if one (or even two) of the generals themselves is actually a traitor and sends a messenger with information meant to cause harm? What if one of the messengers is a traitor and intentionally shares false information?
You quickly begin to see that there is a trust issue embedded in the way these Byzantine generals are trying to come to a consensus (or total agreement) on whether to attack or retreat.
The answer is to use asynchronous Byzantine fault tolerance, a system that allows a distributed system to function even if some of the nodes (generals) aren't working properly. It gives you assurance that the network is going to act fairly.
All decentralized networks (distributed ledgers, such as a blockchain) have independent nodes that act like the Byzantine generals in the hypothetical situation above.
These nodes must come to an agreement, or consensus, on things like: transactions submitted to the network, the ordering of those transactions, and the state of the network itself. These network nodes are likely separated from each other geographically, virtually, architecturally, and sometimes even ethically.
So not only do nodes need to be able to communicate, in order to achieve their end goal of consensus, but they also need to account for some nodes being used for malicious attacks. Trust is a key issue here, as some nodes may be acting dishonestly on the network. They may be taken over by hackers or be intentionally sending incorrect information. Communication between what can sometimes be thousands of nodes makes coming to a consensus on a decision very challenging.
In a decentralized, peer-to-peer network, there is massive value in knowing that the timing and order of transactions taking place on the network have been reached by consensus, and that every transaction is recorded, verified, and shared by participating nodes — even if some of those nodes are not trustworthy, or may even be trying to negatively affect consensus.
In a decentralized network, this entire process has the additional benefit of having a mathematical guarantee of consensus, or that the same decision is reached by honestly participating nodes. This ability for the nodes in a decentralized network to come to the correct agreement on transactions without needing to trust each other — at scale — is what truly sets distributed ledger technology apart.
When a decentralized network is Byzantine fault tolerant, it means that the honest members, or nodes, of a network can be guaranteed to agree on the timing and order of a set of transactions. This is true regardless of whether some nodes are maliciously trying to prevent that consensus — even if as many as one-third of the nodes are trying to negatively affect consensus by delaying transactions or otherwise corrupting things. This is the "fault tolerance" of the network, meaning how many nodes can the network tolerate acting maliciously, but still come to an honest consensus.
The "asynchronous" property of Byzantine fault tolerance overcomes one of the challenges of fault tolerance, which is that of timing. Many forms of Byzantine fault tolerance assume there is a maximum threshold of message latency when coming to a consensus. Nodes must respond within a certain timeframe. However, this approach can be vulnerable to delays and network issues.
An asynchronous network eliminates this assumption and allows for some messages to be lost or indefinitely delayed — there is no dependence on synchronization. An ABFT network assumes only that at some point an honest node’s messages will eventually get through. It is much more challenging for an honest node to assess whether another node is not following the rules, if that node’s messages can be indeterminately delayed, but this scenario much better reflects that network reliability in the real world.
Nodes can reach consensus without the constraints of a fixed time window. This flexibility makes ABFT more robust and resilient against network latency and other potential disruptions.
Hedera's Hashgraph consensus protocol is ABFT — mathematically certified as the highest possible level of network security for distributed systems.
Here's a quick look at some of the benefits of using Hedera Hashgraph with ABFT:
Cost. A hashgraph distributed ledger costs much less to run compared to blockchain distributed ledgers, because it avoids energy-intensive proof-of-work for validation. Individuals and organizations can run hashgraph nodes via readily available hardware that is less expensive than specialized mining rigs.
Efficiency. The hashgraph is 100% efficient, in blockchain terms: the equivalent of a “block” of transactions never becomes stale. Hashgraph is also efficient in its use of bandwidth.
Throughput. A fast home internet connection could enable a hashgraph node to be fast enough to handle transaction volume equal to that of the entire global VISA card network.
State efficiency. Once a network transaction occurs, all nodes in the network will know within seconds where that transaction should be placed in a history of transactions with 100% certainty. More importantly, every node will know that every other node knows this.
Security. All Hedera network communications are encrypted with TLS 1.2, all transactions are digitally signed, and the hashgraph is constructed using cryptographic hashes. Hashgraph meets the standard required for protecting U.S. government Top Secret information.
Hedera is the only public ledger that uses hashgraph consensus, a faster, more secure alternative to blockchain consensus mechanisms. Backed by a network with asynchronous Byzantine fault tolerance, developers and organizations can be confident of system reliability and data integrity.