Bring in example that just spends from a script in L2 and closes

[noonio]

This brings in the bulk of the work from #1742 ; it demonstrates that one can spend from a script on L2. This is useful infrastructure to, say, test a custom ledger operation and check that the Hydra can deal with that on it's own ledger, but still close and go back to L1 successfully.

This is a useful test in any case.

Note that it contains a TODO around a bug we saw with autobalancing, that will hopefully be fixed in subsequent versions of cardano-api.

We make two further additions:

• We attempt to zero-out a few more fee fields in the protocol params
• We provide buildTransactionWithPParams to explicitly set the pparams instead of using the L1 pparams. This is an important observation!

[github-actions]

Transaction cost differences

No cost or size differences found

[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	2025-01-22 12:24:12.192469341 UTC
Max. memory units	14000000
Max. CPU units	10000000000
Max. tx size (kB)	16384

Script summary

Name	Hash	Size (Bytes)
νInitial	c8a101a5c8ac4816b0dceb59ce31fc2258e387de828f02961d2f2045	2652
νCommit	61458bc2f297fff3cc5df6ac7ab57cefd87763b0b7bd722146a1035c	685
νHead	5350e9d521552ebfd9e846fd70c3b801f716fc14296134ec0fb71e97	14492
μHead	6b49dc4e571207d615dba01996548cb610b0caa85c30423d169d0091*	5612
νDeposit	ae01dade3a9c346d5c93ae3ce339412b90a0b8f83f94ec6baa24e30c	1102

• 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	6162	10.33	3.30	0.53
2	6365	12.04	3.82	0.56
3	6571	14.40	4.58	0.59
5	6966	18.74	5.96	0.65
10	7974	28.66	9.06	0.80
44	14811	98.38	30.98	1.82

Commit transaction costs

This uses ada-only outputs for better comparability.

UTxO	Tx size	% max Mem	% max CPU	Min fee ₳
1	559	2.44	1.16	0.20
2	743	3.38	1.73	0.22
3	920	4.36	2.33	0.24
5	1280	6.41	3.60	0.28
10	2179	12.13	7.25	0.40
54	10070	98.61	68.52	1.88

CollectCom transaction costs

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	525	24.20	7.07	0.42
2	113	640	34.07	9.82	0.52
3	168	751	43.38	12.43	0.62
4	228	858	47.81	13.92	0.67
5	281	969	62.31	17.79	0.82
6	338	1081	71.73	20.45	0.92
7	396	1192	78.07	22.37	0.99
8	450	1303	82.96	24.05	1.05

Cost of Increment Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	1796	24.05	8.00	0.48
2	1929	25.60	9.16	0.51
3	2095	27.04	10.35	0.54
5	2435	31.39	13.18	0.61
10	3217	41.28	19.75	0.77
42	8014	98.36	60.07	1.73

Cost of Decrement Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	598	22.44	7.26	0.41
2	814	25.30	8.72	0.45
3	831	23.88	8.97	0.44
5	1171	28.87	11.70	0.52
10	2050	41.16	18.50	0.71
40	6378	95.46	53.66	1.59

Close transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	696	27.03	8.74	0.46
2	797	30.32	10.36	0.50
3	1063	33.23	12.15	0.55
5	1168	32.92	13.15	0.56
10	2080	44.01	20.48	0.75
40	6534	98.21	58.65	1.65

Contest transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	683	33.39	10.44	0.53
2	871	35.90	11.98	0.57
3	1041	37.82	13.25	0.60
5	1200	41.17	15.48	0.65
10	2071	54.03	23.26	0.85
32	5149	96.95	51.39	1.53

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	6069	26.04	8.82	0.69
2	6193	34.68	11.74	0.79
3	6356	43.71	14.86	0.89
4	6485	50.30	17.11	0.97
5	6547	57.80	19.61	1.05
6	6677	70.93	23.96	1.19
7	6825	79.35	26.84	1.29
8	6915	89.35	30.18	1.39

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	6163	18.76	6.42	0.62
10	1	57	6197	19.62	6.80	0.63
10	5	285	6333	28.55	10.36	0.73
10	10	569	6502	36.88	13.76	0.83
10	20	1140	6842	56.83	21.77	1.07
10	30	1705	7180	76.79	29.78	1.30
10	40	2279	7524	96.75	37.80	1.54
10	42	2394	7592	99.73	39.03	1.57

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 2025-01-22 12:27:11.640344232 UTC

Baseline Scenario

Number of nodes	1
Number of txs	300
Avg. Confirmation Time (ms)	4.859384196
P99	9.691626169999967ms
P95	6.517376650000001ms
P50	4.641872ms
Number of Invalid txs	0

Three local nodes

Number of nodes	3
Number of txs	900
Avg. Confirmation Time (ms)	23.494125798
P99	39.63157768999997ms
P95	30.060908199999986ms
P50	21.820992500000003ms
Number of Invalid txs	0

[github-actions]

Test Results

  5 files  ±0  165 suites  ±0   29m 11s ⏱️ - 2m 0s
562 tests +1  560 ✅ +1  2 💤 ±0  0 ❌ ±0 
564 runs  +1  562 ✅ +1  2 💤 ±0  0 ❌ ±0 

Results for commit c5bc555. ± Comparison against base commit 64428c6.

♻️ This comment has been updated with latest results.

[v0d1ch]

It wouldn't hurt if we added couple of lines to also fanout and check the final utxo on L1 but fine

[noonio]

@v0d1ch Ah good call; I'll add that.