Overview of sprint 76
Network Load
The Cardano Foundation monitors the network by injecting "canary" transactions, allowing us to measure the time taken for a transaction to be included in a block. Approximately four to five of these transactions are submitted every hour.
Since early November, network load has increased, but most transactions are still included within the first or second block after submission. Even if the network is not congested, transactions may not reach the Block Producer responsible for the next block in time due to network propagation delays. Therefore, only a transaction that takes three or more blocks to be included indicates a loaded network.
Since November 1, 2024, we have submitted around 3,700 "canary" transactions, and only 59 of them took longer than two blocks to be included, meaning 98.4% of our test transactions were included within the two-block limit. During this period, the longest observed time to inclusion was five blocks for two transactions and the maximum wait time is 201 seconds.
Where the y-axis is a fraction of the block size in the respected dimension (e.g. size, steps, memory).
Hot Standby Block-Producer Nodes
In the last Network Working Group Meeting (NWG) we discussed solutions for running hot standby block producers using P2P.
Short-Term Solution: Local Root Initiator Only Outbound Connections
We agreed to implement initiator-only connections for local roots, which wouldn't bind to the node address (and thus would be made from an ephemeral port). This allows SPOs to have hot standby nodes which are hidden from relays using a firewall rule, while they still can connect to the relays (so they receive blocks while the blocks they produce are not sent to the network). See the ouroboros-network#5020 issue and associated PRs:
The latter PR makes P2P node run on systems with multiple network interfaces or a single interface with multiple IP addresses.
An SPO can control the diffusion mode (initiator only / initiator and responder) in the topology file. A draft PR is available in the coot/connection-manager-initiator-only-0.13.2.5 branch.
In the NWG meeting, it was agreed that once this functionality is implemented, we
can remove NonP2P code from ouroboros-network (ouroboros-network#5007).
Long-Term Solution
An agreed long-term solution is to allow to control block propagation of
self-produced blocks through cardano-cli.
Reusable Diffusion
We continued working on making ouroboros-network reusable for both
cardano-node and mithril (see CIP#137). The PR can be found here:
ouroboros-network#5016, while a more detailed description of its direction can
be found here. During this sprint, we carried out a team-wise PR
review.
Block Fetch Client For Genesis
A new block-fetch client designed for Genesis was merged, see ouroboros-network#4919. The design of the new block-fetch Gensis logic is described in here.
KES Agent: Raw Bearer API
We recently merged ouroboros-network#4395 - a PR which is important for the KES-agent workstream.