# Hobbyist thoughts about Tangle multiverse consensus

Not being sure whether this is the right forum to write these things, I dared to start a new topic to share some thoughts I got after reading the Multiverse consensus blogposts.

In the current Coordice solution consensus and ledger state are nicely decoupled. FPC can be studied without thinking about Tangle or parallel reality ledger state. Hans proposed the Tangle Multiverse consensus model which might be near an optimal consensus model, but according to Popov it is really hard to study mathematicly. Although I havenÂ´t found any explanation on what exactly is so hard to prove mathematicly in that consensus, I still think that I can understand some of the challenges that are related to the problem. In this post I try to give some ideas on how it might be possible to tune the system to make it simpler.

Tangle Multiverse ( TM ) is very hard to visualize, and it is thus difficult to reason what kind of edge cases might arise. Also consensus is not separated from the ledger state, and this gives huge pressure to tip selection process. By pressure I mean that every new transaction confirms two other tips, and with those very limited actions it shoud do two things simultaneously:

1. Confirm tips in a way that Tangle stays in a nice form, that everything flows nicely and that maximal amount of tips get confirmed in a reasonable time.
2. Use a voting right to form a consensus with other issued honest transactions, and do it through tips that get selected in the process

The tip selection process forces one to take account ledger state when considering what kind of situations might arise, because tips that are available depend on a ledger state. Tangle as such is complicated structure, but combined with paraller reality it is massively complex.

I was wondering if it would make any sense to try to decouple those two problems above as much as possible? Then they could be analyzed separately, and we would have two smaller problems instead of a single huge one.

Another thing to notice is that in TM two confirmed transactions (trunk and branch) behave differently. Both are used to solve both problems above, but branch is more dedicated to first problem. Branch like switch helps to tie together two conflicting areas of Tangle so that Tangle doesnÂ´t split in two. Trunk instead devotes more to voting and is more used to solve problem 2.

First letÂ´s take a simplified representation of transactions and conflicts that they are giving their vote:

In the picture above transactions (small restancles with numbers) are lined according to their timestamp in a way that older transactions are on the left side. (This total ordering of the Tangle is only for the representative reasons, also numbers are only used to easily address a certain transaction.) The first color above each transaction refers to their master reality (or funds origin reality). Other colors above each transaction refer to those realities they are giving their vote.

Transactions 8 and 9, as well as 10 and 11 are conflicting transactions and the other reality of that conflict is adressed by the little mark in the corner

Transactions 12 and 13 are conflicting transactions in a subreality and the small dot in the centre relates to their parent reality. So by liking transactions 12 or 13 also gives a vote for the darker blue reality (master reality of transaction 11).

Transactions 14 is a merged reality. By liking transaction 14 one also votes for master realities of transactions 9 and 11.

Transactions 16, 17 and 19 are tips and thus marked with a dotted line.

This representation doesnÂ´t include all the information that the underlying Tangle has, and is thus simplified version of the situation. This picture tells which transactions votes for which reality, but doesnÂ´t tell how all transactions are located.

Tips makes system much more complex because it limits options honest parties have. If the voting process could always behave only based on information on what each previous transaction has voted, (and not where they are in the Tangle) it would be a much simpler system.

Thus I was thinking that what if we decouple voting totally from tip selection. Every transaction still confirms two transactions, but only partially likes them. In TM-language every confirmed tip (trunk or branch) has a branch switch turned to â€śpartially likedâ€ť or 0 all the time. In this setting no voting information is gained from tip selection. Instead in addition to confirming transactions, every transaction can also like for n other transactions. These transactions can be tips that were just confirmed by the transaction or transactions that were already confirmed by other transactions. Voting information travels in the node network with each transaction, so itÂ´s still on Tangle voting.

In the picture above we only care about conflicts and which transaction votes which reality. Based on that we can see how much mana is voting each side of a conflict. We are not so intrested about how the underlaying Tangle behaves. Original TM consensus is like â€śtake it or leave itâ€ť package. There are not much parameters to adjust if something goes wrong after further reseach. Decoupling of tip selections from on Tangle voting gives us endless possiblities for fine tuning. We can change n (the amount of likes given in different situations), and build different transaction selection algorithms for honest voters.

First transaction selection algorithm that came into my mind, was to make every honest vote give a maximal impact on voting.

That leads to this example for transaction selection rule:

1. If there are no unresolved conflicts or issuer has already given his vote in all conflicts, he gives no additional likes.

2. If there are unresolved conflicts in the Tangle that the issuer had not previously voted, he likes the transaction that affects to maximal amount of unresolved conflicts. Yet the issuer of the like will never choose a transaction that votes for even a single reality that the issuer doesnÂ´t support.

3. If there still are be multiple choises, the issuer chooses the most recently issued transaction and likes that.

4. If the issuer had previously voted a reality that issuer now objects, he relates to that conflict like he does with a reality without a previus vote (eg. he can vote on that conflict again but the other side.)

Of course transactions can never vote different sides of the same conflict.

If we look at how that would work in above picture we can see that transactions 15 and 16 affect to three conflicts. LetÂ´s say we support lighter green reality (master reality of transaction 12). Then we also have to support transaction 11 master reality. If we are agains transaction 8 master reality, we would support transaction 9 and thus pick transaction 15 for our first â€ślikedâ€ť transaction. Whe have taken part in all three conflicts so we would not like another transaction. In this case our merged reality would consist of similar realities as transaction 15 merged reality (if our own transaction is not conflicting).

ItÂ´s possible to visualize what might happen with let say 1000 conflicting transactions. Honest majority would start from somewhere and agregate more and more realities under a single â€ślikeâ€ť. Every new transaction could agregate more transactions to their agregated reality, until some of the first conflicts get enough mana votes and become part of the master reality. Then earlier honest transactions affect to fewer and fewer unresolved conflicts. At some point all conflicts should be resolved. At least thatÂ´s my gut feeling. This way of resolving complex situations should also be more efficient than relying only on tips. Proving that this model works might be another beast.

Nevertheless this is quite simple model to visualize with quite simple rules. I didnÂ´t find any reason why tip selection and on Tangle voting could not be totally separated. Tangle would then make sure that everyone participates to the protocol. Paraller reality ledger state would be used to keep track of transactions and in Tangle voting would deal with the consensus. All pieces could be studied quite separately.

Does any of this make any sense? IÂ´d love to hear some feedback about these thoughts.

2 Likes

I donâ€™t think that is doable, because tangle is a permissionless system, you canâ€™t tell a node how to select tip. And tip selection and vote is the same thing in TM, â€śyou select that tip, means you vote that tipâ€ť

Thanks for the comment. I definitely should have been more spesific there. In that sentence I tried to refer firstly the task tip selection rules in the current Tangle has. Honest nodes follow a tip selection rule that tries to maximise confirmation rate of transactions send by other honest nodes. In addition in TM tip selection also tries to prevent Tangle from splitting in two when there is a conflict. You are right that the actual form of Tangle can vary a lot and not everyone has to follow tip selection rules.

In TM indeed if you select a tip you vote a tip, (if your branch like switch is not 0), but why is that? That is not necessary. TM is so powerfull and efficient because of underlying paraller reality ledger state, and also because of the fact that by placing a single virtual vote (=like), one can vote in multiple conflicts simultaneously. By decoupling voting from tip selection rules one does not only make model simpler, but also uses these principles above more efficiently. Likes can be placed on transactions where they matter the most.