-
Notifications
You must be signed in to change notification settings - Fork 33
Categorize blocks after their intended chain has been determined (Detect reorgs, properly label uncles, etc) #14
Comments
From AFDudley: We can check if a block was actually mined by looking at account balances, seems like an accounting nightmare but probably always correct: |
From AFDudley: Thinking about this problem, I'm realizing there are 4/5 types of blocks: Proposed Once a block has a height of at least HEAD - 12 geth considers it canonical. The hashes of uncle blocks are on the canonical chain and miners are rewarded for mining them. (yes this is game-able) but these blocks are not gossiped and it's perfectly valid for clients to discard them. Forked blocks are blocks that were part of chains created while the root of the forked chain was between HEAD and HEAD - 12. It's unclear to me if forked blocks can ever be uncles, I would assume yes. We need to to test see if it's ever happened, we will need to look at etherscan.io to find out. We should have a a table of just "blocks" with a genesis block, networkID, and ChainID associated with them. Over time, block categorized that way can move through these various types of blocks, which should be stored in their own tables. I'll relabel this issue block categorization. |
From AFDudley:
If the local canonical ordering of blocks is indexed by when we saw the block. We can then generate the rest of the required tables from that. The global canonical chain, which should be the basis of most derived data served to users, will be calculated by:
finding the highest block number call it HEAD
2 . CANON_NUM = HEAD - 12
For all blocks at CANON_NUM find the one with the greatest difficulty, this should be the head of the Canonical chain.
This will need to be tested against the full chain to see if this algorithm is ever wrong.
Source of 12 as a magic number: https://github.com/ethereum/go-ethereum/blob/9e5f03b6c487175cc5aa1224e5e12fd573f483a7/core/state/database.go#L35
The fundamental problem is that this claim is "false" (it's not true in a global context, nodes don't know when they are wrong about canonicality, by definition.): https://github.com/ethereum/go-ethereum/blob/43c8a1914ce5014c3589c2de0613a06eb6ad3f69/core/blockchain.go#L76
Where re-org are defined in go-ethereum: https://github.com/ethereum/go-ethereum/blob/43c8a1914ce5014c3589c2de0613a06eb6ad3f69/core/blockchain.go#L818
The text was updated successfully, but these errors were encountered: