Most blockchain applications — wallets, DeFi protocols, block explorers — don't run their own blockchain nodes. Running a full Ethereum node requires terabytes of storage, continuous bandwidth, and ongoing maintenance. So instead, most apps connect to someone else's node through an interface called RPC.
RPC stands for Remote Procedure Call. In the blockchain context, an RPC node is a fully synced blockchain node that exposes a standardized API endpoint, letting external applications read chain state and submit transactions without running their own infrastructure.
Understanding this matters because the RPC layer is where centralization often sneaks back into applications that are otherwise described as decentralized.
The Mechanism
Ethereum and most EVM-compatible chains use the JSON-RPC 2.0 protocol. Requests and responses are structured JSON objects sent over HTTP or WebSocket connections.
A basic call looks like this:
{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}
The node receives the request, executes it against its local chain state, and returns the result. Common methods include:
- eth_getBalance — returns the ETH balance of an address at a given block
- eth_call — simulates a smart contract call without broadcasting a transaction
- eth_sendRawTransaction — submits a signed transaction to the mempool
- eth_getLogs — queries event logs emitted by smart contracts
- eth_getBlockByNumber — retrieves full block data including transaction list
WebSocket connections add subscription capability. The eth_subscribe method lets applications receive pushed updates when new blocks are mined or specific events fire, rather than polling repeatedly.
Providers vs Self-Hosted Nodes
Running an archive node — which stores all historical state, not just the recent chain tip — requires 10+ TB of storage for Ethereum mainnet. Pruned nodes are smaller but can't answer historical queries.
Most developers use managed RPC providers: Alchemy, Infura, QuickNode, Ankr. These services run node infrastructure at scale and sell API access through rate-limited endpoints. The trade-off is direct: reliable, fast RPC access in exchange for depending on a third party's infrastructure and trusting their data accuracy.
There's no cryptographic proof embedded in a standard RPC response. When you call an endpoint, you're trusting that the provider is returning correct chain state.
Where Constraints Live
Trust. This is the core constraint. Full nodes verify every block independently. Applications using RPC endpoints verify nothing — they accept whatever the provider returns. A malicious or compromised provider could return incorrect balances, fabricated transaction receipts, or manipulated contract state. Most dApp users don't know their wallet is making unverified calls to a corporate API.
Rate limits. The practical constraint for developers. Free tier RPC access is throttled — Infura's free tier caps at 100,000 requests/day. High-throughput applications need paid plans or their own node infrastructure. Large DeFi protocols often run their own nodes for this reason.
Historical queries. Pruned nodes can't answer questions about state at arbitrary historical blocks. Archive node access costs more and some providers don't offer it on lower tiers.
Geographic latency. For latency-sensitive applications, provider location relative to validators matters. Some teams pay for dedicated RPC endpoints with guaranteed low latency.
What's Changing
Light clients. The most consequential structural shift. Helios (built by a16z crypto) is a light client that syncs in seconds using only consensus layer headers and can cryptographically verify execution layer RPC responses without running a full node. If Helios or Portal Network integrations reach consumer wallets and dApp libraries, the trust model for RPC changes materially. Right now, almost no consumer application uses one.
Private RPC endpoints. MEV Blocker, Flashbots Protect, and similar services let users submit transactions through endpoints that shield pending transactions from MEV bots. These route transactions directly to validators, bypassing the public mempool — a fundamentally different flow from standard eth_sendRawTransaction.
Provider expansion. Alchemy and QuickNode have moved beyond raw RPC to offer enhanced APIs: indexed token balances, NFT ownership data, webhook subscriptions for on-chain events. The category is evolving from node access to blockchain data platform.
Confirmation Signals
Light client integration in major wallets would confirm the trust model is shifting — watch for Helios or Portal Network adoption in MetaMask, Rainbow, or Coinbase Wallet. Currently absent from all of them.
Sustained growth in private mempool transaction volume relative to public mempool would indicate MEV protection infrastructure has become default rather than opt-in.
Invalidation
If light client development fragments across competing standards without reaching consumer wallets, the centralized RPC model continues indefinitely. Three providers — Alchemy, Infura, QuickNode — handle the majority of Ethereum RPC traffic. A coordinated compromise or simultaneous outage at this layer would expose the concentration risk the current architecture embeds.
Timing
Now: RPC infrastructure is mature and operational. Managed providers offer 99.9%+ uptime SLAs. The trust assumptions are live — most users are already relying on centralized RPC without knowing it.
Next: Light client tooling exists and is functional but not deployed in consumer applications. Integration timelines depend on wallet developer priorities, not research progress.
Later: If Ethereum's statelessness roadmap progresses (Verkle Trees, EIP-6800), node storage requirements drop significantly — potentially changing the economics of running your own node and reducing dependence on managed RPC at scale.
Boundary Statement
This covers the RPC mechanism and the trust trade-offs it creates. It doesn't evaluate specific providers or recommend node infrastructure choices. The light client projects mentioned are in active development — production readiness changes.
The RPC model is how most blockchain applications function today. The centralization it introduces is structural, not accidental — and it persists until verifiable light clients reach production deployments.
