Non-validator nodes provide RPC access to the Plasma network by monitoring consensus clients and serving application requests. This guide covers deployment, configuration, and operational maintenance for running a Plasma non-validator node.

Contact required: Please submit your details here before deploying nodes.

​
Prerequisites

Before setting up a non-validator node, ensure you have:

​
Quickstart

Spinning up a node is a simple process with this pre-packaged ZIP.

  1. Connect to your server and ensure that Docker and Docker Compose are installed.

  2. Grab the latest Non-Validator Node package from your signup email. If you can’t find the package, get in touch with Plasma.

  3. Unzip the package:

    unzip non-validator-node-setup.zip
cd non-validator-node-setup

  4. Run the setup script as root:

    sudo ./setup.sh

    This process should take about 10 minutes to complete.

  5. Check that your Docker containers are running:

    docker ps

  6. Setup complete.

​
Setup Process Explained

The setup script automates the deployment of a two-component architecture that enables your node to participate in the Plasma testnet as an non-validator node. While every setup process is slightly different, you can use that script as a template to spin up as many non-validator nodes as you need.

The remainder of this page will focus on the basic steps outlined in the script, and how they might impact your non-validator node.

​
Architecture Overview

Your non-validator node consists of two main components:

  • Plasma Execution Client: Based on Reth, this handles transaction execution, state management, and provides JSON-RPC endpoints for applications.
  • Plasma Observer Client: A lightweight client that monitors the Plasma consensus network without participating in block production or validation.

​
Detailed Setup Steps

​
Environment Preparation

The script first cleans any existing node data and creates the necessary directory structure:

sudo rm -rf ./node/execution
sudo rm -rf ./node/consensus
mkdir -p node/execution
mkdir -p node/consensus

This ensures a clean installation and creates separate directories for execution and consensus data.

​
JWT Authentication Setup

A shared JWT secret is generated for secure communication between the consensus observer client and execution client:

openssl rand -hex 32 | tr -d '\n' > node/jwt.hex

This secret enables authenticated communication through the Engine API.

​
Network Identity Generation

The script creates cryptographic keys for peer-to-peer networking:

openssl ecparam -name secp256k1 -genkey -noout -out ./node/consensus/ec-secp256k1-non-validator.pem
openssl ec -in ./node/consensus/ec-secp256k1-non-validator.pem -outform DER -no_public -out ./node/consensus/ec-secp256k1-non-validator.der

These keys establish your node’s unique identity on the Plasma network and enable secure communication with other nodes.

​
Genesis Configuration

The script retrieves the official Plasma testnet genesis configuration:

docker run --rm -i -v ./node:/node ghcr.io/plasmalaboratories/plasma-consensus:0.9.2 plasma-cli dump-genesis --chain testnet > ./node/testnet.json

This configuration defines the initial network state and consensus parameters required to sync with the testnet.

​
Database Initialisation

Both the execution and consensus components require database initialisation:

Execution Database:

docker run --rm -i -v ./node:/node ghcr.io/plasmalaboratories/plasma-execution:0.9.2 init --chain /node/testnet.json --datadir /node/execution

Consensus Database:

docker run --rm -i -v ./node:/node ghcr.io/plasmalaboratories/plasma-consensus:0.9.2 plasma-cli init --chain /node/testnet.json --data-dir /node/consensus

These steps prepare the local databases with the correct genesis state and network parameters.

​
Container Deployment

The script deploys two Docker containers:

Execution Client (Reth-based):

docker run --network plasma -d --name plasma-execution -p 8551:8551 -v ./node:/node ghcr.io/plasmalaboratories/plasma-execution:0.9.2 node [...]

Consensus Observer Client:

docker run --network plasma --name plasma-consensus -p 34070:34070 -v ./node:/node -v ./non-validator.toml:/node/non-validator.toml ghcr.io/plasmalaboratories/plasma-consensus:0.9.2 plasma-cli non-validator[...]

​
Network Configuration

The setup includes connections to official Plasma testnet infrastructure:

​
Bootstrap Nodes

Your consensus observer client connects to official Plasma bootstrap nodes:

  • testnet-cs-0.plasmalabs.tech:34070
  • testnet-cs-1.plasmalabs.tech:34070
  • testnet-cs-2.plasmalabs.tech:34070

​
Trusted Execution Peers

Your execution client connects to trusted Plasma execution nodes:

  • testnet-ex-0.plasmalabs.tech:30303
  • testnet-ex-1.plasmalabs.tech:30304
  • testnet-ex-2.plasmalabs.tech:30304

​
Port Configuration

The setup exposes specific ports for different services:

PortServicePurposeExternal Access
8551Engine APIInternal communication between consensus and execution.No - Internal only.
34070P2P ConsensusPeer-to-peer communication with other consensus nodes.Yes - Requires inbound access.

​
Firewall Considerations

Ensure your firewall configuration allows:

  • Outbound connections on ports 30303, 30304, and 34070 for peer discovery and communication.
  • Inbound connections on port 34070 for optimal peer connectivity (recommended but not required).
  • Internal communication on port 8551 between Docker containers.

The JSON-RPC interface runs on port 8545 within the Docker network but is not exposed externally by default for security reasons.

​
Validator Committee Configuration

The non-validator.toml configuration includes references to BLS public keys for the current validator set. These keys are provided in the /node/keys/ directory and allow your observer client to verify consensus messages from active validators.

The configuration references 10 validator public keys (bls12-381-public-key-0.hex through bls12-381-public-key-9.hex), representing the current testnet validator committee.

​
Monitoring Your Node

Once your node is operational, you can monitor its health and synchronisation status. For comprehensive monitoring setup and best practices, see our monitoring guide.

Quick status checks:

# Check container status
docker ps

# View execution client logs
docker logs plasma-execution

# View consensus observer client logs  
docker logs plasma-consensus

Your node will begin synchronising with the Plasma testnet immediately. Initial sync may take several minutes depending on network conditions and your hardware specifications.