> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plasma.org/llms.txt
> Use this file to discover all available pages before exploring further.
# Overview
> Understanding Plasma's modular node architecture and operator roles
## 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](https://a16zcrypto.com/posts/article/progressive-decentralization-crypto-product-management/). 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:
During testnet, all consensus nodes are operated by the Plasma team to enable rapid iteration and minimize operational risk.
After mainnet launch, a small group of external validators will join, selected for reliability, operational readiness, and geographic distribution.
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](https://github.com/ethereum/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](https://ethereum.org/en/developers/docs/networking-layer/#enode) that encode each peer's public key, IP address, and port.
Each network's `enodes.txt` is pre-configured in the [non-validator-templates](https://github.com/PlasmaLaboratories/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](https://docs.libp2p.io/concepts/fundamentals/peers/):
```toml theme={null}
[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:
```toml non-validator.toml theme={null}
[network]
external_address = "node.example.com:34070"
```
```bash CLI theme={null}
--p2p.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](./non-validator-node-setup#port-configuration) guide.
## Quickstart
Understand validator, non-validator, and RPC provider roles
Deploy your node with Docker Compose
Minimum and recommended specs for your node
Get started with permissionless node operation