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: support time-based forking #985

Merged
merged 17 commits into from
Jan 27, 2023
Merged

Conversation

leruaa
Copy link
Contributor

@leruaa leruaa commented Jan 23, 2023

Closes #937

@gakonst
Copy link
Member

gakonst commented Jan 23, 2023

Let's discuss this before merging

@leruaa
Copy link
Contributor Author

leruaa commented Jan 23, 2023

@gakonst yeah I made some impacting changes...

And yet I held back, I was this close to replace:

pub type BlockNumber = u64;

by

pub struct BlockNumber(u64);

@onbjerg onbjerg added C-enhancement New feature or request A-consensus Related to the consensus engine labels Jan 23, 2023
@onbjerg onbjerg changed the title Support time-based forking feat: support time-based forking Jan 23, 2023
@mattsse
Copy link
Collaborator

mattsse commented Jan 23, 2023

pub struct BlockNumber(u64);

what's the motivation for this? this would be super inconvenient imo.

edit: to distinguish between timestamp and blocknumber?

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.

moving this to ChainSpec, seems like the correct change to me.

@Rjected can review these changes best in detail

there are several unwraps and the Default inits that look a bit weird to atm.

crates/primitives/src/forkkind.rs Outdated Show resolved Hide resolved
@leruaa
Copy link
Contributor Author

leruaa commented Jan 23, 2023

edit: to distinguish between timestamp and blocknumber?

Exactly, to be able to impl From<BlockNumber> for ForkDiscriminant and From<Timestamp> for ForkDiscriminant

Copy link
Member

@onbjerg onbjerg left a comment

Choose a reason for hiding this comment

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

Seems ok overall, not sure what I would have done much differently. We need to figure out what we are going to do about the places where we hard depend on Paris having a set block number; this is not the case for all networks, so we should prefer TTD.

crates/consensus/src/consensus.rs Outdated Show resolved Hide resolved
crates/consensus/src/consensus.rs Outdated Show resolved Hide resolved
crates/consensus/src/verification.rs Outdated Show resolved Hide resolved
crates/consensus/src/verification.rs Outdated Show resolved Hide resolved
crates/executor/src/executor.rs Outdated Show resolved Hide resolved
crates/primitives/src/forkkind.rs Outdated Show resolved Hide resolved
crates/primitives/src/forkkind.rs Show resolved Hide resolved
crates/primitives/src/forkkind.rs Outdated Show resolved Hide resolved
crates/primitives/src/forkkind.rs Outdated Show resolved Hide resolved
crates/primitives/src/forkkind.rs Outdated Show resolved Hide resolved
Copy link
Member

@Rjected Rjected left a comment

Choose a reason for hiding this comment

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

good start! most notes are about MergeNetsplit - this has unfortunate naming because it's basically only used in sepolia, and ttd is still used in mainnet

crates/primitives/src/chain_spec.rs Outdated Show resolved Hide resolved
crates/primitives/src/chain_spec.rs Outdated Show resolved Hide resolved
crates/primitives/src/chain_spec.rs Outdated Show resolved Hide resolved
crates/primitives/src/chain_spec.rs Outdated Show resolved Hide resolved
crates/primitives/src/chain_spec.rs Outdated Show resolved Hide resolved
crates/primitives/src/chain_spec.rs Outdated Show resolved Hide resolved
crates/primitives/src/chain_spec.rs Outdated Show resolved Hide resolved
@leruaa
Copy link
Contributor Author

leruaa commented Jan 24, 2023

@Rjected I think I've taken all change requests into account, the PR can be reviewed again

Copy link
Member

@Rjected Rjected left a comment

Choose a reason for hiding this comment

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

just a few nits, otherwise lgtm!

crates/primitives/src/hardfork.rs Outdated Show resolved Hide resolved
crates/primitives/src/chain_spec.rs Outdated Show resolved Hide resolved
crates/primitives/src/forkkind.rs Outdated Show resolved Hide resolved
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.

lgtm

pending @Rjected

Copy link
Member

@Rjected Rjected left a comment

Choose a reason for hiding this comment

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

🚀 lgtm! thank you!

@Rjected Rjected merged commit 9cdead5 into paradigmxyz:main Jan 27, 2023
@leruaa leruaa deleted the time_based_forking branch January 27, 2023 15:50
@gakonst
Copy link
Member

gakonst commented Jan 30, 2023

I think this introduced a regression.

getting a lot of Failed to validate header error=HeaderValidation { hash: 0xb4fbadf8ea452b139718e2700dc1135cfc81145031c84b7ab27cd710394f7b38, error: TheMergeDifficultyIsNotZero }

This happens all the time. @onbjerg probably correctly identified that this is incorrect:

self.paris_ttd <= Some(discriminant.total_difficulty) ||
*block_number <= Some(discriminant.block_number)

because of how it's called here:

ForkDiscriminant::ttd(
chain_spec.terminal_total_difficulty().unwrap_or_default(),
Some(header.number),

Should we revert this PR? And investigate a proper solution, in preparation for Shanghai? cc @onbjerg @mattsse @Rjected

Also see this WIP spec ethereum/EIPs#6122

gakonst added a commit that referenced this pull request Jan 30, 2023
@onbjerg onbjerg mentioned this pull request Feb 1, 2023
4 tasks
literallymarvellous pushed a commit to literallymarvellous/reth that referenced this pull request Feb 5, 2023
literallymarvellous pushed a commit to literallymarvellous/reth that referenced this pull request Feb 5, 2023
literallymarvellous pushed a commit to literallymarvellous/reth that referenced this pull request Feb 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-consensus Related to the consensus engine C-enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support time-based forking
5 participants