Remove musl build and use partially statically linked glibc builds ev…

[locallycompact]

…erywhere

[ch1bo]

Why - as we have full static builds working on Linux Amd64 with Musl?

[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-02-24 13:31:30.47163437 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	10.89	3.38	0.53
2	6292	13.47	4.19	0.57
3	6493	15.46	4.79	0.60
5	6897	19.85	6.13	0.66
10	7901	30.97	9.53	0.82
40	13935	98.97	30.42	1.78

Commit transaction costs

This uses ada-only outputs for better comparability.

UTxO	Tx size	% max Mem	% max CPU	Min fee ₳
1	558	2.44	1.16	0.20
2	735	3.38	1.73	0.22
3	917	4.36	2.33	0.24
5	1274	6.41	3.60	0.28
10	2180	12.13	7.25	0.40
54	10067	98.61	68.52	1.88

CollectCom transaction costs

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	525	26.47	7.60	0.44
2	114	636	33.87	9.75	0.52
3	169	747	46.14	13.09	0.65
4	226	858	53.30	15.20	0.73
5	284	974	65.22	18.41	0.85
6	339	1085	73.33	20.85	0.94
7	394	1196	88.94	24.91	1.10
8	450	1303	87.38	24.98	1.09
9	504	1414	96.05	27.40	1.19

Cost of Increment Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	1790	25.42	8.31	0.49
2	2016	27.70	9.79	0.53
3	2061	28.34	10.57	0.55
5	2279	30.31	12.46	0.59
10	3047	41.04	19.27	0.75
39	7424	98.42	57.21	1.68

Cost of Decrement Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	626	23.99	7.62	0.43
2	728	24.85	8.49	0.44
3	827	25.31	9.28	0.46
5	1202	31.64	12.38	0.55
10	1994	42.14	18.59	0.71
39	6329	97.67	53.27	1.60

Close transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	710	29.15	9.22	0.48
2	884	31.56	10.72	0.52
3	977	35.44	12.48	0.57
5	1218	39.32	14.98	0.63
10	1949	46.22	20.53	0.76
34	5559	95.89	52.54	1.55

Contest transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	692	35.95	11.01	0.55
2	764	37.41	12.00	0.57
3	993	41.03	13.95	0.63
5	1388	47.36	17.48	0.72
10	2044	57.39	23.72	0.87
27	4653	97.84	47.86	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	6008	28.20	9.31	0.71
2	6063	34.07	11.19	0.77
3	6220	46.99	15.49	0.92
4	6451	58.37	19.34	1.05
5	6318	56.95	18.66	1.02
6	6478	68.23	22.44	1.15
7	6715	82.06	27.03	1.30
8	6844	95.61	31.52	1.45

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	6091	19.66	6.46	0.62
10	1	57	6126	22.91	7.67	0.66
10	5	284	6260	29.85	10.44	0.74
10	10	570	6431	40.50	14.57	0.87
10	20	1140	6771	61.80	22.83	1.11
10	30	1705	7109	84.94	31.71	1.38
10	37	2108	7351	98.94	37.19	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-02-24 13:34:10.661083542 UTC

Baseline Scenario

Number of nodes	1
Number of txs	300
Avg. Confirmation Time (ms)	4.065175673
P99	9.155854129999996ms
P95	4.8186259ms
P50	3.9184475ms
Number of Invalid txs	0

Memory data

Time	Used	Free
2025-02-24 13:32:46.531969962 UTC	939M	6098M
2025-02-24 13:32:51.532014745 UTC	1050M	5899M
2025-02-24 13:32:56.532044219 UTC	1053M	5895M
2025-02-24 13:33:01.531939163 UTC	1046M	5901M
2025-02-24 13:33:06.5320491 UTC	1047M	5900M
2025-02-24 13:33:11.532086062 UTC	1051M	5896M

Three local nodes

Number of nodes	3
Number of txs	900
Avg. Confirmation Time (ms)	22.659854355
P99	115.34516115999999ms
P95	30.179197749999986ms
P50	20.2104115ms
Number of Invalid txs	0

Memory data

Time	Used	Free
2025-02-24 13:33:23.680226251 UTC	974M	5984M
2025-02-24 13:33:28.680381595 UTC	1130M	5828M
2025-02-24 13:33:33.680403474 UTC	1141M	5817M
2025-02-24 13:33:38.680369119 UTC	1150M	5807M
2025-02-24 13:33:43.680505193 UTC	1196M	5688M
2025-02-24 13:33:48.680406684 UTC	1238M	5573M
2025-02-24 13:33:53.68040138 UTC	1238M	5572M
2025-02-24 13:33:58.680418793 UTC	1243M	5566M
2025-02-24 13:34:03.680395718 UTC	1246M	5562M
2025-02-24 13:34:08.680261654 UTC	1246M	5562M

[locallycompact]

I think we discussed elsewhere that we only need a partially statically linked hydra-node that will run on the majority of machines. I would prefer that because it removes a whole codepath, but if we really need a fully statically linked binary for other reasons then we don't need to discuss this further.

[ch1bo]

I think we discussed elsewhere that we only need a partially statically linked hydra-node that will run on the majority of machines. I would prefer that because it removes a whole codepath, but if we really need a fully statically linked binary for other reasons then we don't need to discuss this further.

I see. So we need to discuss the benefit of having full static binaries at the cost of maintaining a cross-toolchain build using musl (not much on our end, but keeps us with haskell.nix which does the heavy-lifting). There are drawbacks to the dynamic exe with static libs inside too: it requires us to check for min GLIBC ABI and potentially help users who run into issues, i.e. what is a reasonable "majority of machines"

[ch1bo]

If we decide to do this, we need to update installation instructions to mention what minimum glibc ABI version we require (ideally translated to typical linux distro versions, e.g. "ubuntu 12.04" or "debian bullseye"). Also, the tutorial that downloads binaries should link to those installation requirements.

In its current form, the change is not motivated enough (it just makes it more annoying to use)