Moonbeam released Moonbase Alpha, its first public TestNet, today. This represents a major milestone for the Moonbeam project.
The goal of Moonbase Alpha is to provide developers with a place to start experimenting and building on Moonbeam in a shared environment. Since Moonbeam will be deployed as a parachain on Kusama and Polkadot, we want our TestNet to reflect our production configuration. For this reason, we decided that it needed to be a parachain-based configuration rather than a Substrate standalone setup. It is also essential for us to have a fully automated pipeline executing from GitHub all the way to the Moonbase Alpha deployment configuration.
Developing a Parachain-Based TestNet
Deploying Substrate-based chains as parachains has just recently become possible based on Parity’s work on the Cumulus library, among other things. This functionality is still very new and is actively being developed and improved.
While working to set up the TestNet with these technologies, we encountered several challenges which helped us understand how relay chain <> parachain interactions in Polkadot work at a lower level.
The first challenge was around building the environment, which involves a fair bit of complexity. The process requires two automated pipelines, each producing different outputs (Polkadot binary, Moonbeam binary) and these outputs need to be married to the correct, generated spec files for the Relay Chain Validator and Moonbeam Collator node roles. Then a third process requires us to create the Moonbeam genesis state and WASM binary, which is then registered to the deployed relay chain. These actions need to be automated to execute in the right sequence.
A second challenge arises from the rapid change that Substrate is undergoing. Rust limits us to only one version of a library at any given time. Thus, it took some workarounds to find a version of Substrate that was compatible across Rococo (which we are using as the base for our Relay Chain build), Cumulus (which is currently based on a one-month old version of Substrate), and Moonbeam / Frontier (which we are updating with Substrate master every few days). Hopefully, this will become less difficult as parachain functionality matures and stabilizes.
Moonbase Alpha Configuration at Launch
Currently, the infrastructure supporting the Moonbase Alpha TestNet is hosted by PureStake, the team developing Moonbeam. The initial configuration consists of a parachain–relay chain setup. The parachain has one collator producing blocks, while the relay chain consists of three validators, one of which is selected to finalize each block produced at the parachain level. This setup provides room to expand to a two-parachain configuration in the future. There are a couple of RPC endpoints for both HTTPS and WebSocket calls.
As part of this release, the Moonbase Alpha features implementations of the EVM pallet and the Web3 RPC in Substrate. Moonbeam leverages the Frontier project (for which PureStake’s contributions earned a Web3 grant) to support native Ethereum RPCs. Compatibility with existing Ethereum developer tools such as Truffle, Remix, and MetaMask have been tested and examples of using these can be found on our docs site.
TestNet Feature Roadmap
For the next TestNet update, PureStake is planning to add two key features.
First is the unification of Substrate and Ethereum accounts under the H160 format, an effort that we refer to as Unified Accounts. This is an important milestone because, in absence of this functionality, there are two completely different sets of states: one for Substrate accounts, and one contained within the EVM for Ethereum-based accounts. By unifying them, there will be only one kind of account in the system represented by a single address, instead of two.
The second feature is the inclusion of event subscription support (Pub/Sub). This component is missing on the Web3 RPC side, so we plan to add it since it is commonly used by dApps.
The alpha TestNet version that was released today does not support third-party collators. We will add support in a future update to enable interested parties to test their setups. This may also include the implementation of the rewards system, as well as the token economic model.
Other features such as on-chain governance and the treasury might be added in future updates as well.
Because the system is hosted by PureStake, Moonbase Alpha will run similar to how Polkadot MainNet ran in early times: with Proof of Authority instead of Proof of Stake. This means that block finalization is carried out by a known identity, in this case, the PureStake validators.
Getting Started with the New TestNet
As the first Moonbeam TestNet, there will be some limitations. Tokens on Moonbase Alpha, named DEV, will be issued on-demand. To request tokens, we’ve created a Discord bot (named Mission Control ?) that will automatically send a maximum of 10 DEV tokens per hour (per Discord user). You can check it out on our Discord channel.
In addition, users only have access to Moonbeam (the parachain). In the future, we might open access to the relay chain, so users can test transferring tokens between Moonbeam and the relay chain.
Regarding smart contracts, this early iteration has no gas limit per block in order to provide an easy on-ramp for developers. This configuration will change in the future.
Getting started is fairly simple. Point your provider to the following RPC DNS for connections via HTTPS:
For the Web3 library, create a local Web3 instance and set the provider to connect to the Moonbeam TestNet:
const Web3 = require('web3'); //Load Web3 library . . . //Create local Web3 instance - set the Moonbeam TestNet as provider const web3 = new Web3('https://rpc.testnet.moonbeam.network);
Any Ethereum wallet should be able to generate a valid address or Moonbeam (for example, MetaMask).
For connections via WebSocket, you can use the following RPC DNS:
If you have any feedback regarding the Moonbeam TestNet, feel free to reach out through our official development Discord channel.