ethnode icon indicating copy to clipboard operation
ethnode copied to clipboard

[feature request] forking mode

Open BlinkyStitt opened this issue 4 years ago • 2 comments

ganache-cli has a really helpful --fork flag that uses mainnet state as the starting point. This is essentially necessary for testing multiple defi projects together. However, it has some bugs in how it handles delegatecalls and clearing storage (https://github.com/trufflesuite/ganache-core/issues/797).

It would be awesome if geth could handle this itself, but they closed my issue saying that they'd prefer ganache handle it. https://github.com/ethereum/go-ethereum/issues/21224.

I understand ethereum's decision to have multiple clients, but I think having the development clients separate from the production clients is guaranteed to cause problems (just like the 6 or so I've been dealing with). Having my tests use a production client would make me much more comfortable in my test results.

Do you think this is something that ethnode can help with?

BlinkyStitt avatar Mar 12 '21 23:03 BlinkyStitt

Related: #10

That would be a really useful feature, I'm just concerned about the feasibility. HardHat allows forking mainnet and exposes some cool features like pinning a block and impersonating an account. They use alchemy under the hood, and AFAIK it requires syncing the node.

Do you have any suggestion on how this can be implemented or how it can work with ethnode? I'm a bit lost :thinking:

I understand ethereum's decision to have multiple clients, but I think having the development clients separate from the production clients is guaranteed to cause problems (just like the 6 or so I've been dealing with). Having my tests use a production client would make me much more comfortable in my test results.

I'm of the same opinion. I had issues with events and other things with ganache-cli, and that was my main reason to use a production node with a development configuration :)

vrde avatar Mar 26 '21 14:03 vrde

Maybe to push this issue forward, it's helpful to discuss how you'd go about implementing it.

Say a mainnet contract is self contained, I believe a download of its storage using eth_getStorageAt could be an easy way of replicating the contract locally.

But what about a contract with a state that's connected to e.g. another contract and so on? Suddenly, to replicate mainnet state we'd have to start download megabytes of data from multiple contracts. Things would get real tricky.

Another option that doesn't involve downloading storage is downloading all relevant transactions from mainnet and replaying them on the local network. Though here, too, the complexity comes from having to determine which transactions to download.

Are there tools that can build a transaction graph for a given state of a contract at a block?

I agree with what was said above: Local state replication is useful (not only while testing). State replication should be decoupled from eth tooling. A tool that e.g. gave me all tx for a storage address at a block height may be just what we want.

TimDaub avatar May 16 '21 15:05 TimDaub