[refactor]: remove signatures from blocks

[mversic]

Description

• remove signatures from blocks stored on chain
  Signatures are transient and only applicable during consensus. Since blocks in a blockchain are tied together via block hashes, keeping block signatures after consensus is not only superfluous but also creates issues when replaying blocks when topology has changed (related to How to update peer's blockstore when the whole topology changed #4145)
• removed consensus_estimation from block header - it was unused
• removed event_recommendations from block - it was unused

Future work

• Following this PR, block sync protocol should be modified to prevent syncing with malicious peers. This can be done with not too much overhead

Checklist

• I've read CONTRIBUTING.md
• I've used the standard signed-off commit format (or will squash just before merging)
• All applicable CI checks pass (or I promised to make them pass later)
• (optional) I've written unit tests for the code changes
• I replied to all comments after code review, marking all implemented changes with thumbs up

[Erigara]

I don't think we can get rid of storing block's signatures.
Because this way we forcing a new peer who is joining the network to trust that blocks are valid without ability to verify that.

Since blocks in a blockchain are tied together via block hashes

Without signatures malicious peer can provide any blockchain sequence it want.

[mversic]

I don't think we can get rid of storing block's signatures, because otherwise we force peer who is joining network to trust that blocks are valid.

Since blocks in a blockchain are tied together via block hashes

Without signatures malicious peer can provide any blockchain sequence it want.

yes, but that's only a matter of block sync as I mentioned in the description. This can be taken care of like this:

1. new node joins the network
2. new node broadcasts request to get hash of the next block to all peers
3. it collects responses and is now confident in what the next block is (every response is signed by the corresponding peer)
4. sends a request to one of the peers to get the actual block
5. validates that hash of the block is as expected
6. applies the block

or some more optimized version of this

[mversic]

@Erigara the point is that node needs to contact the network, not just one peer when doing block sync because it cannot trust one node. So it asks the network what the hash of the next block is before requesting next block via block sync

[Erigara]

This makes block synchronization much more complex.

And also vulnerable to cases where suppose that only one peer left of the whole topology for some reason.

With signatures (and initial set of peers) we still have an ability to check that blocks are valid, without them there is no way.

[mversic]

This makes block synchronization much more complex.

somewhat more complex. This is why block sync should be avoided if possible. This change shouldn't increase network traffic by a noticeable amount (just circling some extra hashes)

And also vulnerable to cases where suppose that only one peer left of the whole topology for some reason.

even in the current implementation this lone peer could put anything in the signature set and compromise the blockchain. Note that genesis_private_key only signs genesis transactions, it doesn't sign genesis block. Genesis block is signed by a peer so we have to trust this peer to put correct signatures in the block.

With signatures (and initial set of peers) we still have an ability to check that blocks are valid, without them there is no way.

this is not true again, or true only superficially. As in the previous example, new peer has to trust the peer it's connecting to because that peer can manipulate signatures of the genesis block. With the current approach, new peer trusts the one peer from trusted_peers it connects to. With new approach at least this trust is dispersed among all peers of the trusted_peers set.

[Erigara]

even in the current implementation this lone peer could put anything in the signature set and compromise the blockchain. Note that genesis_private_key only signs genesis transactions, it doesn't sign genesis block. Genesis block is signed by a peer so we have to trust this peer to put correct signatures in the block.

Good point.
I didn't say that current implementation is flawless (far from that).
So current vector of attack is to replace committed_topology of genesis block with only this peer.
Then this peer can produce any block he wants.
Afaik this could be fixed by signing genesis block and inclusion of initial topology public keys into genesis (maybe just inserting them as ISIs?).

After that malicious peer can't mess up with topology because every inclusion or deletion of peer is recorded within transactions ((Un)Register<Peer>).

somewhat more complex. This is why block sync should be avoided if possible. This change shouldn't increase network traffic by a noticeable amount (just circling some extra hashes)

Agree about noticeable amount. I'm more concerned about implementing quorum algorithm for that.

or true only superficially

Yeah, this example is kinda handcrafted but i want to be extra-careful when talking about compromising the whole chain.

All in all i'm suggesting to investigate this question more deeply.
Maybe removal of signatures is fine and i'm just extra cautious.

[mversic]

Afaik this could be fixed by signing genesis block and inclusion of initial topology public keys into genesis (maybe just inserting them as ISIs?).

this seems like it would do the trick, except that we should make sure genesis consists of exactly 1 transaction so that the peer submitting genesis cannot remove or reorder any

All in all i'm suggesting to investigate this question more deeply. Maybe removal of signatures is fine and i'm just extra cautious.

ofc. I'd like this to be thoroughly considered. I'm not that convinced myself