Should we reset the testnet?

[diwakergupta]

Moving a discussion started elsewhere by @lgalabru. Quoting context from Ludo:

Back in December, when we did the setup for Testnet, we did optimize for quick feedback loops on PoX, without thinking about the consequences, mid and long term. We have a better understanding today, and we addressed some issues by tweaking the boot sequence, but we’re doing this at the cost of working on other things + creating frustration for community members. By actively supporting this stretch, I'm also afraid of ending up in a whac-a-mole situation where we fix mainnet but break testnet, and vice versa.

Pros of resetting the testnet:

• Bring it closer to mainnet in PoX parameters (e.g. half the cycle length of mainnet, vs the current 50 blocks)
• Starting with a clean chain could help side-step some of the sync issues that plague the testnet, and that we know we won't see on mainnet for a while
• Potentially evaluate BTC Signet instead of the regular BTC testnet

Cons of resetting the testnet:

• Could be disruptive for people who've built up tooling and workflows, existing data & contracts on the testnet. That said, testnet was basically unavailable for almost a week, so 🤷🏽

[314159265359879]

@diwakergupta thank you for starting this conversation and listing some of the important pro's and cons.

I know it is already quite a task to make sure we have an available and stable testnet and mainnet. I would still like to suggest making it potentially more complex but more predictable to work with.

Example A - working with two testnets:
What if whenever we reset testnet we leave the old one available until we reset testnet again. That gives dev some time to migrate or finish a project before migrating to the new testnet. In some cases it may also be beneficial if the testnet spec changes such as the pox cycle length or BTC testnet. So the most appropriate testnet can be selected for the test.

Testnet 0 (old testnet)
Testnet 1 (reset testnet, fresh with new agreed changes)

Next reset
Testnet 0 (offline)
Testnet 1 (old testnet)
Testnet 2 (reset testnet)

etc.

Example B - working with two testnets:
An other option working with two testnets could be having Testnet 1, specced as similar as possible to mainnet (same pox cycle length even?) and testnet 2 for more experimental network upgrades or other differences that are beneficial to certain testing scenarios. Testnet 2 could be upgraded weekly/montly and testnet 1 only receives fixes when they go to mainnet, mostly can be expected to remain the same.

[dantrevino]

I would like to understand the plan for developer access to the apis during these resets. I assume moving from A to B on the infrastructure side can happen behind stacks-node-api.testnet.stacks.co ... but

1. How will expected data changes be communicated?
2. How will developers access testnet A, if we reset and flip to B? Maybe I want old data for testing?

Hope this is clear.

[aulneau]

I would like to bring this back up in priority for discussion.

I for one think we 100% should reset the testnet, and we should adjust the options such that they both provide a better DX and more closely mirror mainnet in PoX configuration.

For me as a developer who needs to work on deploying and testing contracts, I will almost never opt to use testnet, but instead use regtest. testnet consistently has issues and is more often unreliable than it is reliable.

In addition to what has been laid out here: https://www.dropbox.com/scl/fi/bmuca7tmspjf1hv20298a/Testnet-strategy.paper?dl=0&rlkey=e3zoahkasv8fyimvw8c8217cy, I think it would be really helpful and useful for users if we offered a "production" regtest.
To me this is an ideal setup:

• "production" regtest -> actively developing a contract and anything that integrates with it (very stable, almost no resets)
• "production" testnet -> more in depth beta testing of contract/apps that should basically mirror mainnet as close as possible (very stable, almost no resets)
• "staging" testnet -> our use for rollouts of new features/testing etc (reset often, not "stable")

Pros of resetting the testnet

An additional pro would be that we'd be able to change the private keys of the faucet(s) and prevent them from being drained like they have been.

[jcnelson]

I think the consensus as of today's blockchain meeting is to do it on the next release. @lgalabru will send a PR that bumps the testnet genesis block height.