hydra/sha512

[locallycompact]

The added test canSpendFromASha512ScriptOnL2 is evaluating the sha3_512 builtin added to plutus using the Sha512Example plutus script.

See the cabal.project file for the version of modified plutus that we use.

[github-actions]

Transaction cost differences

No cost or size differences found

[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-04-30 13:19:57.866128945 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	0e35115a2c7c13c68ecd8d74e4987c04d4539e337643be20bb3274bd	14756
μHead	57166715eadb8d3135964325c016eea546c21e1c0aae974ca67df9a5*	5541
ν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	6093	11.23	3.50	0.53
2	6294	13.26	4.11	0.56
3	6496	15.50	4.80	0.60
5	6898	20.38	6.31	0.66
10	7904	31.15	9.60	0.82
40	13935	98.61	30.29	1.78

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	739	3.38	1.73	0.22
3	923	4.36	2.33	0.24
5	1277	6.41	3.60	0.28
10	2178	12.13	7.25	0.40
54	10065	98.61	68.52	1.88

CollectCom transaction costs

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	525	26.44	7.58	0.44
2	114	636	33.87	9.75	0.52
3	171	747	43.75	12.54	0.63
4	225	858	53.03	15.08	0.73
5	282	969	63.58	17.98	0.84
6	340	1081	68.02	19.55	0.89
7	394	1192	85.22	24.11	1.06
8	451	1303	83.92	24.05	1.06
9	506	1414	93.62	26.93	1.16

Cost of Increment Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	1786	25.42	8.31	0.49
2	1988	27.70	9.78	0.53
3	2122	29.44	10.98	0.56
5	2459	34.08	13.80	0.63
10	3268	44.48	20.61	0.80
39	7410	97.82	56.95	1.68

Cost of Decrement Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	602	23.71	7.54	0.42
2	692	23.72	8.18	0.43
3	963	29.20	10.39	0.50
5	1220	32.91	12.73	0.56
10	1948	40.86	18.24	0.70
38	6260	99.04	52.93	1.61

Close transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	672	30.95	9.69	0.50
2	839	31.02	10.45	0.51
3	930	34.83	12.19	0.56
5	1370	38.54	15.04	0.63
10	1999	50.21	21.82	0.80
32	5381	98.35	52.01	1.56

Contest transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	679	35.99	11.01	0.55
2	864	38.77	12.62	0.59
3	1004	40.98	13.94	0.63
5	1299	46.32	17.01	0.70
10	2042	57.20	23.68	0.87
27	4601	98.08	47.83	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	5975	28.29	9.32	0.71
2	6058	34.15	11.21	0.77
3	6212	47.00	15.51	0.92
4	6400	57.11	18.84	1.03
5	6610	68.47	22.67	1.16
6	6655	76.62	25.29	1.24
7	6785	87.16	28.83	1.36
8	6858	92.48	30.45	1.42

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	6092	20.58	6.77	0.63
10	1	56	6124	21.79	7.29	0.65
10	5	284	6260	31.23	10.90	0.76
10	10	569	6430	40.96	14.72	0.87
10	20	1138	6769	62.00	22.90	1.11
10	30	1707	7111	83.57	31.25	1.36
10	37	2105	7348	98.48	37.03	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-04-30 13:21:53.516023628 UTC

Baseline Scenario

Number of nodes	1
Number of txs	300
Avg. Confirmation Time (ms)	4.891481413
P99	13.823874659999976ms
P95	6.522103500000001ms
P50	4.31461ms
Number of Invalid txs	0

Memory data

Time	Used	Free
2025-04-30 13:20:36.955274025 UTC	913M	6457M
2025-04-30 13:20:41.95511829 UTC	1036M	6224M
2025-04-30 13:20:46.955062574 UTC	1041M	6219M
2025-04-30 13:20:51.955055885 UTC	1041M	6219M
2025-04-30 13:20:56.955051271 UTC	1043M	6216M
2025-04-30 13:21:01.955024332 UTC	1043M	6216M

Three local nodes

Number of nodes	3
Number of txs	900
Avg. Confirmation Time (ms)	29.208500826
P99	45.04795369ms
P95	39.37171825ms
P50	27.790470499999998ms
Number of Invalid txs	0

Memory data

Time	Used	Free
2025-04-30 13:21:15.797990564 UTC	954M	6314M
2025-04-30 13:21:20.79804578 UTC	1176M	6091M
2025-04-30 13:21:25.798445328 UTC	1238M	5973M
2025-04-30 13:21:30.798057751 UTC	1248M	5910M
2025-04-30 13:21:35.79810062 UTC	1251M	5907M
2025-04-30 13:21:40.798033893 UTC	1253M	5905M
2025-04-30 13:21:45.798068408 UTC	1254M	5902M
2025-04-30 13:21:50.798094606 UTC	1255M	5901M

[ch1bo]

Looks good to me 👍

I'd approve if the target would not be master, as I think we would not want to merge this there?

[ch1bo]

Are you sure this is not optimized away? A hardcoded, known to be correct hash and pre image would make sure this is indeed run and be slightly better example.

[kwxm]

There are official test vectors for various SHA algortihms at the bottom of this page. We use some of these for testing the existing SHA functions in Plutus and I think they include inputs for the functions you're using here as well.

[locallycompact]

No, I assumed as plutus was eager. I agree though.

[locallycompact]

No do not merge this. Protect this branch and merge to it updates from master if needed. (or first rebase against the pending release and then protect)

[ch1bo]

Converted it to a draft so nobody merges it by accident.