Please login or register.

A formal approach towards better hard fork management

Seeing as how there are going to be things that will have to be introduced via a hard fork in future it stands to reason that we have to look at better ways of doing this than the current "fork and pray" approach. The scheme outlined below does not force miners / nodes to adopt a fork if we add something stupid in, but it creates a more fluid network that can robustly handle changes.

Basic bottom line: every 6 months there's a hard fork. You get 1 hard fork's grace before you have to update or be left behind.

Details

Every 6 months, either on March 15 + September 15 or on April 15 + October 15, the Monero network will have a hard fork. 30 days before the fork we will have a code freeze + tag + release, and if there are no major changes we'll have an increase in the protocol version (ie. that's at a minimum). A similar fork system to Bitcoin will apply, whereby a rollover to the new code after the trigger block will only occur if a sufficient number of miners are running the new code.

Anything that is more of a soft fork will kick in immediately (as long as it doesn't drop pre-fork clients off the network). Anything on the p2p layer (ie. hard forkable) will be kept in the wings until the next fork date (as roughly estimated from block height) and then is enabled.

The upshot of this is that you can run a client that is a year old, but pretty much after that 1 year anniversary you'll be dropped off the network (even if there have been no "real" changes in that year).

There is no goal or aim to continue to support clients running older versions of Monero, and just like you have to update your OS security software we have to create an environment where people are "forced" to update their full node.

Discuss

Thoughts? Suggestions? Changes? Let's discuss them before we make this indelible.

Replies: 46
binaryFate edited 8 years ago Replies: 2 | Weight: -428 | Link [ + ]

One can see how difficult it is to hard-fork in Bitcoin. People are legitimately afraid of it because it's handled in such a ad-hoc way everytime it must happen.

If Monero can have such an organized hard-fork-release schedule right from the beginning, all users and developers will feel at ease with these inevitable events in the future. So I completely support this idea!

Reply to: binaryFate
dEBRUYNE edited 8 years ago Weight: -430 | Link [ + ]

This perfectly describes my thoughts on this subject. So I support this as well!

Kazuki edited 8 years ago Weight: -430 | Link [ + ]

it puts Monero right on its track as scalable cryptocurrency, as long as emission and other key economic aspect that were already agreed upon by the community are maintained, from the record I can see most improvements will be made towards better privacy and more efficiency. So I support this idea as well.

Pandher edited 8 years ago Weight: -430 | Link [ + ]

Yes, dates with GMT times for clients dropping off network, very elegant approach fluffy. I support it

rpietila edited 8 years ago Weight: -430 | Link [ + ]

Without going into details why it is so, I believe that the benefits of the stated approach reasonably overweigh the alternative, which is to "fork and pray" as the OP put it.

Reply to: binaryFate
Kazuki edited 8 years ago Weight: -430 | Link [ + ]

"Nobody panics when things go "according to plan.""

Hueristic edited 8 years ago Replies: 1 | Weight: -430 | Link [ + ]

My only concern would be if this method opens a avenue for attack. GA makes a good point as well.

cAPSLOCK edited 8 years ago Replies: 1 | Weight: -429 | Link [ + ]

Overall I agree with the general sentiment that this is better than the other alternative listed here.

My initial reaction also included a small bit of recoil. My nature is conservative (to a fault at times) and I am inclined to "leave well enough alone". Sometimes budgets scare me since some people approach a budget like: "So.. we have M10,000, but only see M7,000 worth of stuff to spend it on... what else should we buy".

In this way I would hate to think this would foster an environment of change for change sake.

"Well the next fork is coming... what should we use it on?"

Another way of saying it is this: Bitcoin is struggling somewhat against it's own constraints. And many of us can see the negative in this. However, there is a sort of stability that comes with these constraints. We know fundamental change is less likely with the way Bitcoin is built and guided by it's core community.

OK. All that said... In the final analysis I see this is a generally positive idea. I just wanted to shoot out that one caveat.

Reply to: Hueristic
farfiman edited 8 years ago Replies: 1 | Weight: -430 | Link [ + ]

"Well the next fork is coming... what should we use it on?"

Other things to think of. If the hardfork dates are locked in - what happens if one is needed in an emergency (security,attack etc.) or knowing that a hardfork date is coming up there might be a rush to take a change and "stuff it in" before its's really ready so not to have to wait another 6 months. I'm not implying that the current team would ever do it but who knows what the future will bring.

Reply to: cAPSLOCK
fluffypony edited 8 years ago Weight: -430 | Link [ + ]

> In this way I would hate to think this would foster an environment of change for change sake.

I think that the majority of the forks will be "benign", just protocol version bumps, so this is instead just a way of creating an environment that is more robust. As I mentioned to @GingerAle, Bitcoin has had a major fork because of a database change, so keeping everyone current "by force" has the added bonus of not leaving us open to this sort of issue.

Reply to: farfiman Hueristic
fluffypony edited 8 years ago Weight: -430 | Link [ + ]

Emergency hardforks aren't precluded by this policy, they can still be deployed as normal.

Also remember that even though there's a "code freeze" at the 1 month pre-fork point, if it truly is "hard fork" code it'll actually only kick in a year later (to allow for the grace period). For instance, the MRL-0004 minimum mixin could be added in such a freeze, such that a month later it kicks in for your own transactions that you broadcast (and blocks, if you're a miner), but transactions and blocks that don't conform are still allowed for another 6 months until the subsequent hard fork, after which they are then banned even on a p2p level.

rocco edited 8 years ago Replies: 2 | Weight: -429 | Link [ + ]

i want to talk mostly about quality assurance and change management in this post. writing english takes me a lot of energy so i try to make it short:-) First of all, i have no experience in open source projects and its change/release management methods, but i know how big banks and payment processors develop financial software. Also i do not know anything about the deployment process and policy of monero testnet.

new branch means new risk. to be on the safe side and flexible enough with this kind of branching i would recommend you having at least one more testnet instance. also i do not know how far you can run the trunk/your own branch locally, so its difficult to give an advice without really knowing how you prefer to work.

as long as open bugs still can be fixed, one month freeze sounds fine, maybe a little long, but depends on the testing efficiency too.

you devs know best if 6 months is enough or if 3 would be better (and off after 6), there is no need to punish yourself with this. as long as emergency changes are excluded of course (should be possible to completely disable this feature and hardfork immediately) me personally would welcome 3 months, but i do not know if this is possible with still keeping quality high and risks low.

in general i would not make to many rules so in the end you have to make a lot of exceptions. as light as possible is best. my feeling is that 1 year is too long for now, but if we mature more it will be very useful for users to have this. (as we know allready, usability is key). even more non functional things like reliability and robustness of the network profit from it.

maybe you should also think about a method to estimate how much nodes/blocks allready use the new branch, so you can lower the praying even more once the real hard fork kicks in.

all in all, i like it. if i have more info i can give better advise regarding quality assurance

Reply to: rocco
rocco edited 8 years ago Replies: 1 | Weight: -429 | Link [ + ]

if i think about it a little bit, part of the testing could be "easily" automated. imagine automatic deployment on 3-4 virtual machines. then we put them a simple synthetic database inside and let them sync. this would make regression testing much more easy. later make a few trx from node to node and validate. this could all be done with shell skripts i think, but would still be a lot of work no question, maybe too much effort for the gain.

Reply to: rocco
fluffypony edited 8 years ago Replies: 1 | Weight: -429 | Link [ + ]

I agree with you that we can move to a 1 year cycle in future, and I also agree that 3 months is probably going to be more of a nuisance than a positive force. I think the most important thing is to get people used to "update-or-die". I'd rather have 100 nodes all over the world that are ALWAYS current than 1000 nodes where we can't make changes because we somehow have to keep them connected;)

The biggest issue with this is that, unlike commercial software, we don't know the people running the nodes. We might know some of the vocal ones, but honestly even with Bitcoin the loudest talkers don't represent the supermajority. So we have to make changes without knowing who our "clients" are or even if they'll upgrade. This means we have to reduce the set to those that will upgrade, and that is why we have this proposal.

PS. Your English is WAY better than my grasp of any-language-other-than-English!

Reply to: rocco rocco
fluffypony edited 8 years ago Replies: 1 | Weight: -429 | Link [ + ]

OH! I forgot about your comment about testnet.

The problem is that 99% of the nodes don't run testnet (at least not on the same machine). I've noticed that if I stop my testnet miners then testnet stalls entirely, so it's not a particularly strong component at the moment. That will get better in future, and it will be a good proving ground, but even there we still have to have a rolling hard fork schedule (maybe 3 months before for experimental changes?) otherwise everyone gets stuck with the old version.