How Consensus Works on Fantom
In a decentralized system, consensus refers to the process by which participants in the system agree on a single blockchain as the truth, which contains all transactions of the system.
Consensus ensures that transactions are validated and added to the blockchain in a consistent and secure manner. It is crucial for the security and reliability of a decentralized system, as it helps to prevent malicious actors from manipulating the network or its data.
This article will leave readers with a high-level understanding of Fantom’s consensus mechanism, named Lachesis. A basic understanding of blockchain technology is expected.
Lachesis uses asynchronous Byzantine fault tolerance in combination with directed acyclic graphs to achieve consensus. Let's break down the basics of these concepts to better understand the technical jargon.
— Practical Byzantine Fault Tolerance
— Asynchronous Byzantine Fault Tolerance
— Directed Acyclic Graphs
— Lachesis
— The Role of Proof-of-Stake
Practical Byzantine Fault Tolerance
Practical Byzantine Fault Tolerance (pBFT) is a consensus mechanism designed to enable decentralized systems to function correctly in the presence of malicious or faulty nodes. It is named after the Byzantine generals’ problem, which is an idea that illustrates the difficulties of achieving consensus in a decentralized system when some of the participants may be acting in bad faith.
In a pBFT system, nodes in a network communicate with each other to reach consensus on the state of the system, even when there are some malicious actors like in the illustration above. To achieve this, they send messages back and forth that contain information about the state of the system and the actions they are proposing.
Each node verifies the message it receives, and if it determines the message is valid, it sends a message to all the other nodes to indicate its agreement. In the context of cryptocurrencies, the message with which all nodes must agree is the blockchain, a ledger that stores a history of transactions.
Before the invention of cryptocurrencies, the major flaw with pBFT systems was their susceptibility to Sybil attacks. If an attacker controlled sufficient nodes, they could control the entire system; there needed to be a deterrent to launch many nodes, which Bitcoin solved first with proof-of-work, which forced nodes to invest considerable energy to partake in the consensus.
Since then, many new solutions have been developed, such as proof-of-stake that forces nodes to deposit tokens that have monetary value, which is the solution Fantom uses.
Hence Practical Byzantine Fault Tolerance is a mechanism to achieve consensus, and when coupled with proof-of-work or proof-of-stake to deter participants from messing with the network, it forms a functioning decentralized system. However, Fantom has decided to innovate on this mechanism by using Asynchronous Byzantine Fault Tolerance.
Asynchronous Byzantine Fault Tolerance
With Asynchronous Byzantine Fault Tolerance (aBFT), nodes are able to reach consensus independently, and they are not required to exchange final blocks sequentially to confirm transactions; while they do exchange blocks, which is required to achieve consensus, this is done asynchronously. Each node verifies transactions on its own and is not required to incorporate blocks created by other miners or validators in a sequential order.
This is opposed to pBFT systems, such as Bitcoin, in which the majority of nodes must agree to a block before it becomes final that they must then sequentially order into their own blockchain record. This slows down the network during times of high traffic; more on this in the Lachesis section further below.
Now that we have a basic understanding of Byzantine fault tolerance, let’s delve into the second part of Fantom’s consensus mechanism, directed acyclic graphs.
Directed Acyclic Graphs
A graph is a non-linear data structure used to represent objects, called vertices, and the connections between them, called edges. For example, a graph used to represent social media connections would incorporate each user as a vertex and their connections to other users as edges.
A directed graph dictates that all its edges, the connections between objects, only flow in a certain direction. An acyclic graph does not contain any cycles, which makes it impossible to follow a sequence of edges and return to the starting point.
As such, a directed acyclic graph (DAG) only flows in a certain direction and never repeats, or cycles.
The diagram to the right is an example of a directed acyclic graph. Each oval is a vertex, and the lines connecting them are edges. The vertices only connect in one direction, downwards, and never repeat.
Now imagine the same structure in the diagram used to represent blocks full of transactions connected to each other. In a block DAG, each block is represented by a vertex, and the relationships between the blocks are represented by edges. For example, the edges may represent the dependencies between the blocks or the order in which they were added to the DAG.
In a block DAG, multiple blocks, each of which contains transactions, can be created and added to the DAG concurrently. The blocks do not need to be added in a specific order, which enables the system to achieve faster transaction times as it is not limited by the requirement to incorporate blocks sequentially, as is the case with many of the biggest blockchains currently available.
Hopefully, now we have a decent understanding of both Asynchronous Byzantine Fault Tolerance and directed acyclic graphs. Let’s explore how the combination of these two form Fantom’s consensus mechanism, Lachesis.
Lachesis
Lachesis is a proof-of-stake, DAG-based, aBFT consensus mechanism. In Lachesis, each validator has their own local block DAG and batches incoming transactions into event blocks, which they add to their DAG as vertices — each event block is a vertex in the validator’s DAG that is full of transactions.
Before creating a new event block, a validator first needs to validate all transactions in its current event block and part of the ones it has received from other nodes; these are the event blocks it has received during the asynchronous exchange of event blocks explained in the section above. The new event block then is communicated with other nodes through the same asynchronous event communication.
During this communication, nodes share their own event blocks, and the ones they received from other nodes, with other validators that incorporate them in their own local DAGs. Consequently, this spreads all information through the network. The process is asynchronous as the event blocks shared between validators are not required to be sequential similar to how blocks are in a blockchain.
Unlike a blockchain, this DAG-based approach does not force validators to work on the current block that is being produced, which places restrictions on transaction speed and finality. Validators are free to create their own event blocks that contain transactions and share these with other validators on the network asynchronously, creating a non-linear record of transactions. This increases transaction speed and efficiency.
However, blockchains have a role as well in Fantom’s consensus mechanism. As an event block is sent and propagated across validators, it becomes a root event block once the majority of validators have received and agreed upon it. This root event block will eventually be ordered and included in the main chain, which is a blockchain that contains the final consensus among all event blocks that have become root event blocks.
Every validator stores and updates a copy of the main chain, which provides quick access to previous transaction history to process new event blocks more efficiently. As such, the Lachesis consensus mechanism combines a DAG-based approach that allows validators to confirm transactions asynchronously, which greatly increases speed, with a blockchain that orders and stores all final transactions immutably and indefinitely.
Currently, the process of submitting a transaction and having it added to the Fantom main chain through the Lachesis consensus mechanism takes approximately 1-2 seconds. This involves the following steps:
- A user submits a transaction
- A validator node batches the transaction into a new event block
- The event block becomes a root event block once the majority of nodes have received it
- The root event block is ordered and finalized into the main chain as a block
When a user explores Fantom through a block explorer, they view the final blocks on the Fantom main chain. Event block generation and exchange in validators' DAGs is an internal process only and is not visible to end users.
For a more technical understanding of Lachesis, read Lachesis: Scalable Asynchronous BFT on DAG Streams.
The Role of Proof-of-Stake
Proof-of-stake and proof-of-work commonly are mistaken for consensus mechanisms. However, they’re solutions to secure the consensus mechanisms against Sybil attacks from malicious actors.
In Fantom’s Lachesis consensus mechanism, and every other consensus mechanism for decentralized systems, what is stopping someone from launching millions of validator nodes to control the consensus by verifying only their own blocks full of false transactions?
In proof-of-work, the energy consumption required to run the computations needed to validate blocks acts as a deterrent for malicious actors from launching multiple nodes to manipulate the network for profit. The intensive computational power needed to run these nodes is far greater than the potential reward of messing with the network.
In proof-of-stake, which is the solution Fantom uses, validators must deposit tokens that have monetary value; if they mess with the network, they lose their tokens. Validators are incentivized to act in the best interest of the network because their own funds are at stake. As the validators do not need to run computations either, this is a far more energy-efficient alternative to proof-of-work!
