Skip to main content

Consensus on IOTA

The primary goal of consensus in distributed systems is to establish a consistent order of transactions and ensure their availability. In IOTA, consensus is achieved through a combination of Delegated Proof-of-Stake (dPoS) and a Byzantine Fault Tolerant (BFT) protocol. Currently, the Testnet and Mainnet validators employ the Mysticeti BFT protocol, however they will switch to the Starfish BFT protocol, already deployed on the Devnet, once the validators accept the protocol upgrade.

IOTA's consensus mechanism ensures:

  • Low latency: Transactions are confirmed quickly due to efficient leader election and consensus mechanisms.
  • High throughput: The protocol can process a large number of transactions per second, ensuring scalability.
  • Fast finality: Transactions reach finality in a short time, reducing the risk of rollbacks.
  • Energy efficiency: Unlike Proof-of-Work (PoW), a BFT consensus mechanism requires minimal computational resources.
  • Security & decentralization: The protocol resists common attacks by relying on an honest majority of validators while maintaining a decentralized structure.

Delegated Proof-of-Stake (dPoS) in IOTA​

IOTA employs Delegated Proof-of-Stake (dPoS) as the overarching consensus mechanism. In this model:

  • Token holders delegate their voting power to validators.
  • Validators participate in block production and execute the Mysticeti protocol to finalize transactions.
  • Staking rewards serve as the main incentive for validators to behave honestly and secure the network.
  • This structure ensures security and decentralization while maintaining scalability.

Consensus Committee​

Validators that participate in the consensus protocol collectively form the Consensus Committee. This committee is responsible for executing the consensus mechanism and finalizing transactions.

Key Aspects of the Consensus Committee​

  • Validator Set: The consensus committee consists of validators, which are selected based on delegated stake.
  • Fixed Over an Epoch: The validator set remains unchanged during an epoch to ensure stability.
  • Roles of Validators:
    • Accept transactions and execute the consensus protocol.
    • Maintain a consistently ordered ledger state.
    • Prevent double-spending and conflicts.

For more details on validator staking, refer to the Validators Staking page. To understand epoch transitions, see the Epochs documentation.

The Mysticeti Protocol​

Mysticeti is a BFTA Byzantine Fault Tolerant (BFT) consensus protocol enables a distributed network to reach agreement despite malicious or faulty nodes. It ensures reliability as long as most nodes are honest. consensus protocol optimized for low latency and high throughput using an uncertified DAGA Directed Acyclic Graph (DAG) is a data structure where nodes are connected in a one-way, non-cyclic manner. In blockchain, DAGs improve scalability by allowing parallel transaction processing without a single-chain bottleneck. structure. It enables efficient and parallel transaction processing while maintaining strong security guarantees.

Key Features of Mysticeti​

  • Parallel Block Proposals Multiple validators can propose blocks simultaneously, maximizing network bandwidth and improving censorship resistance — a core advantage of DAG-based protocols.

  • Three-Round Finality Rule Blocks reach finality in only three rounds of communication, matching the efficiency of pBFT and achieving the theoretical minimum for BFT consensus.

  • Optimized Voting Unlike traditional leader-based protocols, Mysticeti allows validators to vote and certify blocks in parallel, significantly reducing median and tail latencies.

  • Fault Tolerance The protocol remains resilient even if some validators are offline or crashed, without substantially impacting commit latency.

🔗 Reference: Mysticeti Paper

Observed Limitations of Mysticeti​

Testing across the IOTA Testnet, Mainnet, and controlled local deployments revealed several scenarios where the Mysticeti performance may degrade due to network behavior or validator misbehavior, such as:

  • Disrupted or blocked connections between validators
  • Network latency patterns violating triangle inequality assumptions
  • Validators behaving adversarially or delaying messages

These conditions may increase latency or disrupt transaction propagation, limiting throughput under adverse or hostile environments.

The Starfish Protocol​

Starfish is a BFTA Byzantine Fault Tolerant (BFT) consensus protocol enables a distributed network to reach agreement despite malicious or faulty nodes. It ensures reliability as long as most nodes are honest. consensus protocol inspired by Mysticeti and designed specifically to address the limitations above while retaining its advantages.

Key Improvements Introduced by Starfish​

  • Decoupled Block Headers and Transaction Payloads Block header metadata is separated from transaction data, enabling efficient and flexible dissemination of headers.

  • Cordial Dissemination of Block Headers Even if multiple network routes are unavailable, a single functioning connection is sufficient to propagate block headers — without retries or request–response cycles. This ensures deterministic and predictable commit performance.

  • Linear Communication Cost for Transaction Data Transactions are encoded into shards using Reed–Solomon erasure coding. Nodes can reconstruct missing data from partial shards, removing redundant broadcasts and enabling scalable throughput.

These design improvements significantly strengthen Starfish’s robustness in Byzantine and unstable environments.

🔗 Reference: Starfish Paper