Mana comparisons

This post was written with Luigi Vigneri

The Coordicide project introduces node identities. In order to discourage the creation of counterfeit identities (Sybils), we require a Sybil protection mechanism, which links a certain difficult-to-obtain resource to each node. In the Coordicide, we propose to use the stake as such a resource, and we refer to it as mana. Mana is a crucial aspect in the following building blocks:

Rate control: the throughput of each node is bounded by the mana owned.
Auto peering: nodes with similar mana will be neighbors with high probability.
Voting: the weight of a vote is proportional to the mana owned.

In the future, we expect mana to be only a specific aspect of a more comprehensive reputation system which includes other criteria, such as penalties for misbehavior or incentives for helping the network.

Specifically, mana is a function whose input is a transaction, and whose output is the mana state, a vector which gives the amount of mana staked to each node. There are several different ways of defining mana, and we outline a few of the more popular choices.

Mana 1
This is the original Mana idea. When funds are spent from an account, the funds are pledged to a node. This pledge is revoked once the funds are spent again and pledged to a different node. At every moment, the total Mana in the system is equal to the number of Iota. The amount of transactions a node can issue is proportional to its Mana.

In this model, an issuer has two ways of getting Mana:

  1. It owns coins, and then pledges them to his own nodes.
  2. The issuer effectively rents the coins from other users, by exchanging their Mana with iota, cash, cows, or something else of value.

We say a node controls Iota if the node either owns the funds or rents them. The rate a node can issue transactions will be proportional to the amount of Iota they control.

Mana 1 is fairly straightforward, although it is vulnerable to the following attack. A node with a large amount of mana can constantly keep the mana state in flux by pledging its mana to different weaker nodes in quick successions. Although this may not be a problem for rate control, it might cause troubles in other mana applications.

Also, Mana 1 is hard to store. Indeed, one must store not only the balance of mana for an address, but also which spends contributed to those mana so that they can be removed.

Mana 2
Mana 2 aims to solve the volatility problem of Mana 1, and to provide a way for a node to prioritise transactions.

In this model, accounts generate potential Mana'' after funds are moved to an account. When the funds are spent, the potential Mana is converted to kinetic Mana’’ (note this is a recent term) and pledged to a node, and the potential Mana grows on a new account.

Potential Mana is calculated by
M_p=\frac{I}{\gamma}(1-e^{-\gamma t})
where \gamma is a constant, I is the amount of Iota on the account, t=0 is the time the funds were moved onto the account, and t the time they were spent.

Meanwhile, kinetic mana is given by
M_k=M_0e^{-\gamma t}
where M_0 is the amount of mana pledged at time t=0.

We can prove that actors cannot game the system by converting potential mana to kinetic mana more often. Specifically, the following is true (although we omit the proof).

Suppose an actor has I iota at t=0. No matter how many times he spends that money, the most kinetic mana he can have pledged to a node at time t is (I/\gamma)(1-e^{-\gamma t})

We can conclude several things from this lemma. First, the total mana available (either in kinetic or potential forms) is equal to
\frac{\mbox{Total Iota}}{\gamma}\left(1-e^{-\gamma(\mbox{Age of the system})}\right)
which approaches \mbox{Total Iota}/\gamma. Moreover, if potential mana is continuously converted to kinetic mana, then this will be the approximate value of the total amount of kinetic mana at each point in time.

Second, if a node controls I iota at time t (whether through rental or buying) then they will always have (either potential or kinetic) mana
\frac{I}{\gamma}(1-e^{-\gamma t})
at time t. If a node wants to maximise their kinetic mana, they must minimize their potential mana and constantly convert it to kinetic mana. In this case, the above value is effectively the amount of kinetic manna the actor will have. As time goes to infinity, the amount of kinetic mana a node controls approaches I/\gamma.

Mana 2 has three interesting features. First, once a node gains control, they must wait for their mana to gain their full potential. Second, a node has incentive to constantly issue transaction which convert their potential mana into kinetic mana. Third, this mana is easy to store and snapshottable: since they decay and growth is based on exponential functions, they can be deduced from changes in time: if I know someone’s potential mana at t_1 then I can deduce their potential mana at time t_2 for any t_2>t_1.

Since Mana regenerates, we can also use ``burn’’ it in transactions as a way of a node prioritizing one transaction above others.

One complication with Mana 2 is the time factor. It is debatable whether or not it is best to use the time stamp, the internal clock of the node, or a combinatorial invariant like rank to compute the passage of time.

Mana 5
(Mana 3 and 4 are theoretical exercises and thus not included in this document). In Mana 5, mana is never subtracted from a user. When a transaction is spent, the amount amount of mana generated by the transaction is given by I \Delta t where I is the amount of spent funds, and \Delta t is the time that the funds were held at the address.

Interestingly this mana can be easily stored. Indeed, suppose that an account has funds I_1,\dots,I_n added to it at times t_1,\dots, t_n respectively. Then at time t>t_i, the potential mana is given by
\sum_{i=1}^nI_i(t-t_i)=t\sum_{i=1}^n I_i-\sum_{i=1}^n I_it_i
Since \sum_{i=1}^n I_i is just the account balance, the node only needs to additionally store the second term \sum_{i=1}^n I_it_i which can be adjusted when a new transaction adds funds to the account.

It is interesting to note that amount of mana in the entire system is equal to I_{tot}t where t is the age of the system and I_{tot} is the total Iota.

Mana 6
In this proposal, potential mana is given by the same formula as in Mana 5. But, when actualized, the kinetic or actualized mana is given by
where t is the age of the system. In short, if Iota I entered an account at t_1 and spent and pledged at t_2, then the mana held by the node would be

Mana 6 is equivalent to Mana 5, except it is “normalized”. Indeed, the total amount of mana in Mana 5 is I_{tot} t is the total iota. So, we can simply divide everyone’s mana by t and now the total amount of mana always stays fixed at I_{tot}.

Mana 7
In the previous mana proposals, identities are very temporary and ethereal. If a node misbehaves, we can ban it, and its Mana can just be reassigned to a different node which is potentially operated by the same person.

In Mana 7 we propose having enumerated mana coins. The bearer of each coin can issue a certain, fixed TPS. Nodes can give mana coins to each other (in exchange for Iota). What is interesting about this mana is that identity is strongly enforced. Indeed, if a node misbehaves, we can punish the mana coin color, and thus the punishment can follow the coin to a new node. This provides new tools in the rate control algorithm

The downside of Mana 7 is that it is similar to a permissioned network. Because there is no rental abilities, most users will be unable to affect the distribution of mana in the network.

The various mana proposals are theoretically essentially the same: they all allow you to issue transactions at a rate proportional to the mana you control. Each proposal of course carries its own nuances, which we summarize below.

Mana 1: Simple, but potentially volatile. Perhaps difficult to snapshot.
Mana 2: Requires controllers to constantly spend, nodes must wait to achieve full rate. Time difficult to compute. Complicated formula.
Mana 5 and 6: Simpler formulas, but otherwise similar to Mana 2.
Mana 7: Provides immutable identities but loses rental ability.