Allow to blacklist block hashes

[shargon]

Description

In the event that we have a transaction or block that denies the service, this pull request would allow us to blacklist said hash, and for the consensus to continue working. If it is an attack, it can obviously be repeated and will not work, but in the case of something fortuitous, it will allow us to work on the problem without keeping the service denied for a long time.

Type of change

• Optimization (the change is only an optimization)
• Style (the change is only a code style for better maintenance or standard purpose)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

• Manual test required

Test Configuration:

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[Jim8y]

previously this level of permission belongs to council......

[shargon]

previously this level of permission belongs to council......

If a cn want to recover, policy can't be used

[AnnaShaleva]

I understand that this feature allows to protect the node from an unwanted transactions/blocks/etc, but at the same time it's very easy to "bypass" these constraints by minimal changes in transactions/payloads, e.g. you may change the tx's nonce and it will pass the BlacklistedHashes check. So I doubt that this extension will be useful in practice.

Another pitfall is that every time we configure or update our CNs, this setting must be exactly the same within all CNs configs to avoid differences in behaviour.

[roman-khimov]

I think that banning transactions is not correct. This directly affects the state and once the problem is fixed we either need to re-process them or make "wrong" transaction definition a part of the state (like banning via Policy), but this addition would come after the transaction itself, so it'd mean we need to add these exceptions to every node on the network, a configuration nightmare.

Banning block hashes is a bit more acceptable because if we're to have any incorrect block in real life that's exactly what we're gonna do (just because there is nothing else we can do) --- fork it and have an alternative "correct" block with the same height. Then this means the "bad" block never happened and the chain is fully consistent at least. But it's the same configuration problem and so far this never actually happened (testnet block 5557998 is correct).

[shargon]

@roman-khimov changed to be only for blocks

[shargon]

We agreed at the meeting that it is not the best solution