Align protocol parameters JSON

[v0d1ch]

This is a reproduction of the issue we found where cardano-cli query protocol-parameters is missing to return certain fields (like minFeeA, minFeeB) which are present in the Json instance for PParams in cardano-ledger. Since cardano-cli is just calling the cardano-api query to obtain PParams perhaps the bug is somewhere in the fromLedgerPParams or similar functions that convert back and forth between ledger and api representation of PParams.

@ch1bo / @locallycompact adopted this PR:

In fact, the cardano-cli was not broken, but the hydra-node was expecting cardano-ledger PParams on the --ledger-protocol-parameters input file .. which is wrong and this PR fixes this now. This was a hidden breaking change on master so far!

• 👾 Load --ledger-protocol-parameters using the cardano-api ProtocolParameters instance, which is the one the cardano-cli also uses.

• 👾 Adds a test that asserts the Hydra.Ledger.Cardano.Configuration.pparamsFromJson function can read the JSON returned by cardano-cli query protocol-parameters

---

• CHANGELOG updated or not needed
• Documentation updated or not needed
• Haddocks updated or not needed
• No new TODOs introduced or explained herafter
  • One TODO about the fact that we should add (somewhere) and test against a JSON schema to ensure pparamsFromJson works as expected in hydra-node -> follow-up PR

[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	2024-01-05 18:03:42.349993309 UTC
Max. memory units	14000000
Max. CPU units	10000000000
Max. tx size (kB)	16384

Script summary

Name	Hash	Size (Bytes)
νInitial	985245919fcc6c0c5cd116023cd2c947c43e80dcbb5075fe12433fbb	4072
νCommit	7cb20fa71eb4c563ca283566ebe0aa65859d96c3f8cba35c52c181fd	2043
νHead	7a36661f5c15e9f1783aeaab890812c59b7286cbbc6de762d3110772	8816
μHead	8b111ac12274e46314769295a1c5dcab1d260096fc469fd698065463*	3851

• 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	4375	10.25	3.95	0.45
2	4576	12.72	4.90	0.49
3	4774	15.02	5.77	0.52
5	5180	19.22	7.35	0.59
10	6184	30.30	11.55	0.75
41	12418	99.15	37.65	1.77

Cost of Commit Transaction

This is using ada-only outputs for better comparability.

UTxO	Tx size	% max Mem	% max CPU	Min fee ₳
1	531	11.37	4.44	0.30
2	723	15.04	6.07	0.35
3	912	18.85	7.75	0.40
5	1280	26.90	11.27	0.51
10	2216	49.55	20.97	0.80
19	3906	99.43	41.75	1.43

Cost of CollectCom Transaction

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	480	21.12	8.27	0.40
2	113	590	33.21	13.10	0.54
3	170	700	45.87	18.26	0.68
4	227	810	63.32	25.28	0.88
5	283	924	74.40	30.08	1.01

Cost of Close Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	544	16.72	7.69	0.36
2	722	18.41	9.29	0.40
3	913	20.18	10.93	0.43
5	1215	23.23	13.80	0.49
10	2196	32.49	22.30	0.67
50	8853	98.12	83.29	1.93

Cost of Contest Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	569	20.18	8.94	0.40
2	714	21.72	10.30	0.43
3	908	24.19	12.35	0.47
5	1294	27.98	15.70	0.55
10	2103	36.71	23.34	0.71
43	7670	97.72	76.36	1.83

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	4307	18.85	8.11	0.55
2	4499	32.06	13.97	0.71
3	4661	47.34	20.79	0.89
4	4819	66.19	29.13	1.11
5	4999	87.85	38.74	1.36

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	4205	8.26	3.46	0.43
5	1	56	4238	9.49	4.22	0.44
5	5	285	4375	13.98	7.09	0.51
5	10	570	4546	20.13	10.90	0.59
5	20	1139	4885	32.43	18.53	0.76
5	30	1709	5226	45.15	26.34	0.93
5	40	2278	5565	57.46	33.97	1.10
5	50	2847	5905	69.56	41.52	1.27
5	74	4214	6719	99.34	59.96	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 2024-01-05 18:06:43.034545384 UTC

Baseline Scenario

Number of nodes	3
Number of txs	9000
Avg. Confirmation Time (ms)	23.563835508
P99	116.76609833000005ms
P95	33.556395ms
P50	20.6950895ms
Number of Invalid txs	0

Baseline Scenario

Number of nodes	1
Number of txs	3000
Avg. Confirmation Time (ms)	4.205986084
P99	6.009112069999992ms
P95	4.993861949999998ms
P50	4.10217ms
Number of Invalid txs	0

[github-actions]

Test Results

393 tests  +3   385 ✅ +2   18m 18s ⏱️ - 2m 48s
132 suites ±0     8 💤 +1 
  5 files   ±0     0 ❌ ±0 

Results for commit 191cb0c. ± Comparison against base commit bd8a113.

♻️ This comment has been updated with latest results.

[ghost]

The fact a single change to the withHydraNode function ripples all over the place because we need to modify how it's called appears to me as a want for refactoring and encapsulating the parameters into some structure with default values

[ghost]

This logic is starting to be quite large, I would suggest to extract a function eg. makeProtocolParametersFile or something