Shanghai fork time instead of block number?

[alexqrid]

I actually surprised, why did you set unix timestamp for the Shanghai fork at #26908?
For all previous forks the point of fork was always set to the block number instead of timestamp, and this was pretty clear, because the timestamp synchronization is a tricky in a distributed system, but the block number is a straight way for the Ethereum protocol as the reference point.
There are no engough checks for the block timestamp on the consensus layer as well, so, the question seems reasonable.

[MariusVanDerWijden]

The forks after the merge are actually scheduled by slot on the cl, so we need to activate the same fork on the EL at the same slot. The slotnumber itself is based on a timestamp.
See also the EIP for it: https://eips.ethereum.org/EIPS/eip-6122

[piersy]

Hi @MariusVanDerWijden I still don't see why the switch was made to timestamps because both the CL and the EL are aware of the block number, so you could also use block number to ensure that a fork is activated at the same time on both CL and EL?

[MariusVanDerWijden]

Yes you could, but that would also mean you would need to handle cases where the beacon chain is reorged both on the el and cl. Doing it like this is much cleaner for both layers