EIP-2182: Reduce the Clique SIGNER_LIMIT

[soc1c]

Clique-based networks come to an halt if less than 51% of the signers stop proposing blocks. One of the reasons is the validators in non-value-bearing networks might loose interest and drop off the network without further notice. EIP-2182 addresses this and encourages Clique-based networks to upgrade the signer-limit formula.

resolves goerli#14

partially replaces #1955

[karalabe]

The original reason for the SIGNER_LIMIT was to ensure that only the chain with majority approval can progress. A chain without majority approval is a side fork, and should not be allowed to progress beyond a few blocks, since it's a DoS attack on full nodes (full nodes need to store side chains too, if they ever become heavier than the main one). On ethash side chains cannot go on forever since each block has an inherent cost. On Clique, side chains can actually go on forever, since all the blocks are free to create computationally.

Imagine that you have a network of many signers, but only 2 are online. With this proposal, the 2 online ones can actually each push their own chain, completely disregarding the other one, and both will weigh the exact same. This would cause the network to flip-flop between the two chains until something collapses. This scenario assumes only malicious signers are left.

If there are some legit signers left, I think it should be fine to keep one chain heavier than the others, but I still think it's important to have a contingency plan against malicious side forks. Maybe we could somehow cover how that vector can be minimized.

---

Another issue is that by permitting SIGNER_LIMIT to go below the actual number of authorized signers, you reduce the chain's security to the number of legit miners online at any point in time. Since only "online" majority is needed to push a chain, if at any point the majority online is malicious, game over. I can imagine a similar issue might arise if malicious signers try to retrospectively game an "offline" timespan.

This may or may not be a problem depending on use case however. If the signers are generally well vetted and disappearing ones are generally weeded out before they pile up, I think it can be made to work.

---

All in all I don't think is is a bad EIP, maybe it needs to cover potential attacks and rational why those are not a problem, or what a network operator (group) might need to do to avoid them.

[github-actions]

There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.