"Objective" approval weight with past cone indexing

"Objective" approval weight with past cone indexing

What follows is a rough attempt to define the “objective” approval weight of a given message or group of messages, measured by the cMana distribution visible in the message’s past cone. I’m calling this measure “objective” not because it is truly objective, but because any node trying to determine the approval weight conferred by a given message, or group of messages, would be guaranteed to come to the same calculation of this “objective” approval weight, without the need for any kind of consensus.

I’ve also tried to elaborate one basic method to calculate and use this variation on approval weight, by storing with each message a small index that identifies the value messages in its past cone. This index can be kept relatively small (a handful of list slices), and is calculated by inheriting and merging the indices of a message’s parents, and therefore does not involve any walks through the Tangle. This index implicitly gives us a list of the value transaction which are not in a messages past cone, which can then be “rolled back” to derive the objective cMana state of any message, or messages, based on a nodes most current “subjective” perception of the cMana distribution.

If this approach works, I can’t say if offers major advantages to the current approach(es), but I wanted to share it to see if it contributes some useful ideas. I hope that if this idea stands up to any kind of scrutiny, that having a concept of approval weight which immediately has consensus may prove useful in some contexts.

Subjective vs Objective approval weight

00

Because cMana is pledged or revoked in value transactions, the current cMana state is just the sum of the cMana state changes contained in all the value transactions in the Tangle. The “approval weight” of a message (or group of messages) is just the cMana currently pledged to its issuing node.

By “subjective” approval weight of a given message, I mean approval weight measured in terms of the local perception a node has of the cMana pledged to the various nodes in the network, given the most recent version of the Tangle it has seen. Because every node may have slightly more or less information than other nodes, each node will have a unique perception of how much cMana is attributed to each node, although they will eventually agree on which cMana belongs to whom.

By “objective” approval weight, I only mean the approval weight of a message calculated in terms of the cMana distribution observable in the message’s past cone. In other words, if I receive a new message and calculate a cMana distribution using only the value transactions contained in its past cone, I would have something like the cMana distribution as “perceived” by the message itself.

While this perception may not be exactly what the issuing node saw when it issued the message, it is guaranteed to be part of that node’s perception of the tangle. The past cone of a message is also the set of messages which were necessarily issued before the message itself, and which are therefore guaranteed to be observable to anyone who sees this message.

Past Cone Index

In order to efficiently calculate the “objective” cMana distribution contained in the past cone of a message, we need a way to know what value transactions are in its past cone without having to walk the entire past cone.

The first step is to track value transactions on arrival with a counter that advances as new transactions are processed and booked into the tangle. With this ordered list of value transactions, each new message can be booked with a “past cone index” that identifies which slice or slices of this “value transactions list” are part of its past cone. For example, a message with value transactions 1 through 900 and 950 to 960 in its past cone would have a past cone index of

[1:900, 950:960].

At first glance it seems likes tracking these indices would require many cumbersome walks of the past cone of each message, but when a message arrives, you can always find its past cone index by inheriting the unique elements in the past cone index of its parents:

message.pastConeIndex = parent1.pastConeIndex ∪ parent2.pastConeIndex

Or if the new message is a value transaction, by performing the same operation and adding messages own transaction number to the index:

message.pastConeIndex = parent1.pastConeIndex ∪ parent2.pastConeIndex ∪ message.transactionNumber

What this means is that once we initialize a set of messages with a “past cone index” every subsequent message can be processed relatively quickly on arrival, and associated with a small reference that immediately shows which value transactions are in its past cone. As new messages eventually all see the same old messages, these are automatically bundled in the first slice in the index which sort of “self prunes.”

Incidentally, this little bit of bookkeeping may give you something like the “inverse” of the parallel reality ledger state. You can know which transactions belong to the past cone of any message just as a “reality” lets you know what messages are in its future cone. You can also know all the possible realities a message belongs to by looking at its past cone index - which is the same as the set of past messages that have the message in their future cones.

On tangle voting with “objective” approval weight

38

If two conflicting messages A and B are issued into the tangle at roughly the same time, they will be booked into two separate realities. Once the conflict is registered, a node would have to find which transactions are not in the past cone of A or B, and then, using its current “subjective” perception of the cMana distribution as a reference, “roll back” the mana pledged or revoked in those transactions to find the “objective” cMana distribution for the conflict set. This is given by something like:

messagesNotInPastCone(A,B) = TransactionsList - (MessageA.pastConeIndex ∪ MessageB.pastConeIndex)

conflictSet(A,B).cManaState = subjectiveCManaState

for message in messagesNotInPastCone(A,B):
     conflictSet(A,B).cManaState = conflictSet(A,B).cManaState.reverseUpdate(message.manaPledged)

Now the node has an “objective” version of the cMana state, determined by the past cone of the two messages which make up the conflict set. One could simply stop here, and say that the objective cMana state, observable in the past cone of the conflict set will be “frozen” and used to determine the voting weights as long as the conflict is unresolved. This guarantees that any node who sees the conflict, will have the exact same perception of the voting weights of each node.

43

However, with the tools outlined above, it may be possible to adapt the same approach to update dynamically as new messages arrive - although this would involve some more computational overhead. For example, when a new message C arrives and votes for reality A, something like the code below would update the objective cMana state of the conflict set by iterating over only those value transactions which are in the past cone of C, but not in the past cone of the other messages in the conflict set.

For message in MessageC.pastConeIndex ∩ messagesNotInPastCone(A,B):
     conflictSet(A,B).cManaState = conflictSet(A,B).cManaState.update(message)

As each new transaction votes on the conflict set, a node would update its perception of the “objective” cMana allocated to each node, relative to that particular conflict set.

Conclusion / Questions

What this approach proposes is that “objective” approval weight can be measured entirely with respect to the messages whose approval weight we are trying to measure, for the purposes of handling conflicts, and potentially elsewhere.

Some questions I have are:

  • How computationally expensive would this be in reality?

  • Are there any real advantages to “objective” approval weight over other approaches to measuring approval weight?

  • Would the concept of a “past cone index” potentially be useful in other contexts?

  • Can the concept of “objective” approval weight be used in other ways than in handling conflicts?

Even if it is not strictly necessary, I think there is some value (at least for me) in thinking through the idea of a universally agreed upon measure of approval weight, such that if two nodes see the same conflict, and the same votes, they instantly agree on how to measure those votes. There is even a kind of poetic justice in the idea of using the view of the Tangle contained in the conflict set itself as the source of the voting weights which will decide on the conflict - something like what Hamlet tells his mother:

....Let it work,
For ’tis the sport to have the engineer
Hoist with his own petard