migration: Make migration-block-time a required flag #242
Conversation
| migrationBlockTime = uint64(time.Now().Unix()) | ||
| // If the migration block time is not set, use the time of the last block incremented by one. | ||
| // This makes sure the migration is deterministic. | ||
| migrationBlockTime = header.Time + config.L2BlockTime |
There was a problem hiding this comment.
I don't think we want to do this, or at least not just one block time, because the sequencer will try to fill all the time between the migration block time and 'now' with blocks when it is started. So it's better to leave some space for the migration to happen, ideally we can pick the time to coincide with the completion of the migration.
There was a problem hiding this comment.
So to clarify, we would increment header.time by a number roughly equal (maybe slightly less) than the time it takes to the migration so that the node doesn't try to add too many blocks to fill the gap?
There was a problem hiding this comment.
Yeah so we don't end up spamming blocks just as the network starts, so I would either use the flag or hardcode this a few days before we do the next migration, after we've done a trial run and have an idea of how long it would take.
|
Lets put this on hold till we know roughly how long a mainnet migration will take. |
|
@piersy Another solution here would be to make the block time flag required and since only whoever is doing the first migration will need to run the script without passing a timestamp, we could add a way to explicitly override the requirement. E.g. maybe the flag is required but if |
@alecps I think just making it required is ok, the person who runs it first can just pick a timestamp by adding a few minutes to the current time. |
alecps
force-pushed
the
palango/migration
branch
from
6137080
to
34ba0ba
Compare
alecps
changed the title
-- migration-block-time a required flag
alecps
changed the title
-- migration-block-time a required flag--migration-block-time a required flag
alecps
changed the title
--migration-block-time a required flag
|
The failing test is known to be flaky, see #249. This should not keep us from merging this PR. |
Make migration-block-time a required flag --------- Co-authored-by: alecps <[email protected]> Co-authored-by: piersy <[email protected]>
Make migration-block-time a required flag --------- Co-authored-by: alecps <[email protected]> Co-authored-by: piersy <[email protected]>
Make migration-block-time a required flag --------- Co-authored-by: alecps <[email protected]> Co-authored-by: piersy <[email protected]>
Make migration-block-time a required flag --------- Co-authored-by: alecps <[email protected]> Co-authored-by: piersy <[email protected]>
Make migration-block-time a required flag --------- Co-authored-by: alecps <[email protected]> Co-authored-by: piersy <[email protected]>
Make migration-block-time a required flag --------- Co-authored-by: alecps <[email protected]> Co-authored-by: piersy <[email protected]>
Make migration-block-time a required flag --------- Co-authored-by: alecps <[email protected]> Co-authored-by: piersy <[email protected]>
Resolves https://github.com/celo-org/celo-blockchain-planning/issues/627
By making the flag required, we ensure node operators will always add one. So long as the correct number is passed as an argument (to be shared by the sequencer) the resulting block hash will match the sequencer's