Disclaimer: Some people immediately get defensive, panicked or triggered by merely the suggestion of changing the CHIP process (or anything in BCH). To be totally clear:
-
These are just ideas, discussed hypothetically. Nobody is proposing to make any changes to the CHIP process (yet).
-
If a CHIP is eventually proposed, it will be thoroughly iterated and vetted and could only activate by following the existing tried-and-true CHIP process as normal.
-
The CHIP process is working very nicely at the moment. Nobody wants to disrupt that. But, circumstances can & will change. The CHIP process that works well today may not be suitable or ideal for future conditions. For example, as the community grows in size it’s likely the number of CHIPs being concurrently researched & proposed will increase (perhaps very substantially so) and this could materially strain the existing system (in a variety of ways). It’s also going to take longer for ideas to filter through a growing community, longer for them to be debated/iterated and longer to gain support. There is an inevitable and natural trend to osssification, and that as it may be, it’s still important for the BCH community to pre-empt and delay that inevitable fact as long as we possibly can.
-
The status quo is comfortable and great, but as always, a change with demonstrated sufficient benefit, support and low enough risk is worth making in the interests of incremental improvement.
-
It’s also possible we currently have a totally perfect system which needs no changes. But if we do, discussing and confirming that cannot hurt.
Ok that said, I’d like to have a thread to discuss the frequency and schedule for CHIP upgrades. This concept of a CHIP process review and increased frequency was actually raised by @mainnet_pat on the latest episode (195) of The BCH Podcast. I found this an intriguing concept, with lots of factors & potential. Obviously I’ve also suggested the idea of tweaking the CHIP schedule to only Saturdays, which a lot of people found immediately objectionable even just as a hypothetical idea - this isn’t the same idea but it kinda fits in the same category. Once again, I’m simply raising it for discussion.
Some thoughts:
-
The current annual schedule is partially a result of valuable experience & iteration (it was 6 months under BCH ABC, and that was a mixed bag), but also partially a result of simple inertia & habit. It works, but that doesn’t make it optimal. Slowing down was a great change in 2021 at the time of a fractured, contentious, low-trust community. But the situation is different now, with a proven & working process & lots of positive momentum, good faith discussion & successful collaboration.
-
1 MB is not a fixed & optimal amount of blocksize, the pre-Velma VM Limits were not fixed & optimal limits, 10 minutes is not a fixed & optimal blocktime - 1 year is not necessarily a fixed & optimal upgrade schedule.
-
A simple concept is changing the frequency, faster OR slower. 3 months, 6 months, 18 months (TM, haha), 2 years, 5 years. What are the pros/cons of those options? The extremes of a daily upgrade or a per-decade upgrade seem ridiculous, but there’s a large spectrum between to consider. In fact, it’s not even required to have a regular schedule at all. Of course, that would be a radical departure from how we currently operate I’m simply raising it as a thought experiment - if the CHIP process can be used to reach a decision on a given CHIP it could also be used to set an ad-hoc activation date PER CHIP. This would create a lot of chaos if you assume nothing else is adjusted, so it doesn’t seem intuitively appealing. But I mention it here to accurately describe the options. Perhaps in a system with hundreds of developers working on a large number of CHIPs it would actually be optimal to schedule a stage in the CHIP discussion where an activation date was picked individually & locked in CHIPs would “sleep” in the code for multiple years until their activation date (so a rolling system where some minimum cadence of upgrades by stakeholders would always ensure code was running well in advance). That’s just one idea, it’s possible somebody can think of another clever way to build a rolling pipeline. There are pros/cons to that idea - it could be very fluid and flexible, but of course it sacrifices consistency, defined opportunities to celebrate and so on.
-
Particularly in the case of faster upgrades, creating more lock-in slots does not mean they would all need to have CHIPs actually lock-in. If we had half-yearly upgrades, we could skip slots where no compelling upgrades were ready - we might even still end up doing an upgrade yearly - but the fact of having more slots available would change the social dynamic on its own (the option to delay by just 6 months for increased consensus may be more appealing in borderline cases where 1 year feels too slow but immediate lock in feels too fast).
-
There is strength in simplicity. So our existing system is good for that. But that isn’t the end of the discussion, perhaps a system could have an alternating cadence of major/minor upgrades (which is more complicated, raises questions about how you decide etc. but might allow more speed without overly disrupting stakeholders). Maybe people have other ideas of what kind of schedule we could have.
-
It’s also possible an increased schedule could be only for chipnet(s) or testnet(s) but they also activate on mainnet in one annual upgrade.
-
Obviously all CHIPs have a research element, social element, a technical implementation element and a rollout element. These overlap, and the scheduling would play into all of it. So that needs to be factored into our thinking.
Ok those are just some ideas and concepts for people to play around with, putting it here for people to discuss as they see fit.