Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature request] forking mode #17

Open
BlinkyStitt opened this issue Mar 12, 2021 · 2 comments
Open

[feature request] forking mode #17

BlinkyStitt opened this issue Mar 12, 2021 · 2 comments

Comments

@BlinkyStitt
Copy link

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 (trufflesuite/ganache#797).

It would be awesome if geth could handle this itself, but they closed my issue saying that they'd prefer ganache handle it. ethereum/go-ethereum#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?

@vrde
Copy link
Owner

vrde commented Mar 26, 2021

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 🤔

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 :)

@TimDaub
Copy link
Contributor

TimDaub commented May 16, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants