Skip to main content

· 2 min read
Damian Nadales

High level summary

We have a proposed fix for the mempool forging regression observed in the UTxO-HD branch. We need to confirm this by running system level benchmarks. We are still working on a fall back mechanism for keeping the baseline performance of Cardano node, if the performance of the UTxO-HD is not enough. On the Genesis front, we confirmed with the researchers that the proposed Genesis design is satisfactory for the historical Cardano chain. We also have a proposed fix for the wrong protocol version bug, found in the Sanchonet, after transitioning to Conway.


  • We optimized the mempool revalidation process, which in turn ought to solve the regression observed during system-level benchmarks in the in-memory version (349). System level benchmark results are pending.
  • Regarding the workaround to keep the node's baseline performance if that of the in-memory backend turns out not to be enough for our stakeholders (344), we are still expanding the legacy block package such that we could at some point run the node with a legacy Cardano block. There are some loose ends to wrap up before we can begin the first test run.
  • We also brought the UTxO-HD branch up to date with node version 8.4.0.


  • We finished the discussion with the Researchers on how to argue that the proposed Genesis design is satisfactory for the existing historical Cardano chain. We are now drafting the final self-contained argument. (4157)


  • We debugged a bad parameter update on the Babbage to Conway transition in the SanchoNet testnet (339). A superficial patch is within reach and we are in the process of reviewing the PRs related to this fix (340, 354, and 355) However we are investigating a more principled redesign of the epoch transition logic, which required us to revisit the existing interfaces of the ConsensusProtocol type class and the HardForkBlock combinator (345 and 346). This is important to prevent these kind of errors in the future. This is an overdue step in the process of taking full ownership of the HFC: reconsidering original HFC design decisions for which we now have much more context, a few years later.

· One min read
Jean-Philippe Raynaud

High level overview

This week, the Mithril team has completed the refactoring of the terraform deployment workflows in GitHub actions, and the implementation of snapshot compression parameters in the deployments. They kept working on the refactoring and standardization of the errors in the Mithril nodes. The team also completed the implementation of Cloudflare protection for the aggregator infrastructure and started working on its deployment and activation in the Mithril networks. Additionally, they worked on recording download statistics on the aggregator which will be used to produce usage reports.

Finally, they kept working on the aggregator performance bottleneck that occurs with high client traffic and started creating a new distribution.

Low level overview

  • Completed the issue Add snapshot compression parameters in infrastructure deployments #1200
  • Completed the issue Add Cloudflare protection of infrastructure #986
  • Worked on the issue Record statistics about the downloaded snapshot in the aggregator #1127
  • Worked on the issue Error refactoring #798
  • Worked on the issue Activate Cloudflare protection of infrastructure #1230
  • Worked the issue Release new 2337 distribution #1219
  • Completed the issue Upgrade dependencies #1238

· One min read
Sasha Bogicevic
Sebastian Nagel

High-level summary

This week, most of the Hydra team was attending a cardano scaling workshop in Nantes, France. They used this oportunity to meet fellow mithril team and spend some time together to hack on some code and, as always, reflect on the past work and find optimal path forward for both projects. They also fixed a bug that caused hydra-node to crash when querying L1, worked on a new network resillience proof-of-concept and accepted a new ADR related to stateless transaction observation.

What did the team achieve this week

  • Cardano scaling workshop with members of hydra and mithril teams
  • Accepted user contribution for possible new use-case #1048
  • Fix for the hydra-node crash related to internal wallet query #1053
  • Collected experimental CI findings #1070
  • Propose first POC for the network resilience #1074

What are the goals of next week

  • Monthly review meeting & report including updates from Mithril
  • Review POC and discuss our options for the network resilience
  • Update cardano-api to version 8.20
  • Address TODOs on aiken commit validator #1072
  • Complete hydra-support in kupo kupo#117

· 2 min read
Alexey Kuleshevich

High level summary

The Ledger team's focus is still mainly on the Conway era implementation.

We were able to add ability to specify initial Constitutional Comittee and the initial version of Constitution. Priority in which Governance Action are now enacted matches the specification. DRep's deposits are now properly accounted for. Governance actions that are not allowed to be voted on by Stake Pool operators and Constitutional Committee members are prevented by transaction submission failure, rather than simply being ignored. There was a few important CDDL fixes as well as a lot of new round trip serialization tests. Constraint based testing framework has also received a lot of improvements.

Low level summary

Conway era

  • pull-3681 - Conway Genesis additions
  • pull-3690 - Preserve the order of ProposalProcedures
  • pull-3705 - Removed ProtVer from EnactState
  • pull-3700 - Add conway-specific certs to deposit/refunds
  • pull-3704 - Add comments on deprecating certs to Conway CDDL
  • pull-3698 - Reordering of governance actions
  • pull-3712 - Disallow empty fields in ConwayTxBodyRaw
  • pull-3716 - Abstract threshold calculation
  • pull-3725 - Fix mistaken use of dollar sign in cddl files
  • pull-3718 - Predicate failure for mismatched Voter GovAction
  • pull-3721 - Committee expiration, validation and modification

Improvements and releasing


  • pull-3730 - Implement Show instance for Rep using IsTypeable
  • pull-3697 - Rewrite testEql using Typeable to make it impossible to forget cases
  • pull-3709 - Add many new features to the Constrained modues in cardano-ledger-test
  • pull-3726 - Conway and other eras serialization roundtrip tests
  • pull-3713 - Improve CI resiliency against GitHub issues

· 2 min read
Marcin Szamotulski

High-level overview of sprint 44

Bootstrap Peers

In this sprint, we focused on developing bootstrap peers.

Thanks to the input from Samuel Leathers (IOG) and John Lotoski (IOG), we identified a possible improvement to bootstrap peers. A more detailed description is available here.

Cardano-Node-8.4.0 Release

We also were responsible for the cardano-node-8.4.0-pre release. A final integration PR is currently being merged. We published new versions of ouroboros-consensus, cardano-api and cardano-cli.

Towards Typed Protocols

We also updated the future typed-protocols- and its integration with cardano-node. This is towards our goal which we planned for the next quarter. The identified tasks are to fix breaking tests, and then measure and address possible performance regressions.

Tech Debt

Mark Tullsen (Galois) submitted two more PRs: ouroboros-network-#4663, ouroboros-network-#4664. We provided feedback on their other pull requests: ouroboros-network-#4661 and ouroboros-network-#4660.

P2P adoption

In the last two weeks, there was a regression in P2P adoption concerning the number of SPOs or stakes, although the number of overall P2P relays has increased. Karl Knutsson (Cardano Foundation) is investigating this issue. P2P relays

The following graphs show several different versions of relays running on the mainnet. The green line NodeToNodeVersionV10.True denotes P2P relays, which slowly increase over time. The V9 and earlier versions of the node-to-node the protocol indicates nodes version 1.35.x or earlier. node versions

Data has been kindly provided by Cardano Foundation and their mainnet monitoring infrastructure.

Open Source

We are in the process of upstreaming our ffi to Windows Named Pipes API to the Win32 package, see [win32-220].