feat: user batch support by Mirko-von-Leipzig · Pull Request #1846 · 0xMiden/node

Mirko-von-Leipzig · 2026-03-26T16:25:14Z

This PR is the third and final part of the mempool refactoring PR stack. Part 1 (#1820) performs the broad mempool refactoring to simplify this PR. Builds on part 2 (#1832).

Batch submissions must include their transaction inputs since we currently require this for the validator to verify them before inclusion in a block. This PR abuses this by treating the batch as a set of normal transactions at the mempool level. This simplifies the mempool implementation, which is currently built around a DAG of transactions - so having to insert a batch directly would be more complex. This will need to change once we stop requiring transaction inputs as part of the validator; but it won't be too bad.

The way this is implemented here, is that the transaction DAG tracks user batches and ensures that when a batch is selected, that transactions from user batches are not mixed with conventional transactions. That is, select_batch outputs either a user batch, or a conventional batch.

Effectively, the transaction DAG internally ensures that the user batch's transactions remain coherent even though the batch has been deconstructed into individual transactions. The benefit is that this doesn't require any major structural changes to the mempool. The rest of the mempool then treats the user batch as per normal.

Closes #1112 and closes #1859

Mirko-von-Leipzig · 2026-03-26T16:32:33Z

proto/proto/types/transaction.proto

-    // Encoded using [winter_utils::Serializable] implementation for
-    // [miden_protocol::transaction::proven_tx::ProvenTransaction].
-    bytes encoded = 1;
+message TransactionBatch {


The suggestion here I think was to re-add the proven_batch property, and have the others be optional so we can drop them at some point.

This is probably fine for now, but in the next release, we'll need to change this to something like ProvenTransactionBatch which would contain the ProvenBatch struct + optional data that would allow us to re-execute all transactions in the batch and validate that the proven batch is correct (similar to how we do it for proven transactions).

I've added it in now. Naming might still be off, e.g. TransactionBatch but I think maybe its more useful to end users than Batch.. maybe not though.

Mirko-von-Leipzig · 2026-03-26T16:36:08Z

crates/rpc/src/server/api.rs

@PhilippGackstatter if you could throw an eye on the process here to ensure I'm checking the correct things.

The state itself is checked in the mempool, so here we really just want to ensure that the batch and its transactions are valid and the reference block is correct iiuc.

Looks good to me. I left another comment re batch expiration, but your call where/if to do that.

crates/rpc/src/server/api.rs

crates/block-producer/src/mempool/graph/transaction.rs

sergerad · 2026-03-27T01:10:06Z

crates/block-producer/src/mempool/mod.rs

+        &mut self,
+        txs: &[Arc<AuthenticatedTransaction>],
+    ) -> Result<BlockNumber, MempoolSubmissionError> {
+        assert!(!txs.is_empty(), "Cannot have a batch with no transactions");


Just checking we want to crash here instead of return error

I assumed that one cannot build a ProvenBatch without one, so this would indicate an internal bug somewhere. But maybe that's a poor assumption.

sergerad · 2026-03-27T01:11:38Z

crates/block-producer/src/mempool/graph/transaction.rs

+    }
+
+    pub fn select_batch(&mut self, budget: BatchBudget) -> Option<SelectedBatch> {
+        self.select_user_batch().or_else(|| self.select_conventional_batch(budget))


Might want some doc comments to make it clear that budget is intended to only relevant for conventional batches.

Also are we OK with user batches always taking priority over conventional here?

Also wondering if we need to prevent user batches of size 1 (or some other limit). Unsure if that is relevant to this PR just a general thought.

Also are we OK with user batches always taking priority over conventional here?

I'm unsure, but at the moment it doesn't matter much. If its a concern we can make it random -- I was thinking maybe that's best.

Also wondering if we need to prevent user batches of size 1 (or some other limit). Unsure if that is relevant to this PR just a general thought.

Good question. I'm unsure 😬 I wonder if that makes some user loop more difficult i.e. they always submit user batches, but sometimes they don't have many transactions to bundle..

Probably we would want some limit even in the future? cc @bobbinth

Also are we OK with user batches always taking priority over conventional here?

Would having fees solve this?

It would give us a strategy to use, so yes fees solve this imo. Though it will be potentially complex to implement.

crates/block-producer/src/mempool/mod.rs

crates/block-producer/src/server/mod.rs

igamigo

LGTM! I left some mostly minor, non-blocking comments. Not sure if you tested already but jsut in case, I'm going to run the client integration tests and report back.

crates/block-producer/src/mempool/graph/batch.rs

crates/block-producer/src/mempool/graph/dag.rs

igamigo · 2026-03-27T18:30:42Z

crates/block-producer/src/mempool/graph/transaction.rs

+    }
+
+    pub fn select_batch(&mut self, budget: BatchBudget) -> Option<SelectedBatch> {
+        self.select_user_batch().or_else(|| self.select_conventional_batch(budget))


Also are we OK with user batches always taking priority over conventional here?

Would having fees solve this?

crates/block-producer/src/mempool/graph/transaction.rs

crates/block-producer/src/server/mod.rs

crates/rpc/src/server/api.rs

Mirko-von-Leipzig · 2026-03-30T12:52:25Z

crates/rpc/src/server/api.rs

+        // Verify batch transaction proofs.
+        //
+        // Need to do this because ProvenBatch has no real kernel yet, so we can only
+        // really check that the calculated proof matches the one given in the request.
+        let expected_proof = LocalBatchProver::new(MIN_PROOF_SECURITY_LEVEL)
+            .prove(proposed_batch.clone())
+            .map_err(|err| {
+                Status::invalid_argument(err.as_report_context("proposed block proof failed"))
+            })?;
+
+        if expected_proof != proven_batch {
+            return Err(Status::invalid_argument("batch proof did not match proposed batch"));
+        }


Is this the idea? I'm unsure on how else to align the proof with the batch.. unless I also compare headers and then just assume?

Can a proof differ based on some other variables e.g. time, rng? Or is this safe to do.

cc @PhilippGackstatter

That seems fine and sufficient. The "proof" (which is not a cryptographic one now anyway) should be deterministic based on the input (the proposed batch), since it's really just destructuring the proposed batch, verifying transaction proofs and constructing the proven batch.

crates/rpc/src/server/api.rs

crates/block-producer/src/server/mod.rs

PhilippGackstatter · 2026-03-31T15:19:42Z

crates/rpc/src/server/api.rs

+                "batch reference commitment {} at block {} does not match canonical chain's commitment of {}",
+                expected_proof.reference_block_num(),
+                expected_proof.reference_block_commitment(),
+                reference_header.commitment()


Suggested change

"batch reference commitment {} at block {} does not match canonical chain's commitment of {}",

expected_proof.reference_block_num(),

expected_proof.reference_block_commitment(),

reference_header.commitment()

"batch reference commitment {} at block {} does not match canonical chain's commitment of {}",

expected_proof.reference_block_commitment(),

expected_proof.reference_block_num(),

reference_header.commitment()

Nit: I think these need to be swapped

PhilippGackstatter · 2026-03-31T15:23:49Z

crates/rpc/src/server/api.rs

+        }
+


Is the batch expiration deliberately not checked? This would also be a pretty cheap check, assuming the latest block is easily retrievable here. E.g. if the batch expiration is already older than the latest block, we should be able to discard it directly.

PhilippGackstatter · 2026-03-31T15:24:53Z

crates/rpc/src/server/api.rs

Looks good to me. I left another comment re batch expiration, but your call where/if to do that.

Mirko-von-Leipzig force-pushed the mirko/mempool-user-batches branch 2 times, most recently from 51e74e4 to 6dd5f53 Compare March 26, 2026 16:31

Mirko-von-Leipzig commented Mar 26, 2026

View reviewed changes

Mirko-von-Leipzig marked this pull request as ready for review March 26, 2026 16:34

Mirko-von-Leipzig requested review from PhilippGackstatter, bobbinth, igamigo and sergerad March 26, 2026 16:34

Mirko-von-Leipzig commented Mar 26, 2026

View reviewed changes

crates/rpc/src/server/api.rs Outdated Show resolved Hide resolved

sergerad reviewed Mar 27, 2026

View reviewed changes

crates/block-producer/src/mempool/graph/transaction.rs Outdated Show resolved Hide resolved

sergerad reviewed Mar 27, 2026

View reviewed changes

crates/block-producer/src/mempool/mod.rs Outdated Show resolved Hide resolved

sergerad reviewed Mar 27, 2026

View reviewed changes

crates/block-producer/src/server/mod.rs Show resolved Hide resolved

igamigo approved these changes Mar 27, 2026

View reviewed changes

Base automatically changed from mirko/mempool-tx-reverting to next March 29, 2026 09:02

Merge next

a474113

Mirko-von-Leipzig force-pushed the mirko/mempool-user-batches branch from 681eb87 to a474113 Compare March 30, 2026 08:39

Mirko-von-Leipzig mentioned this pull request Mar 30, 2026

feat(mempool): revert transactions after 3 failures #1832

Merged

Mirko-von-Leipzig added 2 commits March 30, 2026 10:58

Improve comments & address review

2892014

Fix reference header commitment check

149f3ab

Mirko-von-Leipzig commented Mar 30, 2026

View reviewed changes

Require ProvenBatch in gRPC

e528296

Mirko-von-Leipzig force-pushed the mirko/mempool-user-batches branch from 1e09f16 to e528296 Compare March 30, 2026 13:21

sergerad reviewed Mar 31, 2026

View reviewed changes

crates/rpc/src/server/api.rs Outdated Show resolved Hide resolved

sergerad reviewed Mar 31, 2026

View reviewed changes

crates/block-producer/src/server/mod.rs Show resolved Hide resolved

Fix typo

7f2bce1

PhilippGackstatter reviewed Mar 31, 2026

View reviewed changes

Conversation

Mirko-von-Leipzig commented Mar 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

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!

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!

igamigo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Mirko-von-Leipzig commented Mar 26, 2026 •

edited

Loading