IOTA 2.0 Introduction Part 11
TL;DR:
Consensus and access are key aspects of DLT security and protection against malicious nodes. IOTA 2.0 will employ committee-based consensus, where committee selection hinges on staked value to deter attackers. State reversion is guarded via conflicting opinion chains and supermajority consensus. For access security, the protocol introduces token-generated Mana and the Scheduler, thwarting spam by requiring tokens for block issuance, but without introducing fees. A decay factor ensures equitable Mana distribution, while the Scheduler ensures fair block allocation.
Security has been the major point of concern in DLT since its conception. In centralized monetary systems, fees are paid so banks and governments are responsible for keeping our money safe. This consumes the user’s funds and limits their control over their assets. This goes against IOTA 2.0’s vision of Digital Autonomy for Everyone.
To build the future of the Web3 economy and give users autonomy over their assets, the Tangle (the underlying data structure of the IOTA DLT) needs to be secure against all sorts of attacks and exploitations, and this blog post shows how we will achieve this with IOTA 2.0.
What does it mean for a DLT to be secure? It means that someone who wants to harm or exploit the network will not be able to do so by any means using the network.
Among the many targets of an attack on a DLT are consensus and access. Let’s check what kind of worries exist in these two components.
Consensus security: Preventing manipulation
Consensus is the basis of DLT security. Making sure nodes reach the same state of the ledger is equivalent to preventing value from being improperly generated or extracted from the network. Achieving a common state is just part of the objective, as making sure that this common state can’t be reverted is of equal importance.
(For an in-depth look at IOTA 2.0’s consensus, check out our wiki).
If a malicious node can decide what is included in the consensus, it could censor nodes at will, indefinitely delay the consensus mechanism, and freeze network operations. Additionally, the risk of double-spending emerges if consensus is susceptible to reverting. To counteract these threats, the following questions arise:
- How does the protocol prevent malicious nodes from deciding which transactions to accept?
- How does the protocol stop malicious nodes from preventing other nodes from achieving consensus?
The IOTA 2.0 protocol addresses these concerns through its committee-based consensus. By basing committee membership on staked value, attackers will need to invest a very large amount of money in the network (hence reducing the motivation to harm it) or will have negligible chances to be on the committee. Even in the improbable scenario that a malicious validator becomes a committee member, the weighted voting system means that their voting impact will be so low that they can’t decide on the ledger state nor delay voting by other nodes! Furthermore, the rotation of the committee also means that this malicious node can’t impact the network in the long term.
If, on the other hand, a malicious node carries a very high stake in order to manipulate the consensus, the effects of any manipulation would end up harming its own stake as the network loses value with any successful attack. In other words, no one can manipulate the ledger without losing value themselves.
The protocol also introduces a mechanism for reverting states in case of erroneous decisions taken due to communication problems. Changing the ledger state is difficult: By monitoring slot commitment chains and the voting weight of each possible chain, nodes switch opinions when a conflicting chain’s weight massively overtakes the current chain. For a standard node, this means that its current state disagrees with an overwhelming majority of the committee members (two-thirds of the committee’s voting weight, or what we call a ). If a malicious node can’t impact a single consensus outcome, it definitely can’t impact the state reversion process.
Access security: Ensuring fairness for all users
Access is the other important factor in DLT security. Here, “access” refers to the right and ability of a node to use the network, generally by issuing new blocks with data that aims to modify the ledger state. One of the main concerns of any user is that they will be able to use the network in a way that is fair (“fair” in this context means that users receive their share proportionally to their contributions to the network).
Thus, the protocol has to ensure that a malicious node can’t issue an unfair share of blocks (and thus prevent other nodes from being able to issue their fair share of blocks) nor congest the network in order to halt its operation.
So when talking about access, the two main questions are:
- How does the protocol prevent malicious nodes from issuing an unfair share of blocks?
- How does the protocol prevent malicious nodes from spamming and congesting the network?
The IOTA 2.0 protocol addresses these points using two primary tools of congestion control: Mana and the Scheduler.
As described in Understanding Congestion Control: Regulating Access in a Permissionless System, users burn their Mana in order to issue blocks. A block that is received by a node but hasn’t burned the required Mana will not be processed. This means that a spammer must hold a substantial amount of Mana to issue a large quantity of blocks. However, Mana’s decay factor curtails long-term accumulation, impeding the accumulation of excessive Mana for malicious purposes while the Mana Burn system adapts the amount to be burned over time, further limiting the potential for attacks from malicious nodes. This ensures that only legitimate users contribute to network activity.
The Scheduler complements this process by ensuring fair block allocation. It matches block issuance with the proportionate stored Mana, thus curbing the potential for malevolent users to exploit the system.
For more on IOTA 2.0’s congestion control, visit our wiki.
IOTA 2.0: Enhancing DLT Security for Web3 Autonomy
In conclusion, the IOTA 2.0 protocol will tackle DLT security concerns in two key aspects: consensus and access security.
- Consensus security helps prevent manipulation and maintain the integrity of the ledger. IOTA 2.0 implements a committee-based consensus system, where committee membership is based on staked value. This makes it economically unfeasible for attackers to manipulate the consensus, and even in rare cases where a malicious node becomes part of the committee, their influence is minimal, ensuring the network’s integrity and stability.
- Access security ensures fairness for all users in terms of their ability to use the network. The IOTA 2.0 protocol leverages Mana and the Scheduler to regulate access and prevent malicious nodes from issuing an unfair share of blocks or congesting the network. Mana’s decay factor and the adaptive Mana Burn system limit the potential for malicious accumulation, while the Scheduler allocates blocks fairly based on stored Mana, ensuring that legitimate users can contribute to network activity seamlessly.
In essence, attackers cannot spam, indefinitely congest the traffic or issue more blocks than they deserve. IOTA 2.0 promotes a fair and robust allocation where invested users can use the network feelesly, and all in a secure environment!
Published on November 13th, the next article in this series of blog posts will look at Dynamic Availability (the system’s ability to continue to accept or confirm transactions despite any number of validators crashing) and describe how IOTA 2.0. enables you to find your own balance between caution and optimism according to your needs.
IOTA 2.0 Introduction
Part 1: Digital Autonomy for Everyone: The Future of IOTA
Part 2: Five Principles: The Fundamentals That Every DLT Needs
Part 3: Data Flow Explained: How Nodes Process Blocks
Part 4: Data Structures Explained: The Building Blocks that Make the Tangle
Part 5: Accounts, Tokens, Mana and Staking
Part 6: A New Consensus Model: Nakamoto Consensus on a DAG
Part 7: Confirming Blocks: How Validators Operate
Part 8: Congestion Control: Regulating Access in a Permissionless System
Part 9: Finality Explained: How Nodes Sync the Ledger
Part 10: An Obvious Choice: Why DAGs Over Blockchains?
