-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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(op): isthmus genesis header #14066
Conversation
opened right off fork branch as place holder, will fix merge conflicts later this week and mark ready for review |
46bc02b
to
ca5ddbb
Compare
needs review asap @mattsse |
@meyer9 could use a review to speed up review process! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is very hard to review, not obvious what this actually changes, can we limit this pr to the necessary changes
crates/optimism/chainspec/src/lib.rs
Outdated
// header is set in construction of `OpChainSpec` from `ChainSpec` | ||
self.inner.genesis_header.get().expect("header is set") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the From<ChainSpec>
impl ensures that this is safe here. the visibility of the inner type is restricted to private to ensure that the chainspec is constructed using the conversion from ChainSpec
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there was no more obvious place to set the l2 withdrawals field, the semantics of the original code weren't straight forward
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
semantics of the original code weren't
which ones?
all I'm saying is that's unclear to me where the actual change is
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this shouldn't require any changes to that static defs, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it does because the genesis hash needs to be computed after the genesis header has been computed with withdrawals root from the alloc of the genesis file, so in some way the static defs would have had to change, I did it this way
crates/optimism/chainspec/src/lib.rs
Outdated
// fill once lock with a value, if not yet init | ||
_ = inner.genesis_hash.get_or_init(|| header.hash_slow()); | ||
|
||
if inner.hardforks.is_fork_active_at_timestamp(OpHardfork::Isthmus, inner.genesis.timestamp) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make ChainSpec
store a SealedHeader
directly here?
reth/crates/chainspec/src/spec.rs
Lines 223 to 233 in 2ee7748
/// 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>, |
Then all of the static definitions would have direct access to the field, and we won't need to add any header construction logic like this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about this, but then it occurred to me how many bugs it may cause if the inner chainspec has a second wrong header. besides, that would require encapsulating the inner chainspec anyway in order for that approach to be in any way safe, so the construction of OpChainSpec
would change anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I finally understood what this actually does.
I'd like to go with the suggested sealedheader approach for this, because this will also have some additional benefits, for example we could then reuse the entire chainspec type for a different header.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you pls elaborate why you would want to put a different header in the genesis header field of the inner chain spec?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mainly code reuse #13995
but this would just be a nice side-effect of using sealedheader here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wdym @klkvr wrt the OnceLock
, do we want to remove them? issue link pls?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
even if you put the header alongside the inner ChainSpec
, instead of setting the genesis header field of inner ChainSpec
correctly, the extra header needs a OneLock
in order to be initiated in the genesis_header
method which takes imm ref to self, like is done in ChainSpec::genesis_header
. do we want that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@emhane wdym by "extra header"? the idea is that the only header ChainSpec stores is the concrete SealedHeader
in the inner chainspec which is initialized directly. That way there's no lazy header initialization happening at all
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, now I follow, opened this issue #14355
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could also be fixed as follow up of this pr? no need to block isthmus feature for handling that debt imo
…op-reth into emhane/genesis-header
re-opened in #14560 since op-reth fork is archived |
Pull request was closed
Closes #14040
This PR is part of l2tol1 withdrawals root which is confirmed for inclusion in isthmus, ref: ethereum-optimism#19 (successfully follows op-geth sequencer, ref https://github.com/ethereum-optimism/op-reth/actions/runs/13059635977/job/36440108405)