feat: serialize trusted trace proving inputs by huitseeker · Pull Request #3284 · 0xMiden/miden-vm

huitseeker · 2026-06-23T22:59:02Z

The transaction executor can now serialize TraceProvingInputs and send them to a trusted prover. The prover can deserialize the payload, build the trace, prove it, and return a proof.

This adds binary serialization for the trace replay state, sparse MAST replay data, TraceBuildInputs, ProvingOptions, and TraceProvingInputs.

Sparse MAST serialization is a trusted replay format. It preserves the source node IDs, roots, advice data, digest entries, and source forest commitment. It does not implement the untrusted hashless MAST read path (and does not verify node hashes).

Tests cover sparse round trips, malformed sparse payloads, bad serialized forest IDs, trace summary equality after TraceBuildInputs round trip, proof generation after TraceProvingInputs round trip, and fuzz smoke runs for the new deserialize targets.

Closes #3235

plafer

Overall really LGTM!

huitseeker · 2026-06-25T14:32:32Z

@plafer Thanks, both points were right.

I made testing enable arbitrary (as it does in core) for every crate that has arbitrary backed serde tests. make test now builds and runs those generated tests.
I also changed both trailing byte tests so the budget covers the full invalid payload. They now reach the trailing byte checks instead of the budget check.

bobbinth · 2026-06-28T22:55:17Z

Sparse MAST serialization is a trusted replay format. It preserves the source node IDs, roots, advice data, digest entries, and source forest commitment. It does not implement the untrusted hashless MAST read path (and does not verify node hashes).

Question: what would happen if someone sends a malformed MAST forest (i.e., with incorrect hashes) - would the prover error out or crush?

The reason for the question is that we have two separate settings for this:

Block/batch proof generation - where we trust that the block producer is not malicious and so a remote prover doesn't need to verify the inputs.
Transaction proof generation - here, any external user could send a request to prove a transaction to a remote prover. So, in theory, the proving inputs could be serialized incorrectly. Though, maybe this is something that could be caught at a higher level because we do need to enforce some limits (or collect some fees) from users who'd like to use remote provers.

huitseeker · 2026-06-29T14:21:48Z

@bobbinth

Question: what would happen if someone sends a malformed MAST forest (i.e., with incorrect hashes) - would the prover error out or crush?

The prover would not crash. The bad digest is accepted into the sparse forest. build_trace may still succeed, because trace replay uses those stored digests. The STARK proof path does not call ExecutionTrace::check_constraints() before proving The likely developer-visible outcome is an invalid proof that fails verification, or a constraint failure only if they explicitly run check_constraints().

From the PR description:

Sparse MAST serialization is a trusted replay format. It preserves the source node IDs, roots, advice data, digest entries, and source forest commitment. It does not implement the untrusted hashless MAST read path (and does not verify node hashes).

The closest signal for this scope is code documentation, not an API boundary strong enough to prevent misuse.

I opened #3303 for the untrusted serialization.

bobbinth

Thank you! Looks good. Not a full review but I left some comments inline.

bobbinth · 2026-06-30T19:23:24Z

+                "TraceProvingInputs byte budget is smaller than payload length".into(),
+            ));
+        }
+        let allocation_budget = budget.min(bytes.len().saturating_mul(4));


Would be good to add a comment why multiplying by 4 is appropriate/sufficient here.

Addressed in #3314, which names the multiplier and documents the split between the byte budget and the allocation budget. It's the same pattern as the MastForest, UntrustedMastForest, Package, etc.

bobbinth · 2026-06-30T19:24:28Z

+        if reader.has_more_bytes() {
+            return Err(SerdeDeserializationError::InvalidValue(
+                "TraceProvingInputs payload has trailing bytes".into(),
+            ));
+        }


Do we need this check? Having it implies that we wouldn't be able to serialize TraceProvingInputs as a part of some bigger object, right?

The check is in read_from_bytes() because that function reads one full standalone payload. A larger wrapper should call TraceProvingInputs::read_from(reader) inside its own reader, then the wrapper owns the final end-of-input check. #3314 documents that, and it is the same pattern used e.g. by serde_json or bincode for whole-slice vs reader-based deserialization.

bobbinth · 2026-06-30T21:36:11Z

This file has grown too large - let's split it up and move the content under src/trace/trace_state directory. I would split it up along the component lines. For example:

src/trace/trace_state/system.rs

src/trace/trace_state/stack.rs

src/trace/trace_state/block_stack.rs

etc.

I agree that trace_state.rs is large. I have found large mechanical diffs have a negative impact on some reviewers, so I would rather keep that split out of this stack. Happy to have a component split as a separate cleanup PR.

bobbinth · 2026-06-30T21:56:12Z

 pub struct TraceBuildInputs {
    trace_output: TraceBuildOutput,
    trace_generation_context: TraceGenerationContext,
    program_info: ProgramInfo,
 }

 #[derive(Debug)]
 pub(crate) struct TraceBuildOutput {
    stack_outputs: StackOutputs,
    final_precompile_transcript: PrecompileTranscript,
    precompile_requests: Vec<PrecompileRequest>,
    precompile_requests_digest: [u8; 32],
 }


Not related to this PR, but I find the structure of TraceBuildInputs and related structs pretty confusing. For example:

Do we actually need TraceBuildOutput? It seems like 3 out of 4 fields there are about precompiles and probably should be put into a dedicated struct. And once this is done, maybe it would make sense to dissolve this struct entirely?

Also, TraceBuildOutput doesn't need to be pub(crate) as it is used only within this module (and its submodules).

#3314 makes TraceBuildOutput private. I would leave the larger shape change for a follow-up because it is not needed for serialization.

bobbinth · 2026-06-30T22:08:12Z

+    ///
+    /// This uses the same wire shape as `Vec<T>`: a length prefix followed by items in iteration
+    /// order.
+    pub struct SerializableVecDeque<'a, T>(pub &'a VecDeque<T>);


We are doing this because we don't have have serialization implemented for VecDeque in miden-crypto? If so, should we just implement it it there?

If we'd rather keep it here for now, I'd move it src/utils/mod.rs.

#3314 moves the VecDeque helper to core::utils. I did not add it to miden-crypto for now because (besides release propagation delays) the only current caller is trace replay.

bobbinth · 2026-06-30T22:18:40Z

+    fn read_from<R: crate::serde::ByteReader>(
+        source: &mut R,
+    ) -> Result<Self, DeserializationError> {
+        Ok(Self(<u32 as Deserializable>::read_from(source)?))


I'm not sure this is safe. I remember previously we've always avoided deserializing MAST node IDs directly and preferred using from_u32_with_node_count(). I believe this was because MAST node ID values were limited to $2^{30} - 1$ and so a full u32 value could result in an invalid MAST node ID.

If this is not a concern now, we should explicitly document this. But also, I'm a bit weary of adding this serialization option as it could be easily misused.

Addressed in #3313/#3314:

1/3 Serialize sparse MAST forests #3313 keeps MastNodeId serializable but removes the blanket Deserializable impl,

The sparse reader reads raw IDs only through a local helper that checks the source node count

2/3 Serialize trace proving inputs #3314 uses local trace replay readers instead of a global MastNodeId::read_from,

huitseeker · 2026-06-30T23:16:08Z

Closing this version because the change is too large as one PR. It has been replaced by three smaller PRs:

These keep the same code changes, split by scope.

huitseeker requested a review from plafer June 23, 2026 22:59

huitseeker changed the title ~~Trace proving inputs serialization~~ serialize trusted trace proving inputs Jun 23, 2026

huitseeker changed the title ~~serialize trusted trace proving inputs~~ feat: serialize trusted trace proving inputs Jun 23, 2026

huitseeker marked this pull request as ready for review June 23, 2026 23:22

plafer approved these changes Jun 24, 2026

View reviewed changes

Comment thread core/src/mast/mod.rs

Comment thread core/src/mast/serialization/tests.rs

huitseeker force-pushed the trace-proving-inputs-serialization branch from c8d1bda to b661a6f Compare June 25, 2026 14:36

huitseeker added this to the v0.25.0 milestone Jun 25, 2026

huitseeker force-pushed the trace-proving-inputs-serialization branch from 54df782 to cf221e4 Compare June 25, 2026 20:00

This was referenced Jun 26, 2026

Serialize MAST commitment inputs in forest payloads #3294

Closed

Debug info encoder decoder #3276

Open

huitseeker added 12 commits June 29, 2026 10:44

Serialize trace proving inputs

c2916ba

Add arbitrary roundtrips for trace inputs

35922a0

Wire crypto testing for arbitrary impls

cd6c0de

Use upstream arbitrary strategies in trace tests

948432d

Split trace state tests

0139d6b

Clarify sparse replay serialization scope

254aac9

Strengthen trace input round-trip tests

9dff27c

chore: Changelog

893bcd5

Address trace input review feedback

b4d632a

chore: Refresh miden-core-fuzz lockfile

e9669b9

fix: Remove redundant sparse test clone

26ea7f7

docs: Clarify trusted trace input readers

0c4c6f4

huitseeker force-pushed the trace-proving-inputs-serialization branch from cf221e4 to 0c4c6f4 Compare June 29, 2026 14:45

bobbinth reviewed Jun 30, 2026

View reviewed changes

huitseeker mentioned this pull request Jun 30, 2026

Add Commitment Input Sections to MAST Forest Serialization #3291

Closed

huitseeker closed this Jun 30, 2026

huitseeker mentioned this pull request Jul 6, 2026

1/3 Serialize sparse MAST forests #3313

Merged

huitseeker deleted the trace-proving-inputs-serialization branch July 21, 2026 14:09

Uh oh!

Conversation

huitseeker commented Jun 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

plafer left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

huitseeker commented Jun 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bobbinth commented Jun 28, 2026

Uh oh!

huitseeker commented Jun 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bobbinth left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

huitseeker commented Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

huitseeker commented Jun 23, 2026 •

edited

Loading

huitseeker commented Jun 25, 2026 •

edited

Loading

huitseeker commented Jun 29, 2026 •

edited

Loading

huitseeker commented Jun 30, 2026 •

edited

Loading