From 18f0035d2fd4655cd9b5a1f3c5cc75c5da4788d3 Mon Sep 17 00:00:00 2001 From: Abdul Basit Date: Thu, 11 Jul 2024 15:59:54 +0500 Subject: [PATCH 1/9] markdown for upgrade docs --- data/genesis/demo.toml | 2 +- doc/upgrades.md | 62 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 63 insertions(+), 1 deletion(-) create mode 100644 doc/upgrades.md diff --git a/data/genesis/demo.toml b/data/genesis/demo.toml index 5c52dc3861..73e3498951 100644 --- a/data/genesis/demo.toml +++ b/data/genesis/demo.toml @@ -12,7 +12,7 @@ fee_contract = '0xa15bb66138824a1c7167f5e85b957d04dd34e468' timestamp = "1970-01-01T00:00:00Z" [[upgrade]] -version = "0.2" +version = "0.1" view = 5 propose_window = 10 diff --git a/doc/upgrades.md b/doc/upgrades.md new file mode 100644 index 0000000000..627d664cc9 --- /dev/null +++ b/doc/upgrades.md @@ -0,0 +1,62 @@ + +# Upgrades + +Hotshot protocol supports upgrades through an Upgrade proposal mechanism. The Upgrade proposal is broadcast separately from the `QuorumProposal`, typically several views in advance of its attachment. The goal is to ensure ample time for nodes to receive and prepare for the upgrade process. + +Voting for the `UpgradeProposal` begins before its proposal. Sufficient votes are gathered to form an upgrade certificate. Once obtained, the proposal is broadcasted, and any node that receives it accepts and attaches it to its own `QuorumProposal`. + +## Enabling an Upgrade + +To enable an upgrade in Hotshot protocol: + +When preparing for an upgrade, it's essential to define the base version, the upgrade version, and a unique upgrade hash: + +- **Base Version:** Represents the current version of the protocol (`0.1` in this example). +- **Upgrade Version:** Specifies the version to which the protocol will upgrade once the process is successful (`0.2` in this example). +- **Upgrade Hash:** Acts as a unique identifier for the specific upgrade nodes are voting on. It distinguishes between different proposals of the same version upgrade, ensuring nodes vote and execute the correct one. It consists of a sequence of 32 bytes. + +These are defined in [NodeType implementation](../types/src/v0/mod.rs) for the Types (`SeqTypes` in our case). +```rust +impl NodeType for SeqTypes { + type Base = StaticVersion<0, 1>; + type Upgrade = StaticVersion<0, 2>; + const UPGRADE_HASH: [u8; 32] = [ + 1, 0, 1, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, + ], + .. +} +``` + +These parameters are fetched from the genesis TOML file and set in Hotshot config: + +- **start_voting_view:** view at which voting for the upgrade proposal starts. In our implementation, this is set to 1 so that voting begins as soon as the node is bootup. +- **stop_voting_view:** view at which voting for the upgrade proposal stops. To disable an upgrade, set this parameter to 0 or ensure `stop_voting_view` is less than `start_voting_view`. +- **start_proposing_view:** view at which the node proposes an upgrade. This should be set to when an upgrade is intended. If the current view > `start_proposing_view`, the node proposes as soon as `UpgradeCertificate` is formed. +- **stop_proposing_view:** The view after which the upgrade proposal is no longer valid. If the upgrade proposal fails and the current view > stop_proposing_view then the upgrade is never proposed again. + +The window between `start_proposing_view` and `stop_proposing_view` should provide sufficient time for nodes to continue proposing the upgrade until successful. + +Ensure that the `ESPRESSO_SEQUENCER_GENESIS_FILE` environment variable is defined to point to the path of the genesis TOML file. For an example with upgrades enabled, refer to [`data/genesis/demo.toml`](../data/genesis/demo.toml). + +### Example TOML Configuration + +```toml +[[upgrade]] +version = "0.1" +view = 5 +propose_window = 10 + +[upgrade.chain_config] +chain_id = 999999999 +base_fee = '2 wei' +max_block_size = '1mb' +fee_recipient = '0x0000000000000000000000000000000000000000' +fee_contract = '0xa15bb66138824a1c7167f5e85b957d04dd34e468' +``` +In the TOML configuration example above, the `upgrade` section defines an array of tables, each specifying upgrade parameters such as version, view, and propose window. + +- **Version:** Indicates the current version targeted for the upgrade. +- **View:** Represents the `start_proposing_view` value, marking when the upgrade proposal initiates. +- **Propose Window:** Refers to the view window between `start_proposing_view` and `stop_proposing_view`. + +We currently support only chain config upgrades. The `upgrade.chain_config` table contains the complete set of chain config parameters, which can be used, for example, to enable protocol fees or modify other parameters during an upgrade. From 41c113fe854f9e50fa1cc8cc3eebac065540949e Mon Sep 17 00:00:00 2001 From: Abdul Basit Date: Thu, 11 Jul 2024 16:03:26 +0500 Subject: [PATCH 2/9] comments for upgrade struct --- sequencer/src/api.rs | 8 +++---- sequencer/src/genesis.rs | 4 ++-- sequencer/src/lib.rs | 2 +- types/src/v0/v0_1/instance_state.rs | 36 ++++++++++++++++++++++++++++- 4 files changed, 42 insertions(+), 8 deletions(-) diff --git a/sequencer/src/api.rs b/sequencer/src/api.rs index 9f1beb57d7..3674abf4fd 100644 --- a/sequencer/src/api.rs +++ b/sequencer/src/api.rs @@ -1447,12 +1447,12 @@ mod test { ..Default::default() }; let mut map = std::collections::BTreeMap::new(); - let view = 5; + let start_proposing_view = 5; let propose_window = 10; map.insert( Version { major: 0, minor: 2 }, Upgrade { - view, + start_proposing_view, propose_window, upgrade_type: UpgradeType::ChainConfig { chain_config: chain_config_upgrade, @@ -1463,8 +1463,8 @@ mod test { let stop_voting_view = 100; let upgrades = TestNetworkUpgrades { upgrades: map, - start_proposing_view: view, - stop_proposing_view: view + propose_window, + start_proposing_view, + stop_proposing_view: start_proposing_view + propose_window, start_voting_view: 1, stop_voting_view, }; diff --git a/sequencer/src/genesis.rs b/sequencer/src/genesis.rs index 03c278b163..8ad111a66a 100644 --- a/sequencer/src/genesis.rs +++ b/sequencer/src/genesis.rs @@ -67,7 +67,7 @@ mod upgrade_serialization { for (version, upgrade) in map { seq.serialize_element(&( version.to_string(), - upgrade.view, + upgrade.start_proposing_view, upgrade.propose_window, upgrade.upgrade_type.clone(), ))?; @@ -115,7 +115,7 @@ mod upgrade_serialization { map.insert( version, Upgrade { - view: fields.view, + start_proposing_view: fields.view, propose_window: fields.propose_window, upgrade_type: fields.upgrade_type, }, diff --git a/sequencer/src/lib.rs b/sequencer/src/lib.rs index eb0cfac639..81a18bf172 100644 --- a/sequencer/src/lib.rs +++ b/sequencer/src/lib.rs @@ -202,7 +202,7 @@ pub async fn init_node( let version = Ver::version(); if let Some(upgrade) = genesis.upgrades.get(&version) { - let view = upgrade.view; + let view = upgrade.start_proposing_view; config.config.start_proposing_view = view; config.config.stop_proposing_view = view + upgrade.propose_window; config.config.start_voting_view = 1; diff --git a/types/src/v0/v0_1/instance_state.rs b/types/src/v0/v0_1/instance_state.rs index feb2f50052..2b0a5a1569 100644 --- a/types/src/v0/v0_1/instance_state.rs +++ b/types/src/v0/v0_1/instance_state.rs @@ -10,6 +10,7 @@ use vbs::version::Version; use super::l1::L1Client; +/// Represents the specific type of upgrade. #[derive(Clone, Debug, Deserialize, Serialize)] #[serde(untagged)] #[serde(rename_all = "snake_case")] @@ -19,14 +20,33 @@ pub enum UpgradeType { ChainConfig { chain_config: ChainConfig }, } +/// Represents the upgrade config including the type of upgrade and upgrade parameters for hotshot config. #[derive(Clone, Debug, Deserialize, Serialize)] pub struct Upgrade { - pub view: u64, + /// The view at which the upgrade is proposed. + /// + /// Note: Voting for the proposal begins before the upgrade is formally proposed. + /// In our implementation, `start_proposing_view` is set to `1`` for all upgrades, + /// so if an upgrade is planned then the voting starts as soon as node is started. + #[serde(rename = "view")] + pub start_proposing_view: u64, + + /// The time window during which the upgrade can be proposed. + /// + /// This parameter is used for setting the `stop_propose_window_view`. + /// `stop_proposing_view` is calculated as `start_proposing_view + propose_window`. pub propose_window: u64, + + /// The specific type of upgrade configuration. + /// + /// Currently, we only support chain configuration upgrades (`upgrade.chain_config` in genesis toml file). #[serde(flatten)] pub upgrade_type: UpgradeType, } +/// Represents the immutable state of a node. +/// +/// For mutable state, use `ValidatedState`. #[derive(Debug, Clone)] pub struct NodeState { pub node_id: u64, @@ -36,6 +56,20 @@ pub struct NodeState { pub genesis_header: GenesisHeader, pub genesis_state: ValidatedState, pub l1_genesis: Option, + + /// Map containing all planned and executed upgrades. + /// + /// Currently, only one upgrade can be executed at a time. + /// For multiple upgrades, the node needs to be restarted after each upgrade. + /// + /// This field serves as a record for planned and past upgrades, + /// listed in the genesis TOML file. It will be very useful if multiple upgrades + /// are supported in the future. pub upgrades: BTreeMap, + /// Current version of the sequencer. + /// + /// This version is checked to determine if an upgrade is planned, + /// and which version variant for versioned types (e.g., build V2 header is version is 0,2) to use + /// in functions such as genesis. pub current_version: Version, } From d98d2a4b098e07d4319ed871e63e456f752bdc22 Mon Sep 17 00:00:00 2001 From: Abdul Basit Date: Thu, 11 Jul 2024 16:11:07 +0500 Subject: [PATCH 3/9] typos --- doc/upgrades.md | 8 ++++---- types/src/v0/v0_1/instance_state.rs | 5 +++-- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/doc/upgrades.md b/doc/upgrades.md index 627d664cc9..3c35a9b233 100644 --- a/doc/upgrades.md +++ b/doc/upgrades.md @@ -9,7 +9,7 @@ Voting for the `UpgradeProposal` begins before its proposal. Sufficient votes ar To enable an upgrade in Hotshot protocol: -When preparing for an upgrade, it's essential to define the base version, the upgrade version, and a unique upgrade hash: +When preparing for an upgrade, it is essential to define the base version, the upgrade version, and a upgrade hash: - **Base Version:** Represents the current version of the protocol (`0.1` in this example). - **Upgrade Version:** Specifies the version to which the protocol will upgrade once the process is successful (`0.2` in this example). @@ -29,7 +29,7 @@ impl NodeType for SeqTypes { These parameters are fetched from the genesis TOML file and set in Hotshot config: -- **start_voting_view:** view at which voting for the upgrade proposal starts. In our implementation, this is set to 1 so that voting begins as soon as the node is bootup. +- **start_voting_view:** view at which voting for the upgrade proposal starts. In our implementation, this is set to 1 so that voting begins as soon as the node is started. - **stop_voting_view:** view at which voting for the upgrade proposal stops. To disable an upgrade, set this parameter to 0 or ensure `stop_voting_view` is less than `start_voting_view`. - **start_proposing_view:** view at which the node proposes an upgrade. This should be set to when an upgrade is intended. If the current view > `start_proposing_view`, the node proposes as soon as `UpgradeCertificate` is formed. - **stop_proposing_view:** The view after which the upgrade proposal is no longer valid. If the upgrade proposal fails and the current view > stop_proposing_view then the upgrade is never proposed again. @@ -55,8 +55,8 @@ fee_contract = '0xa15bb66138824a1c7167f5e85b957d04dd34e468' ``` In the TOML configuration example above, the `upgrade` section defines an array of tables, each specifying upgrade parameters such as version, view, and propose window. -- **Version:** Indicates the current version targeted for the upgrade. -- **View:** Represents the `start_proposing_view` value, marking when the upgrade proposal initiates. +- **Version:** the current version targeted for the upgrade. +- **View:** Represents the `start_proposing_view` value at which the upgrade is proposed. - **Propose Window:** Refers to the view window between `start_proposing_view` and `stop_proposing_view`. We currently support only chain config upgrades. The `upgrade.chain_config` table contains the complete set of chain config parameters, which can be used, for example, to enable protocol fees or modify other parameters during an upgrade. diff --git a/types/src/v0/v0_1/instance_state.rs b/types/src/v0/v0_1/instance_state.rs index 2b0a5a1569..82f75ba4a7 100644 --- a/types/src/v0/v0_1/instance_state.rs +++ b/types/src/v0/v0_1/instance_state.rs @@ -69,7 +69,8 @@ pub struct NodeState { /// Current version of the sequencer. /// /// This version is checked to determine if an upgrade is planned, - /// and which version variant for versioned types (e.g., build V2 header is version is 0,2) to use - /// in functions such as genesis. + /// and which version variant for versioned types + /// to use in functions such as genesis. + /// (example: genesis returns V2 Header if version is 0.2) pub current_version: Version, } From 170160531021aa92f2041ed0f620f5b91f862e7d Mon Sep 17 00:00:00 2001 From: Abdul Basit Date: Thu, 11 Jul 2024 16:52:39 +0500 Subject: [PATCH 4/9] fee upgrade docs --- doc/upgrades.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/doc/upgrades.md b/doc/upgrades.md index 3c35a9b233..96bf9230ac 100644 --- a/doc/upgrades.md +++ b/doc/upgrades.md @@ -38,6 +38,7 @@ The window between `start_proposing_view` and `stop_proposing_view` should provi Ensure that the `ESPRESSO_SEQUENCER_GENESIS_FILE` environment variable is defined to point to the path of the genesis TOML file. For an example with upgrades enabled, refer to [`data/genesis/demo.toml`](../data/genesis/demo.toml). +Note: We currently support only chain config upgrade. ### Example TOML Configuration ```toml @@ -53,10 +54,19 @@ max_block_size = '1mb' fee_recipient = '0x0000000000000000000000000000000000000000' fee_contract = '0xa15bb66138824a1c7167f5e85b957d04dd34e468' ``` -In the TOML configuration example above, the `upgrade` section defines an array of tables, each specifying upgrade parameters such as version, view, and propose window. +In the TOML configuration example above, the `upgrade` section defines an array of tables, each specifying upgrade parameters: - **Version:** the current version targeted for the upgrade. - **View:** Represents the `start_proposing_view` value at which the upgrade is proposed. - **Propose Window:** Refers to the view window between `start_proposing_view` and `stop_proposing_view`. -We currently support only chain config upgrades. The `upgrade.chain_config` table contains the complete set of chain config parameters, which can be used, for example, to enable protocol fees or modify other parameters during an upgrade. +The `upgrade.chain_config` table contains the complete set of chain config parameters, which can be used, for example, to enable protocol fees or modify other parameters. + + +## Fee upgrade + +A successful Hotshot upgrade results in a new version, which allows us to update the chain config and execute the upgrade if there exists any. Chainconfig includes the fee parameters. The sequencer node has two states: NodeState and ValidatedState. NodeState is an immutable state that contains ResolvableChainConfig, whereas ValidatedState is a mutable state. To make updates to the chain config post-upgrade possible, ResolvableChainConfig is also added to ValidatedState. + +NodeState also includes two additional fields: upgrades and current_version. Functions like Header::new() and ValidatedState::apply_header() include a version parameter, which is used to apply upgrades by comparing this version with current_version in NodeState and fetching the upgrade if available from the upgrades BTreeMap in NodeState. + +In scenarios where nodes join the network or restart, missing the upgrade window may result in their validated_state having only a chain config commitment. In such cases, nodes need to catch up from their peers to get the updated full chain config. \ No newline at end of file From 4d4a8d901696bda5983a3ab62395172dae47a107 Mon Sep 17 00:00:00 2001 From: Abdul Basit Date: Thu, 11 Jul 2024 16:57:58 +0500 Subject: [PATCH 5/9] highlight types --- doc/upgrades.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/upgrades.md b/doc/upgrades.md index 96bf9230ac..75e281d20f 100644 --- a/doc/upgrades.md +++ b/doc/upgrades.md @@ -65,8 +65,8 @@ The `upgrade.chain_config` table contains the complete set of chain config param ## Fee upgrade -A successful Hotshot upgrade results in a new version, which allows us to update the chain config and execute the upgrade if there exists any. Chainconfig includes the fee parameters. The sequencer node has two states: NodeState and ValidatedState. NodeState is an immutable state that contains ResolvableChainConfig, whereas ValidatedState is a mutable state. To make updates to the chain config post-upgrade possible, ResolvableChainConfig is also added to ValidatedState. +A successful Hotshot upgrade results in a new version, which allows us to update the `ChainConfig` and execute the upgrade if there exists any. `Chainconfig` includes the fee parameters. The sequencer node has two states: `NodeState` and `ValidatedState`. `NodeState` is an immutable state that contains `ResolvableChainConfig` (Enum of `ChainConfig`'s commitment and full `ChainConfig`), whereas `ValidatedState` is a mutable state. To make updates to the chain config post-upgrade possible, `ResolvableChainConfig` is also added to `ValidatedState`. -NodeState also includes two additional fields: upgrades and current_version. Functions like Header::new() and ValidatedState::apply_header() include a version parameter, which is used to apply upgrades by comparing this version with current_version in NodeState and fetching the upgrade if available from the upgrades BTreeMap in NodeState. +`NodeState` also includes two additional fields: `upgrades` and `current_version`. Functions like `Header::new()` and `ValidatedState::apply_header()` include a version parameter, which is used to apply upgrades by comparing this version with `current_version` in NodeState and fetching the upgrade if available from the upgrades BTreeMap in NodeState. In scenarios where nodes join the network or restart, missing the upgrade window may result in their validated_state having only a chain config commitment. In such cases, nodes need to catch up from their peers to get the updated full chain config. \ No newline at end of file From 649710ec621892fb3d3aca6f672af10064f7519e Mon Sep 17 00:00:00 2001 From: Abdul Basit Date: Thu, 11 Jul 2024 18:51:54 +0500 Subject: [PATCH 6/9] edit enabling upgrade section --- doc/upgrades.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/doc/upgrades.md b/doc/upgrades.md index 75e281d20f..103844bb2a 100644 --- a/doc/upgrades.md +++ b/doc/upgrades.md @@ -7,9 +7,7 @@ Voting for the `UpgradeProposal` begins before its proposal. Sufficient votes ar ## Enabling an Upgrade -To enable an upgrade in Hotshot protocol: - -When preparing for an upgrade, it is essential to define the base version, the upgrade version, and a upgrade hash: +To enable an upgrade in Hotshot protocol, it is essential to define the base version, the upgrade version, and a upgrade hash: - **Base Version:** Represents the current version of the protocol (`0.1` in this example). - **Upgrade Version:** Specifies the version to which the protocol will upgrade once the process is successful (`0.2` in this example). From f187c4f6bf0aecad89d2cec6700177bda871accd Mon Sep 17 00:00:00 2001 From: Abdul Basit Date: Thu, 11 Jul 2024 19:28:23 +0500 Subject: [PATCH 7/9] suggestions --- doc/upgrades.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/doc/upgrades.md b/doc/upgrades.md index 103844bb2a..b1ee48ca0e 100644 --- a/doc/upgrades.md +++ b/doc/upgrades.md @@ -3,7 +3,7 @@ Hotshot protocol supports upgrades through an Upgrade proposal mechanism. The Upgrade proposal is broadcast separately from the `QuorumProposal`, typically several views in advance of its attachment. The goal is to ensure ample time for nodes to receive and prepare for the upgrade process. -Voting for the `UpgradeProposal` begins before its proposal. Sufficient votes are gathered to form an upgrade certificate. Once obtained, the proposal is broadcasted, and any node that receives it accepts and attaches it to its own `QuorumProposal`. +After enough votes have been collected on the `UpgradeProposal`, an `UpgradeCertificate` is formed. This is attached to the next `QuorumProposal`, and any node that receives an `UpgradeCertificate` in this way re-attaches it to its own `QuorumProposal` until the network has upgraded, or (in rare cases) we failed to reach consensus on the `UpgradeCertificate`. ## Enabling an Upgrade @@ -27,10 +27,10 @@ impl NodeType for SeqTypes { These parameters are fetched from the genesis TOML file and set in Hotshot config: -- **start_voting_view:** view at which voting for the upgrade proposal starts. In our implementation, this is set to 1 so that voting begins as soon as the node is started. +- **start_voting_view:** view at which voting for the upgrade proposal starts. In our implementation, this is set to 1 so that voting is enabled as soon as the node is started. - **stop_voting_view:** view at which voting for the upgrade proposal stops. To disable an upgrade, set this parameter to 0 or ensure `stop_voting_view` is less than `start_voting_view`. -- **start_proposing_view:** view at which the node proposes an upgrade. This should be set to when an upgrade is intended. If the current view > `start_proposing_view`, the node proposes as soon as `UpgradeCertificate` is formed. -- **stop_proposing_view:** The view after which the upgrade proposal is no longer valid. If the upgrade proposal fails and the current view > stop_proposing_view then the upgrade is never proposed again. +- **start_proposing_view:** the earliest view in which the node can propose an upgrade. This should be set to when an upgrade is intended. If the current view > `start_proposing_view`, the node will send out an `UpgradeProposal`. +- **stop_proposing_view:** view after which the node stops proposing an upgrade. If the upgrade proposal fails and the current view > stop_proposing_view then the upgrade is never proposed again. The window between `start_proposing_view` and `stop_proposing_view` should provide sufficient time for nodes to continue proposing the upgrade until successful. @@ -65,6 +65,8 @@ The `upgrade.chain_config` table contains the complete set of chain config param A successful Hotshot upgrade results in a new version, which allows us to update the `ChainConfig` and execute the upgrade if there exists any. `Chainconfig` includes the fee parameters. The sequencer node has two states: `NodeState` and `ValidatedState`. `NodeState` is an immutable state that contains `ResolvableChainConfig` (Enum of `ChainConfig`'s commitment and full `ChainConfig`), whereas `ValidatedState` is a mutable state. To make updates to the chain config post-upgrade possible, `ResolvableChainConfig` is also added to `ValidatedState`. -`NodeState` also includes two additional fields: `upgrades` and `current_version`. Functions like `Header::new()` and `ValidatedState::apply_header()` include a version parameter, which is used to apply upgrades by comparing this version with `current_version` in NodeState and fetching the upgrade if available from the upgrades BTreeMap in NodeState. +`NodeState` also includes two additional fields: `upgrades` and `current_version`. Functions like `Header::new()` and `ValidatedState::apply_header()` include a version parameter, which is used to apply upgrades by checking if this version is greater than `current_version` in NodeState and fetching the upgrade, if available, from the upgrades BTreeMap in NodeState. -In scenarios where nodes join the network or restart, missing the upgrade window may result in their validated_state having only a chain config commitment. In such cases, nodes need to catch up from their peers to get the updated full chain config. \ No newline at end of file +In scenarios where nodes join the network or restart, missing the upgrade window may result in their ValidatedState having only a chain config commitment. In such cases, nodes need to catch up from their peers to get the full chain config for this chain config commitment. + +Note: For the fee upgrade to work, the builder must have sufficient funds to cover the fees. The Espresso bridge can be used to fund the builder. \ No newline at end of file From 866038c6aa5264e9ae549d860f875eb67901f891 Mon Sep 17 00:00:00 2001 From: Abdul Basit Date: Thu, 11 Jul 2024 19:54:47 +0500 Subject: [PATCH 8/9] check upgrade version for enabling an upgrade instead of curr version --- data/genesis/demo.toml | 2 +- sequencer/src/lib.rs | 6 ++++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/data/genesis/demo.toml b/data/genesis/demo.toml index 73e3498951..5c52dc3861 100644 --- a/data/genesis/demo.toml +++ b/data/genesis/demo.toml @@ -12,7 +12,7 @@ fee_contract = '0xa15bb66138824a1c7167f5e85b957d04dd34e468' timestamp = "1970-01-01T00:00:00Z" [[upgrade]] -version = "0.1" +version = "0.2" view = 5 propose_window = 10 diff --git a/sequencer/src/lib.rs b/sequencer/src/lib.rs index 81a18bf172..e9206cdd76 100644 --- a/sequencer/src/lib.rs +++ b/sequencer/src/lib.rs @@ -200,8 +200,10 @@ pub async fn init_node( } }; - let version = Ver::version(); - if let Some(upgrade) = genesis.upgrades.get(&version) { + if let Some(upgrade) = genesis + .upgrades + .get(&::Upgrade::VERSION) + { let view = upgrade.start_proposing_view; config.config.start_proposing_view = view; config.config.stop_proposing_view = view + upgrade.propose_window; From a527857b1f2a1a804057f21d8f0a4aefc045eb81 Mon Sep 17 00:00:00 2001 From: Abdul Basit Date: Thu, 11 Jul 2024 19:56:43 +0500 Subject: [PATCH 9/9] update docs for upgrade::version --- doc/upgrades.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/upgrades.md b/doc/upgrades.md index b1ee48ca0e..c01bef0d4f 100644 --- a/doc/upgrades.md +++ b/doc/upgrades.md @@ -41,7 +41,7 @@ Note: We currently support only chain config upgrade. ```toml [[upgrade]] -version = "0.1" +version = "0.2" view = 5 propose_window = 10 @@ -54,7 +54,7 @@ fee_contract = '0xa15bb66138824a1c7167f5e85b957d04dd34e468' ``` In the TOML configuration example above, the `upgrade` section defines an array of tables, each specifying upgrade parameters: -- **Version:** the current version targeted for the upgrade. +- **Version:** the new version after an upgrade is successful. - **View:** Represents the `start_proposing_view` value at which the upgrade is proposed. - **Propose Window:** Refers to the view window between `start_proposing_view` and `stop_proposing_view`.