ops: Use starting L1 Block for timestamp everywhere #3085
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
github-actions
bot
added
2-reviewers
A-pkg-contracts-bedrock
|
This PR changes implementation code, but doesn't include a changeset. Did you forget to add one? |
trianglesphere
force-pushed
the
jg/new_hh_tasks
branch
6 times, most recently
from
3185bdf
to
a50ca0b
Compare
|
Hey @trianglesphere! This PR has merge conflicts. Please fix them before continuing review. |
trianglesphere
force-pushed
the
jg/new_hh_tasks
branch
from
a50ca0b
to
c236a1b
Compare
mslipper
approved these changes
Jul 28, 2022
|
Hey @trianglesphere! This PR has merge conflicts. Please fix them before continuing review. |
This transitions the starting timestamp to a new flow. The L2 rollup is anchored on a L1 block. The L2 genesis block & rollup config use the timestamp of the L1 start block as the their time. Properly threading this through the HH tasks is a little tricky but possible. This is because we have two flows: creating a L1 network & placing the rollup on that and creating a rollup on an existing L1 network (like goerli). There is still a L1 starting time for the first flow. This also fixes a circular dependcy that previously existed. The starting timestamp was provided and served as the starting timestamp for the L1 genesis & the "L2 Starting Time" in the L2 Output Oracle. The actual L2 genesis & rollup start time were based on when the Optimism Portal contract was deployed (after the L2 Output Oracle contract must have been deployed). The rollup is resilient to being started before contracts are fully deployed, so using a specific L1 block as the start is the cleanest solution I have seen.
trianglesphere
force-pushed
the
jg/new_hh_tasks
branch
from
c236a1b
to
c1a5d14
Compare
|
There's a linting issue and I'd like an ACK from @tynes to change the bedrock hardhat deploy code, but LGTM otherwise. And it looks like I can use this in the Hive setup code. |
|
Fixed lint. Added |
tynes
reviewed
Jul 29, 2022
tynes
reviewed
Jul 29, 2022
tynes
approved these changes
Jul 29, 2022
trianglesphere
commented
Jul 29, 2022
tynes
reviewed
Jul 29, 2022
|
This PR has been added to the merge queue, and will be merged soon. |
|
This PR is next in line to be merged, and will be merged as soon as checks pass. |
Merged
maurelian
pushed a commit
that referenced
this pull request
Sep 15, 2022
* ops: Use starting L1 Block for timestamp everywhere This transitions the starting timestamp to a new flow. The L2 rollup is anchored on a L1 block. The L2 genesis block & rollup config use the timestamp of the L1 start block as the their time. Properly threading this through the HH tasks is a little tricky but possible. This is because we have two flows: creating a L1 network & placing the rollup on that and creating a rollup on an existing L1 network (like goerli). There is still a L1 starting time for the first flow. This also fixes a circular dependcy that previously existed. The starting timestamp was provided and served as the starting timestamp for the L1 genesis & the "L2 Starting Time" in the L2 Output Oracle. The actual L2 genesis & rollup start time were based on when the Optimism Portal contract was deployed (after the L2 Output Oracle contract must have been deployed). The rollup is resilient to being started before contracts are fully deployed, so using a specific L1 block as the start is the cleanest solution I have seen. * Fix lint * Update packages/contracts-bedrock/deploy-config/goerli.ts * Add undefined checks to l1StartingBlockTag * lint * fix checks Co-authored-by: Matthew Slipper <me@matthewslipper.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
sam-goldman
pushed a commit
that referenced
this pull request
Sep 15, 2022
* ops: Use starting L1 Block for timestamp everywhere This transitions the starting timestamp to a new flow. The L2 rollup is anchored on a L1 block. The L2 genesis block & rollup config use the timestamp of the L1 start block as the their time. Properly threading this through the HH tasks is a little tricky but possible. This is because we have two flows: creating a L1 network & placing the rollup on that and creating a rollup on an existing L1 network (like goerli). There is still a L1 starting time for the first flow. This also fixes a circular dependcy that previously existed. The starting timestamp was provided and served as the starting timestamp for the L1 genesis & the "L2 Starting Time" in the L2 Output Oracle. The actual L2 genesis & rollup start time were based on when the Optimism Portal contract was deployed (after the L2 Output Oracle contract must have been deployed). The rollup is resilient to being started before contracts are fully deployed, so using a specific L1 block as the start is the cleanest solution I have seen. * Fix lint * Update packages/contracts-bedrock/deploy-config/goerli.ts * Add undefined checks to l1StartingBlockTag * lint * fix checks Co-authored-by: Matthew Slipper <me@matthewslipper.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This transitions the starting timestamp to a new flow. The L2 rollup
is anchored on a L1 block. The L2 genesis block & rollup config use
the timestamp of the L1 start block as the their time. Properly
threading this through the HH tasks is a little tricky but possible.
This is because we have two flows: creating a L1 network & placing
the rollup on that and creating a rollup on an existing L1 network
(like goerli). There is still a L1 starting time for the first flow.
This also fixes a circular dependcy that previously existed. The
starting timestamp was provided and served as the starting timestamp
for the L1 genesis & the "L2 Starting Time" in the L2 Output Oracle.
The actual L2 genesis & rollup start time were based on when the
Optimism Portal contract was deployed (after the L2 Output Oracle
contract must have been deployed). The rollup is resilient to being
started before contracts are fully deployed, so using a specific
L1 block as the start is the cleanest solution I have seen.
Additional context
This is part of work to improve automation of devnet deployments.
I have confirmed that this works with the local devnet. It needs testing
with the goerli devnet.
Metadata