Module sync 

Provides the client APIs for synchronizing the client’s local state with the Miden network. It ensures that the client maintains a valid, up-to-date view of the chain.

Overview

This module handles the synchronization process between the local client and the Miden network. The sync operation involves:

• Querying the Miden node for state updates using tracked account IDs, note tags, and nullifier prefixes.
• Processing the received data to update note inclusion proofs, reconcile note state (new, committed, or consumed), and update account states.
• Incorporating new block headers and updating the local Merkle Mountain Range (MMR) with new peaks and authentication nodes.
• Aggregating transaction updates to determine which transactions have been committed or discarded.

The result of the synchronization process is captured in a SyncSummary, which provides a summary of the new block number along with lists of received, committed, and consumed note IDs, updated account IDs, locked accounts, and committed transaction IDs.

Once the data is requested and retrieved, updates are persisted in the client’s store.

Examples

The following example shows how to initiate a state sync and handle the resulting summary:

// Attempt to synchronize the client's state with the Miden network.
// The requested data is based on the client's state: it gets updates for accounts, relevant
// notes, etc. For more information on the data that gets requested, see the doc comments for
// `sync_state()`.
let sync_summary: SyncSummary = client.sync_state().await?;

println!("Synced up to block number: {}", sync_summary.block_num);
println!("Committed notes: {}", sync_summary.committed_notes.len());
println!("Consumed notes: {}", sync_summary.consumed_notes.len());
println!("Updated accounts: {}", sync_summary.updated_accounts.len());
println!("Locked accounts: {}", sync_summary.locked_accounts.len());
println!("Committed transactions: {}", sync_summary.committed_transactions.len());

Ok(())

The sync_state method loops internally until the client is fully synced to the network tip.

For more advanced usage, refer to the individual functions (such as committed_note_updates and consumed_note_updates) to understand how the sync data is processed and applied to the local store.

Structs

AccountUpdates

Contains account changes to apply to the store after a sync request.

BlockUpdates

Contains all the block information that needs to be added in the client’s store after a sync.

NoteTagRecord

Represents a note tag of which the Store can keep track and retrieve.

StateSync

The state sync components encompasses the client’s sync logic. It is then used to request updates from the node and apply them to the relevant elements. The updates are then returned and can be applied to the store to persist the changes.

StateSyncUpdate

Contains all information needed to apply the update in the store after syncing with the node.

SyncSummary

Contains stats about the sync operation.

TransactionUpdateTracker

Contains transaction changes to apply to the store.

Enums

NoteTagSource

Represents the source of the tag. This is used to differentiate between tags that are added by the user and tags that are added automatically by the client to track notes .

NoteUpdateAction

The action to be taken when a note update is received as part of the sync response.

Traits

OnNoteReceived