Bella-DeFinTech / uniswap-v3-simulator

the "Tuner", a Uniswap V3 Simulator
https://docs.bella.fi/
Other
144 stars 45 forks source link

Retrieving Swap / Event from Highest Volume Pools #65

Closed Colinr98 closed 2 years ago

Colinr98 commented 2 years ago

Hi, first of all i want to thank the developers of this project for making this fantastic backtester publicly available. I was in the process of implementing a very similar approach in Python before i discovered this project and you all have saved me so much time.

My problem is that requesting liquidity events / swap data from the highest volume pools (e.g. WETH-USDC-500) is taking an unreasonable amount of time (weeks). I am aware of the slow speed of the EVM but i am curious what approach the development team plans to take for high-volume pools such as this. I saw that you mentioned the possible future implementation of the subgraph, but what was the original reason for using the EVM instead of the subgraph?

Also, i would love to know what EVM node option people are utilizing. I am currently using Alchemy, but after anywhere from one to three hours of install/updating events/swaps i run into "bad-response" or "missing-response" server errors (changing batch size doesn't seem to fix this). If anyone has suggestions for faster or more reliable nodes i would really appreciate it.

kafeikui commented 2 years ago

Hi @Colinr98 , thanks for the interest in our tool!

What you mentioned is indeed a tricky problem we are facing. As you can see we checked in an example of events data(WETH-USDC-3000, of a high volume) to the repo and it took 4-5 hours(using Alchemy, from AWS EC2) to download it from the scratch, and every time we update it the number is rising.

We did notice the Graph before but it seems that Uniswap v3 Subgraph is a hosted service and there is no guarantee or even detailed explanation on queries. At that time we were worried about the quality of subgraph but obviously the slow speed of EVM as you said is a bigger problem.

Thanks for the inputs you offered, recently we added the subgraph as datasource of events and I believe it can save at least 75% time spending on downloading than from RPC. #66 Although some network error like 502 bad gateway may happen during a lot of data requests, it's much faster than RPC and we got less errors so this is more acceptable to me.

About EVM node option we tried Infura as well as Alchemy and it seems the latter is better. We took the GROWTH plan but perhaps it's not good enough especially for high volume pools.

After merging #66 we will release a new version of package in npm. Have a try and please let me know if you have any questions. Thanks again!