Implement deposit validators and off-chain code

[locallycompact]

This PR is a continuation of #1587

❄️ It adds $v_deposit$ validator together with deposit and recover transaction building.

❄️ hydra-tx executable is supposed to help our users to quickly obtain needed transactions in order to either deposit some funds to a Head or recover them in case of any problems.

❄️ Changes related to snapshot signing: Now we accept Hash directly for utxo to decommit. Related logbook entry

NOTE:
This PR has two issues that prevent the normal operation in drafting deposit/recover transactions.

1. Fees - we need a way to balance the transaction (using cardano-cli or importing it into some wallet)
2. JSON instance for our Tx type is not compatible with cardano-cli (missing Un/Witnessed string in transaction type)

[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	2024-09-09 08:42:42.422050918 UTC
Max. memory units	14000000
Max. CPU units	10000000000
Max. tx size (kB)	16384

Script summary

Name	Hash	Size (Bytes)
νInitial	2fac819a1f4f14e29639d1414220d2a18b6abd6b8e444d88d0dda8ff	3799
νCommit	2043a9f1a685bcf491413a5f139ee42e335157c8c6bc8d9e4018669d	1743
νHead	2ee477c60839936be49a50030690865b5bed4db8cd2f05bf255ac680	10068
μHead	a1610f6e64843161f4a88229c0286176f5325de3e2f773eec2b1d818*	4508
νDeposit	c2117fd9ebdee3e96b81fd67ff7092d638926415c10f1f7e5a267ad0	2791

• 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	5094	5.61	2.21	0.44
2	5297	7.21	2.85	0.46
3	5496	8.45	3.34	0.48
5	5902	11.12	4.39	0.53
10	6907	18.16	7.18	0.65
57	16355	83.00	32.84	1.78

Commit transaction costs

This uses ada-only outputs for better comparability.

UTxO	Tx size	% max Mem	% max CPU	Min fee ₳
1	569	10.52	4.15	0.29
2	758	13.86	5.65	0.34
3	944	17.33	7.20	0.38
5	1315	24.65	10.44	0.48
10	2252	45.22	19.36	0.75
20	4135	95.99	40.76	1.40

CollectCom transaction costs

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	564	21.46	8.41	0.41
2	112	671	32.14	12.75	0.53
3	169	782	47.45	18.95	0.70
4	226	893	60.85	24.51	0.86
5	283	1004	79.28	32.09	1.07
6	338	1116	96.90	39.50	1.27

Cost of Decrement Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	633	17.95	7.88	0.38
2	772	19.27	9.13	0.41
3	862	19.17	9.78	0.41
5	1175	22.79	12.64	0.48
10	2000	33.04	20.31	0.65
50	7884	97.36	74.47	1.82

Close transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	654	20.07	9.02	0.41
2	798	21.53	10.43	0.43
3	916	22.88	11.76	0.46
5	1224	26.26	14.92	0.52
10	1982	34.15	22.44	0.68
50	8368	98.60	84.60	1.92

Contest transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	694	25.93	11.16	0.47
2	816	27.61	12.62	0.50
3	943	29.45	14.16	0.53
5	1272	33.25	17.47	0.60
10	2027	42.75	25.63	0.77
40	6510	98.99	74.13	1.77

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	4997	17.47	7.61	0.57
2	5060	25.02	10.83	0.65
3	5215	41.70	18.37	0.85
4	5426	58.35	25.88	1.05
5	5458	70.90	31.39	1.19
6	5742	98.41	43.95	1.51

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 ₳
5	0	0	4935	7.89	3.34	0.46
5	1	57	4968	8.43	3.80	0.46
5	5	285	5104	13.94	7.06	0.54
5	10	570	5274	19.20	10.45	0.61
5	20	1139	5613	30.72	17.65	0.77
5	30	1706	5953	41.65	24.61	0.93
5	40	2277	6293	52.78	31.65	1.08
5	50	2847	6634	64.51	38.94	1.24
5	81	4608	7682	99.67	61.07	1.73

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 2024-09-09 08:42:46.356221393 UTC

Baseline Scenario

Number of nodes	1
Number of txs	3000
Avg. Confirmation Time (ms)	4.409358616
P99	6.8408248700000005ms
P95	5.309748299999999ms
P50	4.270317ms
Number of Invalid txs	0

Three local nodes

Number of nodes	3
Number of txs	9000
Avg. Confirmation Time (ms)	23.878198683
P99	100.08334345000053ms
P95	33.37555104999999ms
P50	21.381888ms
Number of Invalid txs	0

[github-actions]

Test Results

488 tests  +29   483 ✅ +29   20m 57s ⏱️ + 1m 9s
153 suites +15     5 💤 ± 0 
  6 files   + 1     0 ❌ ± 0 

Results for commit 30173c7. ± Comparison against base commit 20ceaa7.

♻️ This comment has been updated with latest results.

[ch1bo]

This looks good for integration now.

Only minor comments on re-use and simpler mutations.

[ch1bo]

Looks good

[ch1bo]

Looks good

@v0d1ch @locallycompact Ah one thing: We should update changelog and package versions. This is a 0.19.0 at least on hydra-plutus and hydra-tx.