Support timestamp forks and implement shanghaiTime

[gezero]

Implement shanghaiTime including TimestampSchedule and associated infrastructure code.
TimestampSchedule sits alongside the pre and post MergeProtocolSchedules in TransitionProtocolSchedule.

General call pattern followed is that if a given timestamp precedes the first timestamp in the schedule, i.e. a pre-shanghai block, then delegate to the appropriate MergeProtocolSchedule.

cancunTime has also been implemented in order to effectively test fork order logic.

Note, some issues will follow on from this:
#4793
#4788
#4789

[bobsummerwill]

Is there some EIP specification which is being implemented here?

I am having an issue finding a paper-trail (and prior discussions and justifications) for switching to date-based activation.

[siladu]

Is there some EIP specification which is being implemented here?

I am having an issue finding a paper-trail (and prior discussions and justifications) for switching to date-based activation.

@bobsummerwill I've not seen anything written down other than on calls/discord. It was mentioned in the last 15 mins of the recent ACD#151: Marius from geth team is going to implement an EIP for this. I think most/all client teams have implemented this in some form already though for withdrawals devnet interop.
I think the justification is the ability to couple CL and EL forks, i.e. Capella and Shanghai should fork at the same time. CL uses forks based on Epochs, which are a proxy for timestamps.

There's also some hive tests PRs for Withdrawals that use timestamp activation: ethereum/hive#659
https://notes.ethereum.org/@marioevz/Withdrawals-hive-testing

[ajsutton]

Yep, ultimately this will just be specified by the Shanghai EIP/meta-EIP though I'm not entirely sure if we're doing meta-EIPs for upgrades anymore (we might, I just lost track of the process). Since the format of chain config files aren't standardised it basically just boils down to the fact that Shanghai will state "for any block where timestamp > X" rather than "for any block where number is > X".

Marius Van Der Wijden is putting together an EIP around this though (as per ACD notes) - I think that's predominantly for how the fork ID is calculated now but may cover more than that.

And as Simon notes it is a requirement for making withdrawals work that the CL and EL trigger the upgrade at the same time and that can't be done with block number because the CL needs to perform the transition at an epoch boundary and block number and slot number aren't tied together (can have empty slots that don't increase the block number).

[bobsummerwill]

Thanks for the clarification, @ajsutton.

Meta EIPs are no more, so it would make sense to capture this in an EIP, yes.

Best wishes!

[jframe]

Is the timestamp forks implementation only for non-privacy uses? It's missing the setPublicWorldStateArchiveForPrivacyBlockProcessor and setTransactionFilter which are needed for privacy features.

[siladu]

I don't think we should exclude private use cases (I renamed MainnetTimestampSchedule -> DefaultTimestampSchedule to reflect this).

I didn't spot that anything was missed compared to the others, so I'll look into adding these, thanks!

[siladu]

committed something for this including a new PrivacySupportingProtocolSchedule interface

[garyschulte]

disagree about the privacy stuff. I think we should be excising it in favor of mainnet compatibility. $0.02

[siladu]

I think we should discuss with hyperledger community whether timestamp support is desirable (in lieu of having an easy way to split out these use cases)

[jframe]

There is a lot of duplication between this class and the ProtocolScheduleBuilder. Is it possible to reuse some of the code from ProtocolScheduleBuilder? Or just reuse the ProtocolScheduleBuilder passing the timestamp specific pieces?

[siladu]

I'll have a think about this. Some of the duplication goes away when we remove the modifiers as part of #4788.

There's enough slight differences that I'm worried it could make it unnecessarily complicated to understand the code.
I don't expect the logic of this code to change much either so wouldn't greatly benefit from the DRYness.
Also, eventually we'll probably only use the TimestampSchedule for public networks at least and ProtocolSchedule for private use cases so they may naturally live separately in the future.

[siladu]

OK, I've implemented it using a template pattern and introducing AbstractProtocolScheduleBuilder here: gezero#1

It was easy enough...question is though, is it worth the extra complexity for the future code reader?

[siladu]

After speaking to Jason, decide to add the refactor into this PR.