Restructure use case section and add more content on auctions

[nebojsa-io]

Contribute to #710

Changed the "Use Cases" section of the website.

• It now includes 3 main sections:

  • Payments: a stub with an initial intro to hydra-pay (to be expanded with more use cases later)
    • This category now holds the two legacy use case pages about inter-wallet payments and pay-per-use apis
  • Auctions: includes the description of the current implementation done with mlabs + descriptions of extension use cases that can be built on top
  • Other: Now only holds the "poker game" use case

• The legacy NFT Auction article was removed

• Added redirects to not break links from external

---

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

[nebojsa-io]

Forgot to add: there are still a few missing diagrams, with placeholders on the top page for auctions use cases. These placeholders can/should be removed since I don't think the diagrams are necessary. The text is self-explanatory even without them.

[github-actions]

Test Results

359 tests  ±0   354 ✔️ ±0   23m 58s ⏱️ + 2m 14s
119 suites ±0       5 💤 ±0 
    6 files   ±0       0 ❌ ±0 

Results for commit bf7c756. ± Comparison against base commit 7e1d9fa.

♻️ 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-01 16:45:40.036889095 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	4740	15.10	5.91	0.52
2	4945	17.49	6.81	0.56
3	5152	19.48	7.55	0.59
5	5563	23.78	9.16	0.65
10	6592	34.93	13.34	0.82
36	11920	96.80	36.63	1.72

Cost of Commit Transaction

This is using ada-only outputs for better comparability.

UTxO	Tx size	% max Mem	% max CPU	Min fee ₳
1	600	15.06	5.76	0.34
2	787	19.75	7.76	0.40
3	975	24.76	9.87	0.46
5	1341	36.28	14.63	0.61
10	2282	72.00	28.94	1.04
13	2846	98.24	39.22	1.35

Cost of CollectCom Transaction

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	814	28.04	10.88	0.49
2	113	1133	43.94	17.18	0.68
3	170	1463	62.02	24.40	0.89
4	227	1783	83.03	32.80	1.14

Cost of Close Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	639	18.68	8.34	0.39
2	804	20.38	9.71	0.42
3	965	21.48	10.85	0.44
5	1299	24.57	13.49	0.50
10	2124	31.27	19.66	0.64
50	8725	87.55	70.11	1.75

Cost of Contest Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	677	24.44	10.50	0.45
2	841	26.16	11.87	0.48
3	1007	27.88	13.24	0.52
5	1336	31.75	16.15	0.58
10	2153	39.92	22.84	0.73
44	7771	98.80	69.64	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	4856	22.60	9.44	0.61
2	5176	37.05	15.68	0.79
3	5499	54.20	23.13	1.00
4	5818	74.17	31.80	1.23
5	6139	97.23	41.84	1.51

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	4770	8.72	3.59	0.46
5	1	56	4796	10.12	4.41	0.47
5	5	285	4949	15.71	7.72	0.55
5	10	570	5129	22.69	11.85	0.64
5	20	1135	5480	36.67	20.11	0.83
5	30	1707	5844	50.65	28.38	1.02
5	40	2277	6205	64.63	36.65	1.21
5	50	2849	6566	78.62	44.92	1.40
5	65	3698	7102	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 16:40:28.420612351 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)	122.808244536
P99	310.23645105ms
P95	246.7621704ms
P50	112.86263149999999ms
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)	6.911895033
P99	20.661569159999985ms
P95	14.012666050000002ms
P50	5.525707499999999ms
Number of Invalid txs	0

[pgrange]

We can't merge without the diagrams, I think, because merging would publish on the website and it would look a bit broken without them, in my opinion.

[pgrange]

Hydra Head hosts, in my mind, refers to the hosts that are hosting a Hydra node which is a party in a given head. So when I read this sentence I feel like we want to say that you could deploy your auction in several heads to not depend on one single host. But it's already the case with one single head: you do not depend on one single host but on all the hosts that participate in the head.

So I think I do not understand this sentence. I could use some more explanation here.

[nebojsa-io]

I think it should say "among multiple Hydra heads". You would have some degree of centralization in a delegated model. So choosing between different "service providers" (i.e. different delegated heads) would be a step more decentralized than a single service provider (even if it is multiple node operators running a single head - since they will likely be not too many, they can collude to censor bids).

I'll change it to "among multiple Hydra heads".

[ch1bo]

I think this is a great start. I would like to discuss my ideas of categorizing things, shortening names and headlines.

[ch1bo]

Incorporated the changes I have suggested already. Besides the very verbose auction category and document titles, to be discussed:

[ch1bo]

An SDK is no use case?

I think this should be mentioned in the corresponding hydra-auction pages.

[ch1bo]

@nebojsa-io and I discussed that we should try to incorporate this into the relevant sections of the invitational/open delegated auction use case instead.

[ch1bo]

Let's merge this now and see how it looks on the website. @nebojsa-io should come up with more ideas after that. If we like this approach, the payments vertical could also be treated the same.