Most people run “op-geth”, the traditional flavor of execution-layer nodes for OP Stack chains. Recently “op-erigon” was announced, which can speed up indexing and increase client diversity.
This is an exciting development for the OP Stack ecosystem. Not just for client diversity, which is a crucial protection of decentralisation, hedging against threats like client failures and vulnerabilities. A lesser known advantage of Erigon, is that it offers unique tools for developers with its many optimizations and unique RPC methods.
At Basement we do a lot of indexing, that comes with the occasional deep-dive into execution layer nodes to understand and optimise against slow RPC calls. One of the biggest inefficiencies we found, is getting all receipts for a block.
Logs and transaction result-data are not stored on disk, as your node’s database would simply become too large. To retrieve the result data in these logs, an EVM is spinned up, and transactions are re-executed against a block’s state.
Getting all logs in a block becomes a tricky business. Here’s how indexing all transactions and logs for a block works on geth:
Call eth_getBlockByNumber and retrieve all input data, as well as every transaction hash.
For every hash, we call eth_getTransactionReceipt
for which geth spins up an EVM, and executes every transaction until the matching transaction.
Once we have the state of the preceding transaction, we can execute the transaction whose hash we provided, and get its result state.
Store this indexed data in our database.
If you paid attention in your computerscience class, you’d recognise an inefficient N+1 problem here. This is wasting precious CPU time on your node’s machines, and can result in latency on your RPC API.
Erigon exposes a better approach for indexing, with the eth_getBlockReceipts method. Under the hood, this method spins up an EVM once, executes the entire block and returns the block’s result data in its entirety.
And it’s not just for transactions receipts. Erigon is a more efficient tool for plenty of indexing needs, we use trace_block extensively to get trace data in one go, without having to deal with multiple roundtrips and large batch requests.
Lastly, Erigon is designed to be modular: its RPC server is run in a seperate daemon. This means you can add the methods you really need for your custom use-case, without having to touch the daunting execution-layer part of the codebase.
In Basement’s infrastructure we keep a copy of every transaction, so you can query this data through our SQL and GraphQL tools.
We also offer a service to stream data from your chain to any data-warehouse you’d like. By keeping a copy of onchain data, we can decode historical data at speeds unlike any other indexer, giving your developers the low latency they expect
Result data such as gas usage and contract creation can be important metrics for your chain’s usage, helping your team to make informed decisions about the design of your chain.
The resulting logs of a transaction are also the place where important interactions are tracked, such as NFT transfers, approvals and other contract interactions.
You can learn more about the op-erigon project on GitHub, where there is an excellent guide in its readme for setting up a node.
Don't want to deal with these devops and indexing hassles yourself? The team at Basement is building Stack, a modular and customizable data platform for your L2. We’re actively onboarding new chains, and would love to get you set-up on Basement today.
Don’t hesitate to shoot us a message on:
Email: founders@basementapp.xyx
Twitter/X: @basementapp_xyz
Or plan a demo with our engineers: https://calendly.com/nickvernij/basement