Finalized Root In Genesis Is Not Clarified

[nisdas]

https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/p2p-interface.md#status

Currently in the networking spec:

state.finalized_checkpoint.root for the state corresponding to the head block

This came up in witti, as we were expecting the genesis block root as the finalized root in status messages, but lighthouse instead expected a zero_hash. Is there any reason the genesis_block_root cannot be considered as the root in the finalized checkpoint ?

[arnetheduck]

The reason is that the genesis state contains a zero_hash in this field - the reason for that is bootstrapping - the genesis state is created before the genesis block, so you can't assign the genesis block root to that field.

[nisdas]

While having a zero_hash prevents a circular reference in regards to how genesis state and block are derived we do lose a property with status handshakes at genesis, where we would be able to differentiate peers with different genesis states. Ex: Same genesis validator root but different eth1data/genesis_time.

This would only become clear when each peer is unable to process the other peer's blocks, also intuitively it would be easy to mistake that the genesis state's finalized root is the genesis block.

Maybe this can be clarified in the spec instead that at genesis checkpoint roots are zero_hash and to account for it in status handshakes

[prestonvanloon]

We're looking to restart the Topaz network with v0.12 changes, could we get some clarity on which is the appropriate solution?

The majority of the clients in Witti understood that the finalized checkpoint root was the genesis block root, but we switched to zero_hash for a quick resolution. As we are aiming to restart Topaz for v0.12 fixes, we'd appreciate clarification this week. Thanks

[djrtwo]

Considering 0x00 is used in a number of locations and that clients are currently conformant to 0x00, I'd prefer to keep it here as a special case.

I'll make note in the spec today

[djrtwo]

Also, now that I'm looking at it "state.finalized_checkpoint.root for the state corresponding to the head block" should in fact give you the genesis root as zero_hash because that is how it is handle in state before a new finalized checkpoint comes through.

will still add a clarifying comment