Explaining Mana in IOTA

One of the topics in IOTA 2.0 that we frequently receive questions about is mana. This is an important topic, so we’re happy to explain more about the theoretical side of mana, as well as offer some insight into its implementation.

Our goal here is not to present the specifications from a technical and mathematical perspective, but rather, to help IOTA users understand this important Coordicide component at a theoretical and practical level. Of course, all of the details will be provided when we release the full IOTA 2.0 specifications.

This post covers:

• The basic requirement of every DLT to have both Sybil protection and congestion control. We explain how mana fulfills these theoretical requirements. One straightforward way to think about mana is that it is used to weight influence across different modules, including FPC voting, dRNG, autopeering, and congestion control.
• A presentation of a high-level view of our implementation of mana in IOTA 2.0.
• Comments and thoughts about how users will “interact” with mana in the live network.
• Some frequently asked questions from the community.

Every DLT needs a few different components, but in the context of this discussion, we will focus on the requirement for two specific features: a form of Sybil protection, and a way to control network congestion.

Sybil protection prevents an attacker from gaining undue influence over the network through the creation of multiple identities. Congestion control determines who has the ability to write to the ledger in times of congestion. Any DLT must contain components that fulfill these basic requirements.

Mana is perhaps best thought of as a tool that is used in various roles in the network. It is related to but also remains separate from the IOTA token. When a value transaction is processed, a quantity called mana will be “pledged” to a specified node ID. This quantity is related to the amount of IOTA moved into the transaction. The mana pledged to each node ID is stored as an extension of the ledger.

The only way to gain mana is to convince some token holder to pledge it to you. In this sense, mana is Delegated Proof of Token Ownership. Mana, therefore, provides adequate Sybil protection because it is difficult to acquire it in arbitrary amounts.  

Additionally, mana functions as a Sybil control mechanism in the congestion control algorithm. Thus, although various factors such as network usage affect a node’s message quota, the mana held by a node determines how many messages it can issue relative to the total network throughput.

The pledging process is performed twice, once for the modules dealing with consensus, and again for the congestion control. This is done in order to ensure maximal freedom and security in the network.

Because the incentives for security and access can potentially be at odds, this separation ensures that users will always be able to act in a way that best secures the network, while preserving their freedom to allocate access according to their economic interests. The token holder is thus able to delegate their access without giving the delegate any additional “weight” on the consensus process.

As we discuss later, token holders can lease their access mana, but there is no reason to do this for consensus mana. Specifically, this means that we assign two separate values for mana, which we refer to as consensus mana and access mana.

In this section, we list several important aspects of our mana implementation. We cover mana calculation, how mana is assigned to a node ID, and the role of mana in each of the IOTA 2.0 components.

In addition to the two uses of IOTA (Sybil protection and congestion control), our IOTA 2.0 implementation introduces two ways to calculate mana.

One way to calculate mana (commonly referred to as “mana 1”) is where the mana pledged is simply equal to the number of tokens moved in the transaction. The second way mana can be calculated (“mana 2”) is an augmentation of mana 1 which includes not only a delegated proof of ownership but also proof of node activity. Mana 2 has a predictable evolution over time, in the sense that it is not affected by additional token transfers. This predictability may be important for users interacting in an “access mana market” (more on this below), who want to ensure control over their purchased or leased access.

Our team is still studying which choice among these two is better by implementing both options in GoShimmer. Both options will work, but the final choice will be made through robust testing of both solutions simultaneously in GoShimmer.

We also value feedback received from partners and independent researchers. There is no rush to commit to one option at this stage, without first seeing it “in action.” We see this choice simply as choosing the better of two good options. Once mana is calculated, the protocol proceeds in the following manner.

The weight of both consensus and access mana of a given node is relative to the total “active mana,” or the mana held by nodes active in the network. For example, if a node has 5% of the total access mana and only 50% of the access mana is active, then a node will be able to add 10% of the total data allowed by the protocol to the Tangle.

Similarly, voting power is proportional to active consensus mana. The more consensus mana held by a node, the more FPC queries it receives, i.e. the more voting power it has. Likewise in the dRNG, the random numbers are issued by the top active mana holders. Although access mana guarantees a minimum access to the network, the total active mana determines the actual granted access.

Mana is used by every module in the protocol needing Sybil protection:

• Congestion control: The amount of data one can add to the tangle is proportional to their mana. If data is added to the tangle at a max rate of 1000 KB/s (Note: here we are just using a round number for discussion purposes), then a node with 5% of the mana can add 50 KB/s of data. Specifically, a node with 0 mana can issue no transactions.
• FPC: The probability a node will be queried is proportional to the amount of mana it holds.
• dRNG: Top mana holders set the DRNG.
• Autopeering: Nodes with similar mana peer, thus better protecting high mana nodes from eclipse attacks.

Now, to tie all of this together, we come to the rather important topic of how IOTA users will “interact” with mana.

For most users, mana will be a seamless part of using IOTA. While preparing the signed transaction, the user’s wallet chooses a node ID to pledge the mana to. Typically, the wallet will choose the node ID of the broadcasting node. The Node ID selection is indeed automatic in wallet software created by the IOTA Foundation. Please note that certain use cases may infrequently have mana assigned to node IDs other than the broadcasting node, for example when pledging mana to a new node.

As mentioned above, mana is pledged to a node ID. Technically speaking, node operators can acquire mana in three ways:

• Holding tokens: Node operators can buy tokens and pledge to their own nodes the mana generated by these tokens.
• Renting mana from token holders. Rent payments could be in IOTA or cash.
• Processing value traffic: A node can process payments in exchange for the mana pledged in those payments.

Mana’s role in the congestion control module becomes more important in times of network congestion. During such periods, the amount of active access mana will increase, and thus nodes need more access mana than in uncongested times to guarantee a certain throughput. With enough demand for access mana, it is natural to see that a mana rental market would arise, where token holders can potentially profit from leasing their mana. Smart contracts can be used to make this process a seamless part of the user experience. Given the relatively high network throughput of IOTA 2.0, we don’t expect non-spam congestion to occur for some time — meaning we have plenty of lead time to get our sharding solution in place as adoption grows.

When will mana be released on the Pollen Testnet?  

It is being implemented at the time of publication of this blog post.

How much mana is enough to send transactions?  

The answer to this question depends greatly on network conditions. Since bandwidth is finite when nodes are struggling with transaction flux, there must be a mechanism for prioritizing messages. The mana required to access the Tangle depends on how many transactions you want to send, and how congested the network is.

How does sharding affect mana?  

We are still in the early stages of defining how our sharding solution will work, but it will definitely have some sort of “sharded” mana. There are several possible ways of doing this. For instance, each address will belong to a shard, and when funds are spent from that address, the mana pledged can also be marked with that same shard.

Is mana a kind of Proof of Stake? Is it a kind of Delegated Proof of Stake?  

There are some similarities between mana and Delegated Proof of Stake. However, the terms PoS and DPoS denote a system where validators are elected to create blocks, receive rewards and fees, and can lose their stake if they misbehave. In our novel DAG-based approach, we do not have blocks, rewards, or fees, and so the comparisons between mana and PoS and DPoS are limited.

Is there a role for Proof of Work in IOTA 2.0? Does mana utilize Proof of Work at all?  

For all intents and purposes for honest users, there will essentially be no Proof of Work. The protocol will implement something called adaptive proof of work as spam prevention. Honest nodes creating transactions will have to do a very small amount of proof of work (much smaller than now) to create a message. However, a malicious node attempting to spam the network will be quickly penalized with enormous proof of work requirements which will physically limit their ability to create messages. This mechanism will not penalize honest nodes.

Mana will not use any sort of Proof of Work.

Does difference in perceptions of mana cause problems? Can an attacker exaggerate these differences?  

This is a very important question regarding the implementation of mana but has a very technical answer. Suppose a transaction moving a large amount of funds removes mana from node A and pledges it to node B. While the transaction propagates through the network, some nodes who receive the transaction first will temporarily see that node B has a lot of mana, and others will see that A has lots of mana. Moreover, an attacker with a significant amount of mana can send a sequence of transactions moving a lot of mana between various node IDs.

To ameliorate this attack, the protocol will compute mana with an exponential moving average. This means that the protocol will use two different quantities: base mana and effective mana. Base mana is an extension of the ledger state. It will be computed directly from the transactions added to the ledger state. Meanwhile, the effective mana will be the mana used by each module and will be periodically updated with the following recursive formula:  

New Effective Mana=α(Base Mana) +(1-α)(Old Effective Mana)

where α is between 0 and 1. With the exponential moving average, the effective mana slows the effect of changes in the base mana. Thus the large changes in the base mana in the attack above will only be registered slowly, and not before transactions have a chance to propagate throughout the network. The parameter α controls how slow these changes are.

Each module of the protocol can tolerate some discrepancies in mana perception. We will study in the GoShimmer network exactly how large these discrepancies can be, which will determine the appropriate parameter α.

As a new node, how can I get mana to access the system? Do I have to buy it? How long does it take to start sending messages?  

As we mentioned above, mana will be a seamless part of the user experience. The simplest way for a node operator to get started is to buy tokens of their own, create a transaction that pledges these tokens to themselves, and then find some other node to issue this transaction. The IF may also create a “mana faucet” where users can come and request a mana pledge for their node.

Once the node ID has mana pledged to it, the node must wait a few minutes for the exponential moving average to register the changes in mana, and the node will be free to access the network.

Are there strategies to accumulate mana that an attacker might use to attack the network?  

Mana is always associated with a node ID, which is simply a public key, and certain signed messages trigger the calculation of mana. Thus, a single physical node can easily operate using thousands of node IDs. However, neither splitting nor pooling is incentivized, since the benefit of mana is typically proportional to the amount pledged. In particular, without mana, a node cannot access the network. Mana can be pledged to any Node ID, even IDs corresponding to offline or nonexistent machines. Thus, we say that active mana is mana held by an active node.  

An attacker could try to accumulate mana for nefarious purposes, but the scarcity of mana should make this difficult. Moreover, since no market for consensus mana should develop, a Byzantine actor can only attack the consensus layer by buying tokens, and they would need more tokens than honest actors like the IF.

Is this mana system secure? What prevents an attacker to build up a high amount of consensus mana, sell all tokens, and then attack the system?  

Yes, the mana system is secure. Strictly speaking, consensus mana could be assigned at will. However, it is quite obvious that for anyone who holds iota tokens, there simply is no incentive to “trade” consensus mana. Only an attacker would have an interest in accumulating an undue amount of consensus mana, and so this is why IOTA’s design of separating consensus and access mana is so important. It allows access to be traded, while simultaneously allowing consensus to be protected. Regardless of the lack of incentive to trade consensus mana, an attacker still might try to purchase tokens with the goal of accumulating consensus mana, which could then be used to attack the network. Such an attack would be prohibitively expensive, however, as purchasing drives the price higher, and a large number of tokens would be required to execute an attack. In addition, selling tokens prior to an attack without crashing the price would take much longer than the consensus mana would retain its influence on the network.

Why has the IOTA Foundation not made a choice between mana 1 and mana 2?  

We are confident that both mana calculations serve the intended purpose. This is not a choice between good and bad, but rather between good and better. We want to see them both implemented in Pollen so that we can make an informed decision about which one performs best, or if there is in fact any practical difference between the two.  

Is mana a reputation system?  

Mana can be considered a very basic reputation system in itself, although we envision it to be one component of a reputation score. A good reputation system would take a node’s behavior into account, and the reputation would go to zero if the node misbehaved. We are currently funding a grant which covers this topic.  

We sincerely hope that this post has been informative for you. If you have any questions or comments, you can find our Research team members in the #tanglemath channel on our Discord. You are also welcome to follow and participate in our technical discussions on our public forum: IOTA.cafe.

Follow us on our official channels for the latest updates:
IOTA: Discord | Twitter | LinkedIn | Instagram | YouTube