A blockchain is a peer-to-peer network of nodes that maintains a shared ledger. Every node communicates with other nodes in the network using specialized peer-to-peer (P2P) protocols to verify blocks/transactions, store state, and so on.
If you’re building an app on a blockchain, you need a way to communicate with these nodes to read the current state of the blockchain (balances, contract/account data, logs) and write a new state.
However, direct P2P communication is impractical because node-to-node communication is optimized for consensus and gossip, not for app developers. This is because they involve a lot of complex processes that browsers and typical backends aren’t designed to handle.
Remote Procedural Call (RPC) Nodes exist to abstract this complexity and provide a stable HTTP/WebSocket-friendly way to read and write blockchain data.
What is an RPC Node?
RPC is a communication protocol that allows a program on one computer to execute a function on a different computer as if it were a local call.
On blockchains, this commonly appears as JSON-RPC over HTTP or WebSocket, so you can call methods like getBalance(address) which returns the balance of an address without handling low-level networking.
An RPC node is a blockchain node configured to expose this developer-friendly API. Behind the scenes, it syncs the chain, validates data, and “gossips” with peers; to you, it presents clear methods (read state, submit signed transactions, subscribe to updates) accessible via an RPC endpoint (the URL of the API).
For example:
curl -X POST https://mainnet.infura.io/v3/YOUR_PROJECT_ID \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"method": "eth_getBalance",
"params": [
"0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe",
"latest"
],
"id": 1
}'
The request above fetches the address’s balance (in Wei) using Infura (an RPC provider) via an Ethereum JSON-RPC endpoint. In practice, apps use libraries like viem, ethers.js, or web3.js to talk to RPC endpoints.
How RPC Nodes work
RPC nodes are normal blockchain nodes with an exposed API surface. The node maintains chain state (syncs blocks, executes transactions, stores results). The RPC layer maps your requests to the right internal components (state/execution, transaction pool, or subscription engine).
Note: The mechanisms explained below depict how RPC nodes on the Ethereum mainnet behave. It can vary from blockchain to blockchain.
Blockchain Reads
For a read (e.g., “get balance” or a contract view), the node selects state at the block tag (latest, pending, safe, finalized) you asked for, or a specific block number.
If the method requires execution (for example, an eth_call against a contract), the node runs the call against a sandboxed state at that height, without changing the chain. It then serializes the result and returns it.
Blockchain Writes
For a write (submitting a signed transaction), the node validates format and signature (tx type, chainId, nonce, gas limits/fees, optional access list).
If valid, your request enters the mempool and is “gossiped” to peers. A block producer includes it, and after it has been executed, you can query receipts, logs, and confirmation depth.
Subscriptions
Over WebSocket, Ethereum supports eth_subscribe channels such as:
-
newHeads(new block headers) -
logs(filtered by address/topics) newPendingTransactions
The node manages buffers/backpressure; clients should handle reconnects and resume from the last seen block number to stay consistent.
Using RPC Nodes
To use an RPC node, you can either run your own private RPC node, use a public RPC node, or use an RPC node provider.
Running your own RPC Node
If you need overall control over your own RPC node, you can install and run blockchain clients like Geth, Nethermind, or Reth on your own hardware or virtual server and enable RPC on them.
This method requires a lot of maintenance on your end and is best for teams with special needs.
Using a Public RPC Node
Most blockchains provide free public RPC endpoints that allow anybody to use RPC nodes. Due to their easy accessibility, they are usually overloaded and rate-limited, making them ideal for small Dapps and testing. Additionally, they may not offer WebSocket support.
Examples of Popular Public RPC Nodes include the following:
| Chain | Provider | RPC Endpoint |
|---|---|---|
| Ethereum | PublicNode | https://ethereum-rpc.publicnode.com |
| Solana (Mainnet-beta) | Anza (Solana Labs) | https://api.mainnet-beta.solana.com |
| BNB Smart Chain | BNB Chain (official) | https://bsc-dataseed.bnbchain.org |
| Sui (Mainnet) | Mysten Labs | https://fullnode.mainnet.sui.io:443 |
Using an RPC Node Provider
This is the most popular option for most developers because using RPC node providers is cheaper than running your own RPC node, and you can scale your configuration as your usage increases.
To use an RPC provider, you simply need to sign up on their platform, choose a plan, and start querying their endpoint. Some popular RPC Node providers include Alchemy & QuickNode.
Another interesting RPC provider is the Developer Dao Cloud, which is built on the POKT Network and gives you access to 60+ chains with unbeatable uptime. You can join the Developer Dao Cloud waitlist here.
Conclusion
You can think of RPC nodes as the API layer of the blockchain. They abstract all the complexities associated with P2P communication between a node and a Dapp and expose a friendlier UI.
You can access an RPC node via paid providers (often with free tiers), community/public endpoints, or by running your own dedicated node. Whichever route you choose, decide based on your needs for reliability, latency, and cost, and data/privacy requirements.
Top comments (0)