USDC Yield With Cover Built InQuicknode Earn now runs USDC yield with cover for protocol risk built in, underwritten by OpenCover. Six covered vaults on Base.
TL;DR: An RPC (Remote Procedure Call) request is how your application communicates with a blockchain node. Your app sends a JSON-formatted message to an RPC endpoint specifying which method to call and what parameters to include. The node processes the request, executes the corresponding logic against the blockchain's state, and returns a JSON response with the result. Every wallet balance check, transaction submission, and smart contract interaction follows this request-response pattern.
わかりやすい説明
When you tap "send" in a crypto wallet or check your token balance on a portfolio tracker, your application does not have direct access to the blockchain. It needs to ask a node for that information. The language it uses to ask is called JSON-RPC, a lightweight protocol that structures requests and responses as simple JSON objects.
Here is how the conversation works. Your application constructs a request object with four fields: the JSON-RPC version (always "2.0"), a method name that tells the node what operation to perform, an array of parameters that provide context for that operation, and a unique ID so your app can match the response to the request. It sends this object as an HTTP POST to the RPC endpoint URL. The node receives the request, looks up or computes the answer, and sends back a response object containing the same ID and either a result field (if successful) or an error field (if something went wrong).
Every blockchain defines a set of standard RPC methods that nodes must support. On Ethereum and EVM-compatible chains, these methods follow the "eth_" namespace convention. Read operations query the blockchain's state without modifying it. "eth_blockNumber" returns the latest block height. "eth_getBalance" returns an account's native token balance at a given block. "eth_call" executes a smart contract function in read-only mode, which is how your app retrieves token balances, NFT metadata, and DeFi protocol states without spending gas.
When your application sends an RPC request, multiple steps happen before you receive a response. First, the HTTP client establishes a TCP connection to the endpoint and performs a TLS handshake to encrypt the channel. Then it sends the JSON payload. The node's RPC server parses the request, validates the method name and parameters, and routes it to the appropriate handler. The handler either looks up cached data, queries the node's local database, or executes computation (like running a smart contract call in the EVM). Once the result is ready, the node serializes it as JSON and sends it back over the same connection.
RPC responses include standard error codes when something goes wrong. A malformed request returns a parse error. An invalid method name returns a method-not-found error. Rate limiting typically returns an HTTP 429 status or a JSON-RPC error with code -32005. Understanding these error codes and handling them gracefully in your application is essential for building reliable blockchain software.
If your application only needs occasional reads, plain HTTP is simplest. If you need live blockchain events, a WebSocket subscription beats hammering the node with repeated calls. For a deeper look at the connection types a node exposes, see what an RPC endpoint is, and for the trade-offs between checking repeatedly versus subscribing, see polling vs streaming.
RPC latency is the sum of network transit and node processing time, and both are controllable. Route requests to a node geographically close to your users, reuse connections with pooling and HTTP/2 multiplexing, batch related calls into a single request, and cache data that does not change between blocks. Choosing the leanest method for the job also helps: request a block header instead of full transactions when you only need the header. For the full breakdown of what slows requests down, see what drives RPC latency, or skip the tuning entirely with the globally distributed Quicknode Core API.
Beyond standard JSON-RPC, Quicknode provides enhanced API methods that reduce the number of requests your application needs to make. Instead of calling multiple standard methods to reconstruct a wallet's complete token holdings, a single enhanced API call can return all the data in one response. Quicknode Streams takes this further by eliminating the request-response pattern entirely for real-time data, pushing blockchain events directly to your application or database as they happen. For developers looking to optimize their RPC usage, Quicknode publishes a detailed guide to efficient RPC calls covering pagination, caching, error handling, and method selection best practices.
よくある質問
What does RPC stand for in blockchain?
RPC stands for Remote Procedure Call. It is a pattern where your application calls a function that runs on a remote machine, in this case a blockchain node, as if it were calling a local function. The node executes the procedure against the chain's state and returns the result.
JSON-RPCとは何ですか？
JSON-RPC is the lightweight protocol most blockchains use for RPC. Requests and responses are plain JSON objects. A request names a method and its parameters, and the response carries either a result or an error, matched to the request by a shared ID.
RPCリクエストとAPI呼び出しは同じものですか？
It is a specific kind of API call. A general REST API exposes resources at different URLs, while a blockchain RPC API exposes methods at a single endpoint URL and selects the operation through the method name in the request body. The round-trip request-response idea is the same.
What is the difference between an RPC node and an RPC endpoint?
An RPC node is the running server that holds blockchain data and executes requests. An RPC endpoint is the URL your application sends requests to, which routes them to one or more nodes behind it. See what a blockchain node is for the underlying infrastructure.
