Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
18 commits
Select commit Hold shift + click to select a range
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions Cargo.lock

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

4 changes: 3 additions & 1 deletion bin/bench-transaction/Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -17,14 +17,16 @@ path = "src/time_counting_benchmarks/prove.rs"

[dependencies]
# Workspace dependencies
miden-agglayer = { features = ["testing"], workspace = true }
miden-protocol = { features = ["testing"], workspace = true }
miden-standards = { workspace = true }
miden-testing = { workspace = true }
miden-tx = { workspace = true }

# External dependencies
anyhow = { workspace = true }
serde = { features = ["derive"], workspace = true }
rand = { workspace = true }
serde = { features = ["derive", "std"], workspace = true }
serde_json = { features = ["preserve_order"], package = "serde_json", version = "1.0" }
tokio = { features = ["macros", "rt"], workspace = true }

Expand Down
21 changes: 20 additions & 1 deletion bin/bench-transaction/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,26 @@

Below we describe how to benchmark Miden transactions.

Benchmarks consist of two groups:
### Benchmarked Transactions

The following transactions are benchmarked:

- **P2ID notes**: Consume single/two P2ID notes, create single P2ID note
- **CLAIM notes (agglayer bridge-in)**: Consume CLAIM note for L1-to-Miden bridging and L2-to-Miden bridging
- **B2AGG note (agglayer bridge-out)**: Consume B2AGG note for Miden-to-AggLayer bridging

The CLAIM note benchmarks measure the full bridge-in flow: the benchmark setup executes
prerequisite transactions (CONFIG_AGG_BRIDGE and UPDATE_GER) to prepare the bridge account,
then benchmarks the CLAIM note consumption transaction itself.

The B2AGG note benchmark measures the bridge-out flow: the benchmark setup registers a faucet
in the bridge via CONFIG_AGG_BRIDGE, then benchmarks the B2AGG note consumption which validates
the faucet, performs FPI to get origin asset data, computes the Keccak leaf hash for the MMR,
and creates a BURN note.

### Benchmark Groups

Each of the above transactions is measured in two groups:
- Benchmarking the transaction execution.
Comment thread
partylikeits1983 marked this conversation as resolved.

For each transaction, data is collected on the number of cycles required to complete:
Expand Down
73 changes: 56 additions & 17 deletions bin/bench-transaction/bench-tx.json
Original file line number Diff line number Diff line change
@@ -1,40 +1,79 @@
{
"consume single P2ID note": {
"prologue": 3487,
"notes_processing": 1831,
"prologue": 3501,
"notes_processing": 1761,
"note_execution": {
"0x1421e92d0f84f11b3e6f84e4e1d193e648eb820666ffb8c50ea818c25a32990c": 1791
"0x62e6fe0d5f649b395b5c3f63736fd7b469fd1e0e867c441696d1a70324d3f9a2": 1721
},
"tx_script_processing": 42,
"epilogue": {
"total": 71195,
"auth_procedure": 69694,
"after_tx_cycles_obtained": 608
"total": 72351,
"auth_procedure": 70846,
"after_tx_cycles_obtained": 612
}
},
"consume two P2ID notes": {
"prologue": 4509,
"notes_processing": 3668,
"prologue": 4537,
"notes_processing": 3600,
"note_execution": {
"0x702c078c74683d33b507e16d9fc67f0be0cc943cd94c1f652e3a60e0f4164d9f": 1791,
"0x92cc0c8c208e3b8bad970c23b2c4b4c24cc8d42626b3f56363ce1a6bbf4c7ac2": 1828
"0x51e09a95d1aa86daa64a59ce960c7a6baba576decf870aa4500e9847c3740bf9": 1721,
"0xf11434d602ac1f69b171c08d5b3352c59c57ecec02e191c61b2a6599269a12c3": 1830
},
"tx_script_processing": 42,
"epilogue": {
"total": 71143,
"auth_procedure": 69668,
"after_tx_cycles_obtained": 608
"total": 72299,
"auth_procedure": 70820,
"after_tx_cycles_obtained": 612
}
},
"create single P2ID note": {
"prologue": 1766,
"notes_processing": 32,
"note_execution": {},
"tx_script_processing": 1682,
"tx_script_processing": 1667,
"epilogue": {
"total": 72099,
"auth_procedure": 69906,
"after_tx_cycles_obtained": 608
"total": 73243,
"auth_procedure": 71058,
"after_tx_cycles_obtained": 612
}
},
"consume CLAIM note (L1 to Miden)": {
"prologue": 2897,
"notes_processing": 28536,
"note_execution": {
"0xdbc80122500b117ed9c951e4f1362424ef081cbda9f7d4af3a6a30d1f029d376": 28496
},
"tx_script_processing": 42,
"epilogue": {
"total": 4093,
"auth_procedure": 880,
"after_tx_cycles_obtained": 612
}
},
"consume CLAIM note (L2 to Miden)": {
"prologue": 2897,
"notes_processing": 40786,
"note_execution": {
"0x1f04a3e738aad3c25b4148a9a1be0c4dfe8cc9ec69171909a730630045dced97": 40746
},
"tx_script_processing": 42,
"epilogue": {
"total": 4093,
"auth_procedure": 880,
"after_tx_cycles_obtained": 612
}
},
"consume B2AGG note (bridge-out)": {
"prologue": 3718,
"notes_processing": 145590,
"note_execution": {
"0xa0e31e2fec803d6cb21681b36ea6312d366d9bae97eea9255e43f3fb95e46524": 145550
},
"tx_script_processing": 42,
"epilogue": {
"total": 13756,
"auth_procedure": 880,
"after_tx_cycles_obtained": 612
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

}
}
}
Loading
Loading