Skip to main content

· 2 min read
John Lotoski

High level summary

The SRE team continues work on Cardano environment improvements and general maintenance.

Some notable recent changes, updates or improvements include:

  • Nixpkgs has been updated to 24.11 across all environments

  • Nix has been updated to 2.25.3 across all environments

  • TCP tuning was applied on one relay per pool group across all environments to minimize round-tripping across long distances.

  • This is the last SRE update for 2024. Hello 2025!

Repository Work

Cardano-parts

  • Nixpkgs has been updated to 24.11 and nix to 2.25.3. NixosModules and template just recipes with breaking changes from those updates were fixed. A nix jobs GHA CI test was added to verify environment spin up procedure. Template scripts were updated for compatibility with latest cardano-node protocol version and recent cardano-cli breaking changes. More details are available in the release notes: cardano-parts-release-v2024-12-19

Cardano-playground

  • Nixpkgs has been updated to 24.11 and nix to 2.25.3 and all machines deployed along with breaking changes fixes. A fund-transfer recipe was added along with other miscellaneous improvements. More detail is available in the PR description: cardano-playground-pull-38

Cardano-mainnet

  • Nixpkgs has been updated to 24.11 and nix to 2.25.3 and all machines deployed along with breaking changes fixes. Bootstrap scaling servers were disabled and block producer auto scheduled restarts were stopped. TCP transmission optimization for long distances was applied to one relay per pool group. More detail is available in the PR description: cardano-mainnet-pull-28

Iohk-nix

· One min read
Noon van der Silk

High-level summary

Entering into December, with some colleagues on holidays, we are finalising our outstanding work, and continuing to support the Hydra Doom tournament. We remain focused on finishing incremental commits, and getting multiple-version support into the explorer.

What did the team achieve?

  • Final reviews on incremental commits #199
  • Make it easier to publish docker images for branches #1756
  • Progress on custom ledger experiment #1742
  • Progress on Hydra explorer supporting multiple versions #1282

What's next?

  • Merge incremental commits #199
  • Hydra explorer supporting multiple versions #1282
  • Finish custom ledger experiment #1742
  • Plan the 0.20.0 release
  • Continue support Hydra Doom

· One min read
Damian Nadales

High level summary

  • Well-Typed held a new lsm-trees milestone presentation, where they showed the progress in two important features:
    • Snapshots (for persisting ledger snapshots)
    • Table union (for storing more parts of the ledger state on disk)
  • Finished the UTXO-HD code review work. Since this feature could have a performance impact, we need to run a new set of system-level benchmarks before we can merge it. The next steps are detailed in this comment.
  • Submitted a request to the Technical Steering Committee on how the node should handle low apparent participation.
  • Added support for computing and checking CRCs of ledger state snapshots, which increases robustness when loading this data from disk (#1319).

· One min read
Jean-Philippe Raynaud

High level overview

This week, the Mithril team continued implementing the incremental certification of the Cardano database: they kept working on creating and synchronizing the artifacts. The team finished exploring solutions for signer registration in networks with multiple aggregators and updated the About Mithril section of the website. They also progressed with developing a cache for certificate verification in the WASM client.

Finally, the team accelerated the creation of signer fixtures in the tests and added execution rights to the binaries pre-built in the CI.

Low level overview

  • Completed the issue Explore Signer Registration Solutions #2029
  • Completed the issue Reorganize the About Mithril section in the documentation website #2154
  • Completed the issue Feat: add execute rights on pre-built binaries in CI #2156
  • Completed the issue Accelerate signer fixtures creation in tests with pre-computation #2153
  • Worked on the issue Implement artifacts builder for Incremental Cardano DB #2151
  • Worked on the issue Release 2450 distribution #2124
  • Worked on the issue Handle cache for certificate verification in WASM client #1484
  • Worked on the issue Activate Pythagoras Mithril era #2034

· 3 min read
Marcin Szamotulski

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.

Network Load

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.