​
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

LayerRoleTrust Model
Consensus Layer (CL)Propose and finalize blocksPlasmaBFT
Execution Layer (EL)Process transactions, manage state, serve RPCsFully 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

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

​
Summary Comparison

FeatureValidatorsNon-Validator Nodes
Consensus ParticipationFull (propose, vote, finalize)None (receive only)
Message TypesAll consensus messagesBlock messages only
Network RoleActive participantPassive follower
Resource RequirementsHigher (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:
  1. Centralized Operation – During testnet, all consensus nodes are operated by the Plasma team to enable rapid iteration and minimize operational risk.
  2. Trusted Validator Set – After mainnet launch, a small group of external validators will join, selected for reliability, operational readiness, and geographic distribution.
  3. 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.

​
Quickstart

Node Types

Non-Validator Node Setup

Hardware Requirements

Node Contact Form