One of the challenges with supporting Polygon was the sheer size of the Flume database. Fully indexed with a complete history from the genesis block to present, the logs, blocks, and transactions from Polygon occupy a whopping 6TB at the time of this writing. That makes running a full scale Flume server a computationally intensive proposition. The disk costs are substantial, and the time it takes to scale up additional servers (which have to download a copy of the database) become many hours.

But some of the most common calls we handle at Rivet are:

• eth_getBlockByNumber (usually to get the latest block)
• eth_getTransactionByHash (often to see if a pending transaction has confirmed yet)
• eth_gasPrice (to pick a gas price for a new transaction)
• eth_feeHistory (another way to pick a gas price for a new transaction)

And it turns out that about 95% of the transactions that are handled by Flume are querying information from the last 30 minutes or so worth of blocks.

So we created Flume Light. Flume Light is a new mode of operation for Flume. Flume Light starts up with an empty database, and rather than syncing from block 0 (which can take weeks to sync from an empty database up to current), it starts syncing from about 30 minutes back, then continues syncing with the blockchain.

When requests come in Flume Light checks its database to see if it can respond to that query. If it has all of the required information it handles the request from its local database. If any information required for the request is missing, it delegates the request to a more capable server. At Rivet, this means sending the request to a Flume server with the full database, though if you wanted to run Flume light yourself you could set a Geth server (or other execution client) to be the fallback server.

The net effect is that the most common requests that Flume handles are now handled by servers that are much cheaper to operate and much faster to scale.