Load and save event sourced state

[ch1bo]

• Changes persisted state to be a sequence of events according to ADR24. Persistence is now done incrementally after each StateChanged outcome.

• Removes dependency on persistence format from some e2e tests.

• Changes log schema of LoadedState to contain the number of events loaded.

• Moves parameter/persistence checking to Hydra.Node module

• Updates ADR24 to reflect current implementation and marks it as accepted.

---

• 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-08-01 09:50:40.188229116 UTC
Max. memory units	14000000
Max. CPU units	10000000000
Max. tx size (kB)	16384

Script summary

Name	Hash	Size (Bytes)
νInitial	7ceb53f05e444cfdabfd0a37a0590090066da457a1f1db30d613b8bd	4289
νCommit	70e70fc13217bfde96932956656c1d540a743b1588c845ca09dc3723	2124
νHead	cda51d313c1c8285b6925ce2413def012db27f544e2bbd79b8173000	9185
μHead	1c0b665fc49bc2e9e2ce4e8252c8f37fe84dd75bd8e086abfdb92685*	4149

• 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	4742	14.00	5.47	0.51
2	4945	17.18	6.69	0.55
3	5152	20.29	7.88	0.60
5	5566	23.03	8.86	0.65
10	6588	36.45	13.95	0.84
38	12330	99.90	37.76	1.77

Cost of Commit Transaction

This is using ada-only outputs for better comparability.

UTxO	Tx size	% max Mem	% max CPU	Min fee ₳
1	599	15.06	5.76	0.34
2	784	19.66	7.73	0.40
3	975	24.76	9.87	0.46
5	1342	36.19	14.60	0.61
10	2284	72.00	28.94	1.04
13	2852	98.24	39.22	1.35

Cost of CollectCom Transaction

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	815	28.09	10.90	0.49
2	113	1134	43.98	17.19	0.68
3	170	1454	62.22	24.47	0.89
4	226	1773	83.44	32.96	1.14

Cost of Close Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	639	18.68	8.34	0.39
2	800	20.08	9.60	0.42
3	966	21.78	10.97	0.45
5	1308	24.27	13.37	0.50
10	1463	25.82	11.18	0.50
50	8725	87.55	70.11	1.75

Cost of Contest Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	668	24.44	10.50	0.45
2	840	26.59	12.04	0.49
3	1003	28.31	13.41	0.52
5	1335	31.75	16.15	0.58
10	2153	40.34	23.01	0.74
44	7771	98.37	69.48	1.79

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	4713	19.42	7.86	0.57
2	5176	37.05	15.68	0.79
3	5502	53.94	23.02	0.99
4	5818	74.52	31.94	1.24
5	6002	91.56	39.18	1.44

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	4766	8.72	3.59	0.46
5	1	57	4801	10.12	4.41	0.48
5	5	285	4949	15.71	7.72	0.55
5	10	569	5124	22.69	11.85	0.64
5	20	1138	5484	36.67	20.11	0.83
5	30	1709	5847	50.65	28.38	1.02
5	40	2276	6203	64.63	36.65	1.21
5	50	2848	6566	78.62	44.92	1.40
5	65	3704	7110	99.62	57.34	1.68

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-08-01 09:44:37.221077823 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)	103.961184496
P99	252.40220497999994ms
P95	230.98808359999998ms
P50	93.1443105ms
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)	4.843812933
P99	18.972402079999995ms
P95	11.438818800000012ms
P50	3.4078425ms
Number of Invalid txs	0

[github-actions]

Test Results

339 tests   - 11   334 ✔️  - 11   18m 26s ⏱️ - 4m 11s
113 suites  -   4       5 💤 ±  0 
    5 files    -   1       0 ❌ ±  0 

Results for commit 266d837. ± Comparison against base commit d64e9a1.

This pull request removes 13 and adds 2 tests. Note that renamed tests count towards both.

Hydra.TUI.Options ‑ no arguments yield default options
Hydra.TUI.Options ‑ parses --cardano-signing-key option
Hydra.TUI.Options ‑ parses --connect option
Hydra.TUI.Options ‑ parses --node-socket option
Hydra.TUI.Options ‑ parses --testnet-magic option
Hydra.TUI.Options ‑ parses --version option
Hydra.TUI/end-to-end smoke tests ‑ display feedback long enough
Hydra.TUI/end-to-end smoke tests ‑ doesn't allow multiple initializations
Hydra.TUI/end-to-end smoke tests ‑ starts & renders
Hydra.TUI/end-to-end smoke tests ‑ supports the full Head life cycle
…

Hydra.Node ‑ can continue after restart via persisted state
Test.EndToEnd/End-to-end on Cardano devnet/hydra-node executable ‑ logs to a logfile

♻️ This comment has been updated with latest results.

[v0d1ch]

Nice work guys!

[ch1bo]

I think we should remove this

[ch1bo]

This is missing one consequence/drawbacks we have identified throughout executing this:

• Terms from specification are distributed over update and aggregate functions

[ch1bo]

There is not really a getState and setState function. Instead of the critical area, I think we could use a modifyHeadState call/activation box (using + in the mermaid arrow)