Why Lachesis?
We created Lachesis to overcome the limitations of previous consensus algorithms. It is, in fact, the ideal option for applications that need high-throughput, fast finality, and bank-grade security.
In today’s fast-paced world, anything that requires a wait or delay of any sort would simply not be used.
Lachesis removes the barrier for creating fast, decentralized applications that anyone can use.
Whether you’re building an improved version of existing products
for sectors such as payments, supply chain tracking, healthcare data storage and more, or revolutionizing an up-and-coming industry like DeFi, Lachesis can do it all.
What is a consensus algorithm?
The consensus mechanism is the core of distributed technologies. In a decentralized environment, where no central entity validates transactions, the consensus protocol ensures that all the participants of the network achieve an agreement: the network as a whole validates transactions in a fully trustless way.
Classical consensus
Classical consensus protocols were created long before blockchain; they’ve been used since the 1980s in distributed databases.
Byzantine Fault Tolerance (BFT)
Byzantine Fault Tolerance is the ability of a distributed network to achieve consensus, therefore to continue to operate, despite incorrect information or malicious participants within the network.
Before Bitcoin, the only way to maintain Byzantine Fault Tolerance in a distributed network was to limit the number of nodes.
Practical Byzantine Fault Tolerance (pBFT)
Practical Byzantine Fault Tolerance is a model to reach consensus by enabling many computers to behave as one, a technique known as state machine replication.
The nodes reach consensus about a decision—such as the validity of a block in the case of a blockchain—by passing messages amongst each other about the decision. In this system, security increases with the number of honest nodes. The honest nodes agree on the correct decision and reject the incorrect decision proposed by malicious nodes, as long as the number of malicious nodes is less than one-third of the total.
pBFT systems are energy efficient; they do not need high computational resources or a lot of energy to operate. Furthermore, pBFT can reach consensus at a fast pace because all the nodes are in constant communication with each other, and there’s no need for multiple confirmations. Transactions are finalized as soon as the nodes agree on the decision.
The consensus achievement can be simplified in four steps:
- pBFT uses a voting mechanism to elect a leader node in a round-robin format.
- The leader initiates the decision and broadcasts it to the secondary nodes.
- All the nodes, both the leader and the secondary nodes, send a response.
- The response is considered valid when ⅔ + 1 nodes send the same response.
If the leader acts maliciously, it can be removed by the majority of the nodes.
However, constant communication is also pBFT’s Achilles heel: it only properly works in networks with a limited amount of nodes. The communication overhead increases exponentially with every new node that joins the network, and so does the time necessary to respond.
pBFT networks are also vulnerable to Sybil attacks, where one entity assumes multiple identities. The networks become more resilient to such attacks with a high number of nodes; however, with a higher number of nodes, the performance decreases, as seen above.
Nakamoto consensus
Satoshi Nakamoto designed a consensus mechanism that would solve the scalability issues of Classical consensus.
Nakamoto consensus is a BFT model created to operate in peer-to-peer networks with thousands of nodes, favoring decentralization and security. The model eradicates the communication overhead by introducing Proof-of-Work.
Despite the improvements, this model introduces other issues.
- Proof-of-Work requires all the nodes to solve complex mathematical problems, which consume an enormous amount of energy.
- It has a very high time to finality and a low throughput. In the case of Bitcoin, a new block is produced every 10 minutes by design. It’s safe to wait 3-6 block confirmations—around 30 to 60 minutes—before considering a transaction finalized. In Classical consensus systems, a transaction is considered final within seconds.
Asynchronous Byzantine Fault Tolerance (aBFT)
Asynchronous Byzantine Fault Tolerance is the highest standard of consensus algorithms. It solves the blockchain Scalability Trilemma, according to which only two of the following three components are possible at the same time:
- Decentralization
- Security
- Scalability
An aBFT consensus protocol allows for maximum decentralization, high scalability, and bank-grade security.
In an aBFT network, nodes can reach consensus independently conveys this information, and they don’t need to exchange finalized blocks.
For this reason, aBFT consensus mechanisms are completely leaderless, increasing security: there is no round-robin and no Proof-of-Work.
Unlike pBFT, which relies on the fact that all the messages shared among nodes will eventually be delivered, aBFT allows for messages to be delayed or lost altogether. Besides making networks particularly resilient to DDoS attacks, aBFT also lowers the transaction’s latency, resulting in a faster network.
Finally, aBFT networks allow for greater scalability and decentralization since there isn’t excessive communication to limit the number of participating nodes.
Lachesis consensus
Lachesis is a DAG-based aBFT consensus algorithm that offers tangible improvements over both Classical and Nakamoto models.
Lachesis is asynchronous, leaderless, and final while also being Byzantine Fault Tolerant.
Lachesis is designed to plug into applications written in any programming language easily. Developers can focus on building the application logic and integrate Lachesis to handle the state machine replication aspect.
Lachesis connects to other Lachesis nodes and guarantees that everyone processes the same commands in the same order. To do this, it uses peer-to-peer networking and a DAG aBFT consensus algorithm.
How does Lachesis work?
Each Lachesis node stores a local acyclic directed graph (DAG) composed of event blocks, each of which contains transactions. The DAG, capturing the happens-before relationship between the events, is used to calculate an exact final order of events—and hence transactions—independently on each node.
Event blocks are divided into confirmed and unconfirmed event blocks. New event blocks are unconfirmed, while event blocks from the past 2-3+ frames are all confirmed, and subsequently ordered by honest nodes.
Consensus results in batches of confirmed event blocks, where each batch of events is called a block. Finalized blocks forming the final chain are calculated from event blocks independently on each node.
Unlike Proof-of-Work, round-robin Proof-of-Stake, coinage Proof-of-Stake, and sync BFT, Lachesis nodes don’t; send blocks to each other. Only the events are being synced between nodes. Validators don’t vote on a concrete state of the network; instead, they periodically exchange observed transactions and events with peers.
Unlike Classical consensus, such as pBFT, Lachesis doesn’t use new events in the current election; instead, new events are used to vote for the events in 2-3+ previous virtual elections simultaneously. This leads to a smaller number of created consensus messages, as the same event is reused in different elections.
Hence, Lachesis achieves a lower time to finality and a smaller communication overhead compared to synchronous BFT.
What are epochs in Lachesis?
Lachesis’s event structure is a DAG of events. To optimize storage and retrieval, the DAG is separated into sub-DAGs, each of them is called an epoch. Each epoch comprises many finalized blocks.
Each epoch is sealed when one of these conditions is satisfied:
- The epoch reaches a defined number of blocks
- The epoch lasts for a specified time
- At least one cheater is confirmed in this block
When an epoch gets sealed, its inner epoch indexes get pruned, and new events of the sealed epochs are ignored. Each epoch forms a separate DAG, and thus parents from other epochs are not allowed.
For a sanity check, each event includes the hash of the previous epoch.
For a more technical and in-depth view of Lachesis, you can check our Wiki on GitHub.