Skip to main content

· One min read
Kostas Dermentzis

High level summary

We've made progress in all high level objectives

  • CIP-1694 integration design
  • UTxO-HD integration proof of concept
  • schema migrations with a focus on speeding up frequent queries is part of release 13.1.1.2 and tested
  • Many devx issues resolved

Lower level summary

  • We have improved and validated the design for the Conway integration in db-sync
  • Improved the initial integration of the UTxO-HD feauture branches which are under test
  • Prepared a new release 13.1.1.3 which supports node 8.1.1 #1455.
  • This also fixes a bug #1451
  • Added new tests to the new tx_out options #1429
  • Fixed a chronic issue in db-sync related to exception handling and concurrency This fixes many other issues and simplifies the logic in db-sync #1447
  • A number of fixes and improvements in ci, docker, devx, docs #1436#1442#1448#1452

· 2 min read
Carlos LopezDeLara

2023-06-21 - 2023-07-04

High level summary

  • Started integration of conway era into the cardano-api,
  • Pre-release of cardano-cli 8.2.1 which enables creating goveranance "Update constitution" governance actionsas well as voting. Both only as SPO. DREP and CC will come in future releases.
  • Cardano-cli is moving to a top-level era command structure (i.e. cardano-cli conway, cardano-cli babbage, etc to accomodate for different fucntionalities available in diferent eras. In particular between Babbage and Conway governance-related functionalities.
  • Continue refactoring cardano-testnet
  • CI and docs house keeping on the new cardnao-cli and cardano-api repositories

cardano-cli

cardano-api

cardano-node

cardano-testnet

docs

CI & project maintenance

· One min read
Sebastian Nagel

High-level summary

This week, the Hydra team wrote and published the monthly report for June, implemented the end-to-end functionality for external commits, and tested it on the preview environment. They also listed Hydra as a tool on the Cardano developer portal, providing more visibility for the project. The team clarified the path forward for L2 protocol improvements and explored an alternative CI approach using cabal instead of nix. Additionally, they released version 0.11.0, marking another milestone in the projects development.

What did the team achieve this week

  • Written and published the monthly report for June
  • Implemented external commits end-to-end incl. tested it on preview #215
  • Listed Hydra as a tool on cardano developer portal
  • Cleared up path forward on L2 protocol improvements #728
  • Established an alternative CI using more cabal tools #923
  • Release version 0.11.0

What are the goals of next week

  • Spike on performance improvements of event sourced persistence #913
  • Complete ReqSn only sends transaction ids #728
  • Groom and plan last items for 0.12.0 (remove internal commit)
  • Improve reliability of benchmarks

· 3 min read
Jean-Philippe Raynaud

High level overview

The Mithril team completed the design of the signer deployment model for the SPOs to run Mithril on their Cardano mainnet infrastructure, and implemented the associated Mithril Relay in the Mithril networks. They started working on the design and implementation of a stress test tool for benchmarking the aggregator performances. They worked on the refactoring of the Mithril Stake Distribution entity and the uniformization of the date types in the nodes. They also worked on implementing a new tool command in the aggregator and its first sub-command that helps avoiding re-genesis of the certificate chain when the structure of the certificate is updated. Additionally, they worked on implementing some monitoring for the Mithril infrastructure, and worked on a retry mechanism for the artifact creation of the aggregator.

Finally, they fixed some bugs, and they completed the upgrade of the Mithril networks to Cardano node v.8.1.1.

Low level overview

  • Worked on the epic that prepares the Mithril infrastructure for mainnet #767:
    • Worked on the issue Add infrastructure monitoring #987
  • Completed the epic Prepare Mithril Signer deployment model for SPO #862:
    • Completed the issue Design recommended deployment model for SPOs on 'mainnet' and 'preview'/'preprod' #961
    • Completed the issue Adapt infrastructure to use Mithril Relay #1018
    • Completed the issue Announce the new signer deployment model in a dev blog post #1017
  • Worked on the epic Benchmark performances of Mithril Aggregator #904:
    • Worked on the issue Design & implement basic stress test tool for aggregator #991
  • Worked on bugs:
    • Completed the issue Aggregator does not exit on critical error #993
    • Completed the issue Computation of master certificate of an epoch is incorrect #1006
    • Completed the issue End to end tests are flaky #954
    • Worked on the issue 'testing-preview' network does not create certificates #1015
  • Worked on optimizations:
    • Completed the issue Dates format is not standardized #946
    • Completed the issue Add 'recompute-certificates-hash' command to aggregator #1001
    • Completed the issue Add a retry mechanism for artifact creation in aggregator #984
    • Completed the issue Log node version at startup in Aggregator/Signer #944
    • Completed the issue Reactivate Publish Results job in CI #978
    • Completed the issue Clean 'pending_snapshot' directory of aggregator #983
    • Completed the issue Update OpenAPI spec examples #1000
  • Worked on refactoring:
    • Completed the issue Refactor 'MithrilStakeDistribution' entity #967
    • Completed the issue Refactoring client #982
    • Completed the issue Refactor download code in client #1010
    • Worked on the issue Factorize protocol crypto operations #669
  • Worked on dependencies:
    • Completed the issue Upgrade Cardano node to '8.1.1' #973

· 2 min read
Damian Nadales

High level summary

During the past two weeks the team working on the Genesis implementation continued to engage with the researchers, which resulted in various simplifications of the correctness argument for the historical Genesis window. They also decided on an approach for a syncing node to decide that it is (no longer) caught up. This functionality was requested by the networking team.

The team working on the UTxO-HD implementation ran ad-hoc benchmarks that showed performance issues, which are being investigated. They also merged several improvements required for the first UTxO-HD release, and added a package for easing integration with other downstream components.

Regarding our support activities, we integrated the latest Ledger changes into Consensus in preparation for release 8.2 of node.

Genesis

  • We continued to engage with the researchers on our probabilistic model for historical Genesis window, resulting in various simplifications that make the correctness argument more clear while not being excessively conservative.

  • We decided on an approach of how to implement functionality requested by the Networking team; namely, how a syncing node can safely conclude that it is (no longer) caught up. Certain parameters are still subject to discussion with the researchers, and we have still have to agree on a concrete API for this functionality with the Networking team.

UTxO-HD

  • We merged the last of the PRs that were part of UTxO-HD improvements for version 0.1: expose UTxO-HD configuration options in the node, refactor ledger tables, and expose a method of computing the UTxO set size.
  • We added a new "legacy" cardano block in a new ouroboros-consensus-cardano-legacy-block package that should ease the transition for some downstream packages to UTxO-HD, like db-sync. This is really only useful for downstream packages that use the parts of consensus that don't involve the storage components, in which case we can largely ignore ledger tables. Ignoring ledger tables could also make functionality like block (re-)application more performant for the legacy Cardano block as compared to the actual (UTxO-HD compatible) Cardano block.
  • We performed ad-hoc benchmarks of the UTxO-HD implementation, observing a regression in sync speed in the LMDB implementation as well as a regression in memory usage on the in-memory implementation. We are investigating this.