Skip to main content
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:"$PLASMA_CONSENSUS_VERSION" 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:"$RETH_VERSION" init --chain /node/testnet.json --datadir /node/execution
Consensus Database: 
docker run --rm -i -v ./node:/node ghcr.io/plasmalaboratories/plasma-consensus:"$PLASMA_CONSENSUS_VERSION" 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:"$RETH_VERSION" node [...]
Consensus Observer Client: 
docker run --network plasma --name plasma-consensus -p 34070:34070 -p 35070:35070 -v ./node:/node -v ./non-validator.toml:/node/non-validator.toml ghcr.io/plasmalaboratories/plasma-consensus:"$PLASMA_CONSENSUS_VERSION" 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.Internal only.
34303 (TCP)P2P ConsensusPeer-to-peer communication with other consensus nodes.Requires inbound and outbound access.
34304 (UDP)P2P ConsensusPeer-to-peer communication with other consensus nodes.Requires inbound and outbound access.
34070 (TCP)P2P ConsensusPeer-to-peer communication with other consensus nodes.Requires inbound access.
35070 (TCP)MetricsChecking health of node clients.Requires inbound access.

​
Firewall Considerations

Ensure your firewall configuration allows:
  • Inbound and Outbound connections on ports 30303(TCP) and 30304(UDP) for peer discovery and communication.
  • Inbound connections on port 34070(TCP) for optimal peer connectivity (recommended but not required).
  • Internal communication on port 8551 between Docker containers.
  • Metrics on port 35070(TCP) for checking health of the nodes.
  • 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.
⌘I