Plasma Docs - Build on Plasma

TL;DR

Plasma separates validator nodes (which propose and finalize blocks) from non-validator nodes (which serve RPCs and follow the chain without affecting consensus). This allows Plasma to keep the validator set small and secure, let RPC providers scale independently, and avoid adding consensus or networking risk.

High-Level Architecture

Layer	Role	Trust Model
Consensus Layer (CL)	Propose and finalize blocks	PlasmaBFT
Execution Layer (EL)	Process transactions, manage state, serve RPCs	Fully trusts its paired CL

Each validator runs one consensus node and one execution node, connected directly. Except for its partners, nodes don’t communicate outside their layer peers (CL-to-CL, EL-to-EL). This separation keeps the system predictable, secure, and easy to reason about.

The Scaling Challenge

As usage increases, more apps and users need RPC access to query chain data or send transactions. But if each new execution node must be paired with a new consensus node, scaling becomes inefficient and risks bloating the validator set. Letting RPC providers run additional validators just to meet read demand isn’t practical or aligned with Plasma’s performance goals.

The Solution: Non-Validator Nodes

Non-validator nodes behave like consensus nodes but don’t participate in consensus. Instead, they ‘follow’ a trusted validator for finalized blocks and fork-choice updates. Key behaviors:

They subscribe to a validator’s consensus node to stay in sync.
They expose the same fork-choice view that a real validator would.
They only read, so they don’t add load or introduce security risks.

To applications, a non-validator node looks exactly like a full node: it can respond to RPC requests and reflect the current state but it cannot propose blocks or vote.

Benefits of This Design

Goal	How Non-Validator Nodes Help
Keep validator set lean	Non-validator nodes don’t vote; only validators do.
Unlimited horizontal scale	RPC providers can spin up hundreds of read/write RPC nodes, each with its own non-validator node, without requiring new validator seats.
Maintain consensus correctness	Each execution node still follows exactly one CL. There’s no risk of state divergence.
Reduce risk	Non-validator nodes are read-only and can’t affect consensus messages.
Simplify failover	By following multiple validators, if one goes offline, they can switch to a new one automatically.

Summary Comparison

Feature	Validators	Non-Validator Nodes
Consensus Participation	Full (propose, vote, finalize)	None (receive only)
Message Types	All consensus messages	Block messages only
Network Role	Active participant	Passive follower
Resource Requirements	Higher (full consensus)	Lower (messaging only)

Progressive Decentralization

Plasma is following a progressive decentralization model. Rather than opening the validator set from day one, the initial focus is on stability, performance, and developer usability. This approach prioritizes network reliability while core protocol components are still evolving. Decentralization remains a long-term objective, but it will be phased in gradually. The validator set will expand through three stages:

Centralized Operation

During testnet, all consensus nodes are operated by the Plasma team to enable rapid iteration and minimize operational risk.

Trusted Validator Set

After mainnet launch, a small group of external validators will join, selected for reliability, operational readiness, and geographic distribution.

Permissionless Participation

Over time, validator access will open to the public, supported by protocol-level safeguards for safety, liveness, and economic alignment.

This staged rollout balances decentralization with network integrity. It allows the protocol to harden before handing over critical infrastructure responsibilities to a broader validator set.

Peer Discovery

Plasma nodes discover and connect to peers through two independent mechanisms — one for each layer of the stack.

Execution Layer (Reth)

The execution client uses Ethereum’s standard devp2p protocol for peer discovery. On startup, your Reth node connects to a set of trusted execution peers defined in enodes.txt. These are enode URLs that encode each peer’s public key, IP address, and port. Each network’s enodes.txt is pre-configured in the non-validator-templates repository. After connecting to the initial set, Reth’s built-in discovery protocol (discv4/discv5) finds additional peers automatically. The execution P2P layer operates on port 30303 (TCP/UDP).

Consensus Layer (PlasmaBFT)

The consensus observer client discovers peers through bootstrap nodes defined in non-validator.toml. Each bootstrap node entry includes an API host, P2P port, and a libp2p peer ID:

[network.bootstrap_nodes.0]
api_host = "plasma-mainnet-observer-cs-1.plasmalabs.tech"
p2p_port = 34070
peer_id = "16Uiu2HAm4WdZmik6PVsRvcbCzc1eHuNfQHgj52CxUAjmdC7W5dXi"

Each network ships with 3 bootstrap nodes. Your observer client connects to these on startup and, with peer discovery enabled (discovery.enabled = true), automatically finds additional peers on the network. The consensus P2P layer operates on port 34070 (TCP).

Nodes Behind NAT

If your node is behind a NAT gateway or firewall, other peers may not be able to reach it using its internal address. You can configure an external address so that peers can discover and connect to your node:

[network]
external_address = "node.example.com:34070"

If the port is omitted, it defaults to the value of p2p_port. Make sure the external address is reachable and that the relevant ports are forwarded through your firewall.

Summary

Layer	Protocol	Port	Discovery Method
Execution	devp2p	`30303`	Trusted enodes + automatic discovery
Consensus	libp2p	`34070`	Bootstrap nodes from `non-validator.toml`

For port and firewall details, see the Non-Validator Node Setup guide.

Quickstart

Node Types

Understand validator, non-validator, and RPC provider roles

Non-Validator Node Setup

Deploy your node with Docker Compose

Hardware Requirements

Minimum and recommended specs for your node

Operator Onboarding

Get started with permissionless node operation

Documentation Index

​TL;DR

​High-Level Architecture

​The Scaling Challenge

​The Solution: Non-Validator Nodes

​Benefits of This Design

​Summary Comparison

​Progressive Decentralization

​Peer Discovery

​Execution Layer (Reth)

​Consensus Layer (PlasmaBFT)

​Nodes Behind NAT

​Summary

​Quickstart