feature: RPC Caching about checkthechain

[sslivkoff]

fully agreed. nearly all historical queries would be significantly optimized by this type of cache, at least in the case of using a remote archive node as you mention. ive actually been planning out how to implement this type of cache for a while now, and spending a lot of time on db infra to make it easy+robust to integrate supplementary caches

i have a pretty good idea of how the first pass will look but there remain a few implementation questions:

• what will the exact db schema look like?
• how to designate which contracts and/or functions should have their outputs cached? or should all outputs be cached indiscriminately?
• ctc already has a custom caching system for many protocols. should this new caching system replace those systems, or should it be disabled for those protocols?

package-wise, this cache will exist above rpc in the evm module. this will keep the rpc client lean and robust

[rafaelugolini]

1. I will need to dig deeper into the code to suggest something meaningful but I would say it should be at the lowest level.
2. I would prefer that everything is cached indiscriminately and you could flag something like no_cache=True in some cases.
3. If the implementation is at the lowest level, the apps above should only benefit from it and not even be aware of it

What about starting to implement cache with decorators in some specific functions on rpc or evm?

[sslivkoff]

(2) I agree with this for the default setting. and once an alpha version is ready it will become more obvious whether this is a good idea. if some things need to be excluded for performance/storage reasons then we could come up with some exclusion heuristics and add in some configurability

(3) the way things are designed so far is that ctc.evm has the high level functions that end users should be using, and ctc.rpc + ctc.db have low level functions only needed by advanced users. keeping rpc client separate from the db cache simplifies implementation of each and keeps things more modular. for now end users still have to do certain things like eth_call's using rpc, but for most things like events/blocks/txs and various other datatypes, users can stick to evm. apps built on top of ctc should generally use evm unless theyre doing advanced stuff. evm could have other backends besides rpc in the future like bigquery/thegraph/others. so for example if you want data of a transaction and you don't care where it comes from, you would use evm. rpc is for when you are specifically interested in using an rpc client to obtain the data

at least that is the intention behind how things have been built so far. open to suggestions.

for the currently existing caches in ctc, some would probably be made obsolete by a generic eth_call cache, whereas others would still be faster with their current bespoke solutions. and if the bespoke solution is faster, it could be even faster to keep the generic cache disabled for those calls. but a lot of this is empirical and unknowable until it is actually tested irl

if you need a cache ASAP you could do it using something like toolcache:

from ctc import rpc
import toolcache


@toolcache.cache('disk')
async def get_code(address):
    return await rpc.async_eth_get_code(address)

(but this will use files on disk rather than a nice db so it won't have optimal performance)