• Fantom Logo
  • Technology Tools Enterprise Ecosystem Developers
  • Fantom DeFi
      • Sub menu

        Intro to Fantom

        Fantom is a fast, scalable and secure platform for digital assets.

      • Sub menu

        Stake on Fantom

        Earn rewards by securing the network.

      • Sub menu

        FTM token

        FTM is the primary token of the Fantom ecosystem.

      • Sub menu

        The Consensus

        Discover Lachesis, Fantom’s ultra-fast consensus protocol.

      • Sub menu

        Opera Chain

        The Fantom mainnet, with staking and EVM support.

    • WALLETS

      • Sub menu

        Fantom Wallets

        Store, send, receive, and stake FTM on desktop, mobile, and hardware wallets.

      EXPLORER

      • Sub menu

        FTMScan

        A new Fantom explorer built by the Etherscan team.

      • Sub menu

        Opera Explorer

        Explore the network transactions, blocks, and nodes on Opera.

      • Sub menu

        OKLink

        OKLink is an alternative explorer for the Fantom network

    • GUIDES

      • How to use Fantom Wallet

      • How to set up Ledger Nano with Fantom

    • Sub menu

      Enterprise

      Discover Fantom’s solutions for enterprise clients.

    • Sub menu

      Solutions

      Take a deep dive in real world use cases.

      • Sub menu

        About us

        Meet the people behind Fantom.

      • Sub menu

        Partners and integrations

        Learn how we're creating a cross-chain ecosystem on our innovative platform.

      • Sub menu

        Blog

        Learn about Fantom through our general and tech articles.

      • Sub menu

        Podcasts and interviews

        Check out all the Fantom related interviews and AMAs.

      • Sub menu

        FAQ

        Do you have questions? We have answers!

      • Sub menu

        Community

        Join our wonderful community and share ideas.

      • Sub menu

        Careers

        Come work with us!

    • Sub menu

      Documentation

      Start building on Fantom

      GET STARTED

      Deploy a smart contract Create a fixed-cap asset Create a local test network GraphQL API docs

      GUIDES

      Set up Metamask Run a validator node
    • Sub menu

      Technical papers

      Read our technical papers and latest research essays.

      Covalent API
      The Graph's Subgraphs
      Verified contracts
      Frontend JS Utilities
      DeFi Smart Contracts
      Developers’ chat
Fantom Logo
menu
Fantom Logo close
  • Technology
        • Sub menu

          Intro to Fantom

        • Sub menu

          Stake on Fantom

        • Sub menu

          FTM token

        • Sub menu

          The Consensus

        • Sub menu

          Opera Chain

  • Tools
      • WALLETS

        • Sub menu

          Fantom Wallets

        EXPLORER

        • Sub menu

          FTMScan

        • Sub menu

          Opera Explorer

        • Sub menu

          OKLink

        GUIDES

        • How to use Fantom Wallet

        • How to set up Ledger Nano with Fantom

  • Enterprise
        • Sub menu

          Enterprise

        • Sub menu

          Solutions

  • Ecosystem
      • Sub menu

        About us

      • Sub menu

        Partners and integrations

      • Sub menu

        Blog

      • Sub menu

        Podcasts and interviews

      • Sub menu

        FAQ

      • Sub menu

        Community

      • Sub menu

        Careers

  • Developers
      • Sub menu

        Documentation

      • GET STARTED

      • Deploy a smart contract

      • Create a fixed-cap asset

      • Create a local test network

      • GraphQL API docs

      • GUIDES

      • Set up Metamask

      • Run a validator node

      • Covalent API

      • Verified contracts

      • DeFi Smart Contracts

      • The Graph's Subgraphs

      • Frontend JS Utilities

      • Developers’ chat

      • Sub menu

        Technical papers

What is Lachesis?

Lachesis is Fantom’s aBFT consensus algorithm. Simply put, a consensus mechanism is the engine that powers the blockchain.
Compared to Classical and Nakamoto consensus, Lachesis is a faster, more scalable, and more secure choice.
Developers can use Lachesis to build peer-to-peer applications without having to create their own networking layer.

Lachesis is:

  • Asynchronous: Participants have the freedom to process commands at different times.
  • Leaderless: No participant plays a “special” role.
  • Byzantine Fault-Tolerant: Supports one-third of faulty nodes, including malicious behavior.
  • Final: Lachesis’s output can be used immediately. There is no need to wait for block confirmations; transactions are confirmed in 1-2 seconds.
Header Image
Why Lachesis? What is a consensus protocol? Lachesis consensus How does Lachesis work?

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:

  1. pBFT uses a voting mechanism to elect a leader node in a round-robin format.
  2. The leader initiates the decision and broadcasts it to the secondary nodes.
  3. All the nodes, both the leader and the secondary nodes, send a response.
  4. 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
  • Epoch sealing is requested by the NodeDriver contract

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.

  • Technology
    • Intro to Fantom
    • Stake on Fantom
    • FTM token
    • The Consensus
    • Opera Chain
  • Tools
    • Fantom Wallets
    • Opera Explorer
  • Enterprise
    • Enterprise
    • Solutions
  • Ecosystem
    • About us
    • Partners and integrations
    • Blog
    • Podcasts and interviews
    • FAQ
    • Community
    • Careers
    • Media kit
  • Developers
    • Documentation
    • Technical papers
    • Covalent API
    • Verified contracts
    • DeFi Smart Contracts
    • GraphQL API
    • Frontend JS utilities
    • Developers’ chat
Social
  • Twitter
  • Discord
  • Telegram
  • Telegram ANN
  • Reddit
Fantom Logo

© 2023 Fantom Foundation

  • Cookie Policy
  • Privacy Policy
  • Terms of Service
  • Cookie Policy

The information on this website is for informational purposes only. It contains high-level summaries and is not intended to include all material information regarding the Fantom ecosystem and risk factors associated with holding FTM.