Blog Unicorn Ultra (U2U)

Categories: U2U Ecosystem

What is Asynchronous Byzantine Fault Tolerance (ABFT)? Everything You Need to Know about ABFT

In the evolving world of distributed systems, ensuring security, reliability, and trustworthiness is of paramount importance. As we move towards a decentralized future, finding solutions to the inherent challenges of these systems becomes crucial. One such challenge, rooted deeply in historical context, is the Byzantine Generals’ Problem, which highlights the complexities of achieving consensus in an environment filled with unreliable actors and communicators.

This article delves into the intricacies of this problem, its implications for decentralized systems, and the advent of Asynchronous Byzantine Fault Tolerance (ABFT) — a groundbreaking solution that promises to redefine the way we think about consensus and reliability in distributed networks.

Discover more: Partnership For The Next Big Things: Unicorn Ultra x


Byzantine Generals’ Problem

Byzantine Fault Tolerance is directly related to the Byzantine Generals’ Problem — a concept that was first introduced in 1982 that discusses the reliability of computer systems. The dilemma was described as:

Imagine that several divisions of the Byzantine army are camped outside an enemy city, each division commanded by its own general. The generals can communicate with one another only by messenger. After observing the enemy, they must decide upon a common plan of action.

However, some of the generals may be traitors, trying to prevent the loyal generals from reaching an agreement. The generals must decide on when to attack the city, but they need a strong majority of their army to attack at the same time.

Discover more: Super Apps Insight #4: Unleashing Financial Frontiers In The Symphony of DeFi and Super Apps

The generals must have an algorithm to guarantee that:

  • Each general has to decide to either attack or retreat.
  • All generals have to agree on the same decision and execute it in a synchronized manner.
  • After the decision is made, it cannot be changed.


The difficulty lies in the fact that these generals can only communicate with each other via a courier. While each general may act maliciously, there also exists a lot of problems with the messenger: they can fail to deliver the messages on time or completely, deliberately change the content of the messages,…

Although there are uncertainties regarding both the generals and the couriers, a reliable distributed system must be able to account for such possibly malfunctioning components. Even when some participants behave maliciously, a trustworthy system must be capable of functioning normally and producing the correct, expected results without having to delegate trust to an intermediary.

Discover more: Partnership For The Next Big Things: Unicorn Ultra Network x Ecomtancy

In the context of distributed systems like the blockchain, these generals can be understood as the nodes, while the messengers act as the communication between these nodes. Using the internet as a communication method is as unreliable as these couriers in the aforementioned problem, considering that there is always a chance they will fail to deliver/transmit the messages.

What is Byzantine Fault Tolerance (BFT)?

Byzantine Fault Tolerance (BFT) refers to the ability of a system to withstand such failures as mentioned in the Byzantine Generals’ Problem. The higher the resistance, the higher the level of BFT the system achieves.

When the Byzantine Generals’ Problem was first introduced, it was proved and concluded by the authors that this problem can only be solved if more than ⅔ of the generals act honestly. Initially, this number was not promising enough for a reliable distributed network. Nevertheless, over time, there have been tremendous improvements to the dilemma, dramatically increasing the resistance of modern decentralized systems.

The development of BFT solutions

BFT solutions were essential to the development of distributed systems. The rise of these systems date back to a few decades, as far as when people came to realize how incredibly flawed centralized systems were.

In computation, one of main problems with centralized systems was the possibility of complete failure due to accidents. In early days, computing hardware was mostly gathered in mass, leading to potential accidents like outbursts of fire or water, causing the failure of the whole system.

Another issue was that the servers can be easily hacked, leading to a low level of security. Centralized systems ultimately rely on a single source; therefore, if the safety of that exact entity is compromised, there is no way for the system to recover or make up for this loss.

The last shortcoming of centralized systems in computation is that they are extremely hard to scale. As mentioned above, centralized systems require computing hardware to be gathered locally, at one single location. Other than the exposure to accidents, it can be inferred that this limitation also makes such systems unscalable, geographically and systematically.


In other fields like finance or accounting, centralized systems rely heavily on trust. Centralized entities, like banks, act as the intermediary that has complete control over the flow (input & output) of the system. Therefore, it is easy for them to manipulate the data at their own will. Some even decide to purposely sacrifice transparency in exchange for efficiency and productivity of the system, which essentially makes their services faster but more risky and insecure. To us users, this tradeoff is terrible, especially when talking about finance & accounting when safety and transparency should be the number one priority.

The advent of Bitcoin represents a breakthrough among BFT solutions, because of how it can address both of these problems. Bitcoin’s consensus algorithm, Proof of Work, was the first solution to the Byzantine Generals’ Problem that probabilistically guaranteed trustless consensus in a permissionless setting while being able to resist the failure of less than 50% of participants. Compared to the original method which can only handle the misbehavior of less than 33% of participants (⅓), Bitcoin with Proof of Work is definitely a significant advancement.


Nevertheless, as groundbreaking as it is, there are some critical drawbacks with Proof of Work. Most importantly, it is unscalable. At its core, Bitcoin operates on a synchronous system where the state of its ledger is updated at discrete and relatively regular intervals, typically around every 10 minutes with the addition of a new block.

This rhythmic cadence is essential for ensuring network-wide consensus and avoiding double spends. Unfortunately, smart contracts are not scalable in linear and the synchrony of the Bitcoin blockchain makes it impractical for decentralized applications that require high throughput and fast finality.

Hence, while the emergence of Bitcoin is indeed revolutionary, the research for better BFT systems continues. While there have been some modified BFT-based consensus algorithms such as practical Byzantine Fault Tolerance (pBFT) or delegated Byzantine Fault Tolerance (dBFT), they are still synchronous or partially/weakly synchronous.

Synchronous consensus algorithms have a vulnerability to time-delay attacks because they rely on time-limited message transmission to reach consensus. This makes them a less robust form of Byzantine Fault Tolerance (BFT) since they operate based on time assumptions. As a result, it’s challenging to ensure ongoing operations in hostile environments where time-based attacks are prevalent, especially in contexts like the internet.

To really improve BFT models, we have to make them asynchronous which allows them to make no timing assumptions in order to achieve consensus.

What is Asynchronous Byzantine Fault Tolerance (ABFT)?

The asynchronous property of Asynchronous Byzantine Fault Tolerance overcomes a challenge 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. An Asynchronous Byzantine Fault Tolerant (ABFT) network eliminates this assumption and allows for some messages to be lost or indefinitely delayed.

An ABFT network allows for messages to be lost or indefinitely delayed and 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 indefinitely delayed, but this scenario much better reflects that network reliability in the real world.

At U2U Chain, we use the Directed Acyclic Graph (DAG) architecture along with the Gossip about Gossip with Virtual Voting consensus algorithm, allowing us to achieve not only Byzantine Fault Tolerance but also asynchronous — a much higher level of fault tolerance in a distributed network compared to other existing methodologies. Thanks to this, U2U Chain is much more resilient, secure, and scalable for dApps with high throughput and fast finality.


The journey to establish a secure and fault-tolerant distributed system has deep historical roots, originating from the Byzantine Generals’ Problem. This problem underscored the challenges of ensuring trust and reliability in environments where both communication and participants might be unreliable or even malicious. While traditional consensus methods, like Bitcoin’s Proof of Work, represented monumental leaps forward, their synchronous nature rendered them vulnerable to timing-based attacks and scalability issues.

Asynchronous Byzantine Fault Tolerance (ABFT) heralds a paradigm shift in addressing these challenges. By eliminating time-bound assumptions from consensus mechanisms, ABFT offers a more resilient, adaptable, and reflective model for real-world network unpredictabilities.

U2U Chain incorporates advanced consensus algorithms and structures like DAG, underscores the potential of ABFT in fostering the next generation of decentralized platforms. U2U Chain promises not just fault tolerance, but also the scalability and finality required to usher in a broader adoption of distributed technologies.

Relate Post