Assessment removing non voters from ARS

[lrubiorod]

Problem: The mechanism of Superblocks implies that a committee of miners randomly selected from the Active Reputation Set (aka ARS, the group of nodes that mined a block or solved a request in the last 2000 blocks) would send their votes for the tip of the chain, in order to notify to all Witnet nodes what is the agreement in the tip of the chain. Not voting here could produce not achieving a consensus and generate a rollback where the last 20 blocks would be burned and all the nodes should resynchronize their chain tip. Despite to this big issue, a non voter wouldn’t have any penalty that could incentive it to ensure that its node will be always ready to commit its vote in time.

Solution: Remove non voters nodes from the ARS in order to clean it from possible nodes that wouldn’t working properly. This behaviour could prevent or mitigate rollback periods when big miners would get down or would have experiencing some issues that prevent their nodes to vote.

Issues: Currently, there is not a trivial solution to ensure that all witnet nodes have an agreement in which are the nodes that do not send their Superblock votes in time. Because the punishment would be to remove these nodes from the ARS, different ARS lenghts between the witnet nodes will produce different committees, destroying the Superblock mechanism due to disagreements between nodes in which should be the next proper committee that decides the chain tip.

Proposal: A consensus mechanism has to be used to ensure that all witnet nodes remove the same nodes from the ARS. In my opinion, there are two options:

• Miner consensus: Similar to TAPI, miners could include in their blocks information regarding to which nodes should be punished as a non voters. This information could be included in the BlockHeader as a new field or as a new type of Transaction that only could be created by the miner (like Mint and Tally). In the superblock creation moment, if most of miners agree in which addresses has to be removed, they will be removed.

  The issues regarding this proposal would be the creation of a new transaction or a new field in the BlockHeader implies the development of protobuf migrations and it would increase the weight of the blocks.

• ARS committee consensus: The other option would be using the same mechanism that we are using for the agreement in the chain tip. In this case we would include a new field in the SuperblockVote were the nodes could specify which previous nodes didn’t send the previous superblock votes. Superblock votes are not included in the on-chain information so we would avoid the issues of the other option.

  My proposal is to include an array of 100 bits related con the 100 addresses that should send the superblock votes, in this array, each node can notify which are the non voters. In the next superblock consolidation moment the superblock votes would have an agreement in the chain tip and the addresses that has to be removed from the ARS. One simple idea could be that if one position (related with an address) of the bit array obtains more than 67% of votes, it would be removed. In case of missing votes that could produce a doubt between achieve this percentage, it would produce a rollback (same as chain tip agreement)

Risks:

• This mechanism could be used to punish addresses that were not really non voters in case of agreement of other committee members.
• It could produce more rollbacks in case of missing votes and penalty votes near to 67%
• Punish non voters during rollbacks it is non trivial due to resynchronization
• Could it reduce the ARS to risky numbers?

[aesedepece]

For broader context, I've always run off this idea because of the indistinguishability between missing votes and intentionally censored votes. In other words, a mechanism like this could be easy to exploit to take identities out of the ARS on purpose.

What's more, under the assumption that votes visibility is not perfect, I'm unsure whether any mechanism of that type would turn out to be effective or rather increment the opportunity for rollbacks because of forked ARSs.

Another concern of mine is that if any under situation some player gets to instantly hold >2/3ds of the ARS, then any mechanism that allows to call out lazy miners can be abused by that player to stay in control of 100% of the ARS forever by calling out any 3rd party identity that may join the ARS thereon.

[tmpolaczyk]

It is a tricky issue because the punishment should be high enough to incentivize ARS members to vote, but if it is very high then it creates the opposite incentive, to censor votes for profit. In my opinion removing identities from the ARS is something that should be very rare so there should be some strong economic punishment in order to avoid that, such as the staking implemented in other PoS chains.

I like the idea of putting some information in the block headers, but not sure what.

It could produce more rollbacks in case of missing votes and penalty votes near to 67%

I think this risk is high enough to discard that option, we would be introducing more factors that could cause rollbakcs.

Could it reduce the ARS to risky numbers?

I don't think so, because if >1/3 of the ARS is not voting then there will be rollbacks anyway, and removing a small portion of the ARS should increase the liveness of the network. Also we could implement some safeguards such as stop removing identities if there are less than 1000, for example.

Some ideas:

• Interactive dispute: anyone can create a new kind of transaction that means "I know that identity wit1asdf is not active, so I stake 1 wit" and if that identity does not respond within some period (1 week?) then they get punished.

• Implement some mechanism to allow identities to exit the ARS voluntarily. This would be useful if some miner needs to have some downtime, this way they would avoid to be punished. Of course, this only makes sense if we implement some punishment.

Another concern of mine is that if any under situation some player gets to instantly hold >2/3ds of the ARS

I wouldn't worry too much about such scenarios, because this attacker can already perform this attack by only mining empty blocks and voting for their own chain.

[drcpu-github]

For broader context, I've always run off this idea because of the indistinguishability between missing votes and intentionally censored votes. In other words, a mechanism like this could be easy to exploit to take identities out of the ARS on purpose.

While this is a reasonable worry, I think if there is a single actor (or unified group of miners) that can succesfully censor votes, it seems to me the network is in greater peril than superblock votes being censored. Any one node connects to 8 random peers and transmits votes to those peers. For a vote to be censored, all of those peers need to be controlled by the same entity. As long as the vote gets to one other peer, it will be spread over the network in an exponential fashion, no? Take a look at the probability of those 8 peers to be controlled by one entity:

Nodes controlled	Probability
30%	0.01%
50%	0.39%
70%	5.76%
90%	43.05%

While 5.76% probability of getting censored is already alarming, I think it's safe to assume that we have bigger issues when that amount of nodes (or bigger) is controlled by one entity (e.g., data requests and the actual blockchain being manipulated).

I'm basically sharing the same opinion as @tmpolaczyk. If we arrive at edge cases where one malicious miners controls that much of the mining power, we likely have bigger problems to solve.

... My proposal is to include an array of 100 bits related con the 100 addresses that should send the superblock votes, in this array, each node can notify which are the non voters ...

I like this idea as a working theory.

Interactive dispute: anyone can create a new kind of transaction that means "I know that identity wit1asdf is not active, so I stake 1 wit" and if that identity does not respond within some period (1 week?) then they get punished.

This opens up an interesting possibility. Imagine a malicious actor having to stake WIT in order to remove an identity from the ARS. I think that you cannot know if another node is only connecting to nodes you control (especially as they can cycle between peers), so if you want to censor a vote, you are taking a serious gamble that you actually can achieve that.

Obviously a mechanism like this needs to properly tuned because you also don't want to encounter too many cases where an honest actor tries to remove a node from the ARS and that node rejoins after a day or two causing the honest actor to lose its stake. Though I guess that the probability of a node that is inactive for two days to still be in the ARS and be able to cast a vote is also pretty small.