The Mezo testnet is a network of nodes running the Mezo client software, assisted by several auxiliary services. This network is used for testing and experimentation. Specific components that form the core of the testnet are:
| Component | Public address |
|---|---|
| Validator 0 | mezo-node-0.test.mezo.org |
| Validator 1 | mezo-node-1.test.mezo.org |
| Validator 2 | mezo-node-2.test.mezo.org |
| Validator 3 | mezo-node-3.test.mezo.org |
| Validator 4 | mezo-node-4.test.mezo.org |
| Block explorer app | https://explorer.test.mezo.org |
| Block explorer server | N/A |
| Block explorer database | N/A |
| Faucet | https://faucet.test.mezo.org |
| JSON-RPC HTTP server | https://rpc.test.mezo.org |
| JSON-RPC WebSocket server | wss://rpc-ws.test.mezo.org |
Validator nodes expose the following services:
| Service | Port |
|---|---|
| P2P | 26656 |
| RPC | 26657 |
| REST | 1317 |
| GRPC | 9090 |
| JSON-RPC HTTP | 8545 |
| JSON-RPC WS | 8546 |
External nodes can join the network by connecting to any of the validator nodes. A standard onboarding procedure for validator and non-validator nodes is in progress and will be documented in the future.
From the operational perspective, all aforementioned core components of the testnet are Kubernetes deployments, living on a Google Kubernetes Engine (GKE) cluster. The cluster is managed by the Mezo engineering team and is not accessible to the public. Here is an overview of the setup from the ground up.
The main artifacts necessary to bootstrap a testnet Mezo chain are:
- A global genesis file defining the initial state of the chain (most importantly, the initial validator set)
- Configuration packages for initial validators (private keys, configuration files, etc.)
- A configuration package for the faucet (used to distribute the gas token)
- A seed file containing the public addresses of the initial validators (used by new nodes to join the network)
There is an automated way to generate these artifacts using the
scripts/public-testnet.sh script.
This script generates the genesis file, 5 configuration packages for
initial validators, one configuration package for the faucet, and a seed file.
The resulting artifacts are stored in the
.public-testnet directory.
Note: In the future, the scripts/public-testnet.sh script will be
integrated into the Mezo client software and exposed as a command-line
interface (CLI) command
Testnet artifacts mentioned above are infrastructure-agnostic and can be used
to bootstrap a Mezo chain on any platform. In practice, Mezo engineering team
uses Google Cloud Platform (GCP) as the infrastructure provider for the core
components of the Mezo testnet. Moreover, GCP resources are managed using
Terraform. The Terraform configuration is located in the
infrastructure/terraform/mezo-staging
directory. Most important infrastructure resources managed by Terraform are:
- VPC network
- NAT gateway
- GKE cluster
- Docker image registries (internal and public)
- Cloud functions
Moreover, Terraform is used to automate the deployment of Helm charts on the GKE cluster.
Initial validators are deployed on the GKE cluster using pure Kubernetes
manifests. The manifests are located in the
infrastructure/kubernetes/mezo-staging
directory. Validators deployments leverage testnet artifacts generated by the
scripts/public-testnet.sh script (see Artifacts).
The artifacts are ported to the Kubernetes cluster as config maps and secrets.
Config maps hold configuration files and the genesis file, while secrets store
sensitive information like private keys. Artifacts porting is done manually
for now but should be automated in the future.
Validators deployments use the latest Docker image of the Mezo client software living in the internal Docker registry. The image is built and pushed manually by the Mezo engineering team but this process will be automated in the near future. Moreover, the Mezo client Docker image will be soon available in the public Docker registry for external users to pull and run their own nodes. That will happen once the first stable version of the Mezo client is released and a proper onboarding procedure for external nodes is in place.
Auxiliary services like the block explorer app are deployed on the GKE cluster
using Helm. Helm is a package manager for Kubernetes that allows to define,
install, and manage Kubernetes applications. Helm charts are located in the
infrastructure/helm/mezo-staging
As mentioned in the Infrastructure section, Terraform is used to automate the deployment of Helm charts on the GKE cluster. This makes the process easier as there is no need to deal with Helm directly.
The sidecar is a component of the Mezo node, running as a separate process
responsible for interacting with the Ethereum network. It plays a key role in
the bridging architecture, monitoring the Ethereum network for AssetsLocked
events emitted by the MezoBridge contract when assets are deposited.
Once the blocks containing these AssetsLocked events are finalized, they are cached
for further processing by the Mezo node. Due to Ethereum’s block finality mechanics,
the sidecar is bound by the same constraints. As a result, it takes approximately
13 to 14 minutes for a new event to be finalized and stored in the “finalized” cache
for the Mezo node to process.
More details can be found in the following RFC