Providing the `zkTracer` plugin with a `ProtocolSchedule` to handle hardforks

[OlivierBBB]

Description

The zkTracer plugin (as well as the constraints) will need to support hardforks in the form of block number or timestamp defined upgrades in the underlying EVM. Ideally we would like to be able to handle these upgrades using the same tracer. This could work by providing plugins with a ProtocolSchedule object. The idea being that the zkTracer would trace (and perform line counting) according to the underlying EVM version which can be extracted from said ProtocolSchedule.

Notes

• There are already methods to derive a ProtocolSchedule from a BlockHeader and alternatively from the previous BlockHeader and a futureTimeStamp. It may also make sense to provide an interface for deriving a ProtocolSchedule from a long blockNumber alone.
• The Sequencer, which uses the tracer, cannot rely on a BlockHeader to derive the relevant data as its job is to assemble transactions into a block.
• Conflations produced by the (Linea) Coordinator must be mono-fork.
• We may also leap-frog EVM releases (e.g. switch directly from London to Prague)

Benefits for Linea:

• deploying a single tracer which is backwards compatible with all supported EVM's
• seemlessly upgrade to a new EVM at a given block height without interrupting the block building

Relevant comment of @fab-10

This is a big topic [...] so I start sharing my opinion here: for me the natural and future proof way to manage the hard forks, is to leverage the protocol schedule, the work to make it available to plugins have been kept on hold, since with the centralization it is not mandatory, but could be that it is now time to pick it up. So in a very high view of the processes, when a plugin has some code that needs to run differently according to the hard fork, the choice is driven by the protocol schedule, and every plugin simply needs to ask it which is the path to follow.

[fluentcrafter]

Block time on Linea is not constant/deterministic for several reasons:

• no empty blocks
• sequencer downtime
• change of block time to increase network capacity and lower latency

For these reasons, linea's forks rely on block numbers.

Besu ProtocolSchedule logic seems to rely on blockNumber and timestamp by looking at it's interface methods putBlockNumberMilestone and putTimestampMilestone. Likewise, I think we should extend the interface with a method to retrieve the ProtocolSpec by blockNumber, e.g

ProtocolSpec getByBlockNumber(final long blockNumber);

[fab-10]

Update to the requirements to fulfill the current needs we need to expose two methods:

• get the fork by block header: to query the fork of an existing block
• get the fork for the next block: to query the fork for the block being built