Consider including v2 upgrade heights in binary for common networks #3995
Assignees
Labels
enhancement
New feature or request
WS: Maintenance 🔧
includes bugs, refactors, flakes, and tech debt etc
Comments
|
I am for this |
evan-forbes
added
the
WS: Maintenance 🔧
|
Note: this will be cumbersome to test b/c we'll need to block sync on Arabica, Mocha, or Mainnet through the v2 upgrade height. To make this issue easier, we should build a utility that makes it easier + faster to block sync. |
rootulp
changed the title
rootulp
added a commit
that referenced
this issue
Dec 9, 2024
Closes #3995 If a user specifies the `--v2-upgrade-height` flag then it takes precedence over any defaults. If the user doesn't specify a `--v2-upgrade-height` flag and the chainID is `arabica-11`, `mocha-4`, or `celestia` then the v2 upgrade height is set to the block height that was coordinated on those chains. See: https://docs.celestia.org/how-to-guides/network-upgrade-process#lemongrass-network-upgrade ## Testing 1. `./scripts/single-node.sh` doesn't set a v2 upgrade height 2. `./arabica.sh` if we remove the `--v2-upgrade-height` flag in the script, gets defaulted correctly 3. `./arabica.sh` if we override the `--v2-upgrade-height` flag in the script, that gets used
rootulp
added a commit
to rootulp/celestia-app
that referenced
this issue
Dec 9, 2024
Closes celestiaorg#3995 If a user specifies the `--v2-upgrade-height` flag then it takes precedence over any defaults. If the user doesn't specify a `--v2-upgrade-height` flag and the chainID is `arabica-11`, `mocha-4`, or `celestia` then the v2 upgrade height is set to the block height that was coordinated on those chains. See: https://docs.celestia.org/how-to-guides/network-upgrade-process#lemongrass-network-upgrade ## Testing 1. `./scripts/single-node.sh` doesn't set a v2 upgrade height 2. `./arabica.sh` if we remove the `--v2-upgrade-height` flag in the script, gets defaulted correctly 3. `./arabica.sh` if we override the `--v2-upgrade-height` flag in the script, that gets used
rootulp
added a commit
to rootulp/celestia-app
that referenced
this issue
Dec 9, 2024
Closes celestiaorg#3995 If a user specifies the `--v2-upgrade-height` flag then it takes precedence over any defaults. If the user doesn't specify a `--v2-upgrade-height` flag and the chainID is `arabica-11`, `mocha-4`, or `celestia` then the v2 upgrade height is set to the block height that was coordinated on those chains. See: https://docs.celestia.org/how-to-guides/network-upgrade-process#lemongrass-network-upgrade ## Testing 1. `./scripts/single-node.sh` doesn't set a v2 upgrade height 2. `./arabica.sh` if we remove the `--v2-upgrade-height` flag in the script, gets defaulted correctly 3. `./arabica.sh` if we override the `--v2-upgrade-height` flag in the script, that gets used
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Context
We used a
--v2-upgrade-heightflag on networksProblem
If a consensus node is block syncing from genesis, it needs to provide the
--v2-upgrade-heightProposal
Consider hard-coding the
--v2-upgrade-heights for arabica, mocha, mainnet beta so that node operators don't have to specify it.The text was updated successfully, but these errors were encountered: