Support hydra-cluster with duplicate party

[ffakenz]

Closes #1859

---

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

[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-03-27 12:51:28.139481496 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	6098	10.80	3.35	0.53
2	6292	13.83	4.32	0.57
3	6500	15.50	4.80	0.60
5	6897	20.07	6.21	0.66
10	7903	30.97	9.53	0.82
40	13936	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	559	2.44	1.16	0.20
2	742	3.38	1.73	0.22
3	920	4.36	2.33	0.24
5	1276	6.41	3.60	0.28
10	2174	12.13	7.25	0.40
54	10053	98.61	68.52	1.88

CollectCom transaction costs

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	525	25.67	7.41	0.43
2	112	635	33.99	9.79	0.52
3	170	747	45.71	12.95	0.65
4	227	858	54.68	15.48	0.74
5	282	969	60.67	17.35	0.81
6	340	1081	67.12	19.25	0.88
7	396	1192	80.13	22.76	1.01
8	451	1303	86.54	24.78	1.09

Cost of Increment Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	1789	25.03	8.22	0.49
2	1928	27.03	9.47	0.52
3	2097	29.58	11.00	0.56
5	2436	33.74	13.71	0.63
10	3255	44.43	20.59	0.80
39	7360	98.15	57.07	1.68

Cost of Decrement Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	624	23.99	7.62	0.43
2	785	26.46	8.97	0.46
3	983	29.44	10.45	0.51
5	1201	31.72	12.41	0.55
10	1907	40.03	18.00	0.69
41	6440	99.82	55.16	1.64

Close transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	651	30.91	9.66	0.50
2	804	30.95	10.42	0.51
3	934	34.78	12.18	0.56
5	1315	40.69	15.59	0.65
10	2029	47.31	21.06	0.77
34	5701	97.83	53.49	1.58

Contest transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	693	35.95	11.00	0.55
2	878	38.81	12.63	0.59
3	962	40.36	13.65	0.62
5	1286	46.03	16.87	0.70
10	2040	57.44	23.73	0.88
27	4477	97.48	47.52	1.48

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	5983	28.20	9.31	0.71
2	6091	37.63	12.40	0.81
3	6286	47.82	15.80	0.93
4	6392	53.57	17.65	0.99
5	6439	62.14	20.44	1.08
6	6521	71.18	23.39	1.18
7	6596	76.14	25.05	1.24
8	7006	97.42	32.25	1.48

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	1	57	6125	22.25	7.45	0.65
10	5	284	6260	30.77	10.75	0.75
10	10	569	6430	41.42	14.88	0.88
10	20	1136	6767	62.26	22.99	1.12
10	30	1709	7112	83.57	31.25	1.36
10	37	2104	7346	97.56	36.72	1.53

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-03-27 12:54:38.503317149 UTC

Baseline Scenario

Number of nodes	1
Number of txs	300
Avg. Confirmation Time (ms)	4.387932323
P99	5.711209909999998ms
P95	5.2033704ms
P50	4.262051ms
Number of Invalid txs	0

Memory data

Time	Used	Free
2025-03-27 12:53:22.978830013 UTC	872M	3306M
2025-03-27 12:53:27.978808199 UTC	979M	3190M
2025-03-27 12:53:32.978793463 UTC	979M	3189M
2025-03-27 12:53:37.978837466 UTC	981M	3187M
2025-03-27 12:53:42.978735274 UTC	984M	3185M
2025-03-27 12:53:47.978774655 UTC	984M	3184M

Three local nodes

Number of nodes	3
Number of txs	900
Avg. Confirmation Time (ms)	29.520462696
P99	51.953401039999996ms
P95	41.90164119999999ms
P50	27.7386965ms
Number of Invalid txs	0

Memory data

Time	Used	Free
2025-03-27 12:54:01.497505955 UTC	879M	3298M
2025-03-27 12:54:06.497767349 UTC	1140M	3034M
2025-03-27 12:54:11.498835063 UTC	1194M	2914M
2025-03-27 12:54:16.497596467 UTC	1208M	2855M
2025-03-27 12:54:21.497655146 UTC	1210M	2853M
2025-03-27 12:54:26.49764893 UTC	1216M	2847M
2025-03-27 12:54:31.497685337 UTC	1216M	2846M
2025-03-27 12:54:36.497605688 UTC	1222M	2839M

[noonio]

Thanks for doing this.

I think this is a great result.

There are two changes I'd like before we merge. The first perhaps requires some effort:

1. It occured to me that this test is basically equivalent to running a hydra-node twice, on the same computer, with the exact same information. It would be great to also test the scenario of running with the same keys and information but on a different computer. One important difference is that this should affect the etcd cluster; the majority and such. We need to check we can still operate in this model.

2. Can you add a note in the docs, perhaps under operating-hydra.md, that talks about how to use this "feature"? I.e. what steps someone would like to take, and how to go about it.

We may need to talk this first point through in some detail; but I think it's important to check, because the original ticket is more about this second scenario.

[ch1bo]

It occured to me that this test is basically equivalent to running a hydra-node twice, on the same computer, with the exact same information. It would be great to also test the scenario of running with the same keys and information but on a different computer. One important difference is that this should affect the etcd cluster; the majority and such. We need to check we can still operate in this model.

@noonio AFAIK this was not testing two instances with the exact same configuration as the node-id results in different ports, which makes sense as otherwise we would have an "address already in use" error. What different behavior do you expect from etcd if we have not only different ports, but also differing IPs? To me, that would be equivalent and just much harder to test (requiring at least multiple network interfaces or multiple networked machines in CI).

[noonio]

I'm happy.

I added a small disclaimer at the top, because I don't exactly think people should always be running mirror nodes.