Objective mana based on "local clocks"

🌌 Research Coordicide
1

People who have been following my discussions about the new “multiverse consensus” with Serguei Popov have most probably realized, that most of the discussions concerned the way how mana is calculated.

The basic idea of the “multiverse consensus” is, to put the votes on the tangle (as part of the transactions) and allow nodes to reach consensus by passively observing the statements of others. This would allow us to reach consensus without having to exchange any additional vote messages. For this to work, nodes however need to have consensus on mana (everybody needs to “read” the tangle in the same way to come to the same conclusions).

My initial idea was to use something like the “rank” of a transaction (its distance from genesis) to calculate the mana vector. Since the rank of a transaction is defined by its position in the tangle, everybody would calculate the same mana vector and we would have absolute consensus on mana.

Serguei however pointed out that the rank is “gameable”. An attacker could issue a long chain of transactions that would modify the “perception of time” and allow attackers to gain more mana than the other honest nodes in the network (remember: mana = coins * timeHeld [simplified]).

He therefore favors to use the “local clock” of nodes to calculate the mana vector because this is not “attackable” by gaming the structure of the tangle. Honest nodes who have their time set correctly, will already have “more or less consensus” on the current time without any additional voting.

While I agree to this point and using the “more or less consensus” on time that we get “for free” as a foundation for mana seems to make sense it still has some issues. Nodes that newly join the network or that have been offline for a prolonged period of time will have completely different perceptions of mana than nodes that have seen the transactions “in time” (because they see them only after they have solidified the missing transactions).

I now want to propose a mechanism that combines both of our “ideas” into a single solution that combines the best of both worlds (using local time + reaching absolute consensus on mana - even for nodes that are offline and see the transactions later):

  1. Every node includes a timestamp in his transaction that defines when this transaction claims to be issued.
  2. The timestamp of a transaction needs to be bigger than the timestamps of both of its referenced transactions.
  3. Nodes only use transactions in their tip selection algorithm that have their timestamp set to a value that is smaller than their local time.
  4. The mana gets calculated by using the timestamps in the transactions - but they only consider transactions that again have their timestamp set to a value that is smaller than their local time.

Since nodes can lie about the timestamp in the transaction there are essentially three things a node can do:

  1. It can be honest which is perfectly fine.
  2. It can set the timestamp to be “in the future”, which would increase its mana gains compared to the honest nodes, but since none of the honest nodes will consider the transaction either in their tip selection or in their mana calculations until the transactions “time has come” these gains are essentially meaningless and are equivalent to just issuing the transaction at the claimed time.
  3. It can set the timestamp to be “in the past”: This will cause the transaction to be picked up immediately but the node will artificially decrease the mana that it receives. Since consensus is based on the votes a transaction receives, this artificially lower timestamp will not mess with consensus and just lower the mana an attacker receives.

This essentially means, that both “directions of lying” will be punished:

  • timestamp too far in the future: nodes ignore the tx until the “time has come”
  • timestamp too far in the past: no influence on consensus but the attacker receives less mana

Conclusion

This approach not only creates an incentive for nodes to be honest when assigning their timestamps, but it also creates an objective way to calculate the mana that is directly related to “human time” and that is not gameable by building certain structures in the tangle.

5 Likes
2

I just want to say that I haven’t been really following #tanglemath or Coordicide lately, so my apologies if I am way off with my understanding of the situation. Hopefully I will say something constructive.

Anyhows I understand there is a strong synchrony or partial synchrony assumption (the China argument)… If all you’re trying to achieve is better timestamps this can work under such assumptions.

I am not sure I understand how this solves the long range attack (I think this is what you described).

Someone who spends his funds can go back to a point on the tangle where he had them and issue transactions on top of that. He can start with transactions with timestamps that are lower than the conflicting txs (it already pass constraint 3) and then approve them with honest timestamp transactions.

The success of his attack depends of course on how much mana the actor has and how fast he can issue transactions.

All I know for sure that in Ethereum where they tried to ward off this kind of attacks with slashing and what not for a long time. Now, last time I got updated (I don’t get updated too often), they have a trick with VDF Asics that try to mimic POW properties and thus circumvent the attack directions that are present in POS.

1 Like
3

I am not sure I understand? This is not supposed to “solve” any attacks? We are NOT directly using the timestamps for consensus. It simply allows nodes to reach consensus on the mana vector by leveraging on the already existing consensus on human time (you can require nodes to have their time synced):

  1. It creates a situation where all nodes that read the same tangle will always reconstruct the same mana vector and therefore the same weights in voting. This is particularly interesting since nodes in the IoT will not be online 24/7 and might therefore have completely different mana vectors if we would only use the locally perceived solidification times as a source for mana.

  2. Since it is directly related to “human time” and independent of things like TPS, we can much easier define things like “decay times” for mana and so on.

  3. It is not gameable as both directions of lying will not result in an attackers mana growing faster than the mana of honest actors.

  4. It doesn’t mess with the NE of the tip selection algorithm.

PS: There are other mechanism against long range attacks like “checkpoints” + we have already discussed things like VDF’s anyway - but this is not the scope of this post.

4

I thought a long-range attack was described here. If not, then I misunderstood.

How the mana-vector is calculated exactly? It depends only on the cone of the transactions we are referencing?

5

Yeah you understood wrong. The described attack meant that an attacker issues a really long chain “on top” of the tangle which artificially increases its distance from the genesis (and therefore the “time” which was supposed to be the distance from genesis).

This now means that if he issues a spend at the end of that chain, that he will gain more mana than others who use the normal tip selection algorithm and do not immediately attach to this very long chain of transactions.

6

In general, I like the proposal. By the way, this

was already assumed to be part of our approach, no? (In any case, I’m all for implementing it this way.)

I’d only like to observe that we won’t reach absolute consensus on mana this way. As usual, this is because of “boundary cases”: here

that time may have already come for your node but haven’t yet come for my node, so our mana perceptions will still be different.

7

Yeah, of course you will also always have small differences in perception due to messages taking time to propagate in the network but it will converge to the same perception relatively fast, even for nodes that have been offline or sync freshly (which is a big PLUS for any voting scheme). These small difference will be handled by the consensus being probabilistic.

I agree that some of the named points have been more or less known and it doesn’t introduce anything “groundbreaking” :stuck_out_tongue: But having the specs written down and knowing that we will be able to have a “pretty accurate” consensus on mana makes a lot of things easier as things like DDOS attacks become less powerful and we might even be able to deal with network splits.

8

It will not, in the case when the flow of those “transactions-from-the-future” is significant enough (because in this case whp there will be at least one transaction which you would count and I won’t, or vice-versa).

In any case, I think approximate consensus on mana is already fine :slight_smile:

9

I am not sure I understand what you mean. Are you talking about the fact that a certain node id is constantly issuing new mana generating transactions and the fact that the clocks of two nodes will be permantly “off” will cause a situation where their perception about the mana of that node will also be slightly off?

10

yes, exactly

(so no really absolute consensus)

11

Okay then I agree … :stuck_out_tongue: “absolute consensus” is maybe not a good word as it implies 100% exact agreement and that is problematic because it already implies consensus. What I meant was that it is independent of a nodes “behavior” as in being offline, being DDOSed or joining in later.

Let’s call it “more-or-less consensus” :stuck_out_tongue:

12

Remember, another solution to this type of problem is just to use Mana 1. Also note that with a UTXO address scheme, we can effectively snapshot mana 1

13

The problem of Mana 1 was never that it was hard to snapshot? The problem of Mana 1 is that it is complex to compute (IO/disk + computationally) and that it is extremely volatile, which prevents us from using it as a “resource” for things like rate control.

1 Like
14

Why is it hard to compute? For every spend you have to add mana to one node id, and remove it from another. The add is easy (correct?), and with UTXO, the only expensive thing you need to do is look up the transaction the spend is from (which we can do with the hash) and then do the subtraction?

As for the volatility, you can average your mana vector over several transactions in the past. Suppose for instance, you have a sequence of checkpoints. Your mana could be the average of the last 20 checkpoints.

15

Maybe we have different understandings of what mana1 is?

The way I understand it is that mana1 means the original proposal of mana where nodes pledge their coins to a certain node id and give weight to this node. As soon as the recipient of the funds moves these funds again through one of their own nodes, the old node looses its mana again. To prevent people from just moving funds back and forth and perform a “splitting attack” on the perception of mana, we make the mana take some time to develop its full weight after being received.

Particularly the last point makes it impossible to just book a balance “on arrival” of a transaction and instead we need to “book” the indirect association of funds and addresses to node ids instead.

To then determine the current mana of a node, we need to

  1. Look up all its associated addresses / funds.
  2. Look up how long the funds have been sitting there.
  3. Feed the amount of coins on the address + the time it has been sitting there into some kind of formula.
  4. Sum up the results of these calculations to get the accumulated mana vector of a node.

Mana2 was now slightly modifying these concepts to be able to book on arrival once without having to recalculate everything over and over and over again whenever we look up the mana of a node.

If you are talking about a version of mana where “time” does not play a role and you envision a different form of “smoothing” to prevent the named splitting attack on the perception of mana then that is a different form of mana and I would need to see the specs to judge it.

PS: Mana1 had also some really strong incentive issues. If a node can never know how long he “keeps” the pledged mana as any recipient would anyway just instantly swipe all received funds through one of their own nodes then how would a node know if he should ask for fees by the tx issuer or just accept the transaction for free if it carries enough mana.

16

This is not what I wrote down in the mana comparisons document. (Maybe I misunderstood at the time the proposal, for which I apologize). In Mana 1, the mana generated by a transaction is pledged to a node. When those funds are spent again, the mana can be reassigned in the new transaction. There is no temporal element. So, when a new transaction is arrived, the mana in that transaction is added to the new node id’s balance, and then we must go back to the transaction where the funds were spent previously and then remove the mana from that node IDs account.

17

Okay, then our misunderstand comes from this aspect of the definition of mana. For me, there was always a “time” element in the definition of mana (at least the way it was discussed internally and communicated externally) to fight the named issues. If you remove that, then you can indeed “book on arrival” and then mana1 would have the same properties of providing an objective basis of weight.

But as I pointed out in the previous post, this “ignoring time” would come with a few drawbacks.

18

Ah I see. I am sorry about the confusion. When I wrote all the documents comparing mana, I thought I was capturing the same ideas that we all had. But I do like the idea because of its simplicity. Maybe when you have time, you should look over my mana doc and point out any other errors I have…

Anyhow, the time based problems is why I have suggested using the approach of “averaging over several transactions” because then it does have a time based growth element.