Accelerating Ethereum API Performance: A Guide to Read-Only RPC Caching

Read-only Ethereum RPC calls, like eth_call and eth_getBalance, are frequently repeated even when data hasn't changed, causing inefficiency and strain on RPC providers. The solution is caching, which optimizes Ethereum API interactions by serving static or slowly changing data directly, reducing redundant requests to upstream providers.

Understanding Cacheable Ethereum RPC Calls

Not all Ethereum RPC methods are created equal when it comes to caching. The fundamental distinction lies between read-only operations and state-changing transactions. Read-only methods query the current or historical state of the blockchain and are deterministic for a given block number and set of parameters. This makes their responses highly suitable for caching.

Cacheable Read-Only Methods

• eth_call: Executes a new message call immediately without creating a transaction on the blockchain. The result depends solely on the current state and input parameters.
• eth_getBalance: Retrieves the balance of an account at a given block number. This value changes only when transactions involving that account occur.
• eth_getCode: Returns the code at a given address. Contract code is immutable once deployed.
• eth_getLogs: Fetches logs matching specific criteria. While new logs are constantly generated, historical logs for a specific block range and topics are static.
• eth_blockNumber: Returns the current block number. This value updates with every new block.
• eth_chainId: Returns the chain ID. This is a static value for a given network.

For these methods, if the request parameters (e.g., contract address, function signature, block number, topics) are identical, the response will also be identical, assuming the underlying blockchain state hasn't changed relevant to the query. This characteristic allows for caching.

Non-Cacheable State-Changing Methods

Methods that alter the blockchain state, such as eth_sendRawTransaction or eth_sendTransaction, are inherently non-cacheable. Each transaction is unique, and its outcome depends on the current state and network conditions at the time of inclusion. Attempting to cache or proxy these would lead to incorrect behavior and potential security risks.

Tailoring Cache Lifespans with TTL

Effective caching requires a TTL (Time-To-Live) strategy tailored to each RPC method. A TTL defines how long a cached response is considered valid before it must be re-fetched. For eth_chainId, the TTL can be effectively infinite, as the chain ID does not change. For eth_blockNumber, the TTL should be very short, perhaps just a few seconds, reflecting the rapid pace of new block finalization. For eth_getBalance or eth_call, a TTL might be tied to the current block number, invalidating the cache when a new block is mined, or set based on the application's tolerance for slightly stale data. The goal is to maximize cache hits while ensuring data freshness appropriate for the specific query.

The Challenge of Unoptimized RPC Interactions

Many teams today manage their Ethereum RPC interactions by directly querying their chosen RPC providers. This straightforward approach, while simple to implement initially, often leads to significant inefficiencies, particularly when dealing with repeated read-only calls. Each redundant eth_call or eth_getBalance request incurs a full network round-trip and consumes resources from the RPC provider, which can contribute to higher operational costs and more frequent encounters with rate limits.

Some developers implement client-side caching within their applications. While this can reduce redundant calls from a single client, it doesn't aggregate requests across multiple users or backend services, nor does it offer a centralized solution for shared data. Other teams might attempt to build custom, in-house caching proxies. These solutions, while offering greater control, demand substantial engineering effort for development, deployment, and ongoing maintenance. This diverts valuable resources that could otherwise be focused on core product features, and introduces additional infrastructure complexity and potential points of failure.

This is exactly the kind of problem NodeCache is built to solve.

Introducing NodeCache: Purpose-Built Caching for Ethereum Mainnet

NodeCache addresses the challenge of redundant Ethereum RPC calls by providing a dedicated caching layer. It functions as an EVM RPC caching layer specifically designed for read-only JSON-RPC calls. This includes methods like eth_call, eth_getBalance, eth_getCode, eth_getLogs, eth_blockNumber, and eth_chainId.

NodeCache caches responses per-method, applying a method-appropriate TTL to ensure data freshness for repeated queries. This means that common, repeated queries for static or slowly changing blockchain data are served directly from the cache, rather than forwarding them to the upstream RPC provider. NodeCache supports Ethereum mainnet today. It's important to note that NodeCache does not proxy or cache state-changing methods, such as transactions.

By intelligently caching these read-only calls, NodeCache provides a dedicated caching layer that intercepts repeated queries and serves them from its cache, rather than forwarding them to the upstream RPC provider.

By leveraging a purpose-built caching layer, NodeCache handles repeated queries for read-only requests by serving them from its cache, rather than forwarding them to the upstream RPC provider.

Frequently Asked Questions

What types of Ethereum RPC calls are suitable for caching?

Read-only methods such as eth_call, eth_getBalance, eth_getCode, eth_getLogs, eth_blockNumber, and eth_chainId are suitable for caching. Their responses are deterministic for a given state and parameters.

Why are state-changing methods not cacheable?

Methods that alter the blockchain state, like eth_sendRawTransaction, are not cacheable because each transaction is unique and its outcome depends on current network conditions. Caching them would lead to incorrect behavior.

How does NodeCache optimize Ethereum RPC interactions?

NodeCache provides a dedicated caching layer for read-only JSON-RPC calls. It serves repeated queries directly from its cache, rather than forwarding them to the upstream RPC provider.