Reusing networkId on relaunch lets stale peers push old-chain blocks, causing excessive processing #302
Description
What did you expect to see?
When a blockchain network is re-launched using the same networkId, I expected nodes in the new network (bootstrap/validators) to refuse connections and/or ignore blocks coming from an external node that still has the old network state, especially after the new network’s Block #0 (genesis) is validated.
Concretely: after the new genesis is agreed, peers should only be allowed to sync a chain that is anchored to that genesis and any blocks from a different historical chain should be rejected early and the peer penalized/disconnected.
What did you see instead?
An external node that still has old blockchain state is able to connect to the newly re-launched network (same networkId). After the new network successfully handles/approves Block #0, the external node begins pushing blocks from the old chain (with very large block numbers). The bootstrap/validators start spending time receiving, buffering, requesting dependencies, and “processing started” on those blocks, keeping nodes busy.
Impact: if the old chain has a large number of blocks, this can create a sustained resource exhaustion / availability issue (CPU + IO + scheduler load) for bootstrap/validator nodes. I suppose it definitely can be an availability attack vector under the precondition that the network is re-launched with the same networkId and peers can connect from outside.
Log will be shared in Slack channel
Steps to reproduce the bug
- Start a network (“Network A”) with some networkId. Launch external validator that connects to this network. Allow the network A to progress so there is an existing chain state with many blocks
- Stop Network A and reset its state
- Keep running an external node that still has the old data dir / old chain state from Network A
- Launch a new network from scratch (“Network B”) re-using the same networkId, producing a new genesis (Block #0) for Network B.
- Observe that Network B nodes successfully perform the new genesis ceremony & start receiving and attempting to process high-numbered blocks from the old chain
What version of RNode are you using?
Built from source, from main branch with commit 8084a01
Can be downloaded from docker hub: public.ecr.aws/f6y9h6x4/asi-chain/node:dev
What is your environment?
Each node in the network is located on its own VM machine( bootstrap , validator1, validator2, validator3, external validator)