Implement ChainSpec and HardForks

[frisitano]

Overview

We must implement a ChainSpec and HardForks for scroll and also scroll sepolia testnet.

Hardfork

The Hardfork is used to determine the block number and timestamp at which features / functionality is changed. An example of a Hardfork implementation for Optimism can be found here. It should be noted that there is an expectation for hardforks to be mixed with ethereum hardforks as stated here:

reth/crates/optimism/hardforks/src/hardfork.rs

Lines 17 to 36 in 9c9d82c

	/// The name of an optimism hardfork.
	///
	/// When building a list of hardforks for a chain, it's still expected to mix with
	/// [`EthereumHardfork`].
	OpHardfork {
	/// Bedrock: <https://blog.oplabs.co/introducing-optimism-bedrock>.
	Bedrock,
	/// Regolith: <https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/superchain-upgrades.md#regolith>.
	Regolith,
	/// <https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/superchain-upgrades.md#canyon>.
	Canyon,
	/// Ecotone: <https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/superchain-upgrades.md#ecotone>.
	Ecotone,
	/// Fjord: <https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/superchain-upgrades.md#fjord>
	Fjord,
	/// Granite: <https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/superchain-upgrades.md#granite>
	Granite,
	/// Holocene: <https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/superchain-upgrades.md#holocene>
	Holocene,
	}

We should review the hardforks introduce in scrolls fork of revm which are feature gated in the link provided. We should then implement a pattern similar to optimism by creating a crate to define these in reth for scroll. These will then be subsequently integrated with the revm hardfork type as seen below in the optimism example (this is outside of the scope of this issue and should be handled in #5):

reth/crates/optimism/evm/src/config.rs

Lines 5 to 30 in 9c9d82c

	/// Returns the revm [`SpecId`](revm_primitives::SpecId) at the given timestamp.
	///
	/// # Note
	///
	/// This is only intended to be used after the Bedrock, when hardforks are activated by
	/// timestamp.
	pub fn revm_spec_by_timestamp_after_bedrock(
	chain_spec: &OpChainSpec,
	timestamp: u64,
	) -> revm_primitives::SpecId {
	if chain_spec.fork(OpHardfork::Holocene).active_at_timestamp(timestamp) {
	revm_primitives::HOLOCENE
	} else if chain_spec.fork(OpHardfork::Granite).active_at_timestamp(timestamp) {
	revm_primitives::GRANITE
	} else if chain_spec.fork(OpHardfork::Fjord).active_at_timestamp(timestamp) {
	revm_primitives::FJORD
	} else if chain_spec.fork(OpHardfork::Ecotone).active_at_timestamp(timestamp) {
	revm_primitives::ECOTONE
	} else if chain_spec.fork(OpHardfork::Canyon).active_at_timestamp(timestamp) {
	revm_primitives::CANYON
	} else if chain_spec.fork(OpHardfork::Regolith).active_at_timestamp(timestamp) {
	revm_primitives::REGOLITH
	} else {
	revm_primitives::BEDROCK
	}
	}

ChainSpec

The ChainSpec defines the core primitives of the chain such as the chain id, state genesis data, hardforks and other properties relating to the chain. A comprehensive view of the ChainSpec can be seen by observing the data structure:

reth/crates/chainspec/src/spec.rs

Lines 171 to 216 in 9c9d82c

	/// An Ethereum chain specification.
	///
	/// A chain specification describes:
	///
	/// - Meta-information about the chain (the chain ID)
	/// - The genesis block of the chain ([`Genesis`])
	/// - What hardforks are activated, and under which conditions
	#[derive(Debug, Clone, PartialEq, Eq)]
	pub struct ChainSpec {
	/// The chain ID
	pub chain: Chain,
	/// The genesis block.
	pub genesis: Genesis,
	/// The hash of the genesis block.
	///
	/// This is either stored at construction time if it is known using [`once_cell_set`], or
	/// computed once on the first access.
	pub genesis_hash: OnceLock<B256>,
	/// The header corresponding to the genesis block.
	///
	/// This is either stored at construction time if it is known using [`once_cell_set`], or
	/// computed once on the first access.
	pub genesis_header: OnceLock<Header>,
	/// The block at which [`EthereumHardfork::Paris`] was activated and the final difficulty at
	/// this block.
	pub paris_block_and_final_difficulty: Option<(u64, U256)>,
	/// The active hard forks and their activation conditions
	pub hardforks: ChainHardforks,
	/// The deposit contract deployed for `PoS`
	pub deposit_contract: Option<DepositContract>,
	/// The parameters that configure how a block's base fee is computed
	pub base_fee_params: BaseFeeParamsKind,
	/// The maximum gas limit
	pub max_gas_limit: u64,
	/// The delete limit for pruner, per run.
	pub prune_delete_limit: usize,
	}

We should follow a similar pattern as Optimism and implement a crate for scrolls ChainSpec associated types. The Optimism example can be found here. We should implement a spec for both scroll mainnet and scroll sepolia.

[greged93]

Should we add the fee_vault_address as part of the ScrollChainSpec?

This would follow the pattern used in l2geth and allow us to introduce ScrollEvmConfig and implement ConfigureEvmEnv, where we can set the coinbase for the block to the vault address.

[georgehao]

I think we need to add.