Spike: hydra blockfrost chain observer

[ffakenz]

🥶 Added Blockfrost Mode to hydra-chain-observer.

🥶 The network id and block time are derived from the configured BLOCKFROST_TOKEN_PATH.

🥶 Implemented a naive roll-forward approach:

• 🧊 We start following the chain from a given block hash or the tip (latest block).
• 🧊 We check if the current block is within the safe zone to be processed, using the "number of block confirmations"

  Based on some reference from a not-so-stranger on the internet.

• 🧊 From the transaction hashes of the block, we fetch the transactions in CBOR representations.
• 🧊 We then deserialise them into Cardano API transactions, allowing us to collect head observations by reusing existing code.
• 🧊 Finally, using the next block hash information from the block, we repeat the process.

🥶 Note: If any "retriable error" occurs during roll-forward, we wait based on the known block time before restarting using latest known fetched block and UTxO view (collected observations).

---

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

[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-09-27 13:00:39.163336737 UTC
Max. memory units	14000000
Max. CPU units	10000000000
Max. tx size (kB)	16384

Script summary

Name	Hash	Size (Bytes)
νInitial	2fac819a1f4f14e29639d1414220d2a18b6abd6b8e444d88d0dda8ff	3799
νCommit	2043a9f1a685bcf491413a5f139ee42e335157c8c6bc8d9e4018669d	1743
νHead	2ee477c60839936be49a50030690865b5bed4db8cd2f05bf255ac680	10068
μHead	a1610f6e64843161f4a88229c0286176f5325de3e2f773eec2b1d818*	4508
νDeposit	c2117fd9ebdee3e96b81fd67ff7092d638926415c10f1f7e5a267ad0	2791

• 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.84	2.31	0.44
2	5297	7.44	2.95	0.46
3	5498	8.73	3.46	0.49
5	5901	11.31	4.47	0.53
10	6907	18.30	7.24	0.65
57	16355	82.95	32.81	1.78

Commit transaction costs

This uses ada-only outputs for better comparability.

UTxO	Tx size	% max Mem	% max CPU	Min fee ₳
1	566	10.52	4.15	0.29
2	758	13.86	5.65	0.34
3	943	17.33	7.20	0.38
5	1317	24.65	10.44	0.48
10	2244	45.22	19.36	0.75
20	4125	95.99	40.76	1.40

CollectCom transaction costs

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	560	22.17	8.68	0.42
2	113	671	33.10	13.11	0.54
3	170	782	45.02	18.03	0.68
4	227	893	60.41	24.37	0.85
5	281	1004	73.72	30.03	1.01
6	338	1116	91.64	37.52	1.21

Cost of Decrement Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	646	17.70	7.79	0.38
2	778	18.54	8.78	0.40
3	929	19.98	10.07	0.43
5	1333	24.16	13.14	0.50
10	2097	34.87	20.99	0.68
50	8008	97.17	74.37	1.82

Close transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	648	20.11	9.03	0.41
2	808	21.53	10.43	0.44
3	944	22.99	11.83	0.46
5	1178	25.80	14.56	0.52
10	2065	34.68	22.86	0.69
50	8147	99.50	84.34	1.92

Contest transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	696	25.90	11.14	0.47
2	807	27.61	12.62	0.50
3	947	29.38	14.13	0.53
5	1309	33.82	17.86	0.61
10	2079	43.10	25.94	0.78
39	6352	98.20	72.98	1.75

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	4998	17.47	7.61	0.57
2	5129	29.38	12.94	0.71
3	5290	42.64	18.87	0.86
4	5293	52.49	23.09	0.97
5	5466	73.78	32.74	1.22
6	5726	98.82	44.09	1.52

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 ₳
5	0	0	4934	7.30	3.08	0.45
5	1	57	4969	8.63	3.88	0.47
5	5	285	5104	13.74	6.98	0.54
5	10	570	5274	19.20	10.45	0.61
5	20	1140	5614	30.72	17.65	0.77
5	30	1709	5956	42.04	24.77	0.93
5	40	2273	6289	53.17	31.82	1.09
5	50	2847	6633	63.91	38.69	1.24
5	81	4611	7685	99.47	60.99	1.73

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-09-27 13:02:58.466586879 UTC

Baseline Scenario

Number of nodes	1
Number of txs	3000
Avg. Confirmation Time (ms)	4.508222094
P99	6.869672519999994ms
P95	5.7298588ms
P50	4.346336ms
Number of Invalid txs	0

Three local nodes

Number of nodes	3
Number of txs	9000
Avg. Confirmation Time (ms)	23.078531456
P99	114.69643864000001ms
P95	29.629621299999997ms
P50	20.781996999999997ms
Number of Invalid txs	0

[github-actions]

Test Results

503 tests  ±0   497 ✅ ±0   22m 43s ⏱️ + 1m 59s
160 suites ±0     6 💤 ±0 
  7 files   ±0     0 ❌ ±0 

Results for commit 16f309e. ± Comparison against base commit 2a36ef7.

♻️ This comment has been updated with latest results.