# EPF5 Week9

As with the previous week, I encountered an issue of low-frequency data inconsistency when a Chain Reorgaznion(Reorg) occured, you can find the details here: https://hackmd.io/@jsvisa/epf5-week8#1-data-inconsistency-between-canonical-chain-and-stored-data

This week I ran 3 consensus nodes(prysm) along with 1 execution node(geth) to induce Reorgs more frequently, and stuck with the same issue, and couldn't find a better way to identify the right chanonical block hash while in the handling of the latest block. As the head block was updated by the FCU message, https://github.com/ethereum/go-ethereum/blob/e16df0f475c132c13ee1e90b728ad1999db63851/eth/catalyst/api.go#L314:

func (api *ConsensusAPI) ForkchoiceUpdatedV3(update engine.ForkchoiceStateV1, params *engine.PayloadAttributes) (engine.ForkChoiceResponse, error) {
    ... 
	return api.forkchoiceUpdated(update, params, engine.PayloadV3, false)
}

func (api *ConsensusAPI) forkchoiceUpdated(update engine.ForkchoiceStateV1, payloadAttributes *engine.PayloadAttributes, payloadVersion engine.PayloadVersion, simulatorMode bool) (engine.ForkChoiceResponse, error) {
    ... 
	if rawdb.ReadCanonicalHash(api.eth.ChainDb(), block.NumberU64()) != update.HeadBlockHash {
		// Block is not canonical, set head.
		if latestValid, err := api.eth.BlockChain().SetCanonical(block); err != nil {
			return engine.ForkChoiceResponse{PayloadStatus: engine.PayloadStatusV1{Status: engine.INVALID, LatestValidHash: &latestValid}}, err
		}
        ...
}

So in our side(the live tracer) don't have any knowledge of the head block. To address this, I proposed an alternative method for storing trace data:

Store latest-64 blocks in kvdb(pebble), and freeze the old blocks into freezer db inside the OnBlockEnd hook, details as below:

1. pass `eth.Backend` to the main filter struct;
2. store the traces in the KVDB with the key format as `traceType + blockNum + hash` during the `OnBlockStart` handler
3. inside the `OnBlockEnd` hook, use `eth_getBlock` API to figure out the correct block hashes, and then move the correct resutls into freezer, in the meanwhile delete the `traceType + blockNum + hash -> traces` keypairs in kvdb to free space, this should be handled in async, avoid blocking the execution of the main block processing.

This approach requires additional refactoring and remains a work in progress.