Explaining Mana in IOTA

Last week, we released a new version of our Pollen testnet which contains mana. With this release, we demonstrated the maturity and the efficiency of our mana solution. Soon, mana will be implemented into many modules, an important step in the road to Nectar, our upcoming and first fully functioning Coordicide testnet.

With this important milestone, we thought we would clarify some common questions. Since our first publication about mana, which included an FAQ, several questions have been raised by different parties which we want to address with this post. We’ve sourced these questions from people in the community, through our Discord as well as Reddit. The questions are grouped by subject, and under some questions you will find the longform original question in italics.

Partner and community feedback is very valuable to us as it shows us which aspects are of particular interest, helping us to identify the areas in our full mana specification that we might optimize. The full specification will be published before we enter the “Nectar” stage of our existing “Coordicide” testnet.

Since our last post, there has only been one proposed change related to mana: users with zero mana could potentially be allowed to send messages when the network is not congested, as requested by partners and members of the broader community. We are investigating the possibility of issuing messages for low or zero mana nodes during periods of low congestion, on the condition that they have performed some additional task, e.g. proof of work. This is by no means easy or even possible. We’ll share what our research uncovers once we have results.

Please note that the questions about how much access a certain amount of mana guarantees are actually not questions about mana per se, but are actually questions about our congestion control algorithm. Thus, although mana itself is complete, the questions regarding zero mana nodes are still open. Shortly, we will be releasing another blog post explaining the IOTA Congestion Control Algorithm.

A quick refresher on mana

For those who did not read our first publication about mana, here is a quick review of what mana is and why it is important. Every time a transaction moves funds, that transaction “pledges” a quantity called mana to a node ID. Thus, mana can be thought of as Proof of Delegated Token Ownership. The only way to gain mana is by either controlling tokens, or having some sort of relationship with someone who does control tokens. The amount of mana that is pledged during a transfer is computed in a way so that an attacker cannot artificially inflate the mana held by a node.

Why is mana important? Without some sort of protection mechanism, attackers would be able to attack a network like IOTA by forging millions of fake identities in what is called a sybil attack. Therefore, all DLTs must prevent sybil attacks by connecting identity to some cryptographically verifiable scarce resource. Proof of Work and Proof of Stake respectively use energy and staked tokens as sybil protection mechanisms.

IOTA uses mana to prevent sybil attacks. This is why mana must be taken into account by all the core components of Coordicide, such as IOTA Congestion Control Algorithm, our consensus algorithm (FPC), autopeering, and our distributed random number generator. This is also why implementing mana into the Pollen Testnet was a major stepping stone to the Nectar phase of the testnet: it means that we can begin protections to key components of the core IOTA protocol from fundamental attack vectors.

The difference between mana and congestion control

Mana is our current initial proposal to measure node behavior. In the future, mana will evolve into a more complex multidimensional reputation system to evaluate a node's contribution to the network activity and its security. At the current stage, mana is used as input data to provide unforgeable identities for various Coordicide modules, including the IOTA Congestion Control Algorithm.

Mana characteristics

What is roughly the length of the decay function?
Is the mana's half-life closer to a minute or closer to a year?

Recall that with the mana 2 calculation method, mana decays according to an exponential function and thus must be refreshed with a new pledge. The decay half life will be a matter of hours, e.g. 6 hours. However, we want to see how this actually works out on the testnet, and we will adjust this parameter accordingly.

How is "active mana" measured?

"Active mana" can be computed in infinite ways, depending on its purpose. Being active could mean "the percentage of nodes that have sent at least one transaction in the latest X seconds" or it could mean "the percentage of nodes which have sent ‘enough’ transactions with regards to their reputation."

For the congestion control, the node does not need to know the active mana: the node simply looks at their inbox and reacts according to the mana of the issuing nodes. The information on the amount of mana any node holds is available to any node based on the issuing node ID that is part of every message that propagates through the network.

For FPC and autopeering, the peer discovery module maintains a list of known nodes that are currently online. The node uses this list for FPC queries and for neighbor selection.

Malicious behavior

Will mana run into the same problems from a lack of decentralization, like PoS tokens?
About 0.06% of addresses are holding ~65% of all tokens. This means that even if 99.94% of addresses contribute towards active, honest mana, that’s only ~35% of total mana. How is 0.06% of addresses controlling 65% of tokens not a problem for consensus, or voting, or data throughput?

First, the number of addresses does not correspond to the number of people using IOTA. For example, 35% of all addresses, i.e. 14000 addresses, hold less than 10 MI. It would be preposterous to suppose that these amounts are controlled by 14000 individuals. Wallets and various applications often spread funds across several addresses for various reasons. On the other hand, tokens in cold storage are often clustered onto a single address. Thus the above statistic is not surprising.

Secondly, this statistic is not a problem because the underlying security hypothesis is still satisfied. According to our simulations, an attacker would need to control at least 30% (sometimes more) of the active consensus mana to have a reasonable chance of attacking FPC and causing a double spend. Thus, a significant proportion of the top token holders would have to collude to do a double spend. Since the top .06% of addresses is still several hundred addresses, this seems unlikely. Furthermore, other attacks like censorship attacks or liveness attacks would require significantly more mana.

Thirdly, in any DLT, the access to the network has to be connected to some cryptographically verifiable, scarce resource. Typically, all resource ownership follows a Zipf distribution: a few have a lot, and others increasingly less. Thus this centralization concern is not unique to IOTA, but all endemic to all DLTs.

Lastly, proof of work/proof of stake solutions are rigid schemes. In comparison our approach is much more flexible. The idea is to build a multidimensional reputation system where mana is only one of the components. By using additional metrics – such as rewards for good behavior, notions of age and participation in the network, and reputation losses for selfish or misbehaving nodes – we aim to reduce the discrepancies in reputation across all nodes.

Will a centralized distribution cause problems?

IOTA 2.0 (“Coordicide”) is designed to not have large concentrations of power. Unlike most PoS systems, IOTA is not a blockchain and thus will not be limited by a leader election process. In a blockchain, blocks are sequential and so only a relatively small number of blocks are produced every hour, and thus there can be only so many block producers.

However, in a DAG, multiple people can add information at the same time, and so nodes with small amounts of mana can create messages at the same time as large mana holders. Even if you have a fairly small proportion of mana, that mana will guarantee you at least a minimal amount of access, and that access cannot be revoked regardless of how many large mana holders are saturating the network. Thus the IOTA Congestion Control Algorithm (ICCA) can support thousands of small mana holders. By proportionally allocating mana, we’re making sure that the “little guys” get their fair share of voting power or access.

Understanding the absolute minimum amount of mana needed to issue a message is part of the research involving zero mana nodes.

With enough mana, can you do a double spend?

Is it possible to approve double spends by approving two conflicting transactions and embedding them into the tangle if there are enough malicious node owners “approving” them? What’s the percentage of (active/passive) mana that would be required to successfully do this? How would honest nodes react to relayed, yet conflicting transactions a majority of malicious node owners/mana holders has voted to be legitimate?

With around 30% of the consensus mana, an attacker can potentially manipulate the voting algorithm to make a pair of double spends valid. With this attack, a fork would develop, until resolved, no messages would be final.

However:

No attacker will have 30% of consensus mana from IOTA holdings.
There will be no legitimate market for consensus mana, because it makes no sense to establish. Trading access mana has a legitimate use case, so a healthy market for that will likely grow. Consensus mana is purely for governance. Only attackers would buy it. It would take a long time and a lot of resources to build up a market position to get anywhere near a situation where you can achieve a plurality of the vote. It makes no sense for such a market to mature.

How do you prevent priority inversions?

This could happen with a high-mana transaction depending on a low-mana transaction.

If transaction A depends on transaction B, B is required to be in the past cone of A. If a high mana node issues a message with transaction A, and a low mana node issues transaction B, A will not be gossiped if B is not.

Furthermore – in the gossip protocol – nodes only “gossip upon solidification,” which means that a node will not gossip a message unless its parents have also been gossiped. In fact, the congestion control algorithm will not even consider a message until it has received its entire past cone.

How do you prevent "mana dusting"
“mana dusting,” or assigning mana to non-existing nodes and thus filling everyone's node tables?

We haven't officially specced out any particular solution to this potential problem yet.

Each module only requires “approximate consensus” on mana, which means that the protocol tolerates small differences in mana perception. Thus, mana dust can be deleted without repercussions. However, to enable small mana holders, it may make sense to allow mana dust to live for a short period, like a day or so, but afterwards it can be deleted.

“Free” transactions

When there is no congestion, can a zero mana node issue transactions?

In the current design for the congestion control algorithm, you need mana to send a message. This is to prevent sudden aggressive spam attacks from disrupting the network. As stated in the introduction, we are looking into the possibility of allowing nodes to do some proof of work in order to issue messages without mana. However, the opportunity to exploit the unused bandwidth at low cost can also favor malicious nodes trying to congest the network or, worse, to create ledger inconsistencies. Since IOTA is 100% permissionless, the solution to this problem is non-trivial.

An alternative is having mana faucets, which is something the IOTA Foundation or other big holders on the network could maintain. The idea is that nodes could automatically hold a list of faucets. From the node dashboard, the node operator can request a minimal amount of mana from the faucet.

Do you actually need mana for non-value messages?

The IOTA Congestion Control Algorithm treats all message types in the Tangle the same. Non-value transactions (data messages) will be processed in the same way as value transactions (value messages). In times of congestion, a node will require sufficient mana in order to issue either of them.

Do you need mana at all if you have just set up a node, and want to do a value tx?

You will not need mana to simply “set up a node” and monitor the tangle. 0-mana nodes can use the same peering mechanisms in Chrysalis to simply listen in on the network, although they will not have the eclipse protection that mana would afford them.

However, in our initial version of the IOTA Congestion Control Algorithm, in order to send transactions – or issue any type of message – you will need mana. As mentioned earlier, we are investigating how to allow nodes without mana to send messages when there is no congestion. We have a promising solution, but we need to make sure that it does not open any attack vectors. We will announce our findings at a later stage when this research is more developed.

mana market

What will be the market value of mana?

We don’t know. Mana is a technical solution for various problems in a decentralized IOTA network. The mana market is a by-product of our intention to create a permissionless protocol that is as free from restrictions as possible. We’ve vetted attack vectors that this solution brings, but will leave appreciation of its monetary value to the market.

There are however a few reasonable assumptions that suggest that mana will have some sort of market value. First, if the network becomes congested, access to the network – and hence mana – will become valuable. This is simple supply and demand economics, which applies to all DLTs. However this calculation will change with sharding, since sharding will greatly increase the supply of access.

Second, currently, some corporate entities might be hesitant to hold any crypto due to regulations, taxation, or general skepticism. Thus, renting mana through trusted IOTA infrastructure partners is a way that businesses can have guaranteed access without holding tokens.

Why can mana be pledged to a different node?

What was the reason for the decision to not assign mana to nodes processing transactions? Why should someone be able to assign mana to another entity?

We want to keep IOTA as flexible and free – meaning freedom, not “for free” – as possible. There are almost certainly complicated use cases down the line that we don't want to restrict for arbitrary reasons.

Anyone should be able to use Mana in the way that they see fit. That goes both for users and nodes. If you don't assign mana to the node processing your transaction, they don't have to process your transaction. They can insist that all value transactions they process pledge mana to their node ID.

However, your node might only need its access mana periodically, for instance at peak traffic times, only during weekdays or weekends, or at other intervals. If the node owner owns a lot of IOTA and has no use for (some of) the mana it generates, by being able to pledge it to other nodes, they get increased utility from their IOTA.

For example, some businesses might not want to hold tokens in the near future. Having crypto on the books can create legal issues in some jurisdictions, but they still might want access to the Tangle. By separating the pledge from the node that processes the transaction, it enables a market for them to buy access in exchange for fiat and circumvent legal issues.

Businesses might for example offer public nodes for users to use in order to benefit from the mana they generate through that.

What happens to unused access mana?

Unused bandwidth will be divided proportionally to the amount of access mana active users have.

This means that if for instance you have 1% of access mana and the bandwidth is 60% saturated, you can get at least 1% of the unused 40% allocated to you. Of the unused bandwidth after that you will again get 1%, in perpetuity, until the bandwidth is saturated.

This could congest the network to its hardcoded limit, but it never hinders any mana holder’s access to the network based on their mana.

Can anyone just spam cat pictures and congest the network?

The protocol can’t determine what is spam and what is not spam. This is a feature of permissionless innovation. While cat pictures might seem trivial to some, they might be very important for others. It’s not our place to determine this.

Anyone should be able to use the network as they see fit, even if others disagree. This is a core proposition of DLT, and mana enables this in a fair way. The composition of the congested network is limited by the amount of mana a spammer owns. The network could only consist of 100% of cat images if the spammer has 100% of active mana. Thus, even during this cat spamming event, you will still be guaranteed a fair throughput.

Congestion control

Stay tuned for our upcoming blog post on the congestion control mechanism.

How do you measure when the network is congested?

A Raspberry Pi can process only a fraction of an AWS node, so they would have very different perspectives on when "mana-based rate control" needs to kick in - and if they diverge, you have priority inversion effects again.

To start with, the congestion control algorithm doesn't need to tell if the network is congested or not. If there is no congestion, then the node’s inbox will be mostly empty. Every node in the network will process messages at a maximum fixed rate set by the protocol. This rate will determine the minimum hardware requirements of the node, including bandwidth and computational power. Any machine without these capabilities will not be able to be able to run a node. We will set this rate parameter to enable the type of machines we feel are necessary to operate a node.

In order for a small device to use the network, it does not need to run a node or even a wallet. Typically, today's IoT devices are controlled through a more powerful gateway, which has a reliable internet connection. The gateway can run a wallet or a node. Thus, to enable these low power devices, we only need to make sure that any applications used by low powered devices can work through a gateway.

In the future, sharding will enable a more diverse network, since not all devices will have to process all messages. Then low-powered devices can run smaller shards of the network as a node.

Can you game the system to congest the network?

What’s the percentage of mana held by honest node owners required to prevent artificial network saturation, in order to prevent the emergence of a market of fee-based transactions, assuming that malicious node owners might saturate the network artificially (“spam”) in order to be able to sell their network capacity (or mana) (to the highest bidder).

First of all, a potential mana market does not depend on congestion alone. Businesses that do not want cryptocurrency on their books will already be in the market for mana without congestion.

Next it is important to realize that your mana guarantees access to the network, proportional to the amount of mana you have. No amount of centralization from other holders can prevent your access; they can't unfairly congest the network. You always have that portion of the bandwidth available to you.

Node behavior

Can a node determine whether the issuer of a transaction would credit it with mana before accepting and relaying a transaction?

Yes.

Is that property signed?

Yes, the property is signed.

Can nodes easily reject transactions that do not pledge mana to them?

How costly is it for the node (wrt DoS) to resolve it synchronously so that it can possibly reject the transaction and the user can find out about it?

It is trivial to verify and reject such transactions.

The default setting is that in the communication between the wallet and the node, the wallet will ask the node to give a node ID to pledge the mana to. The node will then give the wallet the ID that it wants the mana pledged to. The wallet can request to pledge it somewhere else, and it’s up to the node to grant this request or not.

This behavior is not specified by the core protocol. It is not essential for security, and we don’t want to inhibit future use cases by setting such a rule. Anyone can construct node software to behave differently regarding how mana is pledged, in a way they see fit for their use case.

What happens when a node loses its mana due to malicious behavior?
What’s against pledging it somewhere else and retry the attack? Isn’t it cheap to repledge?

In IOTA 2.0, mana will not be revoked by the protocol from a misbehaving node. As suggested by the question, there are some obvious questions that would need to be resolved before adding this to the protocol. However, individual users can revoke their mana pledge in the case of misbehaviour. It is their responsibility however to pledge their consensus mana to honest sources.

We have given a grant to Mauro Conti’s group to study a more general reputation system that takes node behaviour into account. This is ongoing research and we will keep everyone posted about their findings.