Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(ethereum-forks): remove total difficulty for hardfork check #13362

Merged
merged 9 commits into from
Dec 20, 2024

Conversation

aroralanuk
Copy link
Contributor

@aroralanuk aroralanuk commented Dec 12, 2024

@aroralanuk
Copy link
Contributor Author

@mattsse, is this how you were thinking of removing total difficulty and relying solely on the block number (given Paris is always the merge fork)?

Comment on lines 10 to 21
/// The fork is activated after a total difficulty has been reached.
TTD {
/// The block number at which TTD is reached, if it is known.
///
/// This should **NOT** be set unless you want this block advertised as [EIP-2124][eip2124]
/// `FORK_NEXT`. This is currently only the case for Sepolia and Holesky.
///
/// [eip2124]: https://eips.ethereum.org/EIPS/eip-2124
fork_block: Option<BlockNumber>,
/// The total difficulty after which the fork is activated.
total_difficulty: U256,
},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, this has implications on the forkid.

I think the way we should go about this is keeping this variant but requiring that it knows the block number

@Rjected @joshieDo I can't remember what the implications of the fork_block field are because we set this.
I think we can't just set the fork_block field because this messes with the forkid, for example for mainnet we must set this to none,

so to enforce a block number for ttd we should add a new field

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, we need to keep one eip-2124 fork block at least. We would want another blocknum field, that is used for checking if the merge is active, but not for the forkid.

@mattsse mattsse added the C-enhancement New feature or request label Dec 13, 2024
@mattsse
Copy link
Collaborator

mattsse commented Dec 14, 2024

@aroralanuk so the way we should solve this is, we keep the TTD variant but add a new mandatory activation_block_number field, because we assume there won't be any more total difficulty hardforks and all activation numbers are known

@@ -607,6 +607,7 @@ impl From<Genesis> for ChainSpec {
hardforks.push((
EthereumHardfork::Paris.boxed(),
ForkCondition::TTD {
activation_block_number: genesis.config.merge_netsplit_block.expect("Merge netsplit block is required"),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mattsse @Rjected, do I need to update merge_netsplit_block to not be optional in the genesis file?

) -> Option<u128> {
if chain_spec.fork(EthereumHardfork::Paris).active_at_ttd(total_difficulty, block_difficulty) {
if chain_spec.fork(EthereumHardfork::Paris).active_at_ttd(block_number) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should I keep the active_at_ttd function as it is and add a new active_at_merge method instead?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's keep this for now to keept changes small

Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool, this looks good overall,

just need some additional time to take a closer look

if !self
.externals
.provider_factory
.chain_spec()
.fork(EthereumHardfork::Paris)
.active_at_ttd(parent_td, U256::ZERO)
.active_at_ttd(block.number)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this should use the parent block number

) -> Option<u128> {
if chain_spec.fork(EthereumHardfork::Paris).active_at_ttd(total_difficulty, block_difficulty) {
if chain_spec.fork(EthereumHardfork::Paris).active_at_ttd(block_number) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's keep this for now to keept changes small

@mattsse mattsse marked this pull request as ready for review December 16, 2024 16:42
@emilianobonassi
Copy link

not sure how much is related but would be great to remove ttd from the response in the block

looks like execution api ratified that and geth recently implemented (seen some slow rollout these days by rpc providers)

ethereum/go-ethereum#30386

@aroralanuk
Copy link
Contributor Author

thanks @Rjected

Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

amazing, this also unlocks a few nice followups

Comment on lines 12 to 13
/// The activation block number for the fork.
activation_block_number: BlockNumber,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we add a one liner that this is mandatory because we expect that all difficulty hardforks are finalized and total difficulty is deprecated?

Comment on lines 119 to 122
&Head {
number: header.number,
timestamp: header.timestamp,
difficulty: header.difficulty,
total_difficulty,
// NOTE: this does nothing within revm_spec
total_difficulty: U256::MIN,
hash: Default::default(),
},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can simplify this a lot in a followup because we only need number+timstamp now

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so much better lol

@@ -27,8 +26,6 @@ where
if let Some(base_block_reward) = calc::base_block_reward(
chain_spec,
block.header().number(),
block.header().difficulty(),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice

@@ -110,8 +110,8 @@ where
/// Configures a new evm configuration and block environment for the given block.
///
/// Caution: this does not initialize the tx environment.
fn evm_env_for_block(&self, header: &Header, total_difficulty: U256) -> EnvWithHandlerCfg {
let (cfg, block_env) = self.evm_config.cfg_and_block_env(header, total_difficulty);
fn evm_env_for_block(&self, header: &Header) -> EnvWithHandlerCfg {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so good

.header_td_by_number(header.number())?
.ok_or_else(|| ProviderError::HeaderNotFound(header.number().into()))?;
Ok(evm_config.cfg_and_block_env(header, total_difficulty))
Ok(evm_config.cfg_and_block_env(header))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can also get rid of this provider trait entirely now

@Rjected
Copy link
Member

Rjected commented Dec 20, 2024

note that we will have a bit of redundancy in:

  • EthereumHardfork::Paris.mainnet_activation_block(),
  • The new activation_block field as part of the TTD fork, and
  • The paris_block_and_final_difficulty field on ChainSpec

So we can probably simplify even more things w.r.t our hardfork traits / structs

@Rjected Rjected enabled auto-merge December 20, 2024 10:40
@Rjected Rjected disabled auto-merge December 20, 2024 14:27
Copy link

codspeed-hq bot commented Dec 20, 2024

CodSpeed Performance Report

Merging #13362 will degrade performances by 10.82%

Comparing aroralanuk:rm-ttd-execution (1574376) with main (4e9f8c2)

Summary

❌ 1 regressions
✅ 72 untouched benchmarks
🆕 4 new benchmarks
⁉️ 4 dropped benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

Benchmark main aroralanuk:rm-ttd-execution Change
🆕 range lookup` N/A 611.6 µs N/A
🆕 any lookup` N/A 20.1 ms N/A
🆕 `prefix set preload size: 1000 input size: 1000 Vec with binary search lookup`
🆕 `prefix set preload size: 1000 input size: 1000 Vec with custom cursor lookup`
⁉️ range lookup` 610.2 µs N/A N/A
⁉️ any lookup` 19.8 ms N/A N/A
⁉️ `prefix set preload size: 1000 input size: 998 Vec with binary search lookup`
⁉️ `prefix set preload size: 1000 input size: 998 Vec with custom cursor lookup`
`receipts root size: 10 HashBuilder` 106.5 µs

@Rjected Rjected added this pull request to the merge queue Dec 20, 2024
Merged via the queue into paradigmxyz:main with commit 82af170 Dec 20, 2024
42 of 43 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove extra Total difficulty argument for execution
4 participants