Ephemeral local fork mode

[banteg]

Rationale

A very common pattern (1, 2) for testing contract integrations is to run them against a forked mainnet environment using ganache-cli, hardhat or hevm. It would be useful to have this functionality built in the client itself as it would work much faster and would follow consensus rules more precisely.

Implementation

Similarly to rpcdaemon, a process could connect to the existing database, and maintain an ephemeral overlay database on top.

Additionally, it'll need to support ability to control chain state, advance time and unlock arbitrary accounts. Hardhat and ganache-cli use custom RPC methods and hevm uses cheat codes.

[AlexeyAkhunov]

Maintaining ephemeral database while still staying in sync with the mainnet is going to require opening a long-lived read-transaction, and cause a rapid database bloat. However, such ephemeral database would be possible if turbo-geth stopped being in sync with the mainnet and just "froze" itself. Then, only ephemeral part will grow, until it is discarded, at which point turbo-geth proceeds with catching up again

[AskAlexSharov]

@AlexeyAkhunov 1. We don’t need transaction if can use GetAsOf 2. Does this require writable ephemeral overlay?

[AlexeyAkhunov]

@AskAlexSharov As far as I understand, the overlay is indeed writable. Yes, I think you are right, we could use GetAsOf to create an appearance of a fork without a long-running read transaction

[kushalbabel]

Hi @AlexeyAkhunov @banteg @AskAlexSharov , was there any further discussion about supporting mainnet forks in the client? Or is it shelved for now?

[riordant]

Would also like to know if this is a planned feature. Existing fork modes are comparatively very slow.

[mandrigin]

@AlexeyAkhunov @banteg

such ephemeral database would be possible if turbo-geth stopped being in sync with the mainnet and just "froze" itself

isn't that how existing forks work? they freeze the DB, sync tx pool and mine on their own.

[mandrigin]

I agree it could be a very cool feature, if we can piggy-back on our dev network

[AskAlexSharov]

@mandrigin FYI:

1. our mining now doesn't use dbRwTransaction, it using only "mutation" object. FunnyGiulio worked on this feature.
   Maybe 1. can be used for this feature (if don't need store ephemeral fork in db

[mandrigin]

could be, @banteg do you need this to be persistent across Erigon launches?

[beejiujitsu]

+1 this would be helpful.

At least from my limited point of view, stateless ephemeral forks would be a good first step.

[sambacha]

+1 this would be helpful.

At least from my limited point of view, stateless ephemeral forks would be a good first step.

This is the only viable method in reality.

[naddison36]

This would be a fantastic feature. Tools like tx2uml require transaction traces like traceTransaction and debug_traceTransaction.
For value transfer diagrams, tx2uml uses debug_traceTransaction with a custom EVM tracer. This is not currently supported by Foundry's Anvil, Hardhat or Ganache. Ideally, Erigon could be run in fork mode locally and transaction traces run against the local node.

[github-actions]

This issue is stale because it has been open for 40 days with no activity. Remove stale label or comment, or this will be closed in 7 days.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.