feat(agglayer): add CLAIM note cycle count benchmark by partylikeits1983 · Pull Request #2618 · 0xMiden/protocol

partylikeits1983 · 2026-03-17T13:51:48Z

This PR adds an assertion to the CLAIM note tests which asserts that the cycle count for consuming a CLAIM note should be less than 40k cycles.

Currently the CLAIM note takes ~25662 cycles for L1 to Miden bridging, and ~38547 cycles for L2 to Miden bridging.

Resolves #2590

bobbinth · 2026-03-17T14:58:56Z

Currently the CLAIM note takes ~25662 cycles for L1 to Miden bridging, and ~38547 cycles for L2 to Miden bridging.

Nice! So, we should definitely set the max for network note execution above 32K cycles. Maybe 64K cycles? cc @Mirko-von-Leipzig (not sure what it is set at currently).

Also, how difficult is it to add an actual benchmark? (i.e., similar to what we have for P2ID notes)

Mirko-von-Leipzig · 2026-03-17T15:30:07Z

We don't explicitly configure the executor, so we get the default values for expected and max cycles.

afaict this is set to 536 870 912

    pub const MAX_CYCLES: u32 = 1 << 29;

partylikeits1983 · 2026-03-17T16:09:46Z

Also, how difficult is it to add an actual benchmark? (i.e., similar to what we have for P2ID notes)

I think it would be easy, will update to be more of a true benchmark.

bobbinth · 2026-03-17T17:00:42Z

We don't explicitly configure the executor, so we get the default values for expected and max cycles.

afaict this is set to 536 870 912
    pub const MAX_CYCLES: u32 = 1 << 29;

Ah - let's create an issue in the node to add such a cap (unless we have such an issue already).

mmagician

While on it, could we further add benchmarks for B2AGG note?

bin/bench-transaction/src/context_setups.rs

…and add B2AGG benchmarks

mmagician

LGTM with the disclaimer that I haven't looked at our benchmarks before, so would be good to get another set of eyes on this

crates/miden-testing/tests/agglayer/bridge_in.rs

mmagician · 2026-03-19T16:16:15Z

bin/bench-transaction/src/context_setups.rs

+    // TX0: EXECUTE CONFIG_AGG_BRIDGE NOTE TO REGISTER FAUCET IN BRIDGE
+    let config_executed = mock_chain
+        .build_tx_context(bridge_account.id(), &[config_note.id()], &[])?
+        .build()?
+        .execute()
+        .await?;
+    mock_chain.add_pending_executed_transaction(&config_executed)?;
+    mock_chain.prove_next_block()?;


This is not strictly necessary here as a transaction: we could get the exact same effect by deconstructing the bridge account storage and directly writing to it, if I'm not mistaken.

You're right that we could directly write to the bridge account storage to achieve the same state. However, I kept the CONFIG_AGG_BRIDGE transaction execution here intentionally for two reasons:

It mirrors the real-world flow more closely, making the benchmark setup more representative.

The CONFIG_AGG_BRIDGE execution happens during setup only, it's not included in the benchmarked cycle/time measurements. Only the returned transaction context (CLAIM or B2AGG) is actually benchmarked.

mmagician · 2026-03-19T16:16:32Z

bin/bench-transaction/src/context_setups.rs

+    // TX0: EXECUTE CONFIG_AGG_BRIDGE NOTE TO REGISTER FAUCET IN BRIDGE
+    let config_executed = mock_chain
+        .build_tx_context(bridge_account.id(), &[config_note.id()], &[])?
+        .build()?
+        .execute()
+        .await?;
+    mock_chain.add_pending_executed_transaction(&config_executed)?;
+    mock_chain.prove_next_block()?;
+
+    // TX1: BUILD B2AGG NOTE TRANSACTION CONTEXT (ready to execute)
+    let burn_note_script = StandardNote::BURN.script();
+    let foreign_account_inputs = mock_chain.get_foreign_account_inputs(faucet.id())?;
+    let b2agg_tx_context = mock_chain
+        .build_tx_context(bridge_account.id(), &[b2agg_note.id()], &[])?
+        .add_note_script(burn_note_script)
+        .foreign_accounts(vec![foreign_account_inputs])
+        .disable_debug_mode()
+        .build()?;
+
+    Ok(b2agg_tx_context)


does the benchmark count cycles in all executed txs?

No, the benchmark only counts cycles for the final transaction (the one returned by the setup function). The prerequisite transactions (CONFIG_AGG_BRIDGE, UPDATE_GER) are executed during setup to prepare the bridge account state, but their cycles are not measured.

bin/bench-transaction/README.md

bobbinth · 2026-03-20T23:00:13Z

bin/bench-transaction/bench-tx.json

+    "epilogue": {
+      "total": 13756,
+      "auth_procedure": 880,
+      "after_tx_cycles_obtained": 612


Summarizing these, we get:

CLAIM (L1 → Miden): 35.4K cycles.

CLAIM (L2 → Miden): 48.9K cycles.

B2AGG (Miden → L1/L2): 163.2K cycles.

Currently, the default maximum for network transaction cycles is 65K - so, processing B2AGG notes would not work. We can of course bump up the limited to 256K, but I'm wondering, why is B2AGG note processing so expensive? Is there something we can do to simplify it?

Looking (verify superficially), at what bridge_out procedure does, it seems like maybe updating the MMR frontier may be the most heavy operation there. Do we have any benchmarks on how many cycles it takes to perform this? cc @Fumuran.

We'll investigate, I'll create a separate issue for that though

it seems like maybe updating the MMR frontier may be the most heavy operation there

It for sure takes quite a lot of cycles (only the load_zeros_to_memory takes 1473 cycles itself), but potentially it could be not the only reason. I'll create a benchmark to investigate how many cycles each stage takes.

bin/bench-transaction/README.md

Fumuran

Looks good, thank you! I left just one nit inline.

Fumuran · 2026-03-23T13:00:39Z

crates/miden-agglayer/src/testing/mod.rs

+///
+/// Amounts are serialized as uint256 values (JSON numbers).
+#[derive(Debug, Deserialize)]
+pub struct MmrFrontierVectorsFile {


nit: I believe that the renaming of the MMR Frontier is already in the agglayer branch, so we should use the new name here (it seems like it was rolled back to the old name during the merge, because the diff has the new name in the test_utils.rs).

feat: add cycle count limit assertion

9c05b23

partylikeits1983 changed the base branch from next to agglayer March 17, 2026 13:51

partylikeits1983 marked this pull request as ready for review March 17, 2026 14:48

partylikeits1983 requested review from Fumuran and mmagician and removed request for Fumuran March 17, 2026 14:49

partylikeits1983 self-assigned this Mar 17, 2026

partylikeits1983 marked this pull request as draft March 17, 2026 16:10

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

Limit the number of execution cycles for network txs 0xMiden/node#1800

Closed

partylikeits1983 and others added 3 commits March 18, 2026 13:48

chore: merge latest agglayer

c28ff5b

feat: add CLAIM benchmark

1b6b532

Merge branch 'agglayer' into ajl-claim-cycle-benchmark

8530a7f

partylikeits1983 marked this pull request as ready for review March 18, 2026 13:39

mmagician reviewed Mar 18, 2026

View reviewed changes

bin/bench-transaction/src/context_setups.rs Outdated Show resolved Hide resolved

bin/bench-transaction/src/context_setups.rs Outdated Show resolved Hide resolved

partylikeits1983 added 4 commits March 19, 2026 15:35

refactor: deduplicate test vector types into miden-agglayer::testing …

0d31c1d

…and add B2AGG benchmarks

Merge branch 'agglayer' into ajl-claim-cycle-benchmark

80a3b29

fix: update to new type name

15e8ce8

fix: taplo

9c39898

partylikeits1983 enabled auto-merge (squash) March 19, 2026 13:02

mmagician approved these changes Mar 19, 2026

View reviewed changes

chore: merge latest agglayer

d9556c1

partylikeits1983 added 2 commits March 20, 2026 20:16

refactor: rename ClaimDataSource variants and improve benchmark docs

b9253d5

fix: lint

6d4d247

bobbinth reviewed Mar 20, 2026

View reviewed changes

bin/bench-transaction/README.md Show resolved Hide resolved

mmagician mentioned this pull request Mar 23, 2026

Investigate B2AGG cycle count #2659

Open

partylikeits1983 force-pushed the ajl-claim-cycle-benchmark branch from 4c3fad9 to 6d4d247 Compare March 23, 2026 09:27

chore: merge lastest agglayer

2a423ae

partylikeits1983 disabled auto-merge March 23, 2026 09:29

partylikeits1983 added 2 commits March 23, 2026 12:51

fix: update test vectors path after MMR frontier rename

35fc5e7

fix: resolve merge artifacts from MMR frontier rename

b6a657a

Fumuran approved these changes Mar 23, 2026

View reviewed changes

Conversation

partylikeits1983 commented Mar 17, 2026

Uh oh!

bobbinth commented Mar 17, 2026

Uh oh!

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

Uh oh!

Uh oh!

partylikeits1983 commented Mar 17, 2026

Uh oh!

bobbinth commented Mar 17, 2026

Uh oh!

mmagician left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

mmagician left a comment

Choose a reason for hiding this comment

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!

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!

Fumuran left a comment

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 17, 2026 •

edited

Loading