chore(sdk): ChainSpec generic over hardforks

[emhane]

Closes #10468

Makes ChainSpec generic over hard forks, leaving ChainHardforks as default generic.

[klkvr]

hmm, wondering what's the plan here? reuse ChainSpec with different generic for optimism? what would that generic look like?

[emhane]

hmm, wondering what's the plan here? reuse ChainSpec with different generic for optimism? what would that generic look like?

yepp. and any rollup with same chain spec type asides hard forks. it's a building block, to make it easier for rollups to enjoy the customisability of the new reth sdk.

[mattsse]

hmm, the chainspec already has some additional chain specific internals, like deposit contract and for other chains it's likely that some additional fields should be included there as well.

so it's imo easier to roll your own, like we already prepped with OpChainspec

[klkvr]

hmm, wondering what's the plan here? reuse ChainSpec with different generic for optimism? what would that generic look like?

yepp. and any rollup with same chain spec type asides hard forks. it's a building block, to make it easier for rollups to enjoy the customisability of the new reth sdk.

makes sense!

I've changed EthereumHardforks trait a bit in #10978, because it seemed reasonable to move final_paris_total_difficulty fn to it. because of that, we now have to implement/require trait on ChainSpec directly which I think breaks this usecase a bit. should we consider moving paris_block_and_final_difficulty to ChainHardforks to support this?

[emhane]

hmm, wondering what's the plan here? reuse ChainSpec with different generic for optimism? what would that generic look like?

yepp. and any rollup with same chain spec type asides hard forks. it's a building block, to make it easier for rollups to enjoy the customisability of the new reth sdk.

makes sense!

I've changed EthereumHardforks trait a bit in #10978, because it seemed reasonable to move final_paris_total_difficulty fn to it. because of that, we now have to implement/require trait on ChainSpec directly which I think breaks this usecase a bit. should we consider moving paris_block_and_final_difficulty to ChainHardforks to support this?

let's move it to Hardforks trait. it's supertrait of EthereumHardforks.

[emhane]

hmm, the chainspec already has some additional chain specific internals, like deposit contract and for other chains it's likely that some additional fields should be included there as well.

so it's imo easier to roll your own, like we already prepped with OpChainspec

it's written as a bullet point in your notion sdk notes?

[mattsse]

we're going with OpChainSpec and EthChainSpec as standalone types, this is more flexible than trying to unify these in a single generic ChainSpec type moving forward