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
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
Summary Comparison
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.
Plasma Node Types
Plasma supports multiple node types based on architecture roles and operational goals.
Non-Validator Nodes
Non-validator nodes are read-only participants that follow the blockchain without participating in consensus decisions. They provide a lightweight way to access blockchain data without the overhead of consensus participation.
Key Capabilities
Block reception: Receive and process blocks from the network
Chain synchronization: Maintain an up-to-date copy of the blockchain
Catchup mechanism: Automatically detect and recover missing blocks
API access: Provide the same API endpoints as validators for querying blockchain state
Technical Characteristics
Simplified configuration with node ID (string identifier)
Read-only access to validator public keys
Connect through bootstrap nodes
Cannot propose blocks, vote, or trigger view changes
RPC Providers
Hosted RPC infrastructure with production-grade availability and support.Current Providers
QuickNode: High-performance global infrastructure with monitoring and alerting.
Tenderly: Managed access with built-in observability, simulations, and incident tooling.
Benefits
Immediate production-ready access
SLAs and support included
Scales with application demand
Use Cases
Production applications requiring high availability
Teams prioritizing development over infrastructure
Projects needing enterprise support and guarantees
Consensus Nodes
Consensus nodes are the core participants in the Plasma consensus layer, implementing the Fast-Hotstuff Byzantine Fault Tolerant (BFT) protocol. The network can tolerate up to f faulty nodes in a system of 3f+1 total validators.
Key Responsibilities
Block production: Validators take turns proposing blocks using round-robin selection based on the current view
Voting: Validate incoming blocks and cast votes that are aggregated into Quorum Certificates (QCs)
Consensus participation: Actively participate in view changes, timeouts, and the 2-chain finalization rule
State management: Maintain full consensus state including vote aggregation, view tracking, and block finalization
Technical Requirements
BLS keypair for cryptographic operations and vote aggregation
Full node configuration with validator ID (numeric identifier)
Access to execution layer (reth) for block production
P2P networking capabilities for unicast and broadcast messaging
