Add blockfrost mode to hydra-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-10-09 09:49:50.106183876 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	5096	5.65	2.23	0.44
2	5295	7.23	2.86	0.46
3	5498	8.51	3.36	0.49
5	5902	11.32	4.48	0.53
10	6906	18.02	7.12	0.65
57	16353	82.89	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	566	10.84	4.26	0.29
2	752	14.31	5.80	0.34
3	947	17.92	7.39	0.39
5	1320	25.56	10.73	0.49
10	2256	47.11	19.97	0.77
19	3940	94.71	39.81	1.38

CollectCom transaction costs

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	560	20.58	7.85	0.40
2	114	675	26.99	10.29	0.47
3	169	786	34.28	13.07	0.56
4	228	897	45.51	17.28	0.68
5	283	1004	52.49	19.98	0.76
6	337	1116	61.76	23.47	0.87
7	394	1227	67.66	25.74	0.94
8	451	1338	71.31	27.18	0.98
9	508	1449	99.20	37.60	1.29

Cost of Decrement Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	624	18.68	8.17	0.39
2	837	21.11	9.87	0.43
3	904	20.71	10.45	0.43
5	1162	23.56	13.12	0.49
10	1974	34.03	21.09	0.66
48	7889	99.92	76.08	1.85

Close transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	664	20.87	9.33	0.42
2	801	22.31	10.78	0.44
3	958	24.02	12.48	0.48
5	1233	27.09	15.43	0.53
10	2192	36.42	24.39	0.72
50	7891	98.24	85.14	1.90

Contest transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	671	26.72	11.45	0.48
2	815	28.57	13.05	0.51
3	1027	31.13	15.24	0.56
5	1306	34.53	18.31	0.62
10	1947	43.12	25.90	0.77
38	6323	98.06	74.03	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	4973	15.34	6.56	0.54
2	5062	19.11	8.09	0.59
3	5300	28.72	12.50	0.71
4	5369	35.17	15.30	0.78
5	5515	42.92	18.64	0.87
6	5771	51.11	22.44	0.98
7	5828	54.86	23.87	1.02
8	5963	64.79	28.28	1.14
9	6024	68.09	29.61	1.18
10	6097	75.44	32.81	1.26
11	6244	81.56	35.33	1.34
12	6502	90.87	39.54	1.46
13	6545	96.38	41.96	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 ₳
10	0	0	5089	10.38	4.35	0.49
10	1	56	5122	11.35	4.98	0.50
10	5	284	5258	15.63	7.71	0.56
10	10	570	5430	21.47	11.32	0.64
10	20	1139	5768	33.44	18.68	0.81
10	30	1709	6111	45.24	25.96	0.97
10	40	2275	6446	56.43	32.99	1.13
10	50	2846	6788	68.24	40.28	1.29
10	76	4325	7668	98.68	59.14	1.71

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-09 09:54:01.600437204 UTC

Baseline Scenario

Number of nodes	1
Number of txs	3000
Avg. Confirmation Time (ms)	4.457003649
P99	8.881529539999965ms
P95	5.7859471ms
P50	4.230888ms
Number of Invalid txs	0

Three local nodes

Number of nodes	3
Number of txs	9000
Avg. Confirmation Time (ms)	24.498231215
P99	101.01428072000044ms
P95	31.730803749999993ms
P50	22.4057065ms
Number of Invalid txs	0

[github-actions]

Test Results

543 tests  ±0   537 ✅ ±0   32m 6s ⏱️ -30s
162 suites ±0     6 💤 ±0 
  7 files   ±0     0 ❌ ±0 

Results for commit 4793f95. ± Comparison against base commit d51977e.

♻️ This comment has been updated with latest results.

[ch1bo]

FWIW its called Ouroboros not Ouroborus (typo)