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
- 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↔CL, EL↔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.