1
1
# Upgrades
2
2
3
3
Hotshot protocol supports upgrades through an Upgrade proposal mechanism. The Upgrade proposal is broadcast separately
4
- from the ` QuorumProposal ` , typically several views in advance of its attachment . The goal is to ensure ample time for
4
+ from the ` QuorumProposal ` , typically several views before the upgrade is attempted . The goal is to ensure ample time for
5
5
nodes to receive and prepare for the upgrade process.
6
6
7
7
After enough votes have been collected on the ` UpgradeProposal ` , an ` UpgradeCertificate ` is formed. This is attached to
@@ -33,10 +33,10 @@ hash:
33
33
different proposals of the same version upgrade, ensuring nodes vote and execute the correct one. It consists of a
34
34
sequence of 32 bytes.
35
35
36
- These are defined in [ NodeType implementation] ( ../types/src/v0/mod.rs ) for the Types (` SeqTypes ` in our case).
36
+ These are defined in [ Versions implementation] ( ../types/src/v0/mod.rs ) for the Type (` SequencerVersions ` in our case).
37
37
38
38
``` rust
39
- impl NodeType for SeqTypes {
39
+ impl Versions for SequencerVersions {
40
40
type Base = StaticVersion <0 , 1 >;
41
41
type Upgrade = StaticVersion <0 , 2 >;
42
42
const UPGRADE_HASH : [u8 ; 32 ] = [
@@ -53,7 +53,7 @@ parameters use Unix timestamps for the same purpose.
53
53
54
54
To simplify configuration, these parameters are fetched from the genesis TOML file and set in the Hotshot config. The
55
55
TOML file can include either view-based parameters or time-based parameters, but not both. Furthermore, the start and
56
- stop voting parameters for both time-based and view-based upgrades are optional. Start parameter is set 0 so that voting
56
+ stop voting parameters for both time-based and view-based upgrades are optional. If omitted, start parameter will be set to 0 so that voting
57
57
begins as soon as node is started while the stop parameter is set to a maximum value so that the nodes keep voting until
58
58
enough votes are collected.
59
59
0 commit comments