Enhance start up logs

[ffakenz]

Closes #2483

🔑 Motivation

Improve node observability by introducing structured lifecycle and sync-status logs.
These logs make startup, hydration, and sync transitions explicit, and provide better insight into drift before going out of sync.

Overall, this PR makes node startup phases and sync health easier to trace and reason about, while reducing noise when fully in sync.

This PR also fixes the smoke tests by allowing enough time (depending on the actual chain backend used during tests) to observe the node becoming InSync before starting the scenario.

🔄 Changes

New Logs Introduced

• LoadedChainState
  Emitted during hydration with the last known chain point loaded into chainStateHistory.

• NodeHydrated
  Emitted once node hydration completes.

• StartingDecision
  Emitted by the chain layer to report the first chain point used as prefix when selecting an intersection during chain-sync.

• ChainBackendStarted
  Emitted after successfully establishing the chain layer connection.

• NetworkStarted
  Emitted after successfully establishing the network layer connection.

• EnteringMainloop
  Emitted right before starting the runHydraNode main loop.

• SyncedStatusReport
  Emitted:

  • On every tick while CatchingUp
  • On every tick when drift exceeds 80% of the unsynced policy while InSync

---

• 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	2026-02-19 13:58:22.193468585 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	a1442faf26d4ec409e2f62a685c1d4893f8d6bcbaf7bcb59d6fa1340	14599
μHead	fd173b993e12103cd734ca6710d364e17120a5eb37a224c64ab2b188*	5284
ν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	5837	10.38	3.29	0.51
2	6038	12.44	3.94	0.54
3	6238	14.50	4.58	0.57
5	6645	18.84	5.95	0.64
10	7650	29.14	9.19	0.79
43	14279	98.58	30.79	1.80

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	740	3.38	1.73	0.22
3	920	4.36	2.33	0.24
5	1283	6.41	3.60	0.28
10	2166	12.13	7.25	0.40
54	10046	98.61	68.52	1.88

CollectCom transaction costs

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	56	524	25.20	7.30	0.43
2	114	636	32.35	9.42	0.51
3	170	747	41.46	12.00	0.60
4	227	858	48.02	13.95	0.68
5	282	974	59.17	16.98	0.79
6	339	1081	67.80	19.50	0.89
7	392	1196	74.66	21.59	0.96
8	451	1303	98.63	27.69	1.20

Cost of Increment Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	1788	24.00	7.62	0.48
2	1882	24.77	8.48	0.49
3	2056	27.36	9.87	0.53
5	2377	31.08	12.26	0.59
10	3114	40.83	18.31	0.75
40	7492	95.66	53.54	1.64

Cost of Decrement Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	598	22.80	7.36	0.41
2	784	25.39	8.75	0.45
3	849	23.99	9.01	0.45
5	1295	30.19	12.08	0.54
10	1959	38.76	17.81	0.68
43	6688	96.15	55.77	1.62

Close transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	702	27.51	8.47	0.46
2	838	31.69	10.29	0.52
3	940	30.87	10.74	0.52
5	1374	36.24	13.62	0.60
10	2065	45.77	19.62	0.75
34	5703	93.53	49.01	1.51

Contest transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	682	33.79	10.15	0.53
2	800	35.88	11.39	0.56
3	999	38.59	12.82	0.60
5	1295	42.53	15.25	0.66
10	2144	55.32	22.20	0.85
30	4963	98.77	47.56	1.51

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	5787	27.09	9.10	0.69
2	5935	36.03	12.10	0.79
3	6079	45.92	15.49	0.90
4	6187	52.88	17.71	0.98
5	6509	64.51	21.78	1.11
6	6456	72.54	24.36	1.20
7	6818	85.53	28.98	1.35
8	6972	93.99	31.68	1.44
9	6799	96.98	32.60	1.47

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	10	570	6175	39.51	14.45	0.85
10	20	1139	6513	59.54	22.38	1.08
10	30	1708	6854	79.78	30.37	1.32
10	40	2276	7192	99.66	38.24	1.55
10	39	2220	7160	98.05	37.58	1.53

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 2026-02-19 14:00:44.834992397 UTC

Baseline Scenario

Number of nodes	1
Number of txs	300
Avg. Confirmation Time (ms)	5.730581203
P99	8.650581379999998ms
P95	6.944487250000001ms
P50	5.5323825ms
Number of Invalid txs	0

Three local nodes

Number of nodes	3
Number of txs	900
Avg. Confirmation Time (ms)	39.115028783
P99	75.45990859ms
P95	64.03832424999999ms
P50	35.701879500000004ms
Number of Invalid txs	0

[github-actions]

Transaction cost differences

No cost or size differences found

[noonio]

Marking this as a draft until it compiles please.

[noonio]

@ffakenz this PR yet again doesn't build and as marked as ready for review; please do not mark a PR that doesn't build as ready for review; as I mentioned above!

[noonio]

I think this is good to go

I'm a bit sad about the huge diff when including the blockTime field into withHydraNode call; it'd be nice if that was abstracted away a bit; but I can live with it for now in the interest of getting a release done. -- Edit: Follow-up issue.

Thanks!