-
Notifications
You must be signed in to change notification settings - Fork 77
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(proto, conductor, cd)!: changes for Forma migration #1843
base: main
Are you sure you want to change the base?
Conversation
Opening this for review despite failing status checks so that review isn't blocking on Geth changes. Once a Geth image can be pulled, we'll be able to run the smoke tests. |
@@ -14,9 +14,15 @@ message GenesisInfo { | |||
// The rollup_id is the unique identifier for the rollup chain. | |||
astria.primitive.v1.RollupId rollup_id = 1; | |||
// The first block height of sequencer chain to use for rollup transactions. | |||
uint32 sequencer_genesis_block_height = 2; | |||
uint32 sequencer_start_block_height = 2; |
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.
Does this warrant a breaking change?
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 don't believe this would be a breaking change (even though the proto breaking changes lint would disagree), since the field is identified by the number itself as opposed to the name. The name change is just to more accurately reflect the new functionality, since conductor can now start from anywhere, not just genesis. I do think the proto changes at large are effectively breaking though, since the old shape will no longer work with with conductor (chain IDs will be empty strings, so the components will never pass initialization).
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.
You are right that the name is indeed a better reflection of how this field is used.
However, I would in general be more conservative when changing APIs: a breaking change (in this case, in the JSON serialization) weighs heavier than a name that's no longer a completely honest representation of the functionality.
Note on the PR: the document #1843 is private. Please put all relevant information into this PR without referring to an outside, private document. |
sequencer_genesis_block_height: tendermint::block::Height, | ||
sequencer_start_block_height: tendermint::block::Height, | ||
/// The Sequencer block height to stop at. | ||
sequencer_stop_block_height: tendermint::block::Height, |
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 case stop_block_height < start_block_height
is not covered in the tests. Should they be?
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.
Hmm, I think it would still just restart in this case? Josh introduced some logic such that if it receives a stop height of 0, it acts as if there is no stop block height. But in the case where stop block height is not 0 and is less than start block height, the conductor will go to execute and then just restart again, so the functionality should already be tested, but I can add a specific test for this scenario just to be sure if you'd like. In either case, if the stop height is ever below the start, I think something is wrong on the rollup end
@@ -61,14 +69,34 @@ impl GenesisInfo { | |||
} | |||
|
|||
#[must_use] | |||
pub fn sequencer_genesis_block_height(&self) -> tendermint::block::Height { | |||
self.sequencer_genesis_block_height | |||
pub fn sequencer_start_block_height(&self) -> tendermint::block::Height { |
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.
If you are breaking the astria-core anyway, let's make tendermint::block::Height
an implementation detail and have this method return u32
instead.
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.
Height
supports Into<u64>
but not u32
, so I used that instead in 2f7ed73. Can convert again to u32
if preferred.
} | ||
|
||
#[must_use] | ||
pub fn sequencer_stop_block_height(&self) -> tendermint::block::Height { |
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.
Same here, let's have this return a u32
instead
@@ -396,6 +412,35 @@ impl Executor { | |||
// TODO(https://github.com/astriaorg/astria/issues/624): add retry logic before failing hard. |
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.
Comment for above: the error cases are not actual errors but part of normal execution. As such, I would change the return type of execute_soft
to encode if a restart should happen due to the max being reached.
@@ -457,19 +505,36 @@ impl Executor { | |||
err, | |||
))] | |||
async fn execute_firm(&mut self, block: ReconstructedBlock) -> eyre::Result<()> { |
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 same arguments as for execute_soft
also apply to execute_firm
. Please see my comments there,
Summary
Makes the changes necessary in the monorepo to migrate Forma to Mainnet.
Background
Migrating Forma to mainnet necessitates introducing stop and start logic into the Conductor. This makes the proto and Conductor changes necessary for that. In addition to this, this will allow for future needs to stop and start EVMs on our networks. These changes will also need to be reflected in the
GenesisInfo
sent by rollups to the conductor.The shutdown and restart logic for the Conductor should be as follows:
GenesisInfo
with new start/stop heights (and potentially chain IDs).The aforementioned rollup changes to be made in
astria-geth
necessitate changing our current charts config for the following. "Forks" now describes a set of instructions for when and how to stop and restart the EVM at different heights, such that changes (such as network migration) can be made.Changes
sequencer_genesis_block_height
tosequencer_start_block_height
inGenesisInfo
(in the execution API).sequencer_stop_block_height
,rollup_start_block_height
,sequencer_chain_id
, andcelestia_chain_id
toGenesisInfo
.rollup_start_block_height
inGenesisInfo
, so that Conductor doesn't start from rollup height 1 again after restarting.astriaForks
to EVM rollup config, to reflect changes inastria-geth
: https://github.com/astriaorg/astria-geth/pull/59/files.Testing
check_for_restart_ok
unit test.Changelogs
Changelogs updated
Breaking Changelist
sequencer_stop_block_height
being read from wire format as 0). Thus, rollups will need to provide an updatedGenesisInfo
to conductor (includingastria-geth
).GenesisInfo
Related Issues
closes #1841