Block pruning related changes to p2p layer
Implementing the idea of older block pruning (see e.g. here, section 1. Pruning with fallback.) impacts several subsystems including p2p layer.
Identified problems
The one area of concern is syncing, the cases that may be disturbed by pruning are:
- Syncing from scratch (starting with an empty blockchain). If a (pruned) peer returns the list starting from its Earliest Known Block (EKB), the node will disconnect the peer with invalid response message. Otherwise if peer responds with empty list, the node will stay connected, which could eventually lead to filling up the connections with peers that can't provide oldest (starting) blocks.
- Regular syncing with pruned peer
- In case of a gap between latest blocks of the node and EKB of the peer empty list is returned and the peer stays connected with consequences as described above.
- When the blocks have been pruned after the peer declared it's got them but before the node asked for them, the peer will be disconnected (suspected of having corrupted database). When the peer is reconnected there will be a gap between node's & peer's blocks, i.e. we've got case 2.1.
Suggested solution
- Add EKB info on sender side to messages exchanged between node and peers - it will allow to distinguish the nature of the problem (pruning) from currently assumed scenarios on receiver side.
- Use attached EKB info to e.g. permanently disconnect the peers that can't help our node syncing due to the gap created by their pruning.
- Handle the case of depleting the peer list due to pruning-related disconnections - report appropriate error and exit (alternatively wait for adding appropriate peer using API).
Implementation proposal
- Define a new version of GRAPHENE_NET_PROTOCOL (e.g. GRAPHENE_NET_PROTOCOL_PRUNING) and broadcast it as part of hello message.
- Use existing peer_connection.core_protocol_version field to check whether the peer is pruning-prone.
- Rename selected existing messages with _old suffix.
- Use their former names by new messages (with new ids), extended with EKB info.
- When about to send a message choose the version (extended or old) based on info provided by peer (its protocol version).
- Receive new messages standard way.
- Most likely there's only one message needing the extension -
blockchain_item_ids_inventory_message
sent fromon_fetch_blockchain_item_ids_message
and received inon_blockchain_item_ids_inventory_message
.
Edited by Łukasz Bujak