Skip to content

Conversation

@kaimast
Copy link
Contributor

@kaimast kaimast commented Oct 9, 2025

Note: snarkVM PR #2951 needs to be merged first.

Most recent snarkVM breaks the devnet CI, because developer scan does not work with test_targets enabled.

 Failed to fetch records
    ↳ Invalid block metadata — Genesis block check failed — Invalid coinbase target for genesis block: Wa 536870911 but expected 31.

This is due to recent changes ensuring that the genesis block is valid when deserializing it. This PR changes the scan command to use from_bytes_unchecked when loading the genesis bytes.
The change is safe because the bytes are hardcoded and, thus, from a trusted source.

let is_development_network = genesis_block != Block::from_bytes_le(N::genesis_bytes())?;
// Use the unchecked version to allow loading the regular genesis block, even if the CLI
// has `test_targets` enabled.
let is_development_network = genesis_block != Block::from_bytes_le_unchecked(N::genesis_bytes())?;
Copy link
Collaborator

@vicsn vicsn Oct 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

test_network/test_targets are a dev-only feature.

I think the simplest change to fix scanning is to just assume we are on a development network if the test_network feature is enabled. And that also implies that the queried network has it enabled, because we were able to deserialize it's genesis block.

Generally I think it's good if we very tightly couple the concept of "dev" and "test_network", maybe even being the same thing one day.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I can change it to that if you prefer.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes please, let's aim for minimal and quick PRs that focus on getting the issue at hand solved.

@kaimast
Copy link
Contributor Author

kaimast commented Oct 10, 2025

Closing in favor of #3928.

In the long-term, this version would still be better, as the genesis block might change due to other feature flags, but, for now, #3928 is sufficient.

@kaimast kaimast closed this Oct 10, 2025
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

Successfully merging this pull request may close these issues.

3 participants