fix race condition leading to seg faults

[anshalshukla]

The fetched_blocks map in the network layer is accessed by both the main thread and the libp2p thread. The main thread was using a shallow copy of the blocks, which caused segmentation faults during long chain syncs. This happened because blocks could be pruned after finalization while still being referenced by the main thread.

This issue doesn’t appear when the chain remains fully synced, since pruning and access don’t overlap in the same way.

The issue happens because the hashmap resizes when new blocks are inserted on the network thread. This causes rehashing, which moves keys to different positions. Meanwhile, the main thread still relies on the old positions based on the previous size, so those references become invalid and lead to a panic.

To fix this, don’t share internal hashmap positions across threads. Either lock the hashmap while it’s being accessed or pass a full copy of the data instead of references.

[anshalshukla]

Closing this as the other approach suggested by @ch4r10t33r seems better

[GrapeBaBa]

What is the blocking issue right now for schedule network callback in the main eventloop(#326) right now? a lot of mutex added recently which could cause live/dead lock issue or perf regression, it should be easy to avoid race by reducing the logic in the network thread. @anshalshukla @ch4r10t33r @g11tech

[anshalshukla]

Included in #765