The purpose of this blog is to clarify our plans for Moonbeam as it relates to the Rococo TestNet and to explain what role we see Rococo playing for us now and in the future.
For some context, Rococo is a Relay Chain TestNet run by Parity (the developers behind Polkadot and Kusama) to serve as an experimentation and testing ground for projects that plan to launch parachains. This is different than previous TestNets because it allows for parachains to interact with the Relay Chain, rather than running isolated Substrate standalone TestNets.
For Moonbeam and Moonriver, Rococo is an important but small component of our overall launch strategy, largely because we have been running our TestNet as a full Polkadot environment with a Relay Chain, parachains, collators, etc called Moonbase Alpha. By running our TestNet as a parachain from the start, we are in a much better position to launch Moonriver and Moonbeam. I’ll explain why.
Creating Launch Readiness via the Moonbase Alpha TestNet
Let’s start with some context. We have been running our Moonbase Alpha TestNet since September 2020, which we believe makes it one of the longest-running parachain-based TestNets in the Polkadot ecosystem. Moonbase Alpha is a full Polkadot environment which includes a Relay Chain, Validators, Parachains, Collators, RPC endpoints, etc. We have had 6 major updates since we launched our TestNet, and currently are working on our seventh (v8) release. We have learned a huge amount in the last eight months through working with a running Polkadot-based system and maintaining our developer-facing functionality throughout that time. Much of the knowledge gained has been around how Polkadot, the Relay Chain, Cumulus consensus, and Substrate all work. We believe that hands-on experience with a running system gives us a deeper knowledge and understanding of it.
But it hasn’t been smooth sailing throughout the past eight months. There have been large amounts of change in the underlying Substrate, Cumulus, and Polkadot codebases since September which has made maintaining a working Polkadot parachain environment very challenging, especially finding versions of the underlying dependencies and our code that would work well together. We also have experienced two complete stalls of the network and many bugs and issues. These challenges have all proven to be extremely valuable learning experiences in understanding how the system works, what can go wrong, how to troubleshoot when things go wrong, where critical danger areas are, and in gaining operational experience running Moonbeam infrastructure, which we will need to teach others to do as we approach our network launches.
The most important point for us is this: by running as a parachain from the start we are in a much better position to launch Moonriver and Moonbeam. It’s only by working with a live parachain environment for the last eight months that we feel ready for production networks.
Rococo as a Testing Checkpoint
So what about Rococo and why aren’t we on it?
As of our last v7 update we are fully compatible with the current Rococo. To illustrate this, we have deployed Moonrock, a parachain based on the current Moonbase Alpha codebase to Rococo. See screenshot below for our registered parachain with all functionality working as expected:
Moonrock is not just a dummy parachain registered for test purposes. It is a fully-functioning Moonbeam implementation including all of our Ethereum compatibility features. To demonstrate this, we deployed Uniswap v2 to Moonrock. You can see the functioning application in the demonstration video below.
What’s Next as We Prepare for Moonriver
Despite this demonstration on Rococo, we plan to continue to focus our efforts on our Moonbase Alpha TestNet in the near term, particularly leading up to our Moonriver launch. When parachain functionality is added to Westend, we may shift focus to a deployment there.
Key reasons for our focus on Moonbase Alpha are:
- Rococo currently has a very short one-day parachain lease time, after which they expire.
- The chain state is reset on a frequent basis. This does not provide a stable environment for our partners to develop and test against. With Moonbase Alpha, we are able to provide a more stable environment for integrations and deployments. Since there are already more than 40 projects building on Moonbase Alpha, it is important to provide them with a stable development environment so they are able to work on writing/porting smart contracts without frequent interruptions.
- No ability to change Rococo Relay Chain configurations, and any Relay Chain actions have to be approved by Parity. On Moonbase Alpha, where we control the entire test network environment, we are able to make these changes ourselves. This allows us to iterate and make changes faster when we need to. As an example, when we do deployments to Moonbase Alpha, we are using a blue / green deployment methodology where we use automation to build an entire new environment including Relay Chain, validators, parachain, collators, RPC nodes, genesis configuration etc, etc. Then we switch the old blue environment to the new green one. This allows us to update without significant downtime, but also offers us a rollback path if necessary. This kind of approach would not be possible on Rococo.
- By controlling the relay chain nodes, we have a much better understanding of the constraints we have to work with when optimizing the execution of our parachain blocks. If the parachain block execution time goes too high, then relay chain validators will not be able to finalize blocks and the parachain will stall (which happened to us in the early days of our TestNet). Stalls are incredibly dangerous for parachains — in production there may be no other recovery choice than abandoning the parachain slot and re-launching on another slot (paying for the slot again). Right now we are enforcing a 0.5s block execution time limit on our parachain blocks. But we will be looking to expand this, and the corresponding block gas limit as we do performance optimizations. I don’t think we would understand all of these performance constraints without running as a parachain for many months and learning some lessons the hard way.
However, despite all of these points, Rococo is very important as a benchmark and we will continue to ensure compatibility with Rococo so we maintain our parachain readiness as Rococo-based features make their way to Kusama. This includes parachain support, auctions, crowd loans, and cross chain integrations among other things. We may revisit our strategy as Rococo continues to stabilize and have its state reset less frequently, or as westend is parachain enabled. But for now, we will continue to use Moonbase Alpha for our primary Moonriver readiness efforts.
To receive updates about Moonbeam and Moonriver as we prepare for launch, sign up for our newsletter or join our Telegram channel and Discord server.
