Implement the deterministic runtime, validator and compatibility corpus

Parent: #4626 · Complete tracking register

Proposed target: 5.0-dev. This is a workstream tracking issue, not a claim that the release branch exists or the implementation is done. Owner: QuantumExplorer. Dates and effort remain unset.

Scope

Build the two VM crates, full named-module runtime/ABI, portable resource enforcement, pinned engine profile and cross-architecture/historical compatibility tooling.

Specification

DVM-02 · DVM-07

The current parent acceptance and module/capability appendices remain authoritative; these DIP drafts add proposed engineering detail without silently approving open allocations.

Completion criteria

Complete every listed task acceptance item, its applicable capability matrix, and the linked specification vectors. Record actual PR/test evidence; drafting is not production completion.

Task acceptance

R03-01

• Build a deterministic comparison corpus covering module validation, output, protocol-metered cost, traps, and resource boundaries on x86_64 and aarch64. Test candidate engine/compiler configurations and exact revisions; distinguish expected historical differences from forbidden differences under identical protocol rules.

Q02 (confirmed direction): Coordinate engine behavior changes through normal protocol upgrades and preserve historical replay. Select the exact release, locked dependencies, Cranelift configuration and adoption evidence through engineering tests. Q41 (confirmed direction with caveat): Use determinism, replay, fees, conservation, native integration, upgrade/recovery tests and a working Rust example as release evidence. Owner agreed with hesitation. Exact test windows are engineering proposals; no audit/funding/deployer-allowlist gate or new recovery authority. Include the new Dashbot advisory leads with locked release/dependency/backend/CPU/guard settings; distinguish upstream evidence, independently reproduced regressions and unaffected configurations. Never substitute Winch fuel/NaN outputs for Cranelift consensus behavior. Shared corpus acceptance: x86_64/aarch64 under one protocol profile and recorded target-specific CPU/guard settings must match canonical NaN bits and protocol-metered cost on each trapping case. Raw Wasmtime trap fuel must match if it affects consensus costs/limits; record it diagnostically otherwise. A consensus-visible mismatch rejects the profile. The reviewer has not demonstrated an architecture mismatch and these tests are not claimed run.

Prerequisites: R13-01.

Dependents: R03-02, R03-03, R11-08, R12-04, R11-09.

Modules: RUNTIME, VALIDATE, HARNESS, INTEGRATION. Original task context. Refinements (not extra dependency edges): FIX-05.

R03-02

• Replay recorded blocks under their original protocol/engine behavior using later node binaries; compare application hashes and per-transition fees after engine changes and backports.

Q02 (confirmed direction): Coordinate engine behavior changes through normal protocol upgrades and preserve historical replay. Select the exact release, locked dependencies, Cranelift configuration and adoption evidence through engineering tests. Q41 (confirmed direction with caveat): Use determinism, replay, fees, conservation, native integration, upgrade/recovery tests and a working Rust example as release evidence. Owner agreed with hesitation. Exact test windows are engineering proposals; no audit/funding/deployer-allowlist gate or new recovery authority.

Prerequisites: R03-01.

Dependents: R08-08.

Modules: ABCI, READINESS, INTEGRATION. Original task context. Refinements (not extra dependency edges): FIX-04.

R03-03

• Benchmark the confirmed Cranelift backend against Winch and a reference interpreter for diagnostic evidence; select a pinned upstream release/profile after representative and adversarial tests. Comparison does not reopen the chosen engine.

Q01 (confirmed): Use pinned upstream Wasmtime with Cranelift and a small Dash integration layer; contribute fixes upstream. A necessary temporary patch is an exception, not a standing engine fork.

Prerequisites: R03-01.

Dependents: None recorded.

Modules: RUNTIME, METER, HARNESS. Original task context.

R03-04

• Define and implement bounded registration validation: admitted WASM features, import/export and capability rules, ABI version, code size, memories/tables, function/parameter/local counts, nesting, and compilation complexity. Specify the exact caps rather than reusing old allocated constants.

Q04 (confirmed): Allow f32/f64 with explicit Cranelift NaN canonicalization and deterministic host/profile tests. SIMD and relaxed SIMD are separate profile choices; proposed initial profile disables both. Q40 (confirmed delegation): Maintain one protocol-versioned allocation register. Supply provisional numeric limits and prices now, then measure and revise before activation. Allocate wire/storage/ABI IDs from actual registries; keep engine/profile pin and unmeasured native costs explicitly unresolved. Confirmed VM crate split: Implement the shared deterministic WASM admission checks and required instrumentation in rs-dashvm-validation. Node and developer tooling use this crate without a dependency on Wasmtime/Cranelift, Drive or ABCI. Stateful authority and active-capability checks remain in the native integration layer.

Prerequisites: R08-01, R08-02.

Dependents: None recorded.

Modules: VALIDATE, ABI, VERSION. Original task context.

R03-05

• Version required host-capability declarations and reject unsupported capabilities consistently. Track advisories for the dependencies actually selected; external subscriptions or communications remain separate operational actions.

Prerequisites: R13-01.

Dependents: R03-06, R08-02.

Modules: ABI, AUTH, VERSION. Original task context.

R03-06

• Validate ABI and target protocol compatibility at registration and upgrades; preserve execution of accepted historical code. Define upgrade preparation explicitly instead of silently freezing contracts or charging first-use recompilation under the old proposal.

Q02 (confirmed direction): Coordinate engine behavior changes through normal protocol upgrades and preserve historical replay. Select the exact release, locked dependencies, Cranelift configuration and adoption evidence through engineering tests.

Prerequisites: R03-05, R08-01.

Dependents: R08-02.

Modules: VALIDATE, READINESS, EXEC_STORE. Original task context.

R03-07

• Define protocol-versioned computation and memory metering with golden vectors and paid limit failures; verify it is independent of local cache state and compiler optimization choices.

Q40 (confirmed delegation): Maintain one protocol-versioned allocation register. Supply provisional numeric limits and prices now, then measure and revise before activation. Allocate wire/storage/ABI IDs from actual registries; keep engine/profile pin and unmeasured native costs explicitly unresolved. Named-module scope: Enforce per-module and aggregate bundle/invocation bounds. Charge initialization, copies, typed module calls and guest work under one shared budget and logical stack; splitting code cannot reset or multiply limits.

Prerequisites: R08-05, R08-01.

Dependents: None recorded.

Modules: METER, FEES, VERSION. Original task context. Refinements (not extra dependency edges): FIX-05.

R08-01

• Implement the Dash runtime abstraction, protocol-versioned engine dispatch and deterministic configuration for the selected engine; specify persistent compiled-cache behavior for executable versions and historical replay.

Q01 (confirmed): Use pinned upstream Wasmtime with Cranelift and a small Dash integration layer; contribute fixes upstream. A necessary temporary patch is an exception, not a standing engine fork. Named-module scope: Integrate named-module linking and deterministic initialization of the selected entry dependency closure, separate module memories, shared resource accounting and safe compiled-artifact reuse. Bundle execution acceptance requires working preparation and module ABI, not runtime scaffolding alone.

Prerequisites: None recorded.

Dependents: R03-04, R03-06, R12-04, R03-07, R08-07, R08-08, R08-09, R11-06, R09-03.

Modules: RUNTIME, CALLS, METER. Original task context.

R08-02

• Implement bounded module preparation/registration and selected structural, compilation, stack, memory, code-size and execution limits; charge according to the specified model and classify failures consistently.

Q14 (confirmed): The deployer pays bounded protocol validation and readiness-verification costs. Evonodes pay their own compilation. No local-time compilation bill, cold-cache surcharge or repeated preparation charge on execution. Q40 (confirmed delegation): Maintain one protocol-versioned allocation register. Supply provisional numeric limits and prices now, then measure and revise before activation. Allocate wire/storage/ABI IDs from actual registries; keep engine/profile pin and unmeasured native costs explicitly unresolved. Named-module scope: Validate the complete named-module bundle: module and aggregate bounds, deterministic graph/interface checks, exact content hashes and bounded preparation. Proposed first profile uses an acyclic dependency graph. Confirmed VM crate split: Keep deterministic validation, instrumentation and validated/prepared WASM metadata in rs-dashvm-validation. rs-dashvm consumes the output for native compilation, cache management and execution. Preserve separate protocol preparation generations and canonical/prepared hashes; validation alone does not satisfy compilation readiness.

Prerequisites: R03-05, R03-06, R06-04.

Dependents: R03-04, R08-03, R08-05, R08-06, R08-07, R13-06, R08-08, R11-06, R11-09, R04-06.

Modules: VALIDATE, METER, VERSION. Original task context. Refinements (not extra dependency edges): FIX-05.

R08-04

• Implement the canonical guest ABI/context/document representation, capabilities and result-code rules; cover every supported Platform value and bound guest-wire expansion independently of stored byte size.

Named-module scope: Specify and implement typed internal module calls with bounded canonical arguments/results, separate memory ownership and preserved contract/signer/caller context. Raw Rust pointers and allocator ownership cannot cross module memories.

Prerequisites: R13-01.

Dependents: R08-05, R08-07, R09-01, CAP-03.

Modules: ABI, SER, RUNTIME. Original task context. Refinements (not extra dependency edges): SDK-01, STUB-RNG, INT-RNG.

R08-06

• Specify and implement preparation on upgrades, restarts and cache loss. Replace the original lazy-first-call preparation policy with behavior consistent with readiness activation and deterministic historical replay; keep missing-cache handling from changing consensus validity.

Q02 (confirmed direction): Coordinate engine behavior changes through normal protocol upgrades and preserve historical replay. Select the exact release, locked dependencies, Cranelift configuration and adoption evidence through engineering tests. Q14 (confirmed): The deployer pays bounded protocol validation and readiness-verification costs. Evonodes pay their own compilation. No local-time compilation bill, cold-cache surcharge or repeated preparation charge on execution. Named-module scope: Recover complete runnable/pending bundles. A reused artifact remains cached while any runnable version needs it; profile changes invalidate affected artifacts without changing protocol outcomes or fees.

Prerequisites: R08-02, R08-05.

Dependents: R08-08, R13-07.

Modules: READINESS, RUNTIME, OPS. Original task context. Refinements (not extra dependency edges): FIX-09.

R08-08

• Add adversarial/golden runtime vectors, proposal/validator integration, cold/warm/recovered-cache comparisons, cross-architecture execution and historical replay, including integer edges, stack/memory exhaustion and host-call fuel boundaries.

Q04 (confirmed): Allow f32/f64 with explicit Cranelift NaN canonicalization and deterministic host/profile tests. SIMD and relaxed SIMD are separate profile choices; proposed initial profile disables both. Q41 (confirmed direction with caveat): Use determinism, replay, fees, conservation, native integration, upgrade/recovery tests and a working Rust example as release evidence. Owner agreed with hesitation. Exact test windows are engineering proposals; no audit/funding/deployer-allowlist gate or new recovery authority. Include the new Dashbot advisory leads with locked release/dependency/backend/CPU/guard settings; distinguish upstream evidence, independently reproduced regressions and unaffected configurations. Never substitute Winch fuel/NaN outputs for Cranelift consensus behavior. Shared corpus acceptance: x86_64/aarch64 under one protocol profile and recorded target-specific CPU/guard settings must match canonical NaN bits and protocol-metered cost on each trapping case. Raw Wasmtime trap fuel must match if it affects consensus costs/limits; record it diagnostically otherwise. A consensus-visible mismatch rejects the profile. The reviewer has not demonstrated an architecture mismatch and these tests are not claimed run. Named-module scope: Test integrated bundle admission/linking/ABI, deterministic closure initialization, tampered hashes/bindings, whole-bundle activation, reuse across versions, cache loss, authority/rollback, aggregate limits, proof tampering and cross-architecture fee/receipt/root parity under sequential and ordered-parallel execution.

Prerequisites: R08-01, R08-02, R08-05, R08-06, R08-07, R03-02, R14-01, FIX-05.

Dependents: R08-11, R11-01, R04-06.

Modules: RUNTIME, HARNESS, INTEGRATION. Original task context. Refinements (not extra dependency edges): FIX-05.

R08-09

• Validate every runtime/host error mapping, pointer/length boundary and deterministic configuration path; fuzz preparation and ABI decoding. Test that guest input cannot select ambient I/O, nondeterministic values or unbounded resource use.

Q04 (confirmed): Allow f32/f64 with explicit Cranelift NaN canonicalization and deterministic host/profile tests. SIMD and relaxed SIMD are separate profile choices; proposed initial profile disables both.

Prerequisites: R08-01.

Dependents: R08-11.

Modules: VALIDATE, ABI, HOST, RUNTIME. Original task context.

R08-10

• Track security fixes/advisories for the selected dependencies and apply the execution/fee-equivalence hotfix rule. No external-audit report, named security owner or closed stage audit is a prerequisite to building.

Q01 (confirmed): Use pinned upstream Wasmtime with Cranelift and a small Dash integration layer; contribute fixes upstream. A necessary temporary patch is an exception, not a standing engine fork.

Prerequisites: None recorded.

Dependents: None recorded.

Modules: DELIVERY, RUNTIME. Original task context. Refinements (not extra dependency edges): FIX-04.

R11-01

• Enforce deterministic host/runtime configuration and dependency identification with appropriate linting and tests; keep golden outcomes/costs per protocol engine behavior and detect accidental dependency/configuration drift.

Prerequisites: R11-08, R08-08.

Dependents: None recorded.

Modules: RUNTIME, VALIDATE, VERSION. Original task context.

R11-05

• Document how protocol changes update metering, limits, cost vectors and compatibility evidence. Use appropriate measurements to choose limits without reintroducing the deferred hardware publication requirement.

Prerequisites: R12-04.

Dependents: None recorded.

Modules: VERSION, DELIVERY. Original task context.

R11-06

• Bound compilation/preparation, executable-cache resources and invocation/instantiation work consistently with readiness activation; test cache loss and cold/recovered nodes. Do not make block validity depend on counting local cache misses.

Q14 (confirmed): The deployer pays bounded protocol validation and readiness-verification costs. Evonodes pay their own compilation. No local-time compilation bill, cold-cache surcharge or repeated preparation charge on execution.

Prerequisites: R08-01, R08-02.

Dependents: None recorded.

Modules: RUNTIME, READINESS, METER. Original task context. Refinements (not extra dependency edges): FIX-03.

R11-08

• Maintain pinned upstream Wasmtime/Cranelift with a small Dash integration layer and upstream fixes; retain locked historical engine profiles for replay.

Q01 (confirmed): Use pinned upstream Wasmtime with Cranelift and a small Dash integration layer; contribute fixes upstream. A necessary temporary patch is an exception, not a standing engine fork. Q02 (confirmed direction): Coordinate engine behavior changes through normal protocol upgrades and preserve historical replay. Select the exact release, locked dependencies, Cranelift configuration and adoption evidence through engineering tests.

Prerequisites: R03-01.

Dependents: R11-01, R11-09.

Modules: RUNTIME, VERSION, DELIVERY. Original task context.

R11-09

• Build engine compatibility/differential tooling over stored contract versions, recorded executions and adversarial generated modules; report result, fee, trap and resource differences, preserve historical replay, and use equivalence evidence for software-only hotfixes.

Include the new Dashbot advisory leads with locked release/dependency/backend/CPU/guard settings; distinguish upstream evidence, independently reproduced regressions and unaffected configurations. Never substitute Winch fuel/NaN outputs for Cranelift consensus behavior.

Prerequisites: R11-08, R08-02, R03-01.

Dependents: None recorded.

Modules: HARNESS, RUNTIME, READINESS. Original task context.

FIX-05

• Enforce portable logical stack and deterministic resource limits

Portable frame/operand accounting, native stack headroom, deterministic reserved growth and versioned costs. Scalar floating point is enabled with explicit NaN canonicalization. Pin Cranelift and its complete CPU/guard/instrumentation profile; exact limits remain proposed benchmark inputs. Q04 (confirmed): Allow f32/f64 with explicit Cranelift NaN canonicalization and deterministic host/profile tests. SIMD and relaxed SIMD are separate profile choices; proposed initial profile disables both. Q40 (confirmed delegation): Maintain one protocol-versioned allocation register. Supply provisional numeric limits and prices now, then measure and revise before activation. Allocate wire/storage/ABI IDs from actual registries; keep engine/profile pin and unmeasured native costs explicitly unresolved. Shared corpus acceptance: x86_64/aarch64 under one protocol profile and recorded target-specific CPU/guard settings must match canonical NaN bits and protocol-metered cost on each trapping case. Raw Wasmtime trap fuel must match if it affects consensus costs/limits; record it diagnostically otherwise. A consensus-visible mismatch rejects the profile. The reviewer has not demonstrated an architecture mismatch and these tests are not claimed run.

Prerequisites: None recorded.

Dependents: R08-08.

Modules: VALIDATE, METER. Original task context.

R04-06

• Test every admitted/forbidden WASM feature and each selected structural/resource cap, including deep recursion, memory growth, compiler stress, and deterministic failure classification.

Q04 (confirmed): Allow f32/f64 with explicit Cranelift NaN canonicalization and deterministic host/profile tests. SIMD and relaxed SIMD are separate profile choices; proposed initial profile disables both.

Prerequisites: R08-02, R08-08.

Dependents: None recorded.

Modules: VALIDATE, METER, HARNESS. Original task context.

R11-11

• Version selected resource limits and feature gates in the final allocation; test pre-activation rejection and correct active behavior without inventing unchosen constants.

Q40 (confirmed delegation): Maintain one protocol-versioned allocation register. Supply provisional numeric limits and prices now, then measure and revise before activation. Allocate wire/storage/ABI IDs from actual registries; keep engine/profile pin and unmeasured native costs explicitly unresolved.

Prerequisites: None recorded.

Dependents: None recorded.

Modules: VERSION, VALIDATE, METER. Original task context.

Coordination and dependencies

Task-level prerequisites above govern order. Workstreams contain multiple stages, so a cross-link is not a claim that the entire other issue must close first. These are Markdown relationships, not native GitHub blocked-by edges. The parent dependency register preserves all 234 links, reasons and explicit/inferred labels.

• R13-01 → R03-01 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R13-01 → R03-05 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R06-04 → R08-02 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-02 → R08-03 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R13-01 → R08-04 (inferred): Rebased source dependency; confirm the implementation ordering. The guest ABI fills the same groundwork crate and uses platform-value-core.
• R08-02 → R08-05 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-04 → R08-05 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R03-01 → R12-04 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-01 → R12-04 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-05 → R03-07 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-05 → R08-06 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-04 → R08-07 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-02 → R08-07 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-01 → R08-07 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-02 → R13-06 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-05 → R08-08 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-07 → R08-08 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R14-01 → R08-08 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-08 → R08-11 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-09 → R08-11 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R12-04 → R11-05 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-06 → R13-07 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-04 → R09-01 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-01 → R09-03 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-04 → CAP-03 (inferred): Schema/document adapters implement the versioned guest ABI.

PR and evidence tracking

Create focused PRs against the chosen development branch. Link this issue with Refs #<issue-number> for partial work. Do not use Fixes for the whole workstream until every listed full task and acceptance criterion is complete.

For a PR that completes an entire task, add a standalone line in its actual PR body: Dash-Tasks: <completed task IDs>. Replace the placeholder with only fully completed IDs. Preparation PRs use ordinary references and omit the completion marker for their broader parent tasks. The site reads this marker on PRs in dashpay/platform and dashpay/grovedb: draft = red, ready for review = yellow, merged with no linked open PR = green. Closed-unmerged is not completion. This does not automatically close issue checkboxes and does not prove acceptance tests passed; reviewers must record the evidence.