At merkle, we consume hundreds of millions of RPC requests every month just to service our products (Private mempool, Transaction network). Using regular RPC providers such as Alchemy made our bill go through the roof. It became clear that in order to scale, we needed to run our own nodes. But because we are a small team, we needed to find a way to run nodes that are cheap, fast and reliable.
What is reth
- Must faster sync time
- Much lower disk usage for archive node (~3TB as of today)
- Much higher RPC concurrent requests capacity
What is eth.merkle.io
eth.merkle.io is our 100% free, unlimited rpc service, backed by reth nodes. Our goal is to provide a free, reliable and fast RPC service to the community while helping the reth team fix performance issues.
How we setup reth
Running reth in production is somewhat easy, but there are a few things to keep in mind:
- reth is still in beta, so expect some bugs
- reth might have some discrepancies with response types
- reth might crash (although it has never happened to us)
Just to be safe, we have setup geth nodes as backups, if the reth nodes ever crash.
The following results come from production data from eth.merkle.io and data from internal usage. The results shown here are response times as measured by our custom load balancer.
Most of the rpc methods in reth have similar response times as geth, but there are a few exceptions.
When we started running reth, we noticed that
eth_getGasPrice was unusually slow:
This issue was reported to the reth team and promptly fixed in #5050. Leading to similar response times as geth:
We also noticed that
eth_getLogs was unusually slow:
Unfortunately, this issue is not solved yet, as it requires the implementation of log indexing #4167.
reth is a great node, but it's still in beta and not a good fit if you are heavily reliant on
eth_getLogs. We are continuing to help the reth team fix performance issue. If you want to help, plug eth.merkle.io in your dapp/wallet and we'll report any issues we find to the reth team.