API: Full transaction in SnapshotConfirmed

[ch1bo]

Updates SnapshotConfirmed server output to contain full transactions (instead of only transaction ids). This also updates TxValid to only include the transaction id, such that transactions are only submitted once per client still. Hence, this will not change the overall bandwidth requirement on websocket clients, but will make their implementation significantly easier.

Before, if clients wanted to act on transactions this was a lot easier to do upon seing TxValid. However, this was only confirming local ledger application and not consensus / enforcability of this transaction onto the L1.

The new API suggests to do the right thing by making it straight-forward to act upon seeing a transaction in a SnapshotConfirmed.

TBD: Changed ServerOutput field name snapshotNumber -> number to be consistent with version (and the internal Haskell data type names). Does anyone like version -> snapshotVersion better as an alternative?

TBD: The field holding the transaction id in TxValid is called transactionId now. The transaction (envelop) itself though contains txId. This feels a bit inconsistent, which of the two should be renamed?

This will also make #1612 easier (is mentioned as a sub-task there).

---

• CHANGELOG updated
• Documentation updated
• Haddocks updated
• No new TODOs introduced

[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-08 13:16:44.542276636 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.81	2.30	0.44
2	5295	7.18	2.84	0.46
3	5499	8.56	3.39	0.49
5	5899	11.12	4.39	0.53
10	6910	18.10	7.16	0.65
57	16355	82.91	32.79	1.78

Commit transaction costs

This uses ada-only outputs for better comparability.

UTxO	Tx size	% max Mem	% max CPU	Min fee ₳
1	567	10.84	4.26	0.29
2	758	14.31	5.80	0.34
3	941	17.92	7.39	0.39
5	1321	25.56	10.73	0.49
10	2257	47.11	19.97	0.77
19	3945	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	36.57	13.91	0.58
4	227	893	46.50	17.65	0.69
5	281	1009	56.49	21.43	0.81
6	340	1116	57.72	21.98	0.82
7	396	1227	73.64	27.94	1.00
8	452	1338	75.21	28.61	1.02
9	504	1449	90.57	34.38	1.19
10	560	1560	87.11	33.23	1.16

Cost of Decrement Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	628	18.40	8.06	0.38
2	755	19.77	9.37	0.41
3	938	21.52	10.75	0.44
5	1163	23.48	13.09	0.49
10	2191	36.91	22.16	0.70
49	7858	97.26	75.79	1.83

Close transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	649	20.79	9.29	0.41
2	821	22.72	11.09	0.45
3	941	23.82	12.25	0.47
5	1288	27.43	15.74	0.54
10	1964	34.91	23.05	0.68
50	8103	98.76	86.10	1.93

Contest transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	705	26.81	11.50	0.48
2	815	28.57	13.03	0.51
3	994	30.76	14.92	0.55
5	1318	34.64	18.36	0.62
10	2099	44.31	26.83	0.79
39	6727	99.60	75.91	1.80

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	4967	15.47	6.61	0.54
2	5165	22.55	9.78	0.63
3	5176	25.69	10.95	0.66
4	5334	32.65	14.06	0.75
5	5509	42.26	18.37	0.87
6	5623	46.98	20.36	0.92
7	5815	56.41	24.61	1.04
8	5876	61.49	26.73	1.10
9	5907	59.52	25.52	1.08
10	6154	73.03	31.62	1.24
11	6379	82.65	36.11	1.36
12	6538	95.05	41.61	1.51
13	6707	98.22	43.02	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.38	4.35	0.49
10	1	57	5123	11.55	5.07	0.51
10	5	285	5260	15.83	7.79	0.57
10	10	567	5426	21.08	11.15	0.64
10	20	1139	5768	33.44	18.68	0.81
10	30	1708	6109	45.52	26.08	0.97
10	40	2275	6447	56.74	33.12	1.13
10	50	2847	6788	68.72	40.49	1.30
10	76	4326	7670	99.47	59.48	1.72

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-08 13:19:34.596131108 UTC

Baseline Scenario

Number of nodes	1
Number of txs	3000
Avg. Confirmation Time (ms)	4.432376369
P99	14.755218669999996ms
P95	5.317036999999997ms
P50	4.115134ms
Number of Invalid txs	0

Three local nodes

Number of nodes	3
Number of txs	9000
Avg. Confirmation Time (ms)	24.493858477
P99	118.22389684000002ms
P95	33.204540049999956ms
P50	20.996691ms
Number of Invalid txs	0

[locallycompact]

hydra-cluster failing here: https://github.com/cardano-scaling/hydra/actions/runs/11213268280/job/31165965017?pr=1685#step:5:2493

[github-actions]

Test Results

543 tests  +25   537 ✅ +25   32m 20s ⏱️ + 1m 34s
162 suites  -  1     6 💤 ± 0 
  7 files   ± 0     0 ❌ ± 0 

Results for commit a125d9b. ± Comparison against base commit 5862033.

This pull request removes 4 and adds 29 tests. Note that renamed tests count towards both.

Hydra.API.ServerOutput/JSON encoding of (ReasonablySized (ServerOutput (Tx ConwayEra))) ‑ allows to encode values with aeson and read them back
Hydra.API.ServerOutput/JSON encoding of (ReasonablySized (ServerOutput (Tx ConwayEra))) ‑ produces the same JSON as is found in golden/ReasonablySized (ServerOutput (Tx ConwayEra)).json
Hydra.API.ServerOutput/JSON encoding of (ReasonablySized (ServerOutput SimpleTx)) ‑ allows to encode values with aeson and read them back
Hydra.API.ServerOutput/JSON encoding of (ReasonablySized (ServerOutput SimpleTx)) ‑ produces the same JSON as is found in golden/ReasonablySized (ServerOutput SimpleTx).json

Hydra.API.ServerOutput/JSON encoding of ServerOutput ‑ allows to encode values with aeson and read them back
Hydra.API.ServerOutput/JSON encoding of ServerOutput ‑ produces the same JSON as is found in golden/ServerOutput/CommandFailed.json
Hydra.API.ServerOutput/JSON encoding of ServerOutput ‑ produces the same JSON as is found in golden/ServerOutput/CommitApproved.json
Hydra.API.ServerOutput/JSON encoding of ServerOutput ‑ produces the same JSON as is found in golden/ServerOutput/CommitFinalized.json
Hydra.API.ServerOutput/JSON encoding of ServerOutput ‑ produces the same JSON as is found in golden/ServerOutput/CommitRecorded.json
Hydra.API.ServerOutput/JSON encoding of ServerOutput ‑ produces the same JSON as is found in golden/ServerOutput/CommitRecovered.json
Hydra.API.ServerOutput/JSON encoding of ServerOutput ‑ produces the same JSON as is found in golden/ServerOutput/Committed.json
Hydra.API.ServerOutput/JSON encoding of ServerOutput ‑ produces the same JSON as is found in golden/ServerOutput/DecommitApproved.json
Hydra.API.ServerOutput/JSON encoding of ServerOutput ‑ produces the same JSON as is found in golden/ServerOutput/DecommitFinalized.json
Hydra.API.ServerOutput/JSON encoding of ServerOutput ‑ produces the same JSON as is found in golden/ServerOutput/DecommitInvalid.json
…

♻️ This comment has been updated with latest results.

[noonio]

Added a commit fixing hydraw to use SnapshotConfirmed instead of TxValid.

I tested this myself by:

• Running the demo: nix run .#demo
• Manually initing the transaction:

nix run .#hydra-tui -- --testnet-magic 42 --connect 127.0.0.1:4001 \
  --node-socket devnet/node.socket -k devnet/credentials/alice-funds.sk

( pressing i to init )

• Commiting funds as everyone (similar invocations to above)
• Running hydraw as bob from within the ./hydraw/static directory

HYDRAW_NETWORK=42 HYDRA_API_HOST=127.0.0.1:4001 \ 
  HYDRAW_CARDANO_SIGNING_KEY=../../demo/devnet/credentials/bob-funds.sk cabal run hydraw

• Clicking around on http://localhost:1337/ to make sure it works!

[noonio]

Looks good; and can confirm that it works as well!