Follow up EOS issue 2204: check block before pushing to fork db

[abitmore]

EOSIO/eos#2204:

Right now we only check if a received block is linkable to an existing block in fork_db but do no other checks. If the network code also doesn't reject multiple blocks at the same block height from the same node, it opens itself up to an easy DOS attack.

Rather than relying only on the network code to protect against such attacks, we should do some light validation of the received blocks (particularly enough to check that it was correctly signed by an active producer from the perspective of that block) before including it into the fork_db.

[abitmore]

EOSIO/eos#2718 is related.

[jmjatlanta]

And here I thought I was taking on an easy fix. It seems that PR #884 opened a discussion with many moving pieces. I am hoping to move that discussion here, to help all find the best solution.

I am generalizing here, and must admit I only have a cursory understanding of the issues involved.

EOS 2204 adds a check to make sure that the witness is an active witness before adding its block to the chain.

EOS 2718 adds a little more data to the header to help get the 2/3+1 majority back, in the case of forks that have diverged and contain subsets of witness approvals that would otherwise require manual intervention to merge.

(1) Can we implement 2204 without 2718? And if so, (1b) does that open the door to an easier DOS than what we have now?

(2) Can a comprehensive fix (i.e. DPoS 3.0) be completed in a short enough time frame to improve security and network stability, or would incremental fixes be the better option?

@abitmore @pmconrad I will pause on PR #884 unless it is deemed worthwhile to continue.

Relevant: #884 (comment)

[pmconrad]

AFAICS EOS 2204 adds that check, except for the first block in a round. That means that as a DOS protection measure the fix is useless (the DOS can still be executed at the start of each round).

EOS 2718 is a protection against a witness signing blocks on two sides of a fork simultaneously, which could lead to multiple forks having a 2/3+1 majority. I think the solution is incomplete (insofar as it does not take timing effects into account), and it also doesn't solve the problem that the list of active witnesses can be different in each side of the fork.

I agree about pausing this, because I don't see an effective short-term solution.

[abitmore]

There is an interesting discussion in Steem which is related to this issue: steemit/steem#2471