Several of us have followed through and created a working group to discuss, and plan such a testnet. Below is our current plan/thinking and we welcome everyone to voice their thoughts (positive or negative) and/or join the working group if you want to contribute further. The below is not set in stone and we are open to ideas/changes.
Where are we now?
Rococo was previously unstable in the early days, however, the stability has improved in the last 6-12 months. This early instability has caused sentiment issues and some teams to create their own private testnets - which limits the ability for teams and dapps to test features like XCM with these chains.
Rococo takes a long time to sync for new developers spinning up the chain (approx 1 day)
Rococo is centralised (by Parity) and permissioned - you need a Parachain slot on Kusama or Polkadot to get access for more than 5 days.
Rococo typically receives runtime changes before Kusama, meaning the environment isn’t as stable as it could be and the environment could be out of sync with Polkadot.
Rococo is a PoA chain, not a PoS like “Polkadot” and so misses some features/functionality of “Polkadot”.
Where do we want to be?
Set up a more decentralised testnet, that receives changes closer to Polkadot. Specifically, after the fellowship proposes a runtime upgrade for Polkadot, the testnet will be updated - giving a period where the testnet will be ahead of Polkadot to allow for testing, but still in a very stable condition.
The testnet should be fast to sync, allowing for teams to get up and running asap.
A testnet that is also friendly for dapp teams building on parachains. Close to “Production” (Polkadot) means less chance of feature/code mismatch when developing products / dapps.
There will be two testnets in Polkadot: Westend & the new testnet, named, “Paseo”.
Set up the new testnet - with the aim of having it running by the 22nd of December with 1 parachain connected.
Allow teams that want to perform protocol testing or new feature testing to gain a slot on Westend. This will allow teams an environment to test things like Async backing, Beefy, etc. Westend will continue to receive updates before Kusama, so will always be the bleeding edge of Polkadot development.
In Q1 24’ - begin to decommission Rococo - more comms to follow.
One of the teams decentralising from Parity (Portico) is planning to support this testnet - they will perform all runtime maintenance and provide a basic level of support for the ecosystem - they have several years of experience running Rococo and are a perfect fit for this role.
How we envisage teams test their code once this testnet is live.
Below is our first pass at a list of who is involved, as mentioned above - this is a COMMUNITY testnet and anyone can help/contribute, please get in touch if you’re interested and where you see your contribution below - the list is not exclusive or exhaustive.
We would love community input and discussion - are we on the right track? Would these changes be helpful to you and your team? Please discuss below.
We are working through finalising the specifics of the network (sudo, multisig, governance, etc etc) which we will post early next week.
This thread will be maintained with updates as we progress.
I think this is a great initiative and we’ll definitely support it from data & infrastructure perspective. In addition to what was listed, I propose the following ideas that I think would make sense for the developer tooling:
Data ingest for Paseo and making all the blocks available for developers, through a similar interface shared here on Dotlake. This is to not reinvent the wheel and save on integration costs into block explorers.
Uptime / Availability & SLIs (service level indicators) monitoring for the testnet , this is essential to keep track of whether or not we’re doing a good job and for us to establish a way to communicate incidents, downtimes and more in a transparent manner.
More “meta” and not directly related to Developer tooling, I think the following are important to define too, especially to address the “where are we now?” painpoints:
Agreed and defined SLOs/SLAs (Service level objectives & agreements) for the testnet (99%, 99,9%, etc) and what guarantees we want to give the community. The stricter the requirements are, the higher the associated tradeoffs and lower the development speed could end up being. We need to establish who will be doing this monitoring and how issues are communicated, otherwise we will be left guessing.
Perhaps also agreed upon “time to get a slot” or “time to get something integrated”, to not leave teams who want to build guessing (which would be covered by SLAs but it’s good to treat them separately from the nodes & machines part)
These definitely don’t have to be over-engineered, but a first rough draft for target numbers we think are achievable would go a long way to give confidence and reliability.
Beyond that, perhaps also documentation updates for how to get started working with the new chain, who to contact etc. Again, this is just my 2 cents. Really looking forward to have the chain live and to replace Rococo in my own applications, thanks to everyone involved
Team OriginTrail is very supportive of this initiative as we have a strong need for a stable testnet for staging environments for all implementations. I think the overview @Birdo posted is really well crafted.
On this point though:
Starting with “why”, I’d like to point out where our initial comments when this discussion was initiated came from - the immediate need for us was to have pretty much a “clone” environment of production (mainnet), as close as possible, ideally “synced” with it in terms of updates. The idea above seems to have morphed into more of a “final testnet” for testing before new code reaches Polkadot. Is that really needed, given Kusama and the current release flow? Could this just be a staging clone of Polkadot, making it synced? @Birdo can you give a bit more clarity on the quoted, such as what has been discussed on the length of the period while this network will be ahead of Polkadot?
Once again we’d be happy to contribute to this effort and are definitely looking to be one of the first to launch on Paseo
It was proposed and discussed in the working group, but the idea was similar to:
When the fellowship proposes a RC, the testnet would upgrade to that version. The delay until it matches Polkadot would be the time it takes to enact the upgrade - assume 28d for OpenGov.
This is just a proposal and could be moved close to Polkadot. e.g. only be 7 days ahead, rather than 28 days ahead. Would love others feedback on this point
We at Polimec also would benefit from this new tesnet.
Also I have to agree with branarakic that if this chain is intended as a tool for us devs to test things before releasing the changes to mainnet, then it doesn’t really make sense for the testnet to not be a 1 to 1 clone of Polkadot.
A devnet for parachain devs should be separate from a devnet for relay chain devs.
One point I wanted to bring up with the wider community is the ability to have access to cross-chain logs. If you think this is useful, please comment! I’d like to know:
What kind of logs you need for parachain development?
Do you need logs from other chains (e.g. for testing XCM)?
Do you need logs from the relay chain validators?
How much value does this bring to the parachain development process?
This is a technical limitation because of some fixes we needed to apply to keep Rococo running. The same can happen to the new test net as well and is more of a technical limitation right now. However, this can be fixed and will be fixed at some point.
Our proposal would be to minimize the time of “syncronization” with Polkadot to ideally be measured in hours if possible, rather than weeks. Perhaps it’s not possible to be that quick, perhaps its more realistic to talk about a couple of days on average, but it would be great to align on the ambition here.
If each upgrade requires a month to for the networks to be 1:1 aligned, that could risk that the networks are actually not fully aligned for a significant amount of time (several months in one year, so order of magnitude larger than 10% amount of time, which is a lot).
On another note, at least in our case (OriginTrail) we haven’t seen this as a high priority issue. It’s useful to make syncing quick but looking at what our key pain points were, this was barely a topic for us (though I’ll let the team pitch in if they think otherwise)
I don’t run a parachain, but the way I see it, it looks like Westend should be the testnet for the relaychain and Paseo the one for parachains. In that sense, my two cents are that it should be a 1:1 clone of Polkadot. I imagine parachains just want to test things without economic value being put at stake, no need for trying out new things before they come on Polkadot. These two goals are clearly different.
This would really simplify my mental model of the testnets at least:
Paseo → Parachain testnet, pushed as the main one, clone of Polkadot but no economic value
Westend → Relaychain testnet, used for core developers to iterate on protocol things like async backing, etc, not relevant for parachain teams to build here in this unstable (which it should be!) environment
And then you have the mainnets:
Kusama → Gets things faster than Polkadot, kind of like a nightly
Polkadot → Offers more stability than Kusama
I feel like it would help new developers joining the ecosystem to push the Paseo/Polkadot journey. It would make it so much simpler to just think of 1 testnet and 1 mainnet.
Some people have asked what should be the requirements for running a validator in this new testnet.
We (Parity) are currently running all Rococo validators and from the current usage pattern we can recommend this configuration as a starting point:
This is similar to what we use today and is fully capable of sustaining the current Rococo. In the future, if this is needed, we could increase it to 1/2 or the full polkadot validator requirements (note that those requirements will also change in the future so this is not set in stone).
This gives us:
CPU
x86-64 compatible;
Intel Ice Lake, or newer (Xeon or Core series); AMD Zen3, or newer (EPYC or Ryzen);
1 physical cores
Storage
An NVMe SSD of at least 100 GB (the Rococo’s database currently uses 130gb disk but it has been running for 1.5 years).
Memory
8 GB DDR4 ECC.
If you want to run your validator in Kubernetes like us (we use GCP for Rococo), you can use n2d-standard-2/4/8 as machine type and set the following:
We shouldn’t forget that currently Westend (and Westmint) is used by external teams and institutions to test their integrations and APIs before launching their product (stable coin issuers, custody services, etc…). For these use cases, the testnet should be as stable as possible, so it would be good to have this into account when deciding the final requirements/aspects of the future testnets.
Paseo sounds like a very good fit for us at KILT.
We would love to have a testnet where we can test integrations with other chains via XCM but which also can be used by developers that integrate the KILT Protocol in their DApp.
We would try to have a high uptime of our Parachain on Paseo since external developers might depend on that network for their development. So we would see this more like a production chain from our side. But I think it’s natural that parachain projects might have slightly different goals for being on Paseo.
For us it might be beneficial to have upgrades 28d earlier on Paseo than on Polkadot. Developers can already test and develop agains the new version. The only fear I would have is that at some point a polkadot upgrade gets canceled and Paseo get’s out of sync with polkadot.
My question would be how parachains are onboarded and for how long?
Something we discussed in the working group last night.
The plan is currently slots of 1 year in duration - given that coretime is going to change this anyway.
When Coretime starts rolling out we will need to pivot and work out the best mechanism.
Hi all,
I wanted to provide an update on the progress of the group
The new testnet “Paseo” is live as of December 22nd!
A dedicated group of ecosystem agents from Portico, Amforc, Dwellir, Paradox, R0GUE, StakePlus, and Zondax played a key role in the testnet’s development.
Portico and R0GUE are made up of individuals from the Parity “Delivery Services” team who have had vast experience running Rococo over the last 2+ years.
Over January we have refined the treasury proposal (to be submitted this week) and spent time to start onboarding the first Parachains.
Rococo deprecation is planned once a few items are checked off including coretime launching on Polkadot, and the migration of key infra from Rococo, e.g. Snowbridge
I have spoken with many of the parachain teams that are looking forward to migrating across and we expect to see positive traction from the parachain teams in Jan & March.
