EIP-6122: Forkid checks based on timestamps

Modifies the forkid checks to work with timestamps and block numbers

Metadata

Status: FinalStandards Track: NetworkingCreated: 2022-12-13

Authors

Marius van der Wijden (@MariusVanDerWijden)

Requires

EIP-2124

Links

GitHub page Discussion on Ethereum Magicians

Abstract

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.

Motivation

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.

Specification

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.
- The fork block numbers or timestamps are fed into the CRC32 checksum in ascending order.
- If multiple forks are applied at the same block or time, the block number or timestamp is checksummed only once.
- Block numbers are regarded as uint64 integers, encoded in big endian format when checksumming.
- Block timestamps are regarded as uint64 integers, encoded in big endian format when checksumming.
- If a chain is configured to start with a non-Frontier ruleset already in its genesis, that is NOT considered a fork.
FORK_NEXT: Block number or timestamp (uint64) of the next upcoming fork, or 0 if no next fork is known.
- Note that it is not important to distinguish between a timestamp or a block for FORK_NEXT.

A FORK_HASH for a timestamp based fork at 1668000000 on top of homestead would be:

forkhash₁ = 0xcb37b2ee (homestead+fictional fork) = CRC32(<genesis-hash> || uint64(1150000) || uint64(1668000000))

Additional rules

The following additional rules are applied:

Forks by timestamp MUST be scheduled at or after the forks by block (on mainnet as well as on private networks).
An implementation of forkid verification of remote peer needs to filter the incoming forkids first by block then by timestamp.

Rationale

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.

Backwards Compatibility

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.

Test Cases

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:

Security Considerations

No known security risks

Copyright