In a dev meeting on Mar 3 there was a discussion about how to handle hard forks / network upgrades after v5.0.0, i.e. once the last of the four currently scheduled hard forks has occurred.
I’m making an attempt here to summarize some of the ideas discussed in the meeting. Please correct anything that is in need of it, and feel free to make other suggestions for improving this or make proposals of your own in tread and I will update.
The objective is to evaluate possible options and attempt to converge on a path forward well in advance of the deployment of v5.0.0 (Jan 15 2021), even if the agreement is to
A continuation of this discussion is on the agenda for the April 14 development meeting, those interested are encouraged to participate.
There are NO PLANNED CHANGES to Grin’s proof-of-work, and is something unrelated to this discussion.
|1||Do nothing||By “community agreement”.||Sticks to the plan, and true to what was said before launch. Limits the degree of centralization. “Immutable by default.”||The path to a hard fork in practice is undefined. If there’s a consensus-breaking critical vulnerability that needs fixing, it may not be possible to upgrade the majority of the network successfully. Without a scheduled HF, the fear is that there will not be any HF. Our stance towards soft-forks will significantly impact the ability to conduct upgrades without hard forks.|
|2||Yearly evaluation||1 scheduled HF, 1 year ahead, re-evaluated yearly.||Provides a controlled path for network upgrades, with the intention to be removed once network stabilizes.||Centralizes around those who control releases, i.e. core team at the moment. When is the network considered “stable enough” to remove hard forks? Will there ever be enough incentive to give up this control of the network?|
|3||x years more||x scheduled HFs, once a year.||Gets the contentious decision out of the way once and for all so that work can focus on development, rather than a debate each year.||Would be a clear statement that Grin is years away from being stable and will remain under heavy development on the consensus layer for the foreseeable future. What happens after x years, and why would the situation be different then?|
|4||Hard fork olympics||Every 4 years, counting from genesis (indefinitely)||Like the bitcoin halving, and Olympic Games|
|5||Hard fork phaseout||Every
||Inspired by the original PoW phaseout schedule, this would appeal more to those who’d like to see Grin become increasingly consensus-immutable than proposals 2 and 3. Note the large 2-year gap after the final pre-planned HF4.||Our stance towards soft-forks will significantly impact the ability to conduct upgrades between hard forks.|
April 07: Tweak wording in #1-considerations.
April 07: Adding #4 and #5
April 08: Adding soft-fork considerations to #1 & #5