feat: add anvil_dumpState/anvil_loadState
#476
Conversation
| /// # Returns | ||
| /// Buffer representing the chain state. | ||
| #[rpc(name = "anvil_dumpState")] | ||
| fn dump_state(&self, preserve_historical_states: Option<bool>) -> RpcResult<Bytes>; |
There was a problem hiding this comment.
How does it interact with forked networks? I assume that load_state will not work on forked network because the state is not empty (or will it?), but if that's the case should we support dump_state at all?
There was a problem hiding this comment.
It will work assuming you are using the same fork for both instances. This is actually a pretty important use case as this feature will be used for CLI options to automatically dump/load state to a local file in intervals of time (see anvil's --dump-state/--load-state/--state/--state-interval) and we shouldn't prohibit using forks with it.
That being said I did not design any fail-safe mechanism for using a different fork. Writing the fork state could be an option but only the user would know if two forks are really the same (URLs can change).
What 💻
Closes #418
Ditto. Required making
TransactionResultserializable so unfortunately touches some seemingly unrelated VM stuff. Had to drop some non-serializable VM structs from state which honestly simplified logic a little bit.Why ✋
Anvil feature parity