NOT MERGE: Less reliable persistence prototype

[ch1bo]

Experiment of disabling all our persistence.

Baseline on my machine 25.703936052ms confirmation time

• after disabling state event persistence -> 26.733588689ms (nothing changed)
• after disabling API server output persistence -> 25.833866523ms (nothing changed)
• after disabling network message persistence -> 0.450605626ms 😮

I dove deeper and

• only disabled the network message persistence (full) -> still 0.732717483ms
• only disabled network message persistence (keep acks) -> 26.061189185ms

So save ackPersistence acks, which uses writeBinaryFileDurableAtomic is the sloth here. Because if putting everything back and only using writeBinaryFile we get -> 0.889962229ms.

Quite obvious in hindsight.

Obviously, don't merge this.

---

• 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	2024-07-10 15:30:01.936268482 UTC
Max. memory units	14000000
Max. CPU units	10000000000
Max. tx size (kB)	16384

Script summary

Name	Hash	Size (Bytes)
νInitial	baafeb5dc37bbe6e068784746bda0a3b1bb1d034fa0c55270f6079c1	4082
νCommit	fe7af84822bcba542fae377ae7311fc5fd20152f925ccd980f73ecdc	2061
νHead	93c08c55e804d7f82ca545a01883b5fda6a6d3623cb78885625800ae	9366
μHead	5e65c73722b4bb3f0cbfcc8433e1dcdfea099eaf0a43060f1731a65b*	4237

• 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	4819	6.02	2.37	0.43
2	5019	7.23	2.84	0.45
3	5222	8.80	3.46	0.48
5	5624	11.39	4.48	0.52
10	6628	18.61	7.33	0.65
58	16278	85.85	33.85	1.80

Cost of Commit Transaction

This is using ada-only outputs for better comparability.

UTxO	Tx size	% max Mem	% max CPU	Min fee ₳
1	559	9.69	3.82	0.28
2	747	12.48	5.10	0.32
3	937	15.33	6.40	0.36
5	1310	21.26	9.09	0.45
10	2243	37.35	16.27	0.67
25	5054	96.42	41.75	1.45

Cost of CollectCom Transaction

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	544	14.55	5.82	0.33
2	113	654	23.06	9.32	0.43
3	170	764	33.58	13.68	0.55
4	228	874	44.65	18.36	0.68
5	283	984	59.39	24.50	0.85
6	338	1099	72.14	30.01	1.00
7	393	1205	86.96	36.39	1.17

Cost of Close Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	590	8.26	4.58	0.28
2	747	8.97	5.66	0.30
3	857	9.63	6.69	0.31
5	1164	11.27	9.07	0.36
10	1258	13.50	7.30	0.37
50	8030	49.46	62.57	1.35

Cost of Contest Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	621	8.60	4.71	0.28
2	831	9.74	6.14	0.31
3	886	10.05	6.86	0.32
5	1106	11.10	8.66	0.35
10	2006	16.39	15.41	0.48
50	8077	50.58	63.20	1.37

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	4686	17.09	7.39	0.55
2	4785	24.63	10.60	0.64
3	4970	42.40	18.61	0.85
4	5027	52.29	22.81	0.96
5	5068	68.83	29.99	1.15

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	4651	7.61	3.18	0.44
5	1	56	4685	8.55	3.80	0.45
5	5	285	4821	13.58	6.83	0.52
5	10	569	4990	19.55	10.48	0.60
5	20	1139	5331	30.66	17.43	0.76
5	30	1706	5670	42.40	24.66	0.92
5	40	2276	6009	53.72	31.71	1.08
5	50	2848	6351	65.47	38.94	1.24
5	79	4500	7336	98.76	59.59	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 2024-07-10 15:32:30.223587967 UTC

Baseline Scenario

Number of nodes	1
Number of txs	3000
Avg. Confirmation Time (ms)	1.937572150
P99	2.811301489999944ms
P95	2.2834975ms
P50	1.8719234999999999ms
Number of Invalid txs	0

Three local nodes

Number of nodes	3
Number of txs	9000
Avg. Confirmation Time (ms)	36.626525560
P99	210.15889824000004ms
P95	116.95792139999998ms
P50	17.2573495ms
Number of Invalid txs	0

[github-actions]

Test Results

437 tests  ±0   425 ✅ ±0   15m 52s ⏱️ +41s
143 suites ±0    12 💤 ±0 
  5 files   ±0     0 ❌ ±0 

Results for commit 30ecb7d. ± Comparison against base commit f2ef4c7.

[v0d1ch]

Perhaps we should also try to not read and then save acks on Ping messages but just keep them in memory here https://github.com/cardano-scaling/hydra/blob/master/hydra-node/src/Hydra/Network/Reliability.hs#L252

[ch1bo]

Closing this PR as we are not merging this. Make sure to consider this in case we revisit persistence of any network state for reliable broadcasts. Relevant issues: #1417 and #1505