Deduplicate queryCurrentEraExpr calls

[locallycompact]

Uses inEonForEra to deduplicate calls to queryCurrentEraExpr.

[github-actions]

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-07-09 12:14:38.286798988 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	be6ebc744208c660bf0fdc1cfbb5157477cd305de5b1777e575cbb4c	14665
μHead	1f47a42d1d6edc32ccd834acb19d5db3b2a5232f0bd7eaa8908dc519*	5284
ν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	5841	10.14	3.20	0.51
2	6037	12.79	4.06	0.55
3	6238	14.68	4.64	0.58
5	6640	18.38	5.79	0.63
10	7651	29.09	9.17	0.79
43	14281	98.53	30.78	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	743	3.38	1.73	0.22
3	920	4.36	2.33	0.24
5	1276	6.41	3.60	0.28
10	2168	12.13	7.25	0.40
54	10066	98.61	68.52	1.88

CollectCom transaction costs

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	529	25.20	7.30	0.43
2	114	636	33.26	9.63	0.52
3	169	747	41.39	11.95	0.60
4	225	858	49.58	14.32	0.69
5	284	969	56.08	16.27	0.76
6	338	1081	75.46	21.30	0.96
7	396	1192	76.23	21.92	0.98
8	448	1303	87.87	25.16	1.10
9	506	1414	98.42	28.03	1.21

Cost of Increment Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	1797	23.78	7.94	0.48
2	1930	25.69	9.17	0.51
3	2114	27.92	10.63	0.55
5	2392	31.12	12.97	0.60
10	3198	41.75	19.85	0.77
40	7767	99.39	58.77	1.72

Cost of Decrement Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	610	22.77	7.34	0.41
2	736	24.24	8.41	0.44
3	979	27.95	10.12	0.49
5	1218	29.74	11.96	0.53
10	2051	39.87	18.11	0.69
43	6747	99.97	56.82	1.66

Close transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	714	27.41	8.83	0.47
2	809	30.79	10.47	0.51
3	949	30.65	11.17	0.52
5	1232	36.69	14.39	0.60
10	2068	45.33	20.78	0.76
35	5914	96.06	54.15	1.58

Contest transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	694	33.73	10.51	0.53
2	863	36.37	12.08	0.57
3	995	38.41	13.36	0.60
5	1227	41.68	15.61	0.65
10	2179	54.73	23.45	0.86
29	4793	96.43	49.09	1.49

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	5803	27.01	9.04	0.69
2	5960	36.81	12.37	0.80
3	6030	44.41	14.87	0.88
4	6099	49.92	16.68	0.94
5	6331	61.06	20.48	1.07
6	6421	70.42	23.56	1.17
7	6677	85.34	28.66	1.34
8	6726	90.10	30.20	1.39

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	5834	18.75	6.26	0.60
10	1	57	5868	21.23	7.22	0.63
10	5	284	6004	29.36	10.43	0.73
10	10	568	6172	39.52	14.45	0.85
10	20	1139	6514	59.76	22.45	1.08
10	39	2220	7160	98.99	37.90	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-07-09 12:18:22.630679029 UTC

Baseline Scenario

Number of nodes	1
Number of txs	300
Avg. Confirmation Time (ms)	4.337371510
P99	8.13012457999999ms
P95	5.214044400000001ms
P50	4.149361000000001ms
Number of Invalid txs	0

Memory data

Time	Used	Free
2025-07-09 12:17:07.382532453 UTC	0m	0;
2025-07-09 12:17:12.38251325 UTC	13	0;
2025-07-09 12:17:17.382465513 UTC	6	0;
2025-07-09 12:17:22.382461644 UTC	1	0;
2025-07-09 12:17:27.382505179 UTC	1	0;
2025-07-09 12:17:32.38250707 UTC	1	0;

Three local nodes

Number of nodes	3
Number of txs	900
Avg. Confirmation Time (ms)	28.357713705
P99	43.149817289999994ms
P95	36.88895864999999ms
P50	27.313178999999998ms
Number of Invalid txs	0

Memory data

Time	Used	Free
2025-07-09 12:17:45.40133402 UTC	0m	0;
2025-07-09 12:17:50.402237517 UTC	11	0;
2025-07-09 12:17:55.401807996 UTC	5	0;
2025-07-09 12:18:00.401512236 UTC	22	0;
2025-07-09 12:18:05.401510072 UTC	16	0;
2025-07-09 12:18:10.401451106 UTC	2	0;
2025-07-09 12:18:15.401531165 UTC	2	0;
2025-07-09 12:18:20.401543898 UTC	2	0;

[github-actions]

Transaction cost differences

No cost or size differences found

[ch1bo]

IMO the continuation passing is less clear than the assumeShelleyBasedEraOrThrow.

Furthermore, the new code does a worse job in saying that it throws if the current era is not a shelley based era.

At the very least we should improve the name and/or add documentation about that to queryForCurrentEraInShelleyBasedEraExpr

[locallycompact]

I should have mentioned that I did this to prepare for the loss of UTxO.fromApi when porting to the upstream Cardano.Api.UTxO, where we do not use a new type but only a new ViewPattern, and where we need to unify the ConwayEra witness for UTxO queries.

https://github.com/cardano-scaling/hydra/pull/2061/files#diff-276e1103e4ea3e18432d556cad69781c3436da9f4026132b76cb74ae84c72504R219-R224

I don't know that this could have been done differently but this what I ended up with.

[locallycompact]

Also the name is queryForEraIn${EON}Expr where ShelleyBasedEra and ConwaEraOnwards are the literal Eon names.

[locallycompact]

Actually my opinion might be to push this somewhere where we can leave out the Era assumption and just unify it later, if it works.

[ch1bo]

push this somewhere where we can leave out the Era assumption and just unify it later,

The reason why we query the current era from the node here (and similar functions in this module) is to make the request work across eras.

[locallycompact]

Coercing to Era strikes me as a lie then in that case.