AlertSourceDiscuss
Skip to content

EIP-6122: Forkid checks based on timestamps

Modifies the forkid checks to work with timestamps and block numbers

⚠️ ReviewNetworking

Peer Review Notice

This EIP is in the process of being peer-reviewed. If you are interested in this EIP, and have feedback to share, please participate using this discussion link. Thank you!

AuthorsMarius van der Wijden (@MariusVanDerWijden)
Created2022-12-13

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 FROK_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

go
type testcase struct {
	head uint64
	want ID
}
tests := []struct {
	config  *params.ChainConfig
	genesis common.Hash
	cases   []testcase
}{
	// Withdrawal test cases
	&withdrawalConfig,
	params.MainnetGenesisHash,
	[]testcase{
		{0, 0, ID{Hash: checksumToBytes(0xfc64ec04), Next: 1150000}},           // Unsynced
		{1149999, 0, ID{Hash: checksumToBytes(0xfc64ec04), Next: 1150000}},     // Last Frontier block
		{1150000, 0, ID{Hash: checksumToBytes(0x97c2c34c), Next: 1920000}},     // First Homestead block
		{1919999, 0, ID{Hash: checksumToBytes(0x97c2c34c), Next: 1920000}},     // Last Homestead block
		{1920000, 0, ID{Hash: checksumToBytes(0x91d1f948), Next: 2463000}},     // First DAO block
		{2462999, 0, ID{Hash: checksumToBytes(0x91d1f948), Next: 2463000}},     // Last DAO block
		{2463000, 0, ID{Hash: checksumToBytes(0x7a64da13), Next: 2675000}},     // First Tangerine block
		{2674999, 0, ID{Hash: checksumToBytes(0x7a64da13), Next: 2675000}},     // Last Tangerine block
		{2675000, 0, ID{Hash: checksumToBytes(0x3edd5b10), Next: 4370000}},     // First Spurious block
		{4369999, 0, ID{Hash: checksumToBytes(0x3edd5b10), Next: 4370000}},     // Last Spurious block
		{4370000, 0, ID{Hash: checksumToBytes(0xa00bc324), Next: 7280000}},     // First Byzantium block
		{7279999, 0, ID{Hash: checksumToBytes(0xa00bc324), Next: 7280000}},     // Last Byzantium block
		{7280000, 0, ID{Hash: checksumToBytes(0x668db0af), Next: 9069000}},     // First and last Constantinople, first Petersburg block
		{9068999, 0, ID{Hash: checksumToBytes(0x668db0af), Next: 9069000}},     // Last Petersburg block
		{9069000, 0, ID{Hash: checksumToBytes(0x879d6e30), Next: 9200000}},     // First Istanbul and first Muir Glacier block
		{9199999, 0, ID{Hash: checksumToBytes(0x879d6e30), Next: 9200000}},     // Last Istanbul and first Muir Glacier block
		{9200000, 0, ID{Hash: checksumToBytes(0xe029e991), Next: 12244000}},    // First Muir Glacier block
		{12243999, 0, ID{Hash: checksumToBytes(0xe029e991), Next: 12244000}},   // Last Muir Glacier block
		{12244000, 0, ID{Hash: checksumToBytes(0x0eb440f6), Next: 12965000}},   // First Berlin block
		{12964999, 0, ID{Hash: checksumToBytes(0x0eb440f6), Next: 12965000}},   // Last Berlin block
		{12965000, 0, ID{Hash: checksumToBytes(0xb715077d), Next: 13773000}},   // First London block
		{13772999, 0, ID{Hash: checksumToBytes(0xb715077d), Next: 13773000}},   // Last London block
		{13773000, 0, ID{Hash: checksumToBytes(0x20c327fc), Next: 15050000}},   // First Arrow Glacier block
		{15049999, 0, ID{Hash: checksumToBytes(0x20c327fc), Next: 15050000}},   // Last Arrow Glacier block
		{15050000, 0, ID{Hash: checksumToBytes(0xf0afd0e3), Next: 18000000}},   // First Gray Glacier block
		{18000000, 0, ID{Hash: checksumToBytes(0x4fb8a872), Next: 1668000000}}, // First Merge Start block
		{20000000, 0, ID{Hash: checksumToBytes(0x4fb8a872), Next: 1668000000}}, // Last Merge Start block
		{20000000, 1668000000, ID{Hash: checksumToBytes(0xc1fdf181), Next: 0}}, // First Shanghai block
		{20100000, 2669000000, ID{Hash: checksumToBytes(0xc1fdf181), Next: 0}}, // Future Shanghai block
	},
}

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:

go
tests := []struct {
	head uint64
	id   ID
	err  error
}{
	/// Local is mainnet Withdrawals, remote announces the same. No future fork is announced.
	{20000000, 1668000001, ID{Hash: checksumToBytes(0xc1fdf181), Next: 0}, nil},

	// Local is mainnet Withdrawals, remote announces the same also announces a next fork
	// at block/time 0xffffffff, but that is uncertain.
	{20000000, 1668000001, ID{Hash: checksumToBytes(0xc1fdf181), Next: math.MaxUint64}, nil},

	// Local is mainnet currently in Byzantium only (so it's aware of Petersburg & Withdrawals), remote announces
	// also Byzantium, but it's not yet aware of Petersburg (e.g. non updated node before the fork).
	// In this case we don't know if Petersburg passed yet or not.
	{7279999, 1667999999, ID{Hash: checksumToBytes(0xa00bc324), Next: 0}, nil},

	// Local is mainnet currently in Byzantium only (so it's aware of Petersburg & Withdrawals), remote announces
	// also Byzantium, and it's also aware of Petersburg (e.g. updated node before the fork). We
	// don't know if Petersburg passed yet (will pass) or not.
	{7279999, 1667999999, ID{Hash: checksumToBytes(0xa00bc324), Next: 7280000}, nil},

	// Local is mainnet currently in Byzantium only (so it's aware of Petersburg & Withdrawals), remote announces
	// also Byzantium, and it's also aware of some random fork (e.g. misconfigured Petersburg). As
	// neither forks passed at neither nodes, they may mismatch, but we still connect for now.
	{7279999, 1667999999, ID{Hash: checksumToBytes(0xa00bc324), Next: math.MaxUint64}, nil},

	// Local is mainnet exactly on Withdrawals, remote announces Byzantium + knowledge about Petersburg. Remote
	// is simply out of sync, accept.
	{20000000, 1668000000, ID{Hash: checksumToBytes(0xa00bc324), Next: 7280000}, nil},

	// Local is mainnet Withdrawals, remote announces Byzantium + knowledge about Petersburg. Remote
	// is simply out of sync, accept.
	{20000000, 1668000001, ID{Hash: checksumToBytes(0xa00bc324), Next: 7280000}, nil},

	// Local is mainnet Withdrawals, remote announces Spurious + knowledge about Byzantium. Remote
	// is definitely out of sync. It may or may not need the Petersburg update, we don't know yet.
	{20000000, 1668000001, ID{Hash: checksumToBytes(0x3edd5b10), Next: 4370000}, nil},

	// Local is mainnet Byzantium & pre-withdrawals, remote announces Petersburg. Local is out of sync, accept.
	{7279999, 1667999999, ID{Hash: checksumToBytes(0x668db0af), Next: 0}, nil},

	// Local is mainnet Spurious, remote announces Byzantium, but is not aware of Petersburg. Local
	// out of sync. Local also knows about a future fork, but that is uncertain yet.
	{4369999, 1667999999, ID{Hash: checksumToBytes(0xa00bc324), Next: 0}, nil},

	// Local is mainnet Withdrawals. remote announces Byzantium but is not aware of further forks.
	// Remote needs software update.
	{20000000, 1668000001, ID{Hash: checksumToBytes(0xa00bc324), Next: 0}, ErrRemoteStale},

	// Local is mainnet Withdrawals, and isn't aware of more forks. Remote announces Petersburg +
	// 0xffffffff. Local needs software update, reject.
	{20000000, 1668000001, ID{Hash: checksumToBytes(0x5cddc0e1), Next: 0}, ErrLocalIncompatibleOrStale},

	// Local is mainnet Withdrawals, and is aware of Petersburg. Remote announces Petersburg +
	// 0xffffffff. Local needs software update, reject.
	{20000000, 1668000001, ID{Hash: checksumToBytes(0x5cddc0e1), Next: 0}, ErrLocalIncompatibleOrStale},

	// Local is mainnet Withdrawals, remote is Rinkeby Petersburg.
	{20000000, 1668000001, ID{Hash: checksumToBytes(0xafec6b27), Next: 0}, ErrLocalIncompatibleOrStale},

	// Local is mainnet Withdrawals, far in the future. Remote announces Gopherium (non existing fork)
	// at some future block 88888888, for itself, but past block for local. Local is incompatible.
	//
	// This case detects non-upgraded nodes with majority hash power (typical Ropsten mess).
	{88888888, 1668000001, ID{Hash: checksumToBytes(0xf0afd0e3), Next: 88888888}, ErrRemoteStale},

	// Local is mainnet Withdrawals. Remote is in Byzantium, but announces Gopherium (non existing
	// fork) at block 7279999, before Petersburg. Local is incompatible.
	{20000000, 1668000001, ID{Hash: checksumToBytes(0xa00bc324), Next: 7279999}, ErrRemoteStale},

Security Considerations

No known security risks

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Marius van der Wijden, "EIP-6122: Forkid checks based on timestamps[DRAFT]," Ethereum Improvement Proposals, no. 6122, 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6122.