deps(deps): bump revm from 42.0.1 to 43.0.0 - #2658
Conversation
There was a problem hiding this comment.
Summary
Blocking: this dependency bump introduces a mixed revm major-version graph in the root crate (revm at 43.0.0 while revm-inspectors still pulls revm 42.0.1, and direct revm-state remains 42.0.0). For an EVM execution stack, running two incompatible major lines in one binary is high risk for semantic divergence and integration breakage; this should be aligned before merge.
🧾 cargo-vet automated audit summary
CI did not commit anything. Review the patch locally and create the final signed commit yourself.
|
0774b32 to
90cf702
Compare
There was a problem hiding this comment.
Summary
Blocking: this bump still leaves a mixed revm major-version graph in the same binary (revm 43.x alongside revm-inspectors/revm-state on 42.x). For core EVM execution components, keeping two major lines is high-risk for semantic divergence and integration breakage; these should be aligned to the same major before merge.
🧾 cargo-vet automated audit summary
CI did not commit anything. Review the patch locally and create the final signed commit yourself.
|
90cf702 to
ae73b13
Compare
There was a problem hiding this comment.
Summary
Blocking: this dependency bump still leaves a mixed revm major-version graph in the same binary. stratus now depends on revm 43.0.0 directly, but revm-inspectors remains pinned to =0.42.0 and resolves to revm 42.0.1, while revm-state remains 42.0.0.
For core EVM execution components, running 42.x and 43.x side-by-side is high risk for semantic divergence (state transitions, precompile behavior, fork logic) and integration breakage across shared types. Please align the revm* family to a single major line before merge.
🧾 cargo-vet automated audit summary
CI did not commit anything. Review the patch locally and create the final signed commit yourself.
|
|
we need to deal with codehashes in this version. We don't store them anywhere so it would rely on either migrating rocks or creating a new CF/type version, or computing them as they are read. The latter is not so bad since hot contracts are always loaded onto the cache anyways, so we'd really only be computing the codehash once (when it is read on perm) |
Bumps [revm](https://github.com/bluealloy/revm) from 42.0.1 to 43.0.0. - [Release notes](https://github.com/bluealloy/revm/releases) - [Changelog](https://github.com/bluealloy/revm/blob/main/CHANGELOG.md) - [Commits](https://github.com/bluealloy/revm/commits/v43) --- updated-dependencies: - dependency-name: revm dependency-version: 43.0.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
ae73b13 to
12e1cbd
Compare
🧾 cargo-vet automated audit summary
CI did not commit anything. Review the patch locally and create the final signed commit yourself.
|
There was a problem hiding this comment.
Blocking: the PR still resolves two major revm lines in the same binary.
From Cargo.lock:
stratusnow depends onrevm 43.0.0revm-inspectorsremains onrevm 42.0.1- direct dep is still
revm-state 42.0.0
This is a concrete risk for an execution engine path (state/account model, codehash handling, precompile/fork semantics, and type interop drift between major versions). Even if it compiles, semantic divergence across 42.x vs 43.x in one runtime can produce hard-to-diagnose behavior differences.
Please align the revm* family to a single major before merge (either all 42.x or all 43.x), including transitive anchors like revm-inspectors and direct revm-state.
Given the thread mention about codehashes in this version, if moving to 43.x is intended, add/point to the migration strategy in this PR (persisted codehash, DB version bump, or deterministic lazy recompute + tests) so behavior is explicit and auditable.
Bumps revm from 42.0.1 to 43.0.0.
Changelog
Sourced from revm's changelog.
... (truncated)
Commits
Most Recent Ignore Conditions Applied to This Pull Request