Pre-production vs. post-production relay chain?
@Ben: There are currently 3 main scenarios -there are others that are too internal, like Versi, but are not thought of from an ecosystem perspective- happening at the moment with regards to testnets:
- Rococo. As a PoA testnet it has been working a lot better since what it was two years ago, and now it runs quite well. Today is the most widely used testnet by parachains, and it’s being managed by Parity. Still, it has in it’s runtime special new features that will not make it to Polkadot in the following release, and that can potentially become an issue, like what happened with Async Backing last week - but yet again, that’s what testnets are for!
- Westend. The original NPoS testnet that Parity had, it currently has 16 validators (15 Parity and one Kagome). With this amount of nodes, it can’t serve a wide range of parachains connected to it.
- Parachain-ran internal testnets. These are used by parachains themselves for internal testing. Usually follow a stable runtime. This is very convenient for teams to get all the logs from the relay chain validators if anything happens, however it’s a difficult model to scale as an ecosystem testnet.
We agree with @branarakic before that we should pursue a stage-net. It would have Polkadot’s runtime with the add-on of the Sudo Pallet to keep things working smoothly.
Who is running the validators / or sets of the validators?
We think we are capable to mantain a good number of validators (~50) and then parachain teams that want to use this testnet long term, should provide 2 additional validator nodes. There are some open questions and more details around our idea before on how to do this, but the TL;DR is that the network needs a good base operation (that’s one of the things that chachacha didn’t have in the past), but also needs to scale. It will require tooling to be built too.
Who will be in control, or how will the sudo permissions get managed?
I think this would be a nice fit for a new System Collective
@OliverTY The collective is a fantastic idea, something that we would definitely get behind and help execute! It could also potentially be the Parachain Technical Fellowship. The interesting thing about this is that it would be deployed as a Substrate<>Substrate Bridge on AH on this stage-net, therefore not being a dependency for the Relay Chain’s runtime. Big question is how can we make it so that tokens don’t flow from one network to another.
For the beginning though, and in order to make the network stable and reliable, we suggest in our proposal to control the SUDO key as a multisig with a set of known people in the ecosystem that will have the best interest of it working.