Our upgrade process has been designed to allow for hotfixes before a consensus rule change is activated. For activation to happen, ≥67% of validator power must update to the new version (which contains the yet-to-be-activated rules), the DAO must approve a PIP, and then this approval must be executed through a pocket gov upgrade transaction submitted by the DAOowner account (currently a Pocket Network Foundation multi-sig).
Well, it’s a good thing we designed it that way, because we need a hotfix for 0.6.0.
This announcement outlines the details of the hotfix, as well as other quality-of-life improvements that will be included in 0.6.1, and what this means for the original 0.6.0 upgrade process as outlined in this post.
The Hotfix
There was a previously dormant bug, going as far back as RC-0.5.0, wherein the GetParams() function ignores the RelaysToTokensMultiplier. This was not a critical bug at the time because the function was only called for simple network queries.
However, we will also be calling this function when we upgrade from amino encoding to protobuf encoding during the consensus rule change, because the switch requires getting the parameters (retrieving the values of DAO parameters in amino encoding) so that we can then set the parameters (defining the values of DAO parameters in protobuf encoding).
If GetParams() ignores the RelaysToTokensMultiplier, this will result in the parameter’s new value, as defined in protobuf encoding in the new consensus rules, being set to 0. In other words, nodes would no longer be earning revenue for relays.
If we activate 0.6.0, block rewards would effectively halt. To proceed with the upgrade, we must therefore use 0.6.1 instead, which patches the bug that caused the block reward parameter to be set to 0.
Other Changelog Items
0.6.1 also ships with a few quality-of-life improvements:
- Added utility CLI command to convert evidence from amino to protobuf
- Updated RPC spec to include stdTx
- Return Dispatch for certain failed relay codes to save a hop on client side
- Fix simulate relay to use basic auth
- Updated User Guide to use RC-0.6.1
- Added unsafe delete command to the keybase
The New Upgrade Process
The upgrade process will proceed as normal, with 0.6.1 as the new version.
We had reached step 3 of the process as outlined in this post: the release was published, the testnet upgrade rehearsal was completed (rehearsal announcement here), and we had a community call to discuss the details of 0.6.0.
It was thanks to Step 2 that we discovered the need for this hotfix; rehearsing the upgrade on testnet resulted in the RelaysToTokenMultiplier parameter being set to 0, which revealed the GetParams() bug.
We’ll now proceed with the process from Step 4:
- 0.6.1 has been released and is available to upgrade now here.
- PIP-4 has been amended to specify 0.6.1 as the new version being upgraded to.
- All node runners, including those who already upgraded to 0.6.0, must upgrade to 0.6.1.
- If/when ≥67% of nodes have upgraded, reaching consensus for the new protocol version, PIP-4 will be amended again to include an upgrade height (the height at which the new consensus rules will be activated and non-updated nodes will be left behind). PIP-4 will then be put to a vote. This gives the DAO the chance to veto the consensus rule change before it is executed.
- Voting on PIP-4 will last 7 days and pass with a 50% majority. If the vote passes, the Foundation will activate the upgrade at the specified height using the
pocket gov upgradetransaction.
All node runners, including those who already upgraded to 0.6.0, must upgrade to 0.6.1
FAQ
For general upgrade FAQs, refer to the original 0.6.0 announcement post here. This FAQ focuses specifically on 0.6.1 and the hotfix.
Is consensus at risk?
No, this is why we do the upgrade process the way we do it. All nodes are currently operating according to the consensus rules defined in 0.5.X. Nodes who already upgraded to 0.6.0 have not been affected by the now-hotfixed bug, because the bug only affects the consensus rule change activation, which has not (and will not as a result of the 0.6.1 release) happen for 0.6.0.
What is the difference between 0.6.0 and 0.6.1? Are the details in the original announcement doc and community call still relevant?
Yes, the upgrade details outlined in the 0.6.0 announcement doc and discussed in the community call are still reflected in 0.6.1. It is still the same upgrade in essence, with the addition of this hotfix and a few quality-of-life improvements.