Understanding Congestion Control: Regulating Access in a Permissionless System

24.10.2023

IOTA 2.0 Introduction Part 8

TL;DR:

To manage congestion and ensure fairness, the IOTA 2.0 protocol will use a dynamic approach based on users’ Mana holdings. Our Congestion Control Mechanism includes a scheduler, Mana burn, and tip selection, all working together to provide consistent, fair, and secure network throughput with predictable fees.

As a directed acyclic graph (DAG), the Tangle enables blocks to be created in parallel, unlike the sequential order in blockchains. This requires a decentralized mechanism to impose some kind of order on how and when blocks are processed. In a DLT system, congestion control mechanisms manage network congestion: however, when a surge in transaction activity causes congestion in a traditional blockchain network, there can be unpredictable delays in transaction processing and exponentially increasing fees.

Conversely, in IOTA 2.0, we’ve designed a congestion control mechanism where throughput is dynamically allocated among users based on the Mana they hold (remember that Mana is the reward resource automatically generated by holding IOTA tokens). As depicted in the figure below, nodes add any valid block received by neighboring nodes (given that they include the necessary Mana to burn) to their local version of the Tangle before appending them to their scheduling buffer.

This blog post describes how congestion control will work in IOTA 2.0 by outlining its main components: the scheduler, Mana burn, and the tip selection. For a more detailed description, we recommend the Wiki version of this article, to be published on October 25th.

Traffic-aware anti-spam mechanism: Mana burn

When creating a block, the issuer must specify an amount in Mana that will be deducted from their Mana balance. This amount depends on block characteristics (e.g., signature, payload type) and Reference Mana Cost, which is objectively calculated for every slot commitment based on the recent traffic activity, namely on the number of blocks included in the previous slot commitment. This value will be known in advance by the user – you don’t have to make a bet or guess.

This mechanism acts as an anti-spam where the number of blocks each user can issue in a certain time interval is bounded as Mana accrual is capped too. However, while this “Mana burn” is registered by nodes as soon as the block is received, the Mana balances are updated only upon commitment. For this reason, the protocol punishes any misbehavior leading to a negative Mana balance by locking the account and its issuer deposit.

Some readers may have already noticed similarities with other protocols, say Ethereum’s EIP-1559, where the base fee adapts over time based on block size. But the situation changes when the traffic load increases… as we’ll see next!

Dynamic allocation and scheduler’s role

Other projects commonly rely on “priority fees” to choose which transactions will be part of the next block. However, when the available throughput (or “blockspace” in blockchain terminology) is not sufficient to contain all new transactions, it becomes impossible to predict or bound the cost of fees to be paid. In IOTA we take a different approach, sharing the blockspace proportionally to the issuer’s Mana.

A dynamic approach is key. It’s like sharing a pizza with four friends. Normally, you’d divide it into four equal pieces. But what if Joe wants more than his one slice while Mary would like a bit less? To make everyone happy, you’d divide the pizza into many small slices and then take a dynamic approach: in turn, you let each friend take a slice – first Joe, then Mary, John, and Lisa, then again Joe, Mary, etc. – until they’ve satisfied their hunger, eating as much or as little as they want.

Our scheduler, which decides which block should be processed next, works in a similar way: each block issuer (friend) is linked to a queue over which the scheduler iterates in a round-robin fashion (in turn, one at a time). The protocol schedules blocks from issuers depending on their deficit (hunger), a quantity proportional to the issuer’s Mana (see deficit round-robin algorithm).

In blockchains like Ethereum, you must add a fee to your transaction to increase its chances of getting processed and validated, leading to excessive prices under congestion due to unpredictable auctions where the highest bidder receives priority. In contrast, our scheduler makes bidding unnecessary and keeps any delay between the creation and dissemination of blocks to a minimum.

Tip selection

In IOTA 2.0, blocks that haven’t yet been referenced by later blocks are called “tips”. Each node keeps a pool of local tips, and when a new block is created, the node chooses between two and eight eligible tips at random from its pool. To be eligible, a block has to belong to the same slot commitment chain chosen by the node and satisfy certain time constraints: after all, we don’t want to reference blocks that are too old or that are likely to be pruned.

Blocks selected by the scheduler are then forwarded to neighboring nodes and added to the local tip pools. In a DLT, the act of blocks referencing other blocks is important because it links block creation to consensus: the more a block is referenced by other blocks, the more “weight” it gains, increasing the probability of being approved and the speed of being confirmed.

Conclusion: A unique approach

The IOTA 2.0 Congestion Control Mechanism satisfies several important requirements.

It is fundamental for consistency as it works as a pre-consensus guaranteeing that blocks issued by honest users are received by all honest users within a specific timeframe with high probability.
It provides fairnessby granting block issuers access to a portion of the network’s available throughput proportional to the amount of Mana they hold in their account.
It guarantees security in the sense that malicious actors won’t be able to affect the consistency and fairness of the system.

Going beyond that, our congestion control mechanism offers more benefits:

Predictability: Unlike traditional mechanisms that experience escalating fees during congestion, IOTA 2.0 sets clear and capped Mana requirements. As a block producer, you’ll know exactly how much Mana is needed to execute your transaction, ensuring transparency and predictability.
Feeless: IOTA 2.0 users can generate their own Mana to issue blocks and are not required to pay fees as in auction-like systems. No more worrying about exorbitant prices!
Efficiency: The blockspace is fully utilized thanks to the dynamic approach: If one doesn’t want a slice of pizza, another friend can eat it. In other words, everyone can access the network during low-congestion periods.

In conclusion, the IOTA 2.0 Congestion Control Mechanism is a unique approach to facilitating a fair sharing of network resources, ensuring efficient block delivery, and providing predictable assurances for block issuers. By leveraging Mana and implementing a scheduling buffer, IOTA 2.0 will pave the way for our future secure and scalable decentralized network.

The next blog post in this series looks at how nodes sync the ledger to achieve finality – look out for it on October 27th.