Skip to main content

· One min read
Kostas Dermentzis

High level summary

The DBSync team has fixed issues of the latest release, related to offchain data, wrong pool_stat fields, invalidated votes. We also added a requested feauture, which optionally adds a new address table, separating the address from the tx_out table. Finally we worked with the ledger team for memory improvements and introducing ledger events for DBSync.

Lower level summary

Older missing summary

Previously, the DBSync team prepared release 13.5.0.2 which passes the HF and brings all new governance functionality.

· 3 min read
Michael Karg

High level summary

  • Benchmarking: New GHC9 benchmarks for Node 9.2.
  • Development: Progress on Governance action workload.
  • Workbench: Switch to Haskell-based profile content generation is imminent, along with significant code cleanup.
  • Tracing: New major release: cardano-tracer-0.3; metrics alignment is ongoing.
  • Consensus QTAs: Automation setup and implementation for beacon is complete, entering testing.

Low level overview

Benchmarking

The GHC team has been busy investigating the optimization behaviour of GHC9 vs GHC8 on the Cardano code base. It appears that speculative evaluation (a feature absent from GHC8) can, in some cases, lead to overeager evaluation - and hence to an unnecessary performance impact on the system. We've created a build of the Node with a patched version of GHC9.6 which disables speculative evaluation for these cases only - and then we've run our release benchmark workloads on a cluster of those nodes. The raw data is still under analysis, but initial results look promising.

Development

The new governance action / voting workload for cluster-wide benchmarks is still under works. Our submission service tx-generator is now able to assume the identity of all registered DReps to sign votes. Currently, we're working on defining (and correctly throttling) a stream of those votes, such that a constant number of open proposals keep receiving votes throughout the entire benchmarking run.

Workbench

The Haskell service to create benchmarking profile content, cardano-profile, has been in beta use for some time now. It has proven to be much more maintainable, and its approach to declare profile content is much more principled than the existing implementation with jq / bash. We've decided to switch to that service for good, including a final validation of all possible profiles between implementations. In the same go, we'll take the opportunity to remove some bulky parts of workbench which were motivated by the jq implementation, as well as simplify the corresponding nix evaluations (and redundant shell invocations).

Tracing

Further adjustments to the metrics naming schema in the new tracing system is ongoing.

For cardano-tracer, several PRs have successfully landed. EKG monitoring is now capable of serving many metrics stores from just one process. Prometheus exposition has been made OpenMetrics compliant. The space leaks in the forwarding backend have been verifiably closed, and the log rotation issue has been resolved. Thus, cardano-tracer will see (alongside the next Node release) a new major release 0.3. This release is considered to be 100% production-ready.

Consensus QTAs

beacon - a first step in building a benchmarking framework based on Delta-Q system design - has received a fully functional automation. According to the design we settled on 3 months ago, it's now possible to test, manage, and deploy a nix service for a self-hosted GitHub runner which performs beacon benchmarks on pre-defined workload fragments. The runner can be triggered automatically or manually. As the nix service will likely share a host with other, potentially resource intensive tasks, a locking mechanism is implemented to prevent distortion of the measurements. The automation is now entering testing phase.

· 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:

  • All environments have been upgraded to cardano-node 9.2.1.

  • Cardano-faucet 9.2 is available and deployed which is compatible with node 9.2.x and has fixed ipv6 functionality.

  • All deployed machines now default to nix 2.24-maint after an upstream bug causing a hash miscalculation in submodules has been fixed. Nix 2.21 forward required some rework of the colmena deployment recipes as dirty git trees now force an impure colmena deployment.

  • To ease the process of upgrading cardano-parts, releases will now be made instead of only PR merges with migration notes.

Repository Work

Cardano-faucet

  • Binds ipv6 interface in addition to ipv4, parses and logs all ips to a unified ipv6 format and applies hlint and fmt updates. cardano-faucet-pull-14

  • Makes required changes for cardano-api 9.2.0.0 and 9.3.0.0, removes void type sig constraints, bumps haskellNix, CHaP, cardano-api -> 9.3.0.0 for node 9.2.x compatibility. Disables mingw32 builds until alex in current haskellNix pin is updated. cardano-faucet-pull-15

Cardano-parts

  • Sets cardano-node to 9.2.1, cardano-faucet to 9.2. Bumps nix to 2.24-maint and adds ipv6 and nix versioning fixes and other improvements. Begins cardano-parts date-based releases for an improved upgrade process. Adds misc fixes and improvements. More detail is available in the release notes: cardano-parts-release-v2024-10-07

Cardano-playground

  • Deploys cardano-node to 9.2.1, cardano-faucet to 9.2. Bumps nix to 2.24-maint and adds ipv6 and nix versioning fixes and other improvements. Adds a wip node pparams api server. More detail is available in the PR description: cardano-playground-pull-33

Cardano-mainnet

  • Deploys cardano-node to 9.2.1, bumps nix to 2.24-maint and adds ipv6 and nix versioning fixes and other improvements. Converts bootstraps to a new cached-index-patch branch and upgrades CF canary sql queries. More detail is available in the PR description: cardano-mainnet-pull-23

· One min read
Noon van der Silk

High-level summary

This month we continued our work on incremental commits and blockfrost. We spent a bit of time conducting some experiments in ways to potentially improve our CI build times, and completed an encouraging spike around using Raft (via etcd) for our networking layer, among some other minor cleanups and version bumps. Up next We will continue on with incremental commits and blockfrost, as well as some items coming out of the Doom work, to improve our memory efficiency, and finally we will aim to move to PlutusV3!

What did the team achieve?

  • Investigated CI improvements #1647, #1615
  • Updated networking documentation to reflect assumptions and present state #1649
  • Good progress on incremental commits #1522
  • Good progress on blockfrost integration in the Hydra node #1631
  • Update to use cardano-node 9.2.0 #1651
  • Investigated Raft for networking #1591
  • Grooming work on the partial fanout feature #1468

What's next?

  • Continued work on incremental commit #199
  • Continued work on Blockfrost integration #1305
  • Improvements to memory usage #1618
  • Work towards moving to PlutusV3 #1665
  • CBOR datum on transaction outputs #1543

· One min read
Damian Nadales

High level summary

Over the past two weeks, we worked on establishing a first baseline for the Consensus QTA (#1256). This work is also helping inform discussions with the Networking team about sync performance goals in general and for specific improvements, such as Genesis.

UTXO-HD was rebased atop main and the tests are passing.

Finally, the team has also worked to improve the Consensus layer's robustness and security.