Skip to content

feat: disallow non-deterministic iteration order#3

Open
kevaundray wants to merge 4 commits intoparadigmxyz:mainfrom
kevaundray:kw/non-det-it-order
Open

feat: disallow non-deterministic iteration order#3
kevaundray wants to merge 4 commits intoparadigmxyz:mainfrom
kevaundray:kw/non-det-it-order

Conversation

@kevaundray
Copy link
Contributor

@kevaundray kevaundray commented Feb 14, 2026

Problem

Some zkVMs run/execute the program multiple times while proving. For example, this can be done once with the emulator and then another time with an assembly generated version of the emulator. These two runs for correctness reasons should match, however since HashMap::iter is non-deterministic, this is not the case.

Moreover, deterministic runs make it a lot easier to debug programs.

For why HashMap is non-deterministic, one can see here

Suggested solution

Replace all usages of HashMap with IndexMap or BTreeMap. These implementations have stable iteration orders. Also added a clippy lint to ensure that those types cannot be used in this crate.

Notes

  • This is somewhat a fairly common issue in code that requires/desire deterministic builds like compilers, see here and here

  • This PR would only partially solve the issue since some crates in reth also use HashMap

Comment on lines +5 to +8
// TODO: `reveal_witness` from reth uses B256Map. We would need to change it from
// there first.
#[allow(clippy::disallowed_types)]
use alloy_primitives::map::B256Map;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This would need to be fixed in reth

@kevaundray
Copy link
Contributor Author

kevaundray commented Feb 14, 2026

This can be somewhat tricky because the change would need to also happen in dependencies (mainly reth and alloy) -- HashMap is technically okay to use, but one would just need to ensure that the iteration order is deterministic.

This is already done in some places with .sorted_unstable_by_key

Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

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

makes sense

@kevaundray kevaundray marked this pull request as ready for review February 18, 2026 15:47
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.

2 participants