How Goldsky Reduced RPC Requests by 50% for Faster Blockchain Indexing

Web3 developers require reliable, fast, and cost-efficient access to blockchain transaction data to build the next generation of applications. Goldsky’s industry-leading architecture employs several technical approaches to make blockchain indexing faster, more efficient, and optimized for existing data stacks.

Goldsky’s RPC (remote procedure call) load balancer is a key component of our indexing infrastructure. By leveraging multiple RPC providers to retrieve live blockchain data, Goldsky enables efficient access to realtime transactions while keeping the system resilient, performant, and cost-effective.

The Benefits of RPC Load Balancing

Goldsky’s RPC load balancer utilizes intelligent failovers whenever our RPC providers experience issues. This allows Goldsky to stay at the edge of the blockchain and continue to reliably stream live data.

Recently, we enhanced our RPC load balancer with a serverless cache using Momento which allowed us to reduce the number of outgoing RPC requests our load balancer makes by more than half, while also improving p50 request latency by 75%.

Our recent implementation of Firehose greatly reduced our reliance on RPC providers, but for architectural reasons, the Graph Node still uses RPCs for chain head updates. Implementing serverless caching into our RPC load balancer allows us to more efficiently call RPC providers when we need them.

Caching + TTL = Graceful Reorgs

One of the challenges of implementing a caching layer into our RPC load balancer is handling blockchain reorgs. The blocks at the edge of the chain are not immutable, so our caching layer needs to account for these scenarios properly.

Our key insight was to add a TTL (time to live) for each cached RPC response equal to half of the block time for a given chain. For example, Ethereum mainnet has a block time of 12 seconds, so the TTL for cached RPC responses is 6 seconds. Polygon mainnet has a block time of 2 seconds, so the TTL for cached Polygon RPC responses is 1 second. This TTL ensures that even if a reorg happens, the cached response will be invalidated at most within 2 blocks.

As an edge case example, suppose that our RPC load balancer serves and caches a mainnet block a time t-ε. Suppose at time t mainnet reorgs and that at time t+12 (because the block time is 12 seconds) a new block is minted. From time t-ε to t-ε+6 our cache will serve incorrect information to the Graph Node. However, as soon as the Graph Node makes an RPC request after t-ε+6 it will see and gracefully handle the reorg that happened at time t. This also means that when The Graph requests the new block at t+12 it will see and handle the reorg that happened at time t. Even though our RPC layer can serve invalid information to The Graph due to the nature of how blocks propagate through the network, indexing speeds aren’t impacted because stale information will not be served for more than 1 block and more often than not we serve valid data from the cache instead of relying on an external RPC service.

At Goldsky, our goal is to provide developers with the fastest, most efficient access to blockchain data. Innovative features like serverless caching and load balancing are just a few ways we’re making that a reality.

Be sure to follow us on Twitter for the latest feature releases and product updates.