Skip to content

Create BLS accumulator benchmarks with UTxO #2346

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 19 commits into
base: vrom911/partial-fanout-SignableRepresentation
Choose a base branch
from
Open

Create BLS accumulator benchmarks with UTxO #2346

wants to merge 19 commits into from

Conversation

@vrom911
Copy link
Contributor

@vrom911 vrom911 commented Nov 10, 2025 •
edited by noonio
Loading

Fixes #1666

  • CHANGELOG updated or not needed
  • Documentation updated or not needed
  • Haddocks updated or not needed
  • No new TODOs introduced or explained herafter

@vrom911 vrom911 self-assigned this Nov 10, 2025
@vrom911 vrom911 force-pushed the vrom911/bench-accumulator branch from 2c4d4e2 to b0ca262 Compare November 10, 2025 14:04
@github-actions
Copy link

github-actions bot commented Nov 10, 2025

Transaction costs

Sizes and execution budgets for Hydra protocol transactions. Note that unlisted parameters are currently using arbitrary values and results are not fully deterministic and comparable to previous runs.

Metadata
Generated at 2025-11-10 14:13:05.31667382 UTC
Max. memory units 14000000
Max. CPU units 10000000000
Max. tx size (kB) 16384

Script summary

Name Hash Size (Bytes)
νInitial c8a101a5c8ac4816b0dceb59ce31fc2258e387de828f02961d2f2045 2652
νCommit 61458bc2f297fff3cc5df6ac7ab57cefd87763b0b7bd722146a1035c 685
νHead e93fdca2467a7aac18e88f63b0f474a78abfba366bdd92078d7f8351 14855
μHead 7abbe644c0bd13fa58c9d34699d054e13bb30cde2cc61d30858284e9* 5316
νDeposit ae01dade3a9c346d5c93ae3ce339412b90a0b8f83f94ec6baa24e30c 1102
  • The minting policy hash is only usable for comparison. As the script is parameterized, the actual script is unique per head.

Init transaction costs

Parties Tx size % max Mem % max CPU Min fee ₳
1 5869 11.04 3.52 0.52
2 6073 12.67 4.01 0.55
3 6268 14.72 4.66 0.58
5 6672 19.10 6.05 0.64
10 7678 28.81 9.07 0.79
43 14314 98.76 30.86 1.80

Commit transaction costs

This uses ada-only outputs for better comparability.

UTxO Tx size % max Mem % max CPU Min fee ₳
1 561 2.44 1.16 0.20
2 741 3.38 1.73 0.22
3 920 4.36 2.33 0.24
5 1283 6.41 3.60 0.28
10 2172 12.13 7.25 0.40
54 10062 98.61 68.52 1.88

CollectCom transaction costs

Parties UTxO (bytes) Tx size % max Mem % max CPU Min fee ₳
1 57 525 24.42 7.12 0.42
2 113 636 34.27 9.87 0.53
3 169 747 43.92 12.57 0.63
4 226 858 53.93 15.36 0.73
5 282 969 55.79 16.16 0.76
6 338 1081 68.24 19.61 0.89
7 394 1192 86.69 24.39 1.08
8 450 1303 96.75 27.29 1.19

Cost of Increment Transaction

Parties Tx size % max Mem % max CPU Min fee ₳
1 2139 24.34 7.81 0.50
2 2336 25.94 9.07 0.53
3 2678 28.47 10.69 0.58
5 2930 30.14 12.93 0.62
10 4134 39.60 21.07 0.80
38 10848 95.79 89.93 2.05

Cost of Decrement Transaction

Parties Tx size % max Mem % max CPU Min fee ₳
1 630 22.82 7.39 0.42
2 770 24.36 8.52 0.44
3 852 24.09 9.10 0.45
5 1698 30.03 12.76 0.56
10 3154 40.77 21.65 0.77
38 10298 96.15 95.56 2.07

Close transaction costs

Parties Tx size % max Mem % max CPU Min fee ₳
1 846 30.07 9.22 0.50
2 979 31.22 10.27 0.52
3 1215 36.26 12.46 0.59
5 2089 38.74 15.41 0.67
10 3518 49.34 24.66 0.88
33 9985 99.80 90.72 2.05

Contest transaction costs

Parties Tx size % max Mem % max CPU Min fee ₳
1 6719 36.08 12.44 0.83
2 7029 38.33 15.51 0.88
3 7200 41.90 18.89 0.94
5 7489 45.35 24.71 1.02
10 7953 59.20 39.70 1.26
25 9775 96.86 81.33 1.95

Abort transaction costs

There is some variation due to the random mixture of initial and already committed outputs.

Parties Tx size % max Mem % max CPU Min fee ₳
1 5847 26.92 9.04 0.69
2 5993 35.91 12.06 0.79
3 6147 45.96 15.49 0.90
4 6197 51.38 17.27 0.96
5 6481 64.85 21.87 1.12
6 6509 73.50 24.73 1.21
7 6831 84.21 28.41 1.34
8 6970 94.54 31.98 1.45
9 6882 95.83 32.28 1.46

FanOut transaction costs

Involves spending head output and burning head tokens. Uses ada-only UTXO for better comparability.

Parties UTxO UTxO (bytes) Tx size % max Mem % max CPU Min fee ₳
10 0 0 5867 19.21 6.42 0.61
10 1 57 5900 19.92 6.77 0.62
10 5 285 6036 28.23 10.05 0.72
10 10 570 6207 38.64 14.16 0.84
10 20 1138 6545 58.68 22.08 1.07
10 30 1705 6883 80.50 30.62 1.32
10 39 2220 7192 99.14 37.96 1.54

End-to-end benchmark results

This page is intended to collect the latest end-to-end benchmark results produced by Hydra's continuous integration (CI) system from the latest master code.

Please note that these results are approximate as they are currently produced from limited cloud VMs and not controlled hardware. Rather than focusing on the absolute results, the emphasis should be on relative results, such as how the timings for a scenario evolve as the code changes.

Generated at 2025-11-10 14:15:33.774218353 UTC

Baseline Scenario

Number of nodes 1
Number of txs 300
Avg. Confirmation Time (ms) 5.619341980
P99 8.522205879999996ms
P95 7.151857850000001ms
P50 5.3905525ms
Number of Invalid txs 0

Memory data

Time Used Free
2025-11-10 14:14:06.063688697 UTC 1474M 7172M
2025-11-10 14:14:07.063684824 UTC 1498M 7114M
2025-11-10 14:14:08.063654487 UTC 1502M 7110M
2025-11-10 14:14:09.06359752 UTC 1528M 7083M
2025-11-10 14:14:10.063590084 UTC 1571M 6965M
2025-11-10 14:14:11.063694178 UTC 1576M 6960M
2025-11-10 14:14:12.063608159 UTC 1588M 6945M
2025-11-10 14:14:13.063635825 UTC 1603M 6925M
2025-11-10 14:14:14.063638554 UTC 1602M 6925M
2025-11-10 14:14:15.063635949 UTC 1602M 6925M
2025-11-10 14:14:16.063643005 UTC 1602M 6925M
2025-11-10 14:14:17.063633647 UTC 1602M 6925M
2025-11-10 14:14:18.063639468 UTC 1602M 6925M
2025-11-10 14:14:19.063641502 UTC 1606M 6921M
2025-11-10 14:14:20.063640369 UTC 1606M 6921M
2025-11-10 14:14:21.063641834 UTC 1606M 6921M
2025-11-10 14:14:22.06361371 UTC 1606M 6921M
2025-11-10 14:14:23.063669764 UTC 1606M 6921M
2025-11-10 14:14:24.063697208 UTC 1606M 6921M
2025-11-10 14:14:25.063671047 UTC 1605M 6921M
2025-11-10 14:14:26.063609779 UTC 1605M 6921M
2025-11-10 14:14:27.063658975 UTC 1606M 6921M
2025-11-10 14:14:28.063660522 UTC 1606M 6921M
2025-11-10 14:14:29.063663984 UTC 1605M 6921M
2025-11-10 14:14:30.063629754 UTC 1608M 6918M
2025-11-10 14:14:31.06368491 UTC 1608M 6917M
2025-11-10 14:14:32.063706624 UTC 1608M 6917M
2025-11-10 14:14:33.063667104 UTC 1608M 6917M
2025-11-10 14:14:34.063640107 UTC 1608M 6917M
2025-11-10 14:14:35.063669924 UTC 1608M 6917M

Three local nodes

Number of nodes 3
Number of txs 900
Avg. Confirmation Time (ms) 43.507685110
P99 82.26066519ms
P95 71.31054295ms
P50 40.144174500000005ms
Number of Invalid txs 0

Memory data

Time Used Free
2025-11-10 14:14:46.706080119 UTC 1484M 7080M
2025-11-10 14:14:47.706049287 UTC 1484M 7079M
2025-11-10 14:14:48.705976882 UTC 1494M 7069M
2025-11-10 14:14:49.706017857 UTC 1496M 7068M
2025-11-10 14:14:50.70601571 UTC 1496M 7067M
2025-11-10 14:14:51.706025966 UTC 1504M 7059M
2025-11-10 14:14:52.706047991 UTC 1504M 7058M
2025-11-10 14:14:53.706117054 UTC 1569M 6966M
2025-11-10 14:14:54.706083168 UTC 1636M 6871M
2025-11-10 14:14:55.706135052 UTC 1701M 6778M
2025-11-10 14:14:56.706414092 UTC 1741M 6738M
2025-11-10 14:14:57.706640106 UTC 1754M 6724M
2025-11-10 14:14:58.708308597 UTC 1801M 6667M
2025-11-10 14:14:59.70620826 UTC 1806M 6650M
2025-11-10 14:15:00.706340256 UTC 1830M 6614M
2025-11-10 14:15:01.709700911 UTC 1835M 6598M
2025-11-10 14:15:02.706813889 UTC 1838M 6586M
2025-11-10 14:15:03.706187315 UTC 1847M 6571M
2025-11-10 14:15:04.706560941 UTC 1862M 6549M
2025-11-10 14:15:05.706072569 UTC 1879M 6525M
2025-11-10 14:15:06.708301285 UTC 1890M 6506M
2025-11-10 14:15:07.706831589 UTC 1891M 6497M
2025-11-10 14:15:08.706905626 UTC 1892M 6487M
2025-11-10 14:15:09.706405051 UTC 1906M 6466M
2025-11-10 14:15:10.705978982 UTC 1917M 6444M
2025-11-10 14:15:11.706071995 UTC 1920M 6437M
2025-11-10 14:15:12.706107439 UTC 1920M 6437M
2025-11-10 14:15:13.706114729 UTC 1920M 6437M
2025-11-10 14:15:14.706157192 UTC 1927M 6429M
2025-11-10 14:15:15.706123057 UTC 1927M 6429M
2025-11-10 14:15:16.706151066 UTC 1927M 6429M
2025-11-10 14:15:17.706162347 UTC 1927M 6429M
2025-11-10 14:15:18.706084881 UTC 1927M 6429M
2025-11-10 14:15:19.706137311 UTC 1927M 6429M
2025-11-10 14:15:20.706016095 UTC 1927M 6429M
2025-11-10 14:15:21.706023923 UTC 1927M 6428M
2025-11-10 14:15:22.706177096 UTC 1927M 6428M
2025-11-10 14:15:23.706134245 UTC 1927M 6428M
2025-11-10 14:15:24.706158054 UTC 1927M 6428M
2025-11-10 14:15:25.706141192 UTC 1930M 6425M
2025-11-10 14:15:26.706219411 UTC 1930M 6425M
2025-11-10 14:15:27.706178454 UTC 1930M 6425M
2025-11-10 14:15:28.706151264 UTC 1930M 6425M
2025-11-10 14:15:29.706093658 UTC 1929M 6425M
2025-11-10 14:15:30.705922132 UTC 1929M 6425M
2025-11-10 14:15:31.706168929 UTC 1930M 6423M
2025-11-10 14:15:32.70612756 UTC 1934M 6419M
2025-11-10 14:15:33.705908176 UTC 1934M 6419M

@vrom911 vrom911 requested a review from a team November 10, 2025 14:34
noonio
noonio reviewed Nov 10, 2025
View reviewed changes
hydra-tx/bench/accumulator/Main.hs
acc500 = buildFromUTxO @Tx utxo500
acc1000 = buildFromUTxO @Tx utxo1000
acc5000 = buildFromUTxO @Tx utxo5000
acc10000 = buildFromUTxO @Tx utxo10000
Copy link
Contributor

@noonio noonio Nov 10, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

do these need to be the strict let bindings (or something) so that they actually get evaluated here, rather than on first evaluation on the bench?

(not that it matters exactly, given that the numbers are good; i.e. it would only be faster?)

noonio
noonio approved these changes Nov 10, 2025
View reviewed changes
Copy link
Contributor

@noonio noonio left a comment

Choose a reason for hiding this comment

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

Really nice!

@locallycompact
Copy link
Contributor

locallycompact commented Nov 11, 2025

Does this need to be here and not in the haskell-accumulator repo? I don't think it needs to depend on hydra.

@vrom911
Copy link
Contributor Author

vrom911 commented Nov 12, 2025

Does this need to be here and not in the haskell-accumulator repo? I don't think it needs to depend on hydra.

We want to bench it on our UTxO, and I think it is easier to run it how we would use it in the repo to know the implications 🙏🏼

@locallycompact
Copy link
Contributor

locallycompact commented Nov 12, 2025

The UTxO type comes from cardano-api, not from us. I think it's better to measure it where it's defined rather than here so others can use it.

Not blocking merge for this though.

@noonio
Copy link
Contributor

noonio commented Nov 12, 2025

The UTxO type comes from cardano-api, not from us. I think it's better to measure it where it's defined rather than here so
others can use it.

It's a nice observation.

I think in this case we may as well have it here; the benchmark is really only important in the context of Hydra; and who knows what else we may want to add that might make it more Hydra-relevant.

ch1bo
ch1bo approved these changes Nov 12, 2025
View reviewed changes
Copy link
Member

@ch1bo ch1bo left a comment

Choose a reason for hiding this comment

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

Would have loved to see example results in the PR description, especially the HTML output of criterion: https://github.com/haskell/criterion

@v0d1ch v0d1ch changed the title Create BLS accumulator benchmartks with UTxO Create BLS accumulator benchmarks with UTxO Nov 13, 2025
@noonio noonio mentioned this pull request Nov 25, 2025
Closed
2 tasks
@v0d1ch v0d1ch force-pushed the vrom911/partial-fanout-SignableRepresentation branch from b8b3bbd to 5def3a0 Compare November 26, 2025 13:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@ch1bo ch1bo ch1bo approved these changes

@noonio noonio noonio approved these changes

Assignees

@vrom911 vrom911

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@vrom911 @locallycompact @noonio @ch1bo