-
Notifications
You must be signed in to change notification settings - Fork 32
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
Comments
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
I'm of the same opinion. I had issues with events and other things with |
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. |
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?
The text was updated successfully, but these errors were encountered: