In the previous post, we talked about DEXON’s Byzantine agreement, which is the core technology that allows DEXON to achieve fast finality and high throughput. In this article, we will dive into DEXON’s Byzantine agreement algorithm and explain how truly powerful it is.
Table of Contents1. The Byzantine Generals Problem
2. Applying the solution to the Byzantine Generals Problem in Blockchain
3. DEXON's Byzantine Agreement
4. Responsiveness
5. Partition-Resilience
The Byzantine Generals Problem
Before we talk shop, time for some lessons in history first.
The Byzantine agreement was first introduced by the Turing award laureate, Leslie Lamport in 1982. The situational problem that was formulated is as follows:
- Imagine that there are three Byzantine generals discussing whether to attack a town or not.
- But if only some of them attack, they might get defeated.
- Regardless of the decision to attack, they must act together.
- However, coming up with a decision is made even more complicated by the fact that discussing face-to-face is impossible and the only option is to send messages one-by-one.
- Ideally, if all the generals are loyal, they can just send their decision to each other and the majority decision wins.
- Here’s one way the decision could turn out (see figure 1): two generals want to attack and only one wants to retreat, and majority wins so they will attack.
But reality can be cruel. Some generals could possibly be traitors and betray their comrades by sending inconsistent decisions to other generals — he could say he decides to attack to one general and retreat to the other (see figure 2).
If this is the situation they are stuck in, how can the loyal generals agree on a final decision with full consensus from each other?
This analogy of the Byzantine generals is an important thought experiment to understand the importance of setting up a mechanism that can guarantee consensus — and achieving consensus is one of blockchain’s strongest features. Thus, what’s popularly known as the “Byzantine Agreement” alludes to the Byzantine generals analogy as a solution to their conundrum.
Applying the Byzantine Agreement principle in blockchain technology, it aims to reach a consensus among many distributed nodes — with some nodes having arbitrary types of failures (such as shutting down, sending abnormal messages, and so on).
Applying the solution to the Byzantine Generals Problem in Blockchain
“Which blocks can be accepted and connect to the blockchain?”
The question above is a central problem in achieving consensus in the blockchain.
Applying the Byzantine Generals Problem in the context of blockchain technology, we can formulate that:
Each validator (general) has its own blockhash (the decision to attack or retreat), and all the validators (all the generals) will agree on the same blockhash (the final decision to attack or retreat) by following the Byzantine agreement protocol. Thus, the block corresponding to the blockhash is the block that is accepted by the honest validator.DEXON’s Byzantine Agreement
So how can we still reach consensus knowing that some nodes could be faulty?
In this case, this is not a rhetorical question, but a real issue that needs to be solved in the blockchain.
In blockchains systems, everyone is required to have the same view regardless of the existence of faulty nodes that are trying to fork the chain or tamper its history.
Staying true to the lessons we have learned from the Byzantine generals, the Byzantine agreement protocol is at the core of DEXON’s consensus algorithm — guaranteeing the security of the network. With rigorous academic analysis, DEXON’s Byzantine agreement is scientifically recognized to be “responsive” and “partition-resilient,” where the former makes DEXON faster and the latter makes DEXON more secure.
Responsiveness
Many blockchain systems are bound by a predetermined time to remain secure. For example, the block time of Bitcoin is 10 minutes and 15 seconds for Ethereum. If we want to decrease the block time of these blockchains and make the system go faster, the security of the network could be compromised and users can fork the chain for their own malicious agenda. Moreover, having a predetermined time can still be problematic even if the network is fast, regardless of the network speed, we still have to wait for the time bound. This only increases our waiting time (and our frustration!).
With all these considered, a new hypothesis arises, “can there exist a blockchain system where only substantive network obstructions can cause delays and not be inherently laggy because of some predetermined time-bound?”
The answer to this question lies within the responsiveness of DEXON, which is a feature thoroughly integrated into DEXON’s Byzantine agreement. More importantly, a truly responsive network is achieved in DEXON without sacrificing network security.
How can DEXON achieve responsiveness and staying secure? Briefly speaking, if the network is operating normally, the block proposers are decided by a list. As the proposer propose a block, other nodes acknowledge the block as soon as they have verified the transactions. The list is ranked at random for each block and is updated every hour. All the nodes work immediately as they receive the messages without waiting for any time bound. The process previously described is how DEXON is able to perform at such high speeds.
Partition-Resilience
To truly perform at great capacities, every possible scenario must be considered and be prepared for, accordingly. So if you’re wondering if DEXON can still stay secure even when the network gets broken, the answer is a resounding, yes, of course! DEXON’s security is guaranteed by our Byzantine agreement even if the network fails in an arbitrary manner.
The CAP theorem states that any distributed system cannot achieve these three properties at the same time: consistency, availability, and partition-tolerance. So is it truly impossible to build a blockchain system that achieves consistency and availability (in most cases) but sacrificing the availability only when the network is partitioned? That is, even if the network fails arbitrarily, the safety of the consensus still holds, and the algorithm will operate normally once the network recovers.
Although the network today is highly reliable, failure can still happen occasionally — underwater cable may still break or cloud services can still experience disruption. DEXON consensus is the first Byzantine Agreement that achieves both responsiveness and the partition-resilience. And as a result, if the network operates normally, DEXON proceeds rapidly. But on the event that the network fails, the safety still holds and the system should still work as expected once the network recovers.
What is noxed?
Noxed is a brand new learning series produced by the DEXON Foundation where we explain the ins and outs of DEXON in written, video, or visual formats. If there’s a topic about DEXON technology you want us to cover, let us know in the comments.
Upcoming
In the next post, we will go back to the bigger picture of DEXON and talk about:
- How the notary set is selected
- How the epoch change mechanism works
Let’s talk about DEXON
You can register for the newsletter for the latest updates, or join us in our various community discussions in different platforms.
✅ Telegram discussions: https://t.me/dexon_foundation
✅ Announcements: https://t.me/dexon_news
✅ Scam alerts: https://t.me/dexon_scam_alerts
👩💻 Gitter (DEXON’s official dev chat): https://gitter.im/dexon-foundation/Lobby
👩💻 Github: https://github.com/dexon-foundation
👩💻 Reddit: https://www.reddit.com/r/DEXONFoundation/
👉 Twitter: https://twitter.com/dexonfoundation
👉 Faceboook: https://www.facebook.com/DEXON.Foundation/
👉 YouTube: https://www.youtube.com/channel/UCbg6l4M8QmSrJphxQvKof5g
👉 Medium: https://medium.com/dexon
