At the moment, we store the minimum required version of Pigeon as hard-coded const inside Paloma. This means to enforce a Pigeon update, we need to roll-out a new version of the protocol as well, which often creates unnecessary noise and maintenance overhead.
Instead, this information should live on the chain directly, and be addressable via governance vote.
Generalize the restriction to pigeon requirements, so we can add new restriction in the future, instead of only minimum version
Add pigeon requirements to valset keeper, as the valset module is the one requiring this information
Add scheduled pigeon requirements, so we can schedule rollouts to a specific block height
Add new gRPC query - q valset get-pigeon-requirements - to get current and scheduled requirements
Add new tx - tx gov submit-legacy-proposal valset propose-pigeon-requirements - to propose changes to pigeon requirements
The valset module checks for pending scheduled changes at each BeginBlock. When a change is applied, scheduled changes are cleared
Added this information to genesis
Testing completed
[x] test coverage exists or has been added/updated
[x] tested in a private testnet
Breaking changes
[x] I have checked my code for breaking changes
[x] If there are breaking changes, there is a supporting migration.
Related Github tickets
Background
At the moment, we store the minimum required version of Pigeon as hard-coded const inside Paloma. This means to enforce a Pigeon update, we need to roll-out a new version of the protocol as well, which often creates unnecessary noise and maintenance overhead.
Instead, this information should live on the chain directly, and be addressable via governance vote.
q valset get-pigeon-requirements- to get current and scheduled requirementstx gov submit-legacy-proposal valset propose-pigeon-requirements- to propose changes to pigeon requirementsBeginBlock. When a change is applied, scheduled changes are clearedTesting completed
Breaking changes