Network Upgrades / Hard forks on Grin v5.0.0 and beyond

lehnberg · April 8, 2020, 3:10pm

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 do nothing.

A continuation of this discussion is on the agenda for the April 14 development meeting, those interested are encouraged to participate.

PLEASE NOTE

There are NO PLANNED CHANGES to Grin’s proof-of-work, and is something unrelated to this discussion.

Alternatives discussed

#	Proposal	Hard forks	Motivation	Considerations
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 `2^i * YEAR_HEIGHT`, for `i = 2,3, ...`	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.

Changelog

April 07: Tweak wording in #1-considerations.
April 07: Adding #4 and #5
April 08: Adding soft-fork considerations to #1 & #5

david · April 7, 2020, 1:04am

I’d like to add one more option: Make Grin more softfork-ready. This isn’t foolproof, since it’s difficult to predict exactly what changes may be desired in the future. But there’s a few things we can do that will provide a decent bit of flexibility.

Grumpy · April 7, 2020, 3:04am

I’m all in for #1. That’s what we’ve been doing right? Y’all found a critical vulnerability before, and it didn’t fuck up the hard fork schedule, at least I don’t think so. Plus, we were due for a critical vulnerability, and we already found it, so we’re not due for another one of those in a long time, or maybe ever, hopefully never.

Also on a side note, when did successful hard forks become a flex? was that 2017? DAMN WE GOOD AT HARD FORKS.

tromp · April 7, 2020, 7:44am

We need to decide how to treat blocks with unknown header version,
and kernels with unknown features. Some soft-forking is possible by accepting either, but care must be taken that the latter is properly deserialized and that signatures are still verified as much as possible.

tromp · April 7, 2020, 7:52am

A critical vulnerability needs to be fixed one way or another, and if breaking consensus is the only way, then that clearly warrants a HF. In what way would it “not be possible to upgrade”?

lehnberg · April 7, 2020, 4:07pm

I’d like to add one more option: Make Grin more softfork-ready. This isn’t foolproof, since it’s difficult to predict exactly what changes may be desired in the future. But there’s a few things we can do that will provide a decent bit of flexibility.

Making Grin mode softfork-ready is something that can be researched and proposed in parallel to this discussion. I think it would be important to understand what changes we would like to see there, regardless of the options above. Would you agree?

lehnberg · April 7, 2020, 4:13pm

I’m all in for #1. That’s what we’ve been doing right? Y’all found a critical vulnerability before, and it didn’t fuck up the hard fork schedule, at least I don’t think so.

So if we go with option #1 as planned, and that vulnerability instead would had been discovered in 2021, there wouldn’t have been any scheduled soft forks to sneak the fix into. We would have needed to come up with a “community justification” for why a hard fork would be required, and hope there would be enough agreement for an upgrade. The RFC that proposed the fix was “enable faster sync”. Not sure that would have been a compelling enough of a use case for a hard fork on its own. And screaming “there’s a critical vulnerability!!” would have increased the likelihood of it being discovered and exploited before any fork.

Plus, we were due for a critical vulnerability, and we already found it, so we’re not due for another one of those in a long time, or maybe ever, hopefully never.

While I wish it worked this way, I’m not sure does.

lehnberg · April 7, 2020, 4:16pm

A critical vulnerability needs to be fixed one way or another, and if breaking consensus is the only way, then that clearly warrants a HF. In what way would it “not be possible to upgrade”?

See my reply to Grumpy above. I guess I was being imprecise - it would always be possible to upgrade, you release a binary and you run the upgraded software, and you have upgraded. The problem would be getting the rest of the network to upgrade with you.

Kurt · April 7, 2020, 4:58pm

Every 4 years counting down from launch (a part from the 4 first ones).

Like the Bitcoin halvings, and Olympic games

tromp · April 7, 2020, 7:39pm

I would like to throw out option 4, inspired by the original PoW phaseout schedule.

Plan increasingly rare successive future hardforks at heights 2^i * YEAR_HEIGHT, for i = 2,3, …

Not saying that I’m in favor of this, but this schedule should 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.

lehnberg · April 7, 2020, 8:16pm

Interesting!

@Kurt & @tromp - both your proposals, they would run indefinitely? or is there some cap at some point?

tromp · April 7, 2020, 8:24pm

That is an uncapped range to be sure…

lehnberg · April 7, 2020, 9:11pm

Added proposal #4 & #5

mably · April 7, 2020, 9:31pm

I think #1 shouldn’t be limited to emergency HF and should be opened to significant major improvements that would require a HF. Obviously it would require its own schedule planning.

david · April 7, 2020, 9:48pm

Would you agree?

Not entirely. Whether it’s a separate option or not, it should be part of this discussion since it would impact which option we choose. If we’re going to take the stance that softforks are hacks, and hardforks should be used when possible, then we’ll want to plan for more frequent hardforks. If instead we decide they’re a useful way to apply backward-compatible updates, we may choose to try avoiding hardforks at all costs.

mcm-mike · April 8, 2020, 8:59am

I would suggest an yearly review of the actual situation and if no emergency HF is needed (can be shorter time span ) , stick to the #4 .

We need some real world experience so 4 years should be enough time to see how GRIN is adapting to the needs of users.

lehnberg · April 8, 2020, 2:10pm

So our stance on soft forks may instruct our stance on scheduled hard forks. Thanks for clarifying, that now makes sense to me.

I’ve added a “soft fork” discussion point to Tuesday’s dev meeting to see if we can get some clarity / action points from that. Please join if you can!

In the meanwhile, how could the matter of soft-forks best be reflected in the table above? Should it be its own option? If so what would the contents of each cell be? Should it be a column? It’s own section? Something else?

david · April 8, 2020, 2:29pm

Maybe just add it as a consideration to #1 & #5?

lehnberg · April 8, 2020, 3:10pm

Cool - updated, let me know if it needs further clarification.

Anynomous · April 9, 2020, 5:01pm

I like #5, with possibly some added possibility for softforks. However, in the end I trust the core team to evaluate the needs for a hard fork. So if after 4 years it is deemed desirable to have still more yearly hardforks and good arguments are provided, sure, go ahead with #1. In the end I do think it is more important to be flexible and realistic than to set these rules in stone (stone tablets can always be broken ).