Structurize x/upgrade.Plan #10149
Replies: 2 comments 6 replies
-
What do you propose the |
Beta Was this translation helpful? Give feedback.
-
@robert-zaremba I think I generally get the gist of what you're trying to accomplish here now. Basically, you want to prevent invalid upgrade info that would cause a chain halt which makes sense. The limitations would be that we can't:
An alternative which leverages the existing plain text upgrade info field is simply to make all of the checks above as part of the CLI command but not the blockchain protocol. So when one is submitting a proposal, the CLI will validate the format, download all of the referenced links, check hashes, and even run the binary for the user's platform. There could even be a validate upgrade plan command that validates a proposed upgrade plan to inform users when voting. This seems to be more scalable and flexible and doesn't try to push things into the protocol that the state machine can't really check. This functionality for validating the upgrade info could live in either cosmovisor or the SDK although maybe it makes sense to start with cosmovisor and then we could create an example which would call the CLI to get the upgrade info and pipe it to cosmovisor to validate. I would also note that cosmovisor was never intended to be run by validators fully unsupervised. There should also be human monitoring and alerting. |
Beta Was this translation helpful? Give feedback.
-
I would like to discuss few issues I see with the existing x/upgrade flow in the recommended Cosmos SDK setup.
Let's define a recommended Cosmos SDK based chain setup:
Currently, all upgrade instructions are part of the
x/upgrade.Plan.Info
attribute. It's an plain text filed without any required structure. User should put there information on how to perform an upgrade.However, there are conventions for the cosmovisor. The
Plan.Info
is expected to be:Cosmovisor will fail the upgrade process if the
Plan.Info
contains other data, will not pass one of conventional checks, then the whole upgrade process will stop. If at least of 1/3 validators (by staking power) uses cosmovisor, then it will lead to a chain halt.On one hand we want an automation using tools like cosmovisor which requires structured data. On the other, we don't make any rules for the on-chain upgrade info data (we don't perform any validation). This generalization may lead to issues we are experiencing now with
x/params
and problems like the bad Osmosis x/params gov update.If we want to create a solid integrations, then we need a solid protocol. Solid protocol informs users what they should provide for making a good upgrade proposal and is able to validate it.
Let's discuss the pros and cons for creating more structured
x/upgrade.Plan
which will enable more solid integration and verification.Beta Was this translation helpful? Give feedback.
All reactions