Repository navigation
build(deps): bump rwasm to 0.7.2 - #570
Conversation
rwasm 0.7.1 keeps the wire format and fuel schedule of 0.6.0 and adds the wide-arithmetic opcodes (90-93), emulates the rwasm recursion depth and value-stack window on the Wasmtime backend (wasmtime-rwasm 45.0.0-rwasm.3), widens the interpreter's trampoline headroom from 4 to 13 slots, and no longer grows a function's StackCheck for dead code after end. StrategyDefinition::Rwasm gained entrypoint_type, the Wasm signature a named entrypoint is checked against; the four state-routed constructions pass None, which keeps the executor behaviour of 0.6.0. All five lockfiles move together (root, contracts, examples, e2e/evm, e2e/codec) so the guest builds and the node compile with the same rwasm: with the contracts lock left behind, the runtime-upgrade tests that compare a host compile with what the guest installed fail on the smaller StackCheck reservations. The revm fork is relocked to v107-patched at revm-rwasm#64, which pins the same rwasm. Verified: every historical runtime-upgrade payload of mainnet (138), testnet (188) and devnet (226) still decodes and passes validate_system_runtime on both flavours.
Record what 0.7.1 changes for existing bytecode (interpreter window, Wasmtime stack-limit emulation), how the bump is verified (payload replay and re-execution), the node-before-guest order for the wide-arithmetic opcodes, and that node-compiled artifacts no longer match bodies produced by an older on-chain compiler byte for byte.
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: ⛔ Files ignored due to path filters (5)
📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe workspace upgrades rWasm from 0.6.0 to 0.7.2. Runtime strategy configurations set ChangesrWasm upgrade
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~10 minutes Change: Other Suggested reviewers: Merge Risk: ⚪ Minimal · up to The dependency and runtime-strategy changes are consistent with the documented behavior; no actionable issue remains before normal merge checks. Security Architecture ReviewSecurity architecture risk: 🟡 Moderate · up to The upgrade has a documented rollout order, but changes to execution limits can affect existing bytecode before every node is upgraded. Compatibility during a partial rollout needs confirmation. Retained concerns
Security review detailsSecurity Blast Radius
Security Findings and Attack Paths
Trust Boundaries and Controls
Resilience and Maintainability Implications
Hardening Proposals
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 2 files. (2 skipped: 2 unsupported.)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Criterion results (vs baseline)Heads-up: runner perf is noisy; treat deltas as a smoke check. |
0.7.2 is 0.7.1 plus wasmtime-rwasm 45.0.0-rwasm.4, where a tail call made after a plain call publishes the caller's rwasm stack counters again instead of reading the callee's. No opcode, bytecode or fuel change; the five lockfiles follow the pin.
|
Moved to rwasm 0.7.2 ( Local verification on the final locks: fmt, |
Summary
rwasm0.6.0 → 0.7.1 in the workspace manifest and in all five lockfiles (root,contracts/,examples/,e2e/evm/,e2e/codec/);wasmtime-*-rwasm45.0.0-rwasm.2 → rwasm.3 follows; the revm fork is relocked tov107-patchedat build(deps): bump rwasm to 0.7.1 revm-rwasm#64, which pins the same rwasm.StrategyDefinition::Rwasmgainedentrypoint_type; the four state-routed constructions passNone(behaviour of 0.6.0).docs/07-rwasm-integration.md: what 0.7.1 changes for existing bytecode, how the bump is verified, and the node-before-guest order for the wide-arithmetic opcodes.What 0.7.1 means for the node
N_MAX_STACK_SIZE + 13(was+ 4, rwasm#212), and the Wasmtime backend now trapsStackOverflowat the interpreter's recursion depth and window instead of its native 32 KiB stack (rwasm#213). Same class as the 0.5.0/0.6.0 bumps:fluent re-executeon both flavours before a release ships it.+wide-arithmetic. The published SDK must not enable the target feature by default before that.StackCheckreservations for functions with dead code afterendand different active-segment table entries (rwasm#220). Historical state is unaffected (user WASM is compiled by the on-chain WASM runtime guest, system runtimes by 0x…520010), butbins/runtime-upgradeartifact equality against an older on-chain compiler will differ, and the guest builds must stay on the same rwasm as the node, which is why thecontracts/lock moves in the same commit.wasmtime-rwasm45.0.0-rwasm.3 areturn_callafter a non-tailcallin the same function reads stale stack counters and can trapStackOverflowon the Wasmtime backend only. No historical hint uses tail calls (rustc guests are built without+tail-call); it needs a fork fix before any tail-call payload lands.Verification
RwasmModule::new_checked+validate_system_runtime: mainnet 138, testnet 188, devnet 226 → 552/552 decode and admit on bothstdandstd,wasmtime.cargo fmt --check,cargo fetch --locked×5, clippy root/contracts/examples with-D warnings, nextest root 985 tests ×2 flavours, contracts 138, examples 46, evm-e2egood_coverage_tests34 ×2 andfixture12 ×2,cargo check --all --locked.Owed before a release:
fluent re-executeof mainnet, testnet and devnet on both flavours.Summary by CodeRabbit