Don't keep deposit script utxo in local state

[v0d1ch]

Why

This is a leftover from off-chain changes needed to implement #199

We kept in the local state a map of UTxO we already observed so this simplifies the code around that since the observed UTxO is already to be found in the chain state UTxO. Now we keep a list of [(TxId, UTxO)] where UTxO is just there to check off-chain if the next snapshot is snapshotting exactly what we saw already as (utxoToCommit).

What

Remove the local map and fields in the observations for increment/recover and rely completely on observed UTxO (spendableUTxO)

---

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

[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-10-10 09:30:02.396186048 UTC
Max. memory units	14000000
Max. CPU units	10000000000
Max. tx size (kB)	16384

Script summary

Name	Hash	Size (Bytes)
νInitial	b512161ccb0652d7e9a0b540e4a3c808f73d6558a4bcabf374d85880	3969
νCommit	ea444d37d226e71eef73ac78d149750da977feb588900135bf9e8221	692
νHead	2253ddd95837c7aacc8635a971caaea743434152dd8dd2849bdf4162	10797
μHead	4d648ca239040b0e87901835aa11423e7aa3bd947ce6befe7db1bae8*	4508
νDeposit	1a011f23b139a6426767026bde10319546485d553219a5848cdac4e5	2993

• 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	5097	5.85	2.31	0.44
2	5298	7.17	2.84	0.46
3	5498	8.37	3.30	0.48
5	5899	11.32	4.48	0.53
10	6907	18.02	7.12	0.65
57	16355	83.04	32.85	1.78

Commit transaction costs

This uses ada-only outputs for better comparability.

UTxO	Tx size	% max Mem	% max CPU	Min fee ₳
1	564	10.84	4.26	0.29
2	758	14.31	5.80	0.34
3	943	17.92	7.39	0.39
5	1323	25.56	10.73	0.49
10	2250	47.11	19.97	0.77
19	3948	94.71	39.81	1.38

CollectCom transaction costs

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	560	19.84	7.58	0.39
2	114	671	27.94	10.64	0.48
3	171	782	37.75	14.35	0.59
4	227	893	44.05	16.75	0.67
5	281	1004	51.45	19.56	0.75
6	338	1120	65.20	24.74	0.90
7	394	1231	66.31	25.27	0.92
8	448	1338	73.36	27.95	1.00
9	504	1449	85.76	32.62	1.14
10	560	1560	91.77	34.92	1.21

Cost of Decrement Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	628	18.40	8.06	0.38
2	817	21.07	9.86	0.43
3	858	19.95	10.17	0.42
5	1207	25.12	13.77	0.51
10	2341	39.87	23.25	0.74
50	7835	95.30	75.85	1.81

Close transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	675	20.83	9.33	0.42
2	809	22.34	10.80	0.44
3	914	23.77	12.21	0.47
5	1257	27.38	15.71	0.54
10	2022	35.31	23.46	0.69
50	7992	98.59	85.72	1.92

Contest transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	711	26.76	11.48	0.48
2	865	28.94	13.36	0.52
3	977	30.39	14.63	0.54
5	1379	35.13	18.75	0.63
10	2284	45.14	27.65	0.81
39	6361	98.12	74.49	1.76

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	4996	15.47	6.63	0.54
2	5107	21.81	9.38	0.62
3	5273	28.90	12.55	0.71
4	5337	35.16	15.19	0.78
5	5483	42.46	18.44	0.87
6	5582	46.43	20.05	0.92
7	5670	53.22	22.98	1.00
8	5805	55.76	24.06	1.03
9	5996	67.76	29.40	1.17
10	6247	74.44	32.51	1.26
11	6221	79.56	34.45	1.32
12	6507	87.52	38.16	1.42
13	6566	96.02	41.83	1.52
14	6505	99.37	42.98	1.55

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 ₳
10	0	0	5089	10.47	4.38	0.49
10	1	57	5123	10.96	4.81	0.50
10	5	285	5259	16.11	7.91	0.57
10	10	570	5429	22.06	11.57	0.65
10	20	1136	5765	33.94	18.89	0.81
10	30	1708	6109	45.44	26.05	0.97
10	40	2279	6451	56.74	33.12	1.13
10	50	2847	6788	68.63	40.45	1.30
10	76	4327	7670	98.68	59.14	1.71

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-10-10 09:32:49.65453531 UTC

Baseline Scenario

Number of nodes	1
Number of txs	3000
Avg. Confirmation Time (ms)	4.679798689
P99	8.143153579999996ms
P95	6.297088299999997ms
P50	4.43782ms
Number of Invalid txs	0

Three local nodes

Number of nodes	3
Number of txs	9000
Avg. Confirmation Time (ms)	24.076374163
P99	110.6109681900003ms
P95	32.68849794999999ms
P50	21.6268965ms
Number of Invalid txs	0

[github-actions]

Test Results

543 tests  ±0   537 ✅ ±0   34m 59s ⏱️ + 2m 23s
162 suites ±0     6 💤 ±0 
  7 files   ±0     0 ❌ ±0 

Results for commit 0a36f5b. ± Comparison against base commit d51977e.

♻️ This comment has been updated with latest results.

[noonio]

Suggested change

	, pendingDeposits = Map.toList . Map.fromList $ pendingDeposits <> existingDeposits
	, pendingDeposits = pendingDeposits <> existingDeposits

no? it compiles for me, at least.

[v0d1ch]

It does compile but I wanted to make sure there are no duplicate keys in this list

[noonio]

Interesting.

What's the difference in behaviour? Does the toList fromList just drop the duplicates silently? Isn't that what the union would do as well?

Maybe we could emit an error, or something, if we have duplicate keys; if that's never intended to occur? Or at least a comment explaining the situation?

[v0d1ch]

So the union would also not produce duplicates (and is left biased while doing that). We don't really expect duplicates here since the TxId's are reasonably unique anyway but list type doesn't give us the same guarantees as the Map does so I thought it might be good to be really sure we are not appending two same commits.

[noonio]

I see; I see.

Fine.

But maybe we can still error if we do find a duplicate?

It'd be nice if there was a type like a map that let us express uniqueness of the "keys" here... but I can't find anything nice in Hoogle.

[noonio]

Looks great!