"The term "blockchain reorganization" is used to refer to the situation where a client discovers a new difficultywise-longest well-formed blockchain which excludes one or more blocks that the client previously thought were part of the difficultywise-longest well-formed blockchain. These excluded blocks become orphans. Chain reorganization is a client-local phenomenon; the entire bitcoin network doesn't "reorganize" simultaneously." ~ https://en.bitcoin.it/wiki/Chain_Reorganization
How do you spot these?
When subscribing to incoming blocks, you might notice the block number shift in block hash. This doesn't happen very often, but it does happen. Notice that this block number has uncle rewards https://etherscan.io/block/15294144. More details here https://etherscan.io/uncle/0xf4aee932f3d85440075578024be7711c77ce2d15f22bffdea7482a5aad2dc2c5
So if you were listening for incoming blocks, the nodes might register this block as0xf4aee932f3d85440075578024be7711c77ce2d15f22bffdea7482a5aad2dc2c5
but shortly after reorged to0x84f53f8babb2ba03902cd7ae1f30891f1a0f069b22c2f5b55b1459917540b539
when the network came to a consensus.
How do I handle reorgs?
If you're indexing the blockchain, you don't want to store an uncle or reorg block data.
- don't index too close to the tip of the chain, as it can happen
- implement a delay when doing
eth_getBlockByNumber
oreth_getBlockReceipt
- keep an eye out for reorgs and how often they happen via the block explorer like https://etherscan.io/blocks_forked and https://polygonscan.com/blocks_forked
Comments
0 comments
Article is closed for comments.