Implement a 100 Ada hard-coded commit limit in the hydra-node

[v0d1ch]

fix #762

• CHANGELOG updated
• Documentation updated
• Added and/or updated haddocks
• 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-03-14 08:42:44.295098176 UTC
Max. memory units	14000000
Max. CPU units	10000000000
Max. tx size (kB)	16384

Script summary

Name	Hash	Size (Bytes)
μHead	N/A	4458
νInitial	9492414f8f96e8483a0b8ee268fc06a954641cb2cbaa9a8b093c2c9b	4621
νCommit	5d3f107aaa56d06188cf231941cf8163e777236a9cfdc48fd4bbfa23	2422
νHead	82f16b51e2d81c6f4d42dd7398b4713a445464902f63dfd86ffe754e	8954

Cost of Init Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	5059	15.39	6.10	0.54
2	5257	16.31	6.39	0.56
3	5464	17.99	7.01	0.59
5	5875	24.93	9.70	0.68
10	6900	36.86	14.21	0.85
36	12236	99.70	37.98	1.77

Cost of Commit Transaction

Currently only one UTxO per commit allowed (this is about to change soon)

UTxO	Tx size	% max Mem	% max CPU	Min fee ₳
1	603	15.83	6.22	0.35

Cost of CollectCom Transaction

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	816	24.50	9.95	0.46
2	114	1139	40.40	16.53	0.65
3	171	1461	58.95	24.26	0.87
4	226	1784	80.46	33.24	1.12

Cost of Close Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	647	16.99	7.31	0.37
2	804	18.43	8.09	0.39
3	770	17.28	7.43	0.38
5	1307	23.00	10.55	0.47
10	1471	24.56	10.79	0.49
50	8725	85.88	45.25	1.55

Cost of Contest Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	708	22.70	9.66	0.43
2	832	23.97	10.20	0.45
3	1005	25.59	11.04	0.48
5	1327	29.02	12.81	0.54
10	2168	37.33	17.13	0.67
46	8102	99.19	48.98	1.66

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	5171	29.49	12.60	0.71
2	5491	48.00	20.73	0.93
3	5816	70.09	30.47	1.19
4	6139	95.36	41.63	1.49

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	5078	10.59	4.43	0.49
5	1	57	5114	12.12	5.31	0.51
5	5	284	5256	18.22	8.83	0.59
5	10	568	5440	25.85	13.23	0.69
5	20	1139	5798	41.11	22.05	0.90
5	30	1707	6156	56.37	30.86	1.10
5	40	2276	6516	71.64	39.68	1.30
5	50	2848	6877	86.92	48.50	1.50
5	58	3303	7164	99.14	55.56	1.67

[github-actions]

Test Results

297 tests  +1   291 ✔️ +1   23m 16s ⏱️ + 1m 58s
  99 suites ±0       6 💤 ±0 
    5 files   ±0       0 ❌ ±0 

Results for commit dc7af42. ± Comparison against base commit 31c4cf6.

♻️ This comment has been updated with latest results.

[pgrange]

This review tries to apply the perfection game protocol
I will describe what I like about this P.R. and then what improvement I can think of to make it perfect.
Ask for clarifications if my comments are not clear.
If you disagree with my comments, just ignore them and don’t answer or explain.
Hence I, in advance, approve the P.R.
To describe what I would change, I will try to extensively use the suggest change feature of GitHub as I believe this is the most efficient way to upload data from my brain to the authors' brains. That being said, the suggestions I will write will probably not compile or pass the test so do not just accept them but consider them for what they are: the description of an improvement to make the P.R. perfect.

What I like about this P.R.:

• One single commit with precise and small perimeter. It really makes it a pleasure to review.
• Tests have been introduced to cover the new case.

For me to find it perfect you would have to:

• see other improvement proposals inline

[ch1bo]

You found the right place where to check for this, but we require this to be documented. For this, I would suggest moving this into a top-level variable and encode the maximum supported and tried to commit value in a dedicated error type. That way, users will get a clearly understandable error when they try to commit too much.

[ffakenz]

what is the idea when we want to remove this limit?

• revert the PR?
• remove the hardcode?

should we have this procedure documented somewhere?

would not be better to have a maybe limit option as part of our node configuration?

maybe this way, we can configure the limit and accept to join a head if it is under it.

[ch1bo]

We should not hard-code the value more than once and return it to the user. Also knowing how much they tried to commit is likely helpful.

[ch1bo]

Ideally we would be using the Lovelace type directly to describe that the amounts are lovelace (and not ada).

I do approve already though, as this could be also done after if you don't want to do it right away.