Five Client Releases and Four Runtime Upgrades Since Launch
It’s been three weeks since we launched the Moonriver network, and in that time there has been a large amount of interest and usage on the network.
To give some examples of the demand we are seeing, we started with zero traffic and 12 regionally-distributed RPC servers supporting the public RPC endpoints for the network. We have had to scale this up to 32 RPC servers that are handling around 2.5K queries per second at this point. And this doesn’t include load, which is going to other infrastructure providers that are serving Moonriver RPCs.
There are close to 100K wallet addresses on the network that have sent over 1M transactions in the last 3 weeks. Over 650 ERC20 tokens have been created, and there are DeFi protocols with over $100M in TVL already operating on the network. At one point there were over 5000tx in the pending pool and we are at 100K+ tx per day at this point. There is a lot of activity happening on the network given that we are three weeks in.
On the engineering front, Moonriver has had 5 client releases and 4 runtime updates since launch (client releases: 0.11.2, 0.11.3, 0.12.1, 0.12.2, 0.12.3; runtimes: 500, 501, 600, 600tc).
Overall, we have learned a lot by having a production-running network with real-world load and use cases on it. Many of the things we have observed were not previously seen on either our Moonbase Alpha TestNet or in our performance tests.
Multiple bugs and performance issues have been found and addressed, and we expect this to continue in the coming weeks and months. Some of the issues we are finding are part of Moonriver, some are underlying Substrate issues, some are related to Moonriver’s interaction with Kusama, and some are potentially issues with Kusama itself or its validators.
All of this experience and learning is in keeping with the idea of Kusama and Moonriver as a CanaryNet where things happen first.
Overall, the ability to respond to what we are learning is key — that applies to the Moonriver and Parity teams being responsive, but also the upgradability that is built into Substrate and Moonriver which has also allowed us to quickly adapt.
Moonriver Design Principles: Compatibility, Interoperability, Decentralization
I’m getting a lot of questions on the design goals of Moonriver, so I wanted to take the opportunity to clarify a few of them here. I won’t mention security being first, as I take that as a given for any serious project. The question is what the guiding principles are after security.
The first for us is compatibility — we have tried to create the most Ethereum-compatible environment on Kusama. This has been a guiding principle throughout our development and is a core principle of our project. We want to make sure existing Ethereum-based tools and code would work out-of-the-box on Moonriver, and have gone to great lengths to ensure this is the case.
The second guiding principle is interoperability. This is what drove the decision to be a parachain rather than a standalone chain or something else: because we believe that the built-in cross-blockchain networking that Polkadot/Kusama provides will enable unique scenarios and use cases with a high degree of security. This built-in networking and messaging will be used in a lot of the features planned for the Moonriver and Moonbeam roadmaps. It will allow us to deliver native cross-chain integrations with other parachains that are connected to Kusama.
The third principle is decentralization. Being a parachain on Polkadot/Kusama means that we are building on highly secure and decentralized infrastructure. We want to carry forward those same decentralization properties from the Relay Chain to our parachain. This has implications for performance, since it is often easy to improve performance by centralizing certain elements. We are committed to finding ways of moving forward that maintain the decentralization standard set by the Polkadot/Kusama Relay Chains, such as the work we have done to have a permissionless and decentralized collator set.
Performance Enhancements on the Horizon
Moonriver is currently running in a reduced performance state. This is true for all Kusama parachains in this phase of onboarding to the Relay Chain. The idea is to make it easier to work out technical and performance issues before working on optimizations and increasing performance levels.
One notable example is that the parachain block time is currently set to half speed — or ~12s vs the ~6s block time — on the Relay Chain. A 6s parachain block time will be enabled by a future Relay Chain upgrade and will double throughput.
The second key performance parameter is the amount of WASM execution time that validators have available to process the transactions and state transitions in parachain blocks.
While block time is fairly straightforward to understand; let me provide a bit more context on what I mean when talking about WASM execution time. Recall that in the Polkadot/Kusama architecture, parachains are responsible for block production, but Relay Chain validators are responsible for validating and finalizing those parachain blocks. So the flow is that a parachain collator produces a parachain block and then sends the relevant part of the parachain state (this is being called Proof of Validity or PoV) and the block to the Relay Chain validators that have been randomly assigned by the Relay Chain to validate blocks for that parachain at that time. When a Relay Chain validator receives the PoV for the parachain block, it will load the parachain runtime as a WASM (Web Assembly) program. Then the block is executed using the runtime and the PoV is used to validate the result of the block. This process is called the Parachain Validation Function (PVF) and has a limited execution time to ensure the parachain block can be included in the relay block. This execution time is the effective compute constraint for parachains right now.
At this time, parachain teams are currently expected to keep PVF execution time on Kusama under 500ms per block. A third of that time is reserved for block initialization, which leaves only 333ms effectively available to process transactions. Moonriver has been configured accordingly to keep within this 333ms execution time for parachain block transactions. Right now, that is enforced on Moonriver through Substrate weights and a 15M block gas limit for Ethereum transactions. While we are living within the 333ms execution time right now, it is expected that 2000ms of WASM execution time will be made available to parachain blocks via future upgrades (overall 5-6x more throughput).
There is further work that Parity is doing on something called contextual execution, which can improve the 2000ms execution time to perhaps 3000-4000ms with some tradeoffs. And in addition, more complex optimizations like parallel verification of the transaction signatures are being prepared, to allow more transactions per block.
In summary, we will continue to work through a number of performance and other optimizations while the network is in this reduced capacity state. The full throughput of the system will only be available once these performance enhancements are complete and these initial constraints are lifted.
Roadmap: Kusama Cross-Chain Interoperability
Now that version 1 of XCMP has stabilized, we are working on the first of many Kusama-native cross-chain integration scenarios. The first scenario will be to support the bi-directional movement of KSM from the Relay Chain to an ERC20 representation on Moonriver using XCMP. This is the next major feature we are looking to ship, and will be deployed to Moonbase Alpha next week for testing.
Once this feature is deployed to Moonriver, KSM holders on the Kusama Relay Chain will be able to send KSM to Moonriver using a special extrinsic. That KSM will be locked on the Relay Chain, and a KSM token will be created on Moonriver. The Moonriver KSM token will be represented as a special ERC20 compatible precompile in the Moonriver EVM. Moonriver users will then be able to use this ERC20 version of KSM to interact with DeFi and other protocols that are deployed to Moonriver. Users will also be able to send the KSM back to the Relay Chain to take control of it there once again.
We expect this to land on Moonriver in the next 4-6 weeks. This is the first of many cross-chain integration scenarios on Moonriver that will be powered by XCMP. We see our ability to extend the base EVM with Polkadot/Kusama native integrations for assets and other cross chain operations as one of our core differentiators relative to other EVM compatible chains.
Final Thoughts
Substrate and Polkadot/Kusama are very complex software frameworks and systems that are rapidly evolving. We continue to learn a large amount every week as we implement new features, identify new issues and provide new solutions. In terms of priority, security always comes first, so this means that the timing of features may not be predictable. Also, since we are only one part of a larger network, we sometimes need support from other teams, and fixes are not directly under our control. I expect cross-chain and cross team scenarios to become increasingly the norm within the Polkadot/Kusama ecosystems.
It’s an exciting time in the Polkadot/Kusama ecosystem as the full functionality of the networks are activated. The Moonbeam team has been blown away by the energy and enthusiasm of the developers and users that are deploying to and interacting with Moonriver. As more parachains come to life on Kusama, we are also very excited about helping make cross chain scenarios happen on Moonriver. We look forward to continuing to iterate and improve Moonriver together with all of you.
