To Transfer? - The Sequel
Cryptium Labs is voting “No” on Cosmos Hub governance proposal #3.
Synopsis
We fully support enabling transfers, but we think the 24/48-hour expedited second-proposal process does not provide sufficient time for review and introduces unacceptable risks. We suggest that the standard governance timeline be used for the second proposal of a software upgrade process. We have not vetoed proposal #3, and if it passes we will follow its guidance.
Proposal overview
Unfortunately, this proposal bundles together two distinct changes to the Cosmos Hub, so we must vote on them as a bundle. The first change is to endorse the v0.34.0 release milestone, launch a test-net, and enable transfers. We fully support this change and would have voted “Yes” on the proposal if only this change was included.
The second change is to introduce an “expedited process” for passing proposals. This process would allow a proposal to pass as soon as 48 hours after the start of the voting period if over 2/3 of bonded stake is voting in favor and has been for 24 hours. Insofar as we understand it, this proposal only proposes utilizing the expedited process for this particular upgrade — it is not clear if it would be used in the future, although a precedent could be set.
Insufficient review time
Our primary concern with this expedited process is that it will provide an insufficient amount of time for validators, delegators, and network stakeholders more broadly (e.g. node operators) to review the new software version. The v0.34.0 release of the Cosmos Hub — https://github.com/cosmos/cosmos-sdk/milestone/13 — includes many breaking changes beyond enabling transfers which should be reviewed in detail. Participating in Hub governance cannot be expected to be a full-time job — if a proposal is passed in 48 hours, only a small fraction of stakeholders will have time to review it (or enlist assistance in reviewing it).
Risks of expedited process
Our secondary concern is that the abbreviated and unpredictable timeline may increase the risk of a difficult-to-recover network halt or undesirable state reversions. No software mechanism exists to automatically stop validators after the 2/3 threshold is reached, so operators will have to manually query every so often and halt their nodes by hand. Should other validators change their votes and cause the quorum to dip below the 2/3 threshold (and the proposal to fail the expedited process), validators who halted their nodes may be slashed for downtime.
Furthermore, if many nodes continue onward (past the block at which the chain was intended to halt), transactions will continue to be executed by the network which may not be persisted if the export is (eventually) created from the originally specified height. Many of these concerns also apply to the standard proposal process, but are substantially mitigated by a longer voting period, known proposal tally time, and inability for proposals to change states once tallied.
So, what instead?
We suggest a two-proposal software upgrade process where the second proposal runs the standard two week voting period to completion to allow for sufficient review and operational coordination. Some of our concerns would also be assuaged by an expedited timeline of a week with the same higher threshold but a defined tally time. To facilitate quickly enabling transfers, we think the second proposal can be created in parallel with the voting period of the first as soon as an exact code hash has been chosen.
In conclusion
Note that we have not voted “NoWithVeto”. We think this proposal is substantially safer than the first (which proposed automatically endorsing the v0.34.0 software release without a second proposal), and we recognize the difficulty of engineering a safe upgrade process. We think designing and engineering that process is worth spending time, but we understand the desire of many network participants to quickly enable transfers. If this proposal is passed, we will follow its guidance — and continue to advocate in favor of caution and careful analysis in future governance decisions.
