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

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

Like the Bitcoin halvings, and Olympic games

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

  1. 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.

2 Likes

Interesting!

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

That is an uncapped range to be sure…

1 Like

Added proposal #4 & #5

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.

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.

3 Likes

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.

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?

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

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

1 Like

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 :wink:).

Is it accurate to call this “increasingly immutable”? The space between HFs increases but its not really any less mutable. I’m not sure that a stable period of 8 years followed by a HF is really any more immutable than a HF every 12 months?

Edit: Not trying to pick holes in this - just trying to wrap my head around what “immutable” looks like, short of zero HFs.

By the time it exceeds a lifetime, most people will consider it immutable…

They might only be used to remove technical debt acquired in intervening upgrades and soft forks.

1 Like

My opinion, as of right now, is that hardforks should be seen as extreme measures, as they are in Bitcoin. I’m not a fan of having them standardized. Breaking consensus should be seen as a doomsday measure.
Nevertheless, as david mentioned, softforks and hardforks must be discussed together. It’s practically the same discussion.

If there’s any community member who has a really good grasp of Bitcoin’s history regarding this subject of forks, please do join the dev meeting or comment here. There’s much to know and learn, and many conclusions to draw.

Anyway, why does the stance towards softforks lean negative currently? Was there already a discussion about it?

1 Like

How did you arrive to that conclusion?

Why do you write about hard forks if you can make soft forks?
I am against hard forks
please consider my opinion

Our stance towards soft-forks will significantly impact the ability to conduct upgrades without hard forks.

I figured this meant “our (negative) stance towards softforks will impede on our ability to upgrade without hardforking”.
Guess I was wrong.

1 Like

Consider your opinion considered.

Definitely want to take all opinions into consideration - is there a specific reason(s) why you prefer one over the other?

I think this is obvious hard fork is unacceptable it should only be done in critical situations.
If you can’t make a soft fork, then you should make the hard fork the first and last time, which will make the soft fork smoother.

You must strictly prescribe the rules for the soft fork and never return to the hard fork again.