I’d like to discuss the idea of incorporating patch versions and bugfixes for proposals into the on-chain governance process.
For example, with the current Hangzhou proposal, a critical issue was found during testing. Now bakers will most likely have to use Octez’s “User Activated Protocol Override” mechanism in order to implement the Hangzhou upgrade.
This method works, more or less, but in the spirit of on chain governance would it not be better to formally incorporate patch versions into the government process?
For example: during the exploration phase, protocol upgrade H is found to have a critical bug. During the cooldown phase, a new proposal is allowed to be injected that then progresses through it’s own round of voting and testing, and assuming the patch gets voted in, the original protocol upgrade is implemented simultaneously along with the agreed upon patch.
The “patch protocol governance process” could be a streamlined subset of the regular governance process, maybe just an exploration phase, cooldown/testing phase, and final vote phase. We could recursively repeat this “patch protocol governance process” ad infinitum if more issues are found during the testing of those patches.
This is one developers rough, back of the napkin idea, I’d love to hear the communities thoughts. I love the idea of putting as much of the governance process as we can on chain.
I’m getting some reactions, which I definitely appreciate, but no discussion. I would love it if some long time community members could comment. I’m happy to take constrict criticism too if this feature seems unneeded .
Why delay an upgrade if consensus on the changes has already been reached? Putting a patch through another vote is redundant and doesn’t change anything about the outcome.
First, TY for your response. I’m excited to hash out this idea.
To answer your question - because the method used to implement the patch after the vote concludes (the “User Activated Protocol Override” feature of Octez), isn’t great - it’s really more of a workaround that requires all bakers to take an action roughly simultaneously.
This specific feature of Octez, which we have relied on twice now for updates requiring immediate patching, ties the community to one specific implementation of the Tezos software, Octez. This doesn’t seem great for decentralization, as creating a new implementation of the Tezos software that does not have this “User Activated Protocol Override” feature, which we are starting to rely on, would introduce serious risk.
Maybe a rule, where if you implement/propose a new change to the original one, all nodes are informed to vote within the same voting period time frame. If they do not vote, however, their initial vote will be taken, and if they want to, they can decide to vote against it.
These changes can only be implemented by the creator.
So an “optimistic” algorithm that applies the way you voted (yay, nay, pass) for the first iteration of the non-patched proposal to any subsequent patches of that same proposal, unless you explicitly vote no. With a potential limitation that allows only the proposer of the original amendment to propose the patch.
I like the suggestion and I think it’s definitely worth discussing. I do wonder if limiting who can propose a patch is a benefit to security, maybe we can discuss further.
Your first iteration counts towards the second one, if you do not vote on the second one.
However, some thoughts:
There should be a minimum relief time for the second iteration, I would suggest 7 days.
The thought is, that no one can change a proposal last second, imagine it like a bidding system, the last bidder needs 7 days before the bid ends, if there is more than 7 days, no extension is needed, but if its less than 7 days, the extension period needs to readjust to 7 days.
Also, there needs to be some type of prompt on the system for node operators to know that a change on the proposal has been submitted.
I am also thinking, if extra security is needed, the proposal would have to be signed off by credible signatories too.
I definitely support the idea of preventing users from changing a proposal last second. I think a relief period could work - by basically adding 7 days of voting time as soon as a patch is proposed, and any subsequent patches that get proposed during the current “patch governance process” would be “stacked” on top of that initial patch while voting is occurring and then that relief period would reset back to 7 days.
This would allow the community to put multiple patches up for approval in rapid succession, without requiring each individual patch to go through a separate “patch governance process” iteration.
Couldn’t a bad actor exploit such a system and continue to propose “patches”? I think a fixed-time period with some kind of voting mechanism (and without quorum perhaps) could work.
That’s a great call out. I wonder if there is a great way to limit bad actors spamming patches while also making it easy for good actors to rapidly develop and inject patches.
I agree with you that a fixed time period would work, I think a good MVP would just be time based voting rounds of 7 days. In which patch authors may inject a new patch at any time, but must have a 2 day period between injecting each subsequent patch. The action of injecting a subsequent patch would trigger that 7 day voting window to re-up.
We would need a way to prevent a bad actor patch author from proposing new patches every 2 days infinitely. Maybe some sort of payment that gets refunded at the end of the “patch governance process”?
Honestly if we only allow the original proposer to upload the patch then this whole issue seems to be mostly mitigated.
I suppose a bad actor could propose an amendment and then keep it perpetually in a patch process. But the chances that a baker with 8000 Tez chooses to act maliciously ar probably low.
Yes, initially I suggested that only the original proposer could propose a patch.
But what if something tragic happens to him? or he’s on holiday? it prevents community devs from having a say.
Additionally, if we only let the initial proposer, recommend other signatories to submit patches, this can lead to a small closed circle.
The best way is through those elected by the community and mostly invested. i.e. node operators with a substantial amount of rolls.
With the liveliness vulnerability found and the recent override patch required for Nairobi, I would love to hear @NomadicLabs and some of the other development teams (@Marigold , @Benjamin_Fuentes) thoughts on incorporating the patch process into the on-chain governance process.
reactions, which I definitely appreciate, but no discussion. I would love it if some long time community members could comment. I’m happy to take constrict criticism too if this feature seems unneeded 
.
