Cached Blockchain Data vs Direct Node Access: Understanding the Tradeoff

Intro

Blockchain nodes are the access point between users, applications, and a blockchain network. When a user or application interacts with a blockchain, it does so through a node using RPC requests. At a simple level, a node does two things: it reads data from blockchain networks and can submit transactions to the network too. Reading means asking the blockchain for information: a wallet’s ETH balance, a transaction’s status, the latest block, and a token balance. Nothing changes on-chain. Writing means submitting a transaction: sending ETH, swapping tokens, staking, or calling a contract function that changes state. Write requests are ultimately submitted to the network. Read requests can be answered in more than one way, and that is where the difference between direct node access and cached or indexed data becomes an important nuance.

The Direct Node Model

A blockchain node keeps a local, synced view of the chain. When a user asks for a balance, a receipt, or a block number, the node checks the state it has independently received, verified, and stored, and returns the answer. The request path is simple: user → node → response.

There are a few layers between the user and the blockchain.

The Cached and Indexed Provider Model

Many large RPC providers add systems on top of their nodes to improve speed and scale. For read-heavy workloads, a request may be served from a cache, an indexed database, or another pre-processed layer rather than by a node every time. When a new block arrives the provider’s node receives it, an indexing system extracts the transactions, logs, token transfers, and contract events, and the provider updates its database so future requests can be fulfilled faster. This is positive and does not increase risks for most blockchain applications.

Why Caching is Faster

A simple analogy between a caching system and querying a node: someone asks, “What is Malta’s capital?” You could open a book, find Malta, and read the answer, or you could already know it and reply immediately: Valletta. Caching is the second option. The system stores commonly requested information, so repeated questions get quicker answers.

In blockchain terms, caching improves performance in three ways:

1. The answer may already be stored, so popular data like the latest blocks, major token contracts, and historical transactions are served instantly at scale.
2. The data may be reorganized into structures that are easier to search than raw chain data.
3. And the node does less work, because the cache layer absorbs common read requests instead of passing every one through.

Cached data is, in most cases, correct and reliable, as it is copied from real blockchain nodes and, at professional providers, updated continuously. The blockchain remains the source of truth; the cache is a copy of that truth, optimized for speed.

An additional consideration is that different data requires different update patterns. Some data is updated every block, as the indexer processes each new block on arrival. Some is cached on demand: a user asks for a balance, the provider fetches it and stores the result briefly in case the same request repeats. Fast-changing data may refresh every few seconds or near real-time. Historical data like old blocks, finalized transactions, and past logs can be stored long-term, because once data is old and finalized enough, it does not change.

Measurements and Methodology: How We Made Ethereum's Slowest Queries 50x Faster

We ran some analysis on what the impact of caching is on latency, and the results show that Spectrum Nodes’ caching layer transforms some of Ethereum’s most computationally expensive RPC calls from multi-second node operations into near-instant reads.

In benchmarks conducted from Central Europe, we compared Spectrum’s cached Ethereum archive endpoints with a standard archive node running within the same infrastructure, using first-time client requests against randomly selected historical blocks.

• eth_getBlockReceipts improved from 2.4 seconds to 47 milliseconds, approximately 51 times faster
• debug_traceBlockByNumber fell from 1.9 seconds to 52 milliseconds, a 37x improvement.

The full distribution shows that Spectrum’s advantage is not limited to a better median: it makes heavy RPC performance dramatically more predictable.

Across roughly 30 randomly selected historical blocks per method, the standard archive node ranged greatly, from milliseconds to seconds, with substantial block-to-block variation. By contrast, Spectrum’s cached endpoint clustered tightly in the tens of milliseconds, returning 57 of the 59 requests in under 100 milliseconds.

These were first-time requests from the benchmark client to randomly selected historical blocks, but the corresponding results were already present in Spectrum’s server-side cache; they were therefore cache-hit measurements rather than cold-cache population times.

Only two cached responses exceeded 100 milliseconds, while many standard-node requests took seconds. For indexers, real time analytics systems, tracing pipelines and MEV infrastructure, this reduction in both latency and variance means faster processing, more stable throughput and less need to engineer around unpredictable archive-node response times.

The tradeoff: speed versus freshness

A cached answer may have been correct a few seconds ago, but no longer reflect the latest chain state. For example, a balance might have changed and the cache may be lagging the status update and thus would return a wrong value.

For a transaction from two years ago, that is irrelevant, and a cache is perfectly appropriate, but for time-sensitive work, seconds matter: checking a balance before submitting a transaction, monitoring liquidation risk, tracking pending transactions, reacting to new contract events, or reading the state immediately after another transaction lands.

In these situations, the question is not “Is the data eventually correct?” but “<u>Is the data absolutely correct right now?</u>”.

That is where direct node access has the advantage: the answer comes from the node’s current synced view rather than from a separate layer with its own update cycle.

The risks and limitations of cached data

The extra layers between the user and the node introduces several considerations:

• Stale data: If the chain state changes before the cache updates, the user gets an answer that is slightly behind the latest blockchain status.

• Lower Transparency: With a direct node, the model is simple: the node checks its state and answers. With a cached system, the answer may come from a database, an indexer, a regional replica, or some combination, and the user must trust that this internal pipeline is correct, up to date, and well maintained.

• Reorg Handling: A reorg happens when the blockchain replaces a temporarily accepted block with a different one. Providers must detect this and correct any indexed data built on the discarded block; until they do, cached results may reflect information included in an old block.

• Edge Cases: Queries that depend on very recent state, mempool visibility, pruning, archive availability, or contract behaviour at a specific block are situations in which “querying a node” and “querying a processed data layer” can return different results.

• Operational Dependency: The cache is another system that must be maintained, monitored, and secured, and it can fail independently. The node may be healthy while the indexing pipeline is delayed; the API may respond quickly while the answer lags the chain.

• Hacks: A direct RPC call is not immune to attacks, but it has a simpler trust boundary: the user is asking the node for the state it currently sees. A cached system adds more components where errors or manipulation can occur. Malicious actors may not need to compromise the node itself; they could target the caching layer to serve stale, incomplete, or incorrect responses while the underlying node remains healthy.

Spectrum Nodes Solution: How We Increased Output and Minimised Risks

Spectrum Nodes caching solution is a fault-tolerant RPC proxy with re-org-aware permanent caching, and accounts for most of the risks listed above by caching only historical data, instead of trying to correctly provide the most recent data. By following this approach, re-orgs and stale data risks are practically erased, as old blocks are not re-organised and the data has been definitely confirmed by the whole network.

The cache only holds one category of data: finalized historical blocks and everything derived from them: receipts, traces, block bodies. This is the data that is both the most expensive for a node to produce, and the only one that is guaranteed never to change. Once a block is finalized, the network cannot reorganize it, its receipts are fixed, and a trace of it will produce the same result today, next month, and in ten years. Caching it permanently carries no freshness risk, because there is nothing supposed to change.

Every piece of data that is not fully finalized is never served from the cache. Requests about the chain head (the latest block, current balance, pending state) pass through to the node itself and are answered from its live, synced view. In our testing, the cached endpoint tracked new blocks in step with the direct endpoint at every poll; there is no update cycle to lag behind, because for live data the cache is not in the request path at all.

Where direct node access matters most

Direct access matters most where freshness, transparency, and institution-grade reliability are requirements: transaction monitoring, latest balance and block tracking, recent contract state reads, validator operations, DeFi infrastructure, and security-sensitive applications where users cannot afford a stale or wrong state. This does not mean the direct model is free of operational demands though; nodes still need to be synced, monitored, updated, and scaled; a badly operated node is not better than a well-operated cache. But when node infrastructure is run correctly, direct access gives users a cleaner path to the chain.

From a security standpoint, the question is not only how fast a provider answers, but how much hidden infrastructure sits between the user and the source of truth, and how vulnerable that infrastructure is to downtime or hacks. Cache expiry logic, indexers, databases, regional replicas, and re-org handling can each be engineered well, but each adds complexity that must be trusted. A simpler request path is easier to understand, audit, and verify, and in security-sensitive environments, that simplicity has value.

Conclusion

Caching and indexing are important tools for making blockchain data faster to serve, easier to query, and easier to scale. For historical data, repeated reads, analytics, and high-volume workloads, they can be the right approach. Direct node access, however, offers a shorter and more transparent path to the chain, with stronger freshness guarantees for use cases that depend on the latest state.

The tradeoff is not simply “fast versus slow.” It is about choosing between optimized data delivery on one side, and freshness, safety, and reduced infrastructure dependency on the other. For users building systems where timing, accuracy, and trust minimisation matter, direct node access remains the cleaner connection to the source of truth.

Because both models have legitimate advantages, Spectrum Nodes will support both cached and direct node access (be it archived or pruned), supporting the modular vision of our platform.

Rather than deciding on behalf of users, Spectrum Nodes will start giving them the optionality to choose the setup that best matches their application, performance requirements, and trust assumptions.

For those unaware that this is an industry-wide standard, we recommend reviewing your protocol's risk profile to see if your foundational assumptions still hold up.