In developing and iterating on Crosslink in our prototype workshops, we’ve been starting to adopt some terminology around testnets in Zcash, and I wanted to share a few terms/axes to see if other Zcash devs, power users, beta testers, explorers, et al find them useful.
We all know & love Mainnet where real ZEC lives, faithfully storing transferrable unstoppable value. But when it comes to the term “testnet” there are many sources of confusion (is there “one testnet or many?” “Is it a network or a mode/flag of software?” etc…) So we advocate simply avoiding the term testnet, since we all know there is only one Mainnet, all other networks are for testing in one form or another.
Network Kinds
Mainnet
Covered above. Defining feature is real ppl use it with real value at stake.
Staging
What often is referred to as “the Zcash testnet” or “the Testnet” we’ve begun referring consistently to “the Staging network” within Shielded Labs.
This comes from our team’s shared experiences where a “staging deployment” is a deployment intended to be as identical to a “production deployment” as possible as the last live environment in which to test, benchmark, experiment, and connect integrations. Meanwhile a “production deployment” is where real customers and data live, aka Mainnet for Zcash.
A property exclusive to Mainnet and Staging is that they are ‘singletons’. Mainnet could split, and ideally we would be calling those two different child network/currencies, like “Zcash-Foo” and “Zcash-Bar”. Aside from that caveat, there is only one Mainnet, and changes to it require widespread consensus and coordination across the live ecosystem. Staging, OTOH, requires coordination from a smaller group of devs, which are a kind of (useful) gatekeeper.
By contrast, all of the following network kinds can have any number, and are permissionless to launch, and only require coordination among their participants:
Feature Nets
These are networks whose aim is to demonstrate, prove out, and develop specific features. These will typically have a much narrower scope of change than Zcash’s historical network upgrades. A prime example is the ZSA testnet. The Crosslink prototype networks, and our forthcoming “Crosslink Seasonal” networks are Feature Networks. These are typically fairly unambiguously named by the feature, such as “the ZSA testnet”, but sometimes, there may be multiple for the same feature (e.g. different versions, or different variants of the feature), so an unambiguous name can help everyone avoid confusion.
Upgrade Candidates
These are networks which have a scope similar to our historic Network Upgrades: they combine multiple features or changes which are ready around the same time, even though logically, those features may be distinct or separable. Because they can be deployed permissionlessly and combine features, they need unambiguous names, aka an opportunity for creativity. 
These haven’t existed historically, and so part of this post is to advocate for this new category:
Upgrade Candidate Motivations
Typically, after a set of features have been integrated for a network upgrade, they would be deployed to Staging, and this would all happen after an unambiguous mandate to deploy those features. With this mindset, the engineering and product work to flesh out what would become Staging for “the next” Network Upgrade can naturally become blocked on consensus building.
By contrast, an Upgrade Candidate could bundle and deploy a set of features for a potential upgrade before or without clear widespread consensus. We see this could provide several potential benefits:
- They can be deployed prior to consensus building, enabling engineers and product developers to flesh out many important details (especially the “little paper cuts” that are hard to anticipate) prior to consensus building. This enables them to approach consensus building with much greater clarity and precision in a proposal, at the trade-off of doing this effort prior to consensus building, when there’s less certainty about the ecosystem’s position. (This is quite akin to entrepreneurs taking a risk on launching a new product before knowing how the market responds.)
- If they are developed prior to consensus building, then the Zcashers can see, look at, explore/experiment with an actual working network before deciding how much to support bringing it to Mainnet. Historically Zcashers are often faced with intentions, plans, ambiguity, and differing expectations about what a thing is when we request that they weigh in. There’s nothing wrong, per se, about checking the pulse with Zcashers early in the process. This is just a way to also enable getting their assessment later in a product development process when there’s more clarity and specificity.
- Because these aren’t singletons, there’s no requirement that they are tied to a specific upgrade. For example, suppose there are two different Upgrade Candidate nets with different features, and they’re both compelling and widely supported, but not yet integrated. Awesome! Now we have more choices as a community: do we wait to integrate them, then deploy in an upgrade? Or maybe we should deploy one right away, then update the other one for the next upgrade (which can now happen quite rapidly, since it’s sitting in an almost ready state). Or maybe, the other order is faster. Etc…
- They enable de-risking engineering / product concerns prior to the Staging → Mainnet pipeline. Suppose we’re relatively late along in a plan to deploy a Network Candidate to mainnet when a new concern is raised, such as “if it ships like this, such and such may become a significant problem, but if we changed it to that, we could still ship the upgrade features without that problem”. Someone counters, “no, but that proposal introduces this other downside, so we shouldn’t do that.” While we still have the optino as we do know to carefully reason through these trade-offs “on paper”, Upgrade Candidate Networks give us a new tool: let’s just deploy the altnerative to a new network, then experiment with the live systems about the concerns and trade-offs.
- “Ship As Soon As Ready”: A style of deployment that appeals to me from the “move fast” culture is “ship as soon as ready” (SASAR) where we might have several Upgrade Candidates maturing and instead of deciding up front the sequencing of several upgrades, we use a the SASAR heuristic: which-ever passes the finish line first gets shipped as soon as it passes the finish line. Obviously, we can’t “move fast and break things” like the classic web2 trope, and we must hold safety as paramount. And also we still require widespread consensus to ship anything. Yet, with those caveats named, I still believe there could be great benefit for Zcash agility and velocity to respond to the market if we are able to more rapidly ship improvements without blocking as much on the Upgrade process.
Misc / Special Purpose Nets
We may have a variety of other networks that are more specialized or bespoke, such as benchmarking / high load networks, more controlled simulator networks, red team / chaos monkey networks, and so forth. I won’t really drill into these with a more fine grain, except to mention the four kinds above aren’t necessarily comprehensive. I just see them as the four major kinds in a feature / upgrade lifecycle
Wdyt?
Are these categories / terms useful for us?
Is the Upgrade Candidate concept useful?