feat: implement quicknode geth vs reth output comparison

[jsy1218]

Paradigm RETH just released production read 1.0.0. QuickNode is ready for us to consume the production-ready dedicated RETH cluster as well. From Uniswap perspective, the migration from GETH to RETH boils to two considerations:

1. Can we rely on the RPC provider to do automatic failover for us? Meanwhile QuickNode could, Uniswap has no way to know when that happens. Also RETH is newly productionized, it's better if the clients do the output comparisons ourselves. Hence this PR aims to compare the GETH vs RETH RPC responses ourselves.
2. Can we confidently live migrate from GETH to RETH at Uniswap scale? Since RETH is only ready on L1, we are only speaking the Uniswap RPC volume on L1:
   a. eth_call is about 1.4k RPS
   b. eth_getBlockNumber is about 345 RPS
   c. ethers js v5.5 style send, which can be eth_call/eth_getBlockNumber/eth_feeHistory/eth_estimateGas RPC. Those calls are in additional to the RPC calls in (a) and (b):

We have done the Perf testing using the Paradigm Flood, at above mentioned scale, and can see QuickNode RETH can cut QuickNode GETH latencies by half in P50, P90, and P99:

With this perf testing, we will implement a live migration in a separate PR, such that it allows us to migrate from GETH to RETH at designated percent as we want, i.e. 100% GETH 0% RETH -> 99% GETH 1% RETH -> 95% GETH 5% RETH -> ... -> 0% GETH 100% RETH.

Client output comparison implementation correctness wise, I've covered with complete unit test coverage, as well as run npm run test:e2e against my local AWS routing-api endpoint:

Due to low traffic volume, I can only verify the basic RPC outputs matching on my local. I will have to merge to prod to see the comparison at a subset of prod traffic volume (sampling at 5%).

[jsy1218]

• feat: implement quicknode geth vs reth output comparison #775 👈
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @jsy1218 and the rest of your teammates on Graphite

[graphite-app]

Graphite Automations

"Request reviewers once CI passes on routing-api repo" took an action on this PR • (07/02/24)

6 reviewers were added and 1 assignee was added to this PR based on 's automation.

[cgkol]

lets do it!

[mikeki]

Early comments/questions

[xrsv]

@jsy1218 just curious what are the benefits switching to RETH? is it supposed to be faster?

[jsy1218]

@jsy1218 just curious what are the benefits switching to RETH? is it supposed to be faster?

@xrsv Short-term, we benefit from a faster quote (presumably RETH output has the same correctness as GETH). Long-term, the entire ethereum ecosystem benefit from a higher throughput, better performance for full/archive node syncing, better client diversity from GETH, etc. I see Uniswap switching from GETH to RETH for high up-time full-node use case will bring positive effect to those long-term benefits overtime.

[jsy1218]

@mikeki @cgkol I'm going to merge this PR, as I've written the complete unit test coverage. I'm slightly uncertain about the ethers v5.5 style send output comparison, hence I want to ship to prod, and see if there's any unexpected output mismatch, due to any implementation glitch in this PR.