[feelix]

I'm far from an expert on this, you probably know better than I do, but wouldn't forking the blockchain at the block height you're interested in with Ganache and execute it there be enough? or is the issue the transaction queue?

[vmception]

yes and that is very resource intensive as you have to do it rapidly and continually

you still need to know what markets and contracts you are targeting and with that variables

[feelix]

I'm curious about exploring this myself, would you mind explaining in more detail what is lacking after forking the main net with ganache?

Is it that you need a high powered server to fork it continuously, and that smart contracts tend to cost a lot to execute, or is there more to it than that? I don't understand what contracts and variables that you're targeting won't be included with the solution we're discussing

[vmception]

You need an archival node to store all the states and also monitor unconfirmed transactions. The primary client go-ethereum (geth) creates archival nodes that grow 1 terabyte per year (7tb now).

Despite archival nodes not being needed for consensus, some people’s kneejerk response is that this means Ethereum is not sustainable, but really geth just has unoptimal coding.

There are other clients out there that have chosen different data structures and reduced this by an order of magnitude. Turbo-geth, for example can sync an archival nodes at 1tb and is working on other improvements.

There is more support for geth at the moment but this is also an area of development if you want to improve upon.

Its likely many nodes out there are using their own optimizations and are not offered to the community.