Moving voting to the mempool layer - Lightning Voting in the Native Contract

[vncoelho]

closes #300
closes neo-project/proposals#82

NEO holders should be able to modify validators during block creation.
In this sense, the proposed mechanism allows voting to happen in an upper layer, namely, in the mempool.
This was an insight with a discussing with @jsolman.

I believe that we could try to implement this for NEO3 while doing the Native Contract for Voting. What do you think @igormcoelho?

[erikzhang]

In mempool, how do you solve the consistency problem?

[vncoelho]

What is the current feasibility of this, @erikzhang?
I was just going to ask what you asked. Messages came together...aehauea

I do not see a simple way of counting the votes in the mempool, that is not really scalable.

On the other hand, we could do it in a third party service and just publish newvalidators as a single transaction.
Maybe the new set of validators can publish a block with a single transaction that calls function newvalidators of the Native Voting Contract.

• This block should could have one single transaction (for simplicity and avoiding inconsistencies).

The core of the idea is that If the block has a valid newvalidators, then, current consensus should be the one described after this transaction is included.

In fact, this is a hypothetical scenario in which f nodes are lost. Not something that we should really worry. aheuahuea

But it would be interesting to say that the NEO protocol can handle that by the power of voting.
I believe it can be done in a simple manner, we just need to think a little bit more.

[erikzhang]

I think this is not feasible. The matter of replacing the consensus nodes itself requires consensus.

[vncoelho]

Consensus are chosen by NEO holders, which is a matter of signing their voting intention. Philosophically, it is an "offchain" process (that is why we picked lighting as a name, copying BTC Lightning Network).

But I agree that it is not easy exceptions to be handled. But the power such mechanism would remain.
There is almost nothing impossible to us, master...aehauheauea

[erikzhang]

In the simplest case, everyone modifies the configuration file and chooses a new set of consensus nodes. (nodes that have not modified the configuration file will fork out)

[vncoelho]

Ok, @erikzhang. Thanks for your time and discussion.
The current configuration file should have a set of consensus nodes that matches the current votes.
For example, the first block published by this set of consensus should have this signatures.

However, consider this solution could probably be an eternal debate with old "offchain" transactions modifying the validators and forking.

[erikzhang]

Vote in mempool, if everyone is online, and every nodes are connected with each other, and every messages are sent to every nodes well, then it is feasible. Otherwise, different nodes will see different transactions in mempool, and get different consensus nodes, and fork.

[vncoelho]

That is true, @erikzhang.
Let's keep this in mind. Thanks for the insight, my friend.