Reducing Slow Dapp Loading Due to RPC Calls with Effective Caching

Slow dapp loading due to RPC calls often stems from the repetitive nature of read-only Ethereum RPC requests like eth_call, eth_getBalance, and eth_getLogs for data that remains unchanged. This article explores why these calls are so frequently repeated and how a dedicated caching layer can address this.

Understanding Cacheable vs. Non-Cacheable RPC Calls

Not all Ethereum RPC calls are suitable for caching. The key distinction lies between read-only methods and those that alter blockchain state. Read-only methods, which simply query data without initiating transactions, are prime candidates for caching. These include:

• eth_call: For simulating contract execution and querying state.
• eth_getBalance: To retrieve the balance of an account.
• eth_getCode: To get the code of a contract at a specific address.
• eth_getLogs: For fetching event logs.
• eth_blockNumber: To get the current block number.
• eth_chainId: To retrieve the current chain ID.

These methods return data that, depending on the specific query and block number, can remain static for periods ranging from seconds to indefinitely. Caching responses for these methods, especially when querying historical data, significantly reduces redundant calls. A method-appropriate Time-To-Live (TTL) is crucial here, defining how long a cached response remains valid. For instance, eth_blockNumber might have a short TTL, while eth_getCode for a deployed contract might have a very long or even infinite TTL if the address is known to be immutable.

Conversely, state-changing methods, primarily transaction-related calls such as eth_sendRawTransaction or eth_sendTransaction, are inherently non-cacheable. These methods modify the blockchain state, and their responses are unique to each invocation, making caching inappropriate.

The Cost of Redundancy: How Teams Handle RPC Today

Without a dedicated caching layer, development teams typically interact directly with their RPC providers. This often means every eth_call or eth_getBalance request, even for identical parameters and unchanged data, results in a new network round-trip to the RPC endpoint. This approach incurs several tradeoffs:

• Repeated Provider Costs: Each redundant request contributes to the overall usage count, which directly impacts billing from RPC providers.
• Increased Latency: Every request must traverse the network, adding latency to dapp interactions, contributing to slow dapp loading.
• Rate Limit Throttling: Frequent, identical requests can quickly exhaust provider rate limits, leading to throttled requests and service interruptions for dapps.
• Manual Workarounds: Teams might attempt to implement basic in-application caching, but this is often ad-hoc, difficult to maintain, and lacks the specialized logic for method-appropriate TTLs across a range of RPC calls.

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

NodeCache: Optimizing Ethereum RPC Interactions

NodeCache is an EVM RPC caching layer for read-only JSON-RPC calls on Ethereum mainnet. It caches responses for methods like eth_call, eth_getBalance, eth_getCode, eth_getLogs, eth_blockNumber, and eth_chainId.

NodeCache operates by caching responses per-method, applying a method-appropriate TTL to manage how long a cached response remains valid. This means that if your application repeatedly requests the same balance for an account or the same contract code, NodeCache can provide a cached response, reducing the need to query the upstream RPC provider again. It does not proxy or cache state-changing methods.

By deploying NodeCache, developers can utilize cached responses for repeated read-only RPC requests on Ethereum mainnet.

Implementing an RPC caching layer is a strategic step for any Ethereum developer or infrastructure engineer. NodeCache provides a specialized solution for caching responses to read-only RPC calls on Ethereum mainnet.

Frequently Asked Questions

Which Ethereum RPC calls can be cached?

Read-only Ethereum RPC methods such as eth_call, eth_getBalance, eth_getCode, eth_getLogs, eth_blockNumber, and eth_chainId are suitable for caching.

Why is caching important for read-only RPC calls?

Caching read-only RPC calls is important to avoid redundant requests for data that has not changed, which can otherwise lead to repeated billing and increased network latency.

Does caching apply to all Ethereum RPC methods?

No, caching applies only to read-only methods. State-changing methods, such as those related to transactions, are not cached.

What is a method-appropriate TTL?

A method-appropriate TTL (Time-To-Live) is a configurable duration that determines how long a cached response for a specific RPC method remains valid, managing data validity based on the volatility of the queried data.