Implement forking support with lazy loading backend #426
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
2 tasks
dimartiro
changed the title
alindima
reviewed
Nov 24, 2025
crates/anvil-polkadot/src/substrate_node/lazy_loading/backend/mod.rs
Outdated
Show resolved
Hide resolved
dimartiro
force-pushed
the
forking-support
branch
from
52d3c29 to
04279c8
Compare
alindima
reviewed
Nov 25, 2025
alindima
reviewed
Nov 25, 2025
alindima
reviewed
Nov 25, 2025
alindima
reviewed
Nov 25, 2025
| /// Tests that forking preserves contract state from source chain and that multiple contract | ||
| /// instances maintain independent storage | ||
| #[tokio::test(flavor = "multi_thread")] | ||
| async fn test_fork_with_contract_deployment() { |
There was a problem hiding this comment.
not neccessarily for this PR, but have a look at what other forking-related test scenarios regular anvil has. We should mirror them where it makes sense
There was a problem hiding this comment.
as an example, what we discussed earlier in the call, using calls which mutate the state on top of a forked network (anvil_setBalance, etc)
Author
There was a problem hiding this comment.
But we are already doing that with test_fork_preserves_state_and_allows_modifications right?
There was a problem hiding this comment.
I'm talking about the RPCs that use node-side state mutation, so mutating the state without sending extrinsics (using the BackendWithOverlay we mentioned yesterday).
like set_chainid, set_balance, set_code, set_storageAt, setNonce
alindima
reviewed
Nov 26, 2025
| // List of general purpose DRPC keys to rotate through | ||
| static DRPC_KEYS: LazyLock<Vec<String>> = LazyLock::new(|| { | ||
| let mut keys = vec!["AgasqIYODEW_j_J0F91L8oETmhtHCXkR8JAVssvAG40d".to_owned()]; | ||
| let mut keys = vec
|
Let's also fix clippy |
|
While playing around with this branch locally I ran into another panic. I was just sending balances around on both the original node and the fork Full logs: |
hmm actually I'm getting similar panic on a node that uses master. Looks like only a problem when using cast and sending requests one after the other (if we wait a bit more there is no issue). I'll investigate. Probably cast is not properly waiting for the response before sending the next request |
alindima
reviewed
Nov 26, 2025
yeah, this was the issue: #438 |
Author
Great finding! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR implements forking functionality for anvil-polkadot, allowing users to fork from a remote Substrate/Polkadot node and run local tests against live network state.
Adds the ability to fork from a running anvil-polkadot node (or compatible Substrate node) using the
--fork-urlflag. The implementation uses a lazy-loading approach to fetch state from the remote node on-demand, caching values locally for performanceManual testing
After compiling the entire project using
cargo build --release1. Start base node
2. Modify state on base node
3. Verify modified balance
4. Start fork node (inherits modified state)
5. Verify fork inherited state
6. Make changes on fork (doesn't affect base)
7. Verify isolation
Integration tests
Closes: ChainSafe/gossamer-parity#52, ChainSafe/gossamer-parity#58, ChainSafe/gossamer-parity#65, ChainSafe/gossamer-parity#84