T4 · What Is RPC?

A Real-World Problem

A DApp that worked perfectly on your computer begins behaving strangely three days after launch.

• A user sees a zero balance on page load, but the right value after refreshing several times.
• Another user sees missing transaction history that reappears the next day.
• Every test you run looks normal.

You inspect logs and find many 429 responses, then timeouts. Further down, one response reports a block height lower than a response from five minutes earlier.

Then you realize: **your code has never touched a blockchain directly.**It talks to an HTTP endpoint—a service you did not write, deploy, or monitor, whose logs you cannot inspect when it fails.

Who is behind that endpoint? Why should it have the data? When might it stop answering? How would you know if its answer were wrong?

Thought Experiment

Imagine building a reporting system on a read-only database replica. You are told five things about the replica:

1. **It rate-limits.**Beyond some query rate it refuses requests, and queries have different "weights": fetching one row and scanning ten million rows may consume hundreds of times different quotas.
2. **It may lag.**There is no guarantee when a primary write reaches the replica. Two consecutive requests can make the second look older if a load balancer sends you to another machine.
3. It may lack history.To save disk, it retains only recent data. Asking for older data producesan opaque error, not an empty result.
4. **It may return false data.**Nothing inherently prevents that. You receive JSON but cannot judge its truth from the JSON alone.
5. **You do not operate it.**If it goes down, you wait.

Ask yourself: can you still make a reliable reporting system under these conditions?

Yes, but your architecture must handle all five explicitly: backoff and queuing for limits; monotonic checks for lag; known boundaries for missing history; cross-checks for false data; backup sources when the operator is unavailable.

Those five concerns are the whole chapter.

Replace "read-only replica" with "RPC endpoint" and every point still applies. The only difference is that the database replica might at least belong to your company; the endpoint may not.

Your Decision

You must choose an RPC setup for a product about to launch.

What Happens

The options differ on five dimensions:

Of these five, trust is the only dimension that money alone cannot solve.

The rest are trade-offs: buy more quota, buy archive access, or spend staff time on your node. But no matter how much you pay, "how do I know this JSON is true?" has the same answer: you do not, unless you verify it.

The key fact about RPC is this: **using a third-party RPC means trusting the data it returns.**At that point, the endpoint puts a ceiling on how decentralized your product really is.

Build a Model

The path a request really takes:

Three dimensions that limit your product:

1. Rate limits.Think of them as computational quotas, not simply "requests per second." Reading one balance and scanning a million blocks of logs may consume very different amounts. Usage therefore depends less on user count than onwhich methods you call.

Optimize by narrowing log ranges, combining batch queries, and caching stable data. T15 covers the cache layer.

**2. Data depth.**Nodes vary: some retain only recent state; some retain all blocks but prune old state; archive nodes retain complete state at every historical height.

A balance or storage query at an old height fails on the first two rather than returning empty. The error message often looks nothing like "historical data unavailable", so first-time users mistake it for a bad parameter.

**3. Consistency.**Two instances may have different latest heights at the same time, and the chain tip can reorganize. Two consequences follow:

• Repeating the same logical request can return older state the second time.
• Data read at "latest" may disappear seconds later.

Handle this with explicit block tags rather than always asking for "latest":

**Practical rule: any process whose result must match on a second run should pin a block height instead of using latest.**An indexer built against latest is not replayable; when it fails, you cannot even reproduce its input.

What your Provider wrapper should provide:

The last two turn "multiple backends" into actual resilience. With only the first four, you have load balancing; with all six, you address trust.

What It Is Called

Hands-on

for i in $(seq 1 10); do
  curl -s -o /dev/null -w '%{time_total}\n' -X POST <endpoint-A> \
    -H 'content-type: application/json' \
    -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'
done

curl -s -X POST <endpoint-A> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBalance",
       "params":["<any-active-address>","0x<very-old-block-height>"]}'

curl -s -X POST <endpoint-A> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getLogs","params":[{
        "fromBlock":"0x...","toBlock":"0x...",
        "address":"<active-token-contract-address>"}]}'

AI Lab

Step one:
Write an RPC Provider wrapper with multiple backend endpoints, timeouts,
failed-request retries with exponential backoff, method-based routing
(archive methods to a designated endpoint), and a circuit breaker.
Use my chosen language and no third-party libraries I did not request.

Step two:
Assume a replayable indexer uses this wrapper.
List every situation in which your implementation could return inconsistent results that look normal.
Propose a fix for each one.

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check