Staging CHIPs on Testnet

Continuing a discussion from BCH Devs & Builders with @emergent_reasons, @cculianu, @fpelliccioni, and @Jonas:

Should we deploy Cash Improvement Proposals (CHIPs) to testnet before they are deployed on mainnet?

This would:

  • Ensure all proposals are thoroughly and publicly reviewed, integrated, and tested (including deployment procedures) in an environment where most large ecosystem actors are likely to encounter any eventual issues they will need to address in their own software. Testnet is nearly as adversarial as mainnet, so defects are more likely to be identified prior to mainnet deployment.
  • Enable user experimentation with new features – experimenting with new features can require significant time and resources. On testnet, developers can often use existing infrastructure to test their applications, reducing costs and enabling wider integration tests. New features can often even be tested by end users without significant technical expertise.
  • Strengthen testnet infrastructure – BCH itself is cheap to send, and these days, many developers simply test their contracts on mainnet. Testnet support has fallen behind: many block explorers no longer support BCH testnet, testnet faucets are commonly empty, and few wallets maintain testnet support. By giving developers a strong reason to use testnet, we ensure testnet infrastructure gets used and maintained.
  • Improve business certainty around upgrades – Testnet deployment would offer a strong Schelling point for any particular upgrade: if it’s not already live on testnet, it’s not going to suddenly happen on mainnet. Testnet forks are also relatively low-impact and less likely to be complicated by “fork markets” and other possible conflicts of interest. If meaningful technical disagreement exists, that disagreement will be very visible long before it can hurt end users, giving businesses plenty of planning time. (Coupled with sufficient prediction markets, this could practically eliminate upgrade-related business uncertainty.)
  • Stronger mainnet launches – With improved certainty of deployment and easier access to testing infrastructure, developers are more likely to commit resources to development which uses the new upgrade before it is deployed on mainnet. By the time an upgrade is deployed to mainnet, more downstream applications are likely to be production-ready, making network upgrades more exciting and valuable for users and businesses.

To do this, we would probably want each CHIP to specify two different activation times in its Deployment section, one for testnet (either November or May), and one for mainnet (typically May).

Some questions:

5 Likes

One reason I’ve been thinking about this: I believe the math and introspection CHIPs will almost certainly be ready to “lock-in” in this November and go live in May 2022. But some of the other CHIPs should probably wait, if only to set a careful precedent.

I agreed with @emergent_reasons here:

Ya, I’m also thinking it would be best for the May 2022 upgrade to only include the math and introspection CHIPs. It would be really great to set the precedent that BCH consensus moves carefully with >1 year of review.

The math and introspection CHIPs will solve the most urgent issues with the VM, unblocking a lot of really valuable use cases. The other consensus CHIPs I’ve proposed - targeted limits, bounded loops, and PMv3 - are very important, but can stand to have a longer time horizon.

Limits and loops would be immediately useful, but aren’t actually blocking any ready-to-deploy use cases, they would just make those use cases more efficient. And PMv3 could be immediately useful to improve the efficiency and UX of a few use cases, but big things like SLP 2.0, decentralized exchanges, and prediction markets will probably take another 6-12 months of development to have the first production-ready implementations.

One idea I’ve been thinking about: we can get almost the same value by coordinating deployment of limits, loops, and PMv3 to the primary testnet in May 2022 (the testnet used by most block explorers). That would give the other proposals a full year to be thoroughly tested while allowing developers to start working on real, complex applications using them in a reliable, almost-production environment.

Thoughts?

It would be a great precedent to set that future consensus changes are staged on the primary testnet for 6-12 months before mainnet deployment. And I think we’re at a sweet spot development-wise: the math and introspection CHIPs really reduce the current pain for BCH contract developers. If we got the other proposals on testnet in May 2022, there aren’t a lot of other big pain points which developers are going to be eager to “fast-track”, and we can afford to be much more patient with e.g. future crypto APIs, zero-knowledge proofs, MAST, multi-key input aggregation, etc.

We’ll have plenty of time to deliberate over the other CHIPs before May (when they would hit testnet), so the primary focus for now would be getting math and introspection on testnet in November.

3 Likes

Re: which testnet:

I’d like to propose that node implementations and businesses begin migrating to testnet4 in November as their “canonical” testnet.

This isn’t easy, but it would pay significant dividends. Testnet4 is tuned for low resource consumption and good block difficulty resilience, making it really excellent for developers to test functionality on new block explorers, applications, and wallets. It’s also very young, so the 50 tBCH rewards are very helpful to fill new faucets and developer tools. (Trivial, but we shouldn’t underestimate how much fun meaningful numbers are for new developers.)

Looking around, I count 4 working BCH testnet3 block explorers right now:

Notably, bitcoin.com no longer has a BCH testnet explorer because they migrated to blockchair, which doesn’t yet support any BCH testnets: https://blockchair.com/explorers?from=bitcoin.com

There are two wallets which support BCH testnet3 as far as I know:

  • BitPay
  • Electron Cash

And looking around, every BCH testnet3 faucet I can find is drained. (Which isn’t surprising when you note that at time of writing – testnet3 block 1,464,335 – the block reward is only 0.78125 tBCH.)

I think a coordinated switch to testnet4 would really revitalize BCH’s testnet infrastructure. With just a few working testnet4 block explorers and faucets, we’d be well ahead of testnet3’s existing infrastructure.

If most node implementations committed to making testnet4 their “default” testnet, and we can get a few of the above services to switch over, we’d have a very nice test ecosystem for developers to work on contracts using the new CHIPs before they ship on mainnet. :rocket:

3 Likes

If it were desired, it would be trivial to change testnet4 to always have a 50 BCH block reward preventing this issue from occurring again. This would not require coordination from any implementations. They may make the change at their leisure as long as it is done before the first halving date on testnet4 (otherwise a testnet fork might occur).

1 Like

Thinking about it, the underlying issue is that testnet is so far ahead of mainnet due to abuse of past difficulty adjustment algorithms. Testnet is ~14 years ahead of mainnet (the 7th halving from 0.78125 BCH to 0.390625 BCH at block 1,470,000 should happen in ~2036), so the inflation rate of mainnet is currently closer to testnet4 than to testnet3. :laughing:

In the long run, I think it would be ideal if testnet4 maintained the same inflation schedule as mainnet, but offset to be earlier in its history. Then the numbers used on testnet should generally be sensible when compared to real BCH, with slightly higher available circulation to make faucet funding easier. (Otherwise, if BCH is dominant by ~2034, testnet4 would have a supply of 31.5M tBCH and a daily inflation rate of >$300M in today’s tUSD. It would probably be filled with comically large transactions such that faked currency conversions in user interfaces would all look like real-estate sized transactions.)

So I think the underlying issue has already been solved by the new difficulty adjustment algorithm, we just need to reset our canonical testnet because testnet3 is hopelessly far ahead. Without any changes, testnet4 will probably maintain ~8x mainnet’s inflation rate. I think that will be just enough to encourage testnet miner/faucet “generosity”, but not enough to ruin test conversion rate UIs. :ok_hand:

2 Likes