From 5b1ee227c2dc6e41176686ca54d361d0bcc59f91 Mon Sep 17 00:00:00 2001 From: Julien Robert Date: Wed, 5 Apr 2023 00:34:41 +0200 Subject: [PATCH] docs(gov): remove unimplemented section (#15697) --- x/gov/README.md | 28 ---------------------------- 1 file changed, 28 deletions(-) diff --git a/x/gov/README.md b/x/gov/README.md index 6d1a8fe2d8..3861c76a27 100644 --- a/x/gov/README.md +++ b/x/gov/README.md @@ -231,34 +231,6 @@ At present, validators are not punished for failing to vote. Later, we may add permissioned keys that could only sign txs from certain modules. For the MVP, the `Governance address` will be the main validator address generated at account creation. This address corresponds to a different PrivKey than the CometBFT PrivKey which is responsible for signing consensus messages. Validators thus do not have to sign governance transactions with the sensitive CometBFT PrivKey. -### Software Upgrade - -If proposals are of type `SoftwareUpgradeProposal`, then nodes need to upgrade -their software to the new version that was voted. This process is divided into -two steps: - -#### Signal - -After a `SoftwareUpgradeProposal` is accepted, validators are expected to -download and install the new version of the software while continuing to run -the previous version. Once a validator has downloaded and installed the -upgrade, it will start signaling to the network that it is ready to switch by -including the proposal's `proposalID` in its *precommits*. (*Note: Confirmation that we want it in the precommit?*) - -Note: There is only one signal slot per *precommit*. If several -`SoftwareUpgradeProposals` are accepted in a short timeframe, a pipeline will -form and they will be implemented one after the other in the order that they -were accepted. - -#### Switch - -Once a block contains more than 2/3rd *precommits* where a common -`SoftwareUpgradeProposal` is signaled, all the nodes (including validator -nodes, non-validating full nodes and light-nodes) are expected to switch to the -new version of the software. - -Validators and full nodes can use an automation tool, such as [Cosmovisor](https://docs.cosmos.network/main/tooling/cosmovisor), for automatically switching version of the chain. - #### Burnable Params There are three parameters that define if the deposit of a proposal should be burned or returned to the depositors.