NEP: Lightning-Voting

[vncoelho]

Fully distributed systems have the cost of safety.

It is impossible to deny that, in unlucky cases, M (safety level) nodes can be Byzantine and attack the Blockchain.
While there are different types of possible attacks, some of them are easy to detect, such as: 1- blocks with wrong transactions; 2- blocks with double-spending; 3 - more than f consensus node lagging plenty of time to sign next block: among others.

Considering this possibility, this NEP proposes a lightning voting experience, in which NEO holders would be able to modify validators during block creation.
In this sense, this proposal is a simple mechanism that allows voting to happen in an upper layer, namely, in the mempool.

[EdgeDLT]

I like the idea, but would it be better to use a reputation system instead of banning outright? Banning nodes could affect our fault tolerance quite heavily. We would need a large number of backup nodes ready to quickly replace banned CNs.

Using reputation would have the added benefit of being useful information for NEO holders who are deciding which consensus nodes to vote for. The most reputable nodes are evidently strong candidates.

There is an example reputation module for BFT protocols called Guru, perhaps it could be a good reference?

[vncoelho]

@Edgegasm, I checked out the Guru, thanks for the nice references as always! 🗡️
By the way, we gonna count with you in the PART-III or -II of the Consensus in order to implement a Redundant strategy (such as that paper you sent us).

The point here, Edge, is that this NEP is not related to the Consensus layer itself, it is talking about an upper layer in which the Correct nodes already lost power against Byzantine nodes.
The idea is to ban directly because we are talking of a Consortium with, at least, M nodes destroying the Blockchain.

---

Recently, @igormcoelho called my attention to the fact that if some Validators just disappear (for example loosing their private key) the NEO blockchain might get stopped because the voting for new Validators should be approved by the CN and published in the Blockchain (and, then, how to publish if the quorum can not reach M?).
This case is even harder to be discussed, however, a first idea could be to to ban nodes that do not sign any of the last X blocks.

---

Here, in this NEP, the idea is to cover cases wherein the system behaved wrongly and should be reverted (at least, M nodes were fault).
In this sense, we need a NEP that guides the re-organization (deep-regeneration) in a deterministic manner, which will promote transparency for such rare but possible cases.

Faults should not be tolerated and stakes should be lost, reputation is not a matter here since it is impossible to trust again in someone that behaved like that.
The key aspect here is to preserve the correct chain (without double-spending or fault transactions) and registering this in the Blockchain in a way that the history tells honestly what happened.

[EdgeDLT]

Ah I understand, so if such a fault occurs, the remainder of the network may still preserve itself. Makes a lot of sense, you guys are thinking far ahead as usual. We're lucky to have you 😅

---

Could you resolve the second case by having backup candidate nodes (next most highly voted) working as record keepers and ready to assist in restarting consensus after t?

[jsolman]

I'm interested to know if others think this mechanism is needed given the voting mechanism used in NEO.

some of them are easy to detect, such as: 1- blocks with wrong transactions; and 2- blocks with double-spending.

Easy to detect ones are effectively the same as just not creating a block in the time you are supposed to.

It is impossible to deny that, in unlucky cases, M (safety level) nodes can be Byzantine and attack the Blockchain.

The possible types of misbehavior I see are:

1. Attempt to stall the network by not sending PrepareResponse or not signing in the Commit phase
2. Attempt to censor transactions when it is ones turn to create a block
3. Attempt to DDOS the chain with consensus messages that will be rebroadcast everywhere

All of these behaviors should be detected by services that offer wallet clients to users. Neo holders therefore would have the tools to vote out bad acting node. Ideally most of this should happen automatically in the future. The penalty of being voted out, would mean that the cost paid to be a CN node candidate would have been lost, since it is unlikely to be voted in again as a CN node. Shouldn't this be enough of a penalty already?

[vncoelho]

Voting requires a transaction to be processed, thus, requiring CN to create a block.
In both cases we need a Proof-of-Safety mechanism ready to deep-reorganize the chain for keeping blocks generation in such cases.

[jsolman]

n = 3F + 1 where F = faulty validators

The bad entity would have to control F+1 CN nodes to completely censor votes. So in this case you are suggesting the bad entity obtained votes so that they controlled F+1 nodes? It should be and needs to be generally prohibitively expensive for a malicious entity to ever control F+1 nodes.

Deep reorganizing the chain is against finality. Such a reorganization should not be designed by a mechanism in code since then finality guarantees are lost. There must be another way.

If the chain were halted by a malicious entity that obtained control of F+1 CN nodes then it would seem to me that if there were going to be some automatic mechanism to recover, it would need to allow voting to still take place. For example perhaps voting transactions in the MemoryPool can be used for CN nodes to adjust consensus rules to effectively vote out the malicious CN nodes. However, currently this scenario would take the equivalent of a software change (hard fork) to resolve.

That being said in practice, entities that propose to run CN nodes will be publicly known entities. In the future no same entity should control F CN nodes. Say that company A that owned F-1 nodes were going to acquire company B that owned 2 CN nodes. Prior to this exchange taking place, voters should vote replacements CN nodes for 2 of the CN nodes owned by company A or company B to preserve decentralization. Wallets that aid users in performing voting, can also follow rules that will ensure they don't vote for the same entity to have more than F-1 CN nodes.

A solution using the possibility of MemPool voting that I mentioned above to recover from an F+1 byzantine CN node attack should be possible; however if one entity were able to control M nodes (all the nodes required to sign a block M = n-F), then the only solution at that point to solve the problem where the malicious entity could censor transactions would likely be a hard fork by software change.

In conclusion, a malicious entity could only continue to censor transactions if they control at least F+1 nodes, otherwise they will be voted out from being a CN node, since they cannot censor all the votes to vote them out. They should be prevented from controlling F+1 nodes due to voters not voting the same entity to control more than F-1 CN nodes, and to purchase enough NEO to vote in a specific node would require a prohibitively expensive amount of funds. In the case of protecting from that, perhaps we should further pursue what I'm calling "MemPool Voting", but in the absence of that, it can be treated the same as what would happen in the situation where a malicous entity gained control of M nodes, which would be to hard fork validators by a software change (doomsday scenario).

[vncoelho]

Nice insights, Jeff!

• Finality is guaranteed until 66% of the network is honest.

it would need to allow voting to still take place.

Exactly, voting associated with a proof of bad behavior of that CN (in fact, the proof will not be needed in the line of reasoning that you are supporting because the voting represents that in an intrinsic manner).

For example perhaps voting transactions in the MemoryPool can be used for CN nodes to adjust consensus rules to effectively vote out the malicious CN nodes

Exactly, @jsolman, you got the felling (they would just select new candidates, it would not have the need to explain about who is malicious or not).

• The hard part here is to achieve a representative part of NEO holders, currently 100M, mempool currently cannot handle that. In this sense, we could do the following:
  • A special kind of transaction could be created for that purpose, which could aggregate the voting process in an upper layer.

I think that this line of reasoning you proposed is very good and also solves the problem that we could have if F+1 nodes just disappear (for example, lose their private keys).

Thanks for these good ideas.

Maybe we could think about another name for this proposal, more suitable to this new line of direction, for example:

• NEP: mempool-voting
• NEP: voting-safety
• NEP: lightining-voting

[jsolman]

The hard part here is to achieve a representative part of NEO holders, currently 100M, mempool currently cannot handle that

It doesn’t have to, the Top 2000 holders will likely account for 99%+ of votes.

[vncoelho]

@erikzhang, what do you think about this proposal?

As suggested by @jsolman, it is now more related to an upper layer where the voting could occur.

[vncoelho]

Closing this in favor of the native implementation in NEO 3 neo-project/neo#757.

[vncoelho]

Reopen due to the current discussions going on at Community Assembly.

@dahongfei mentioned a way of setting CN offchain.

This proposal has this potential by enabling voting on mempool level.

[erikzhang]

This proposal has this potential by enabling voting on mempool level.

But mempool is non-deterministic.

[vncoelho]

We understand that it is non-deterministic, that is why this is meticulous....aheuahuea
Maybe it is better to close this for now.

[vncoelho]

In particular, @erikzhang, the Emergency Mode (neo-project/neo#2226) also solves this.