chore: ntx-builder subs to block stream + sync before execution by SantiagoPittella · Pull Request #2085 · 0xMiden/node

SantiagoPittella · 2026-05-15T21:30:53Z

closes #1952

This PR replaces that with a subscription to the store's stream of committed blocks: the builder now derives all network-relevant state: new network notes, network-account updates, and nullifiers directly from SignedBlocks via a new CommittedBlockEffects, and only ever sees committed state. Inflight tracking, the mempool replay path, and the purge_inflight startup step are gone, and references to inflight transactions in the DB layer have been replaced with commitment-based bookkeeping.

To support this, the NtxBuilder gRPC service gains a BlockSubscription RPC (and removes GetBlockHeaderByNumber removed), sharing its implementation with StoreReplica::BlockSubscription so the ntx-builder can drive everything through a single store client. On startup the builder reads its last applied block from the DB, opens the subscription from that point, and runs a dedicated catch-up phase that drains the stream up to the current chain tip before any account actors are spawned, ensuring actors only ever observe a DB that is consistent with the tip.

Submitted network transactions now carry an expiration delta (default 5 blocks, configurable via tx_expiration_delta).

test: add test for ntx builder block sync

add ntx install to makefile fix lint remove inflight tx support

sergerad · 2026-05-19T01:33:50Z

 - [BREAKING] Removed `miden-node ntx-builder` subcommand and created a separate `miden-ntx-builder` binary ([#2067](https://github.com/0xMiden/node/pull/2067)).
 - [BREAKING] Reworked note proto types for multi-attachment support: `NoteMetadata` now carries `attachment_schemes` (repeated) and `attachments_commitment` instead of a single `attachment`. `Note` and `NetworkNote` gained an `attachments` field. `NoteSyncRecord` now embeds full `NoteMetadata` instead of `NoteMetadataHeader`. Removed `NoteAttachmentKind` enum and `NoteMetadataHeader` message ([#2078](https://github.com/0xMiden/node/pull/2078)).
 - [BREAKING] Changed `SyncChainMmr` endpoint: the upper end of the block range we're syncing is now the chain tip with the requested finality level. Validator signature is also returned ([#2075](https://github.com/0xMiden/node/pull/2075)).
+- Switched the network transaction builder from mempool subscription to the store's committed-block subscription: on startup it resumes from its persisted block, catches up to the chain tip before spawning any account actors, and applies committed network-account updates, notes, and nullifiers from each block. Submitted transactions now carry a configurable expiration delta (default 5 blocks).


Do we need a changelog entry for this? Need link to PR if we keep it.

I think we can consider this internal-only refactoring, so not needed.

However the expiration config item should be added I think.

sergerad · 2026-05-19T04:58:44Z

Have had a pass of this and LGTM more or less. Will have another pass tomorrow. Quite large change set

Mirko-von-Leipzig · 2026-05-19T11:31:56Z

We shouldn't need any additional endpoints except for this one - so in theory we could yank this service and use the RPC's streaming method only?

But maybe I've missed something. We can also do this in a follow-up PR so its less noisy perhaps..

I didn't fully removed some of the calls to other endpoints yet. Basically changed the mempool subscription and the sync to use the block subscription but we still use get_current_blockchain_data to get the chain tip but this can be removed if the blockchain subscription also returns the chain tip I think.

Then we have a couple of methods used by our DataStore implementation for execution:

get_account

get_vault_asset_witnesses

get_storage_map_witness

get_note_script_by_root

And then we use some endpoints for account hydratation:

get_network_account_details_by_id and get_network_account to fetch the full Account state for an account not yet in the local DB.

get_unconsumed_network_notes.

We use this last two when we initialize the ntx-builder from an existing node, otherwise we will need to start every new (one with an empty database) ntx-builder from genesis

If we go only with block subscription from the genesis, during catch up we are only going to accumulate the partial accounts from the beginning to the chain tip instead of just fetching the account state. Should we store the notes from the very beginning despite we have a large amount of blocks to sync? Or should we discard them?

This PR is a commit on top of this changes moving to only the block subscription #2109

Let me know wdyt if I should keep that path

It is inefficient but imo much simpler if we just process block-by-block.

Ideally we would also always be in-sync so what we're "optimising" for here is really a cold start/reset of the ntx builder. Which is okay, but I think not something we should focus on.

I'll checkout the linked PR 👍

Mirko-von-Leipzig · 2026-05-19T11:34:26Z

+pub fn compile_expiration_tx_script(tx_expiration_delta: u16) -> TransactionScript {
+    let script_src = format!(
+        "begin\n    push.{tx_expiration_delta}\n    exec.::miden::protocol::tx::update_expiration_block_delta\nend",
+    );
+    CodeBuilder::new()
+        .compile_tx_script(script_src.as_str())
+        .expect("expiration tx script should compile")


I did not realize this had to be inserted as masm code 🤔 I somehow thought its something you specify on the transaction/builder itself.. But I guess it makes sense,

Mirko-von-Leipzig · 2026-05-19T11:45:04Z

+    /// Network accounts are only ever updated by ntx-builder transactions, so a commitment change
+    /// here is equivalent to "some submission for this account has been included in a block."
+    WaitForNextBlock {
+        submitted_commitment: Word,
+        submitted_at: BlockNumber,
+    },


Do we have a problem with pass-through transactions maybe? As in, if the network account for whatever reason just acts as a pass-through then the commitment wouldn't change even though the transaction has been committed?

Maybe a better model is

Suggested change

/// Network accounts are only ever updated by ntx-builder transactions, so a commitment change

/// here is equivalent to "some submission for this account has been included in a block."

WaitForNextBlock {

submitted_commitment: Word,

submitted_at: BlockNumber,

},

TransactionSubmitted {

transaction: TransactionId,

expires_at: BlockNumber,

},

though this might mean we need to track the latest committed transaction ID for a given account?

Or we need to allow inspection of the block by actors and our notify model is overly simplistic?

Something else.. We should probably store the transaction itself so we can apply its delta to the local account without having to hit the database again.

Mirko-von-Leipzig · 2026-05-19T11:45:50Z

We could use backon here already since you're actively changing it :)

Mirko-von-Leipzig · 2026-05-19T12:00:21Z

+    /// Notifies every active actor that a new block has been applied.
+    ///
+    /// Called once per committed block so that actors waiting on their own submitted transaction
+    /// (in [`ActorMode::WaitForNextBlock`](crate::actor::ActorMode)) reliably wake up even when
+    /// the block did not touch their account.
+    pub fn notify_all(&self) {
+        for handle in self.actor_registry.values() {
+            handle.notify();
+        }
+    }


Ah.. I didn't think of this 🤔

This is okay for now, but we should figure out a better approach in the future.

Mirko-von-Leipzig · 2026-05-19T12:05:29Z

+        while self.last_applied_block < target {
+            let block = self
+                .block_stream


We should consider adding the chain tip to the block stream so that we can always know from within the stream where we want to get to.

So we would sync until we hit the actual current tip.

Alternatively, what we can do now, is loop in the caller by checking after the catch up ends that the current store chain tip is within a couple of blocks of the latest block streamed.

For example if you need to stream a million blocks, then by the time you get there the chain tip will be like.. a thousand blocks ahead.

i.e. something like:

let mut local_tip = db.chain_tip.block_number; loop { let chain_tip = client.store.latest_block().block_num(); if local_tip + 5 > chain_tip { break; } local_tip = self.catch_up(chain_tip).await; }

SantiagoPittella force-pushed the santiagopittella-block-subscription-and-sync branch 2 times, most recently from 5562325 to c765e9a Compare May 18, 2026 19:04

SantiagoPittella added 4 commits May 18, 2026 16:34

chore: ntx-builder subs to block stream + sync before execution

0362e42

test: add test for ntx builder block sync

fix ntx builder store replica

509f4e2

fix: inflight txs wasn't stopping generation

b1a599a

fix: use commitment instead of nullifiers, remove inflight tx mentions"

e337b7d

add ntx install to makefile fix lint remove inflight tx support

SantiagoPittella force-pushed the santiagopittella-block-subscription-and-sync branch from 8473127 to e337b7d Compare May 18, 2026 19:41

SantiagoPittella added 3 commits May 18, 2026 16:55

chore: remove deprecated endpoint for ntx builder

67d113a

remove store replica usage, add block stream to ntx builder store proto

1bbb08a

remove store replica client

339f0a7

SantiagoPittella marked this pull request as ready for review May 18, 2026 20:43

SantiagoPittella requested review from Mirko-von-Leipzig, kkovaacs and sergerad May 18, 2026 20:43

SantiagoPittella mentioned this pull request May 18, 2026

chore: avoid hammering store at ntx builder startup #2064

Closed

sergerad reviewed May 19, 2026

View reviewed changes

Mirko-von-Leipzig reviewed May 19, 2026

View reviewed changes

SantiagoPittella added 2 commits May 19, 2026 10:05

Merge branch 'next' into santiagopittella-block-subscription-and-sync

6a31203

review: changelog + add missing parameter to CLI

c9d19bb

Conversation

SantiagoPittella commented May 15, 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!

sergerad commented May 19, 2026

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!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

SantiagoPittella commented May 15, 2026 •

edited

Loading