Currently, when resolving conflicts and performing a state reorganization, the system completely resets the state to genesis and re-validates/re-computes all blocks from block 1 to the new tip of the incoming chain. Recomputing the entire state from genesis during a reorg is highly inefficient and does not scale well as the blockchain grows. The local chain and the incoming heavier chain will almost always share a common prefix up to a certain block N*
Instead of rebuilding the state from genesis, the node should:
- Identify the highest common block (N∗ ) between the local chain and the incoming chain.
- Roll back the current state to the state at block N∗ .
- Apply and validate only the new blocks from the incoming chain that come after N∗ .
Currently, when resolving conflicts and performing a state reorganization, the system completely resets the state to genesis and re-validates/re-computes all blocks from block 1 to the new tip of the incoming chain. Recomputing the entire state from genesis during a reorg is highly inefficient and does not scale well as the blockchain grows. The local chain and the incoming heavier chain will almost always share a common prefix up to a certain block N*
Instead of rebuilding the state from genesis, the node should: