Reliable persistence

[v0d1ch]

handles part of #1079

---

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

[github-actions]

Transactions 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	2023-10-10 10:10:28.112829142 UTC
Max. memory units	14000000
Max. CPU units	10000000000
Max. tx size (kB)	16384

Script summary

Name	Hash	Size (Bytes)
νInitial	eaf589de11c6c805af24b759e7794d62661d3db4ade79594892ebaec	4106
νCommit	8dcc1fb34d1ba168dfb0b82e7d1a31956a2db5856f268146b0fd7f2a	2051
νHead	e35bdf32cd3806596150c1cbab6ab5456bd957b36019ed2746bf481d	8797
μHead	386ad19467be96131379dacf57a9351a762da2dee3486a855f0409c9*	4151

• The minting policy hash is only usable for comparison. As the script is parameterized, the actual script is unique per Head.

Cost of Init Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	4745	11.70	4.61	0.49
2	4949	13.97	5.47	0.52
3	5154	16.54	6.46	0.56
5	5565	21.57	8.38	0.63
10	6590	33.29	12.84	0.80
37	12127	98.06	37.51	1.75

Cost of Commit Transaction

This is using ada-only outputs for better comparability.

UTxO	Tx size	% max Mem	% max CPU	Min fee ₳
1	599	12.64	4.97	0.31
2	786	16.26	6.61	0.36
3	972	20.20	8.37	0.42
5	1350	28.32	11.97	0.52
10	2287	50.99	21.84	0.82
18	3778	94.76	40.36	1.37

Cost of CollectCom Transaction

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	815	24.57	9.76	0.46
2	114	1136	36.83	14.81	0.60
3	171	1455	50.89	20.63	0.77
4	226	1774	69.65	28.34	1.00
5	283	2094	90.89	37.08	1.24

Cost of Close Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	711	18.84	8.71	0.40
2	788	18.66	8.25	0.40
3	1099	22.47	11.88	0.47
5	1510	25.53	14.71	0.53
10	1869	29.75	14.16	0.57
50	7156	81.97	42.23	1.43

Cost of Contest Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	736	22.67	10.15	0.44
2	937	24.63	11.78	0.48
3	1106	26.54	13.24	0.51
5	1566	30.04	16.41	0.58
10	2738	40.22	24.99	0.78
43	9551	99.96	76.46	1.93

Cost of Abort Transaction

Some variation because of random mixture of still initial and already committed outputs.

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	4978	21.36	9.21	0.61
2	5477	36.01	15.73	0.80
3	5860	54.24	23.79	1.02
4	6397	75.14	33.09	1.28
5	6482	92.76	40.61	1.48

Cost of FanOut Transaction

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 ₳
5	0	0	4771	8.78	3.71	0.46
5	1	56	4798	9.73	4.35	0.47
5	5	285	4948	15.18	7.64	0.55
5	10	571	5125	21.94	11.72	0.64
5	20	1138	5482	34.94	19.66	0.82
5	30	1706	5846	47.94	27.62	0.99
5	40	2276	6205	60.94	35.57	1.17
5	50	2843	6562	73.69	43.43	1.35
5	70	3982	7281	99.73	59.36	1.70

End-To-End Benchmark Results

This page is intended to collect the latest end-to-end benchmarks results produced by Hydra's Continuous Integration system from the latest master code.

Please take those results with a grain of salt as they are currently produced from very limited cloud VMs and not controlled hardware. Instead of focusing on the absolute results, the emphasis should be on relative results, eg. how the timings for a scenario evolve as the code changes.

Generated at 2023-10-10 10:05:19.9137102 UTC

3-nodes Scenario

A rather typical setup, with 3 nodes forming a Hydra head.

Number of nodes	3
Number of txs	900
Avg. Confirmation Time (ms)	68.484206147
P99	220.68482235999994ms
P95	155.91714174999996ms
P50	55.134828ms
Number of Invalid txs	0

Baseline Scenario

This scenario represents a minimal case and as such is a good baseline against which to assess the overhead introduced by more complex setups. There is a single hydra-node d with a single client submitting single input and single output transactions with a constant UTxO set of 1.

Number of nodes	1
Number of txs	300
Avg. Confirmation Time (ms)	6.366695193
P99	16.856689059999994ms
P95	11.667769999999999ms
P50	5.2121445ms
Number of Invalid txs	0

[github-actions]

Test Results

355 tests  +1   350 ✔️ +1   16m 18s ⏱️ +15s
120 suites ±0       5 💤 ±0 
    5 files    - 1       0 ❌ ±0 

Results for commit e9a6ebd. ± Comparison against base commit 6a0f3d4.

♻️ This comment has been updated with latest results.

[abailly-iohk]

As already commented, this change does not completely fix #1079 even though it's a good step forward. the fact we are using 2 Persistence handles we need to pass to the Reliability layer somehow feels wrong but I don't have a better solution right now, perhaps something we should discuss together?

[abailly-iohk]

Some comments left, and we should update the documentation for the Reliability module

[abailly-iohk]

Add some more comment on what's this directory is used for