EIP-2124 proposed a way of identifying nodes on the p2p network based on their chain configuration via the forkid parameter. It allows nodes to cut incompatible nodes off quickly which makes the P2P network more reliable. After the merge, forks are scheduled by block time instead of block number. This EIP updates the forkid calculation with block time.
While in proof-of-work forks were scheduled by block number, the proof-of-stake consensus layer schedules forks by slot number. The slot number is a time based measurement. In order to schedule forks at the same time on the consensus and execution layer, the execution layer is forced to also schedule forks by timestamp after the merge.
The forkid calculation allows peers to quickly determine the configuration of peers and disconnect peers that are misconfigured or configured for other networks.
Each node maintains the following values:
FORK_HASH: IEEE CRC32 checksum ([4]byte) of the genesis hash and fork blocks numbers or timestamps that already passed.
uint64 integers, encoded in big endian format when checksumming.uint64 integers, encoded in big endian format when checksumming.FORK_NEXT: Block number or timestamp (uint64) of the next upcoming fork, or 0 if no next fork is known.
FORK_NEXT.A FORK_HASH for a timestamp based fork at 1668000000 on top of homestead would be:
0xcb37b2ee (homestead+fictional fork) = CRC32(<genesis-hash> || uint64(1150000) || uint64(1668000000))The following additional rules are applied:
Shanghai will be scheduled by timestamp thus the forkid calculations need to be updated to work with timestamps and blocks. Since all block number based forks are before time based forks, nodes need to check the block based forks before the time based forks.
This change modifies the forkid calculation slightly. As a consequence nodes applying this change will drop peers who are not applying this change as soon as timestamp-scheduled fork occurs. This is not only expected, but actually the purpose of the forkid in the first place.
Here's a suite of tests with mainnet config and withdrawals enabled at time 1668000000 and merge netsplit block at block 18000000
Here's a suite of tests of the different states a Mainnet node might be in and the different remote fork identifiers it might be required to validate and decide to accept or reject:
No known security risks
Copyright and related rights waived via CC0.