Create a hydra-plutus-extras package

[ch1bo]

This allows better re-use of the utilities to wrap up validators and the time conversion functions.

The Hydra.Plutus.Orphans is deliberately not called Hydra.Plutus.Extras.Orphans to not suggest it being re-exported through Hydra.Plutus.Extras

---

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

[ch1bo]

This is the purpose of this PR

[github-actions]

Test Results

358 tests   - 3   353 ✔️  - 3   17m 54s ⏱️ + 1m 16s
119 suites  - 2       5 💤 ±0 
    6 files   ±0       0 ❌ ±0 

Results for commit 1d5901a. ± Comparison against base commit e12cfc6.

This pull request removes 3 tests.

Hydra.Data.ContestationPeriod ‑ roundtrip posixFromUTCTime . posixToUTCTime (up to millisecond precision)
Hydra.Data.ContestationPeriod ‑ roundtrip posixToUTCTime . posixFromUTCTime
Hydra.Data.ContestationPeriod/posixToUTCTime ‑ is homomorphic w.r.t to Ord

♻️ This comment has been updated with latest results.

[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-14 15:29:16.893004253 UTC
Max. memory units	14000000
Max. CPU units	10000000000
Max. tx size (kB)	16384

Script summary

Name	Hash	Size (Bytes)
νInitial	3ffaf6b87df35cb01a52eb23032b8f0b1a2a3ad3acf0930abc9c833a	4150
νCommit	e4c32d6dc83b2917aa7805571f30437ad98b6d20d821d34d45943755	2093
νHead	8508839dfce39b6be65c018ce124ab549238e1b2ed08fb6588e5601f	8799
μHead	7e939052f278f7721cb1f98c3f2ca646827df9314a7e0d0168765b49*	4055

• 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	4646	11.43	4.53	0.48
2	4851	13.17	5.20	0.51
3	5059	15.18	5.98	0.54
5	5469	19.02	7.46	0.60
10	6493	29.49	11.51	0.76
45	13671	99.30	38.47	1.83

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.75	5.01	0.32
2	787	16.41	6.66	0.37
3	968	20.28	8.39	0.42
5	1351	28.46	12.01	0.53
10	2288	51.35	21.96	0.82
18	3761	95.35	40.55	1.38

Cost of CollectCom Transaction

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	815	24.75	9.82	0.46
2	114	1135	38.68	15.47	0.62
3	170	1454	51.56	20.86	0.78
4	228	1777	68.54	27.91	0.98
5	283	2094	88.69	36.23	1.22

Cost of Close Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	700	17.71	8.26	0.38
2	892	19.15	9.71	0.41
3	1088	20.27	10.89	0.44
5	1595	24.24	14.44	0.52
10	2668	32.62	22.14	0.69
50	10756	92.53	79.65	1.95

Cost of Contest Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	731	23.02	10.27	0.44
2	960	24.60	11.80	0.48
3	1097	26.51	13.25	0.51
5	1561	30.33	16.53	0.58
10	2612	39.77	24.55	0.76
44	9452	98.62	75.98	1.91

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	4871	21.66	9.31	0.61
2	5336	36.70	15.96	0.80
3	5771	54.68	23.92	1.02
4	6227	76.59	33.57	1.29

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	4671	8.79	3.70	0.45
5	1	57	4707	10.36	4.60	0.47
5	5	286	4853	15.61	7.80	0.55
5	10	567	5032	21.91	11.68	0.63
5	20	1136	5384	35.29	19.78	0.81
5	30	1705	5748	48.16	27.66	0.99
5	40	2274	6103	61.30	35.66	1.17
5	50	2843	6466	74.17	43.56	1.35
5	69	3930	7155	99.68	58.99	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-08-14 15:19:47.220804155 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)	109.812744334
P99	279.34593585ms
P95	232.6245404ms
P50	92.133866ms
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)	5.088185446
P99	18.118987009999998ms
P95	10.2877211ms
P50	4.0118855ms
Number of Invalid txs	0

[ghost]

LGTM. Only suggestion would be to minimise the impact of the change by keeping things under Plutus.X namespace as this seems innocuous to me