Skip to main content

Mithril Team Update

· 3 min read
Jean-Philippe Raynaud
Mithril Tech Lead

High level overview​

This week, the Mithril team resolved the SNARK verification key collisions deterministically in the key registration, measured the download time of a mainnet Cardano database with IPFS on dev-mainnet, and implemented a ratio for IPFS downloads in the client. They also filled the fake protocol configuration reader from a JSON hex-encoded marker configuration.

The team kept working on the activation of the snark feature by default, the prototype of the orchestrator of the setup command, the migration of the existing immutable archives to the deterministic format, and the stabilization of the certificate chain cache in the client library and CLI.

Finally, they replaced the retired macos-14 runner in the CI workflows, and worked on the upgrade to Cardano node 11.2 and on the size of the signature messages sent to the DMQ node.

Low level overview​

Features​

  • Completed the issue Resolve SNARK verification key collisions deterministically in the key registration #3591
  • Completed the issue Measure the download time of a mainnet Cardano database with IPFS on dev-mainnet #3608
  • Completed the issue Implement a ratio for IPFS downloads in the client #3641
  • Completed the issue Fill the fake protocol configuration reader from a JSON hex encoded marker configuration #3670
  • Worked on the issue Activate snark feature by default #3573
  • Worked on the issue Prototype the orchestrator of the mithril-setup command #3642
  • Worked on the issue Define the migration of the existing immutable archives to the deterministic format #3653
  • Worked on the issue Stabilize the certificate chain cache in the client library and CLI #3658

Protocol maintenance​

  • Completed the issue Rename DeprecatedCommand to RemovedCommand in the client CLI #3626
  • Completed the issue Replace the retired macos-14 runner in the CI workflows #3645
  • Completed the issue Upgrade the websites JavaScript dependencies to fix security vulnerabilities #3669
  • Worked on the issue Upgrade to Cardano 11.2 #3585
  • Worked on the issue Update the guild-operators scripts to use the on-chain protocol configuration #3661
  • Worked on the issue Keep the signature messages below the maximum size accepted by the DMQ node in testing-preview #3667

Performance & Tracing Update

· 6 min read
Michael Karg
Performance and Tracing Team Lead

High level summary​

  • Benchmarking: Preliminary benchmarks on the Leios prototype and the Leios Week42 build; refinement of performance analysis.
  • Development: In preparation for Node 11.2, we focused on fixing issues and addressing reports from the community.
  • Tracing: Switch to Hermod Tracing - preparation phase concluded; Optimization pass for trace filtering; Alert manager and Native spans ongoing.
  • Infrastructure: New Dijkstra-scoped benchmarks such as nested transactions and reference script measurements.
  • Leios: Tx validation benchmark on SPO hardware analyzed.

Low level overview​

Benchmarking​

The Performance & Tracing team has done several cluster benchmarks on the Leios prototype and the subsequent Leios Week42 build. There were several focus areas we watched out for, such as the ratio of certified EBs (Endorser Blocks). With voting traffic and timing constraints, and physical bandwidth being known limiting factors, we wanted to measure both high- and low-confidence parameter sets for the protocol in that regard. Additionally, we compared RBs' (Ranking Blocks') performance properties to a Praos-only baseline - how do block production, diffusion and adoption metrics fare? Then, we quantified mempool fragmentation and potential improvements due to the TxCache. Last but not least, as usual, our eye was on resource usage of a fully integrated build.

Our surgical windows into Leios performance are still being adjusted, based on the observations we make and asks from the Leios team; we're continuously refining coverage of our performance reports for Leios. All of the findings have been shared with the Leios team; however, they're not a public item as they do not describe an official release candidate and already contain known bottlenecks that are actively being worked on.

Development​

In preparation for Node 11.2, the team worked through a handful of community-reported bugs. A counter tracking slots missed while block forging was intentionally disabled used to jump by the whole disabled interval the moment forging resumed, booking time that was never actually missed; this is now fixed (cardano-node PR#6726). On Windows - and on Linux under a non-UTF-8 locale - the node could crash outright on a non-ASCII host or node name, or emit trace lines that weren't valid UTF-8; both cardano-node and cardano-tracer now force UTF-8 console encoding on startup regardless of the host's locale settings (cardano-node PR#6731). On the Hermod Tracing side, the Prometheus metrics endpoint now exposes its label sets with full conformance to the Prometheus text format, fixing a parsing issue some scrapers ran into (hermod-tracing PR#20).

Tracing​

As reported in earlier posts, the plan is to replace the node's current tracing system (trace-dispatcher) with Hermod Tracing once it's ready, bringing a cleaner API/core split, live reconfiguration of trace filter rules, and a single source of truth for defining tracers used across emission, documentation and consistency checks. Hermod Tracing's packages have now reached version 1.1.0, completing the API rework needed so the node's own dependencies - ouroboros-network, cardano-diffusion and ouroboros-consensus - can build against Hermod's lightweight public interface alone, rather than pulling in the full implementation package (hermod-tracing PR#21). With this now tested together with the existing node codebase, the preparation phase for the tracing system switch is concluded.

Separately, the team has been making the cost of a filtered-out trace message as cheap as possible, since most emitted traces are dropped by a severity or namespace filter before they're ever written anywhere. A series of changes to Hermod's internal configuration and message-combination logic - avoiding repeated allocations, building configured tracers once instead of per message, and specialising hot code paths - cut the cost of discarding such a message by roughly 7x, with a similar drop in memory allocated per message (hermod-tracing feature branch). The work isn't in a PR yet, pending full validation.

The monitoring/alarm system (cardano-node PR#6664) as well as library support of tracing spans (hermod-tracing PR#19) is ongoing work, with the latter being finalized and under review currently.

Infrastructure​

In preparation for the Node 11.2 release, the team extended our performance workbench (the benchmarking automation framework) with new Dijkstra-scoped profiles: nested transactions - transactions that themselves carry sub-transactions - and reference-script-based Plutus calls, benchmarked alongside the existing witness-script path (cardano-node feature branch). Getting representative results for the nested-transaction profiles also required lowering how long a node waits before requesting transactions from a newly connected peer, from the default 60 seconds down to 1, so the new profiles' load reaches the whole cluster fast enough to produce meaningful numbers.

Leios​

Validating that Leios's ledger-side assumptions hold up on a real implementation is an effort we've reported on over several past posts: can the ledger keep up with the transaction throughput Leios is designed for, and - since that depends heavily on disk I/O once the UTxO set no longer fits in memory - how much does storage hardware matter (Leios issue#553)? Last month we turned the resulting transaction-validation benchmark into a standalone executable and shipped it to SPOs so it could be run directly on their own hardware, without a nix or Haskell/cabal stack.

We've now collected and analysed submissions from a broad sample of real SPO machines. Raw read latency per transaction varied by about 32x across the field; once that's adjusted for each machine's raw CPU speed (which accounts for much of the spread on its own), the gap narrows to roughly 7-8x, driven mainly by one factor: whether a disk's write cache is write-back or write-through. Write-through disks were close to 6x slower than write-back ones before adjusting for CPU, and still more than 3x slower after - unless they sit behind a battery-backed RAID controller, which closes most of the gap. The full breakdown is available for anyone who wants to dig deeper (Benchmark results).

Mithril Team Update

· 2 min read
Jean-Philippe Raynaud
Mithril Tech Lead

High level overview​

This week, the Mithril team defined the progressive rollout strategy of the IPFS distribution, documented the replication of the immutable archives with a Kubo node, and created the new mithril-setup crate. They also addressed the findings of the M1.1 and M1.2 milestone audits.

The team kept working on the deterministic resolution of the SNARK verification key collisions in the key registration, the activation of the snark feature by default, the implementation of a ratio for IPFS downloads in the client, and the prototype of the orchestrator of the setup command.

Finally, they fixed the blocks and transactions verification failure on the testing-preview network, cleaned the mithril-test-lab directory, fixed the dependencies with security advisories, and worked on the upgrade to Cardano node 11.2.

Low level overview​

Features​

  • Completed the issue Define the progressive rollout strategy of the IPFS distribution #3607
  • Completed the issue Document the replication of the immutable archives with a Kubo node #3625
  • Completed the issue Create a new mithril-setup crate #3616
  • Completed the issue Address the findings of the M1.1 milestone audit #3635
  • Completed the issue Address the findings of the M1.2 milestone audit #3646
  • Worked on the issue Resolve SNARK verification key collisions deterministically in the key registration #3591
  • Worked on the issue Activate snark feature by default #3573
  • Worked on the issue Implement a ratio for IPFS downloads in the client #3641
  • Worked on the issue Prototype the orchestrator of the mithril-setup command #3642

Protocol maintenance​

  • Completed the issue Blocks and transaction verification fails on testing-preview #3526
  • Completed the issue Clean the mithril-test-lab directory #3595
  • Completed the issue Fix the dependencies with security advisories reported by the weekly check #3649
  • Worked on the issue Upgrade to Cardano 11.2 #3585

Mithril Team Update

· 3 min read
Jean-Philippe Raynaud
Mithril Tech Lead

High level overview​

This week, the Mithril team released the 2642 distribution. This version reads the protocol configuration from the Cardano chain in the signer and the aggregator, supports the Cardano node 11.1.3 and the DMQ node 0.7.2.0, and removes the support for the Gzip compressed snapshot archives. It also introduces a certificate chain cache in the client, support for compact SNARK certificates with a genesis-signed registry of the trusted circuit verification keys, and preliminary support for IPFS as a storage location of the immutable files (all unstable). It includes various bug fixes and improvements as well.

The team also published the immutable archives directory of the aggregator under an IPNS name, and selected a crate for the user interaction of the setup command. They kept working on the deterministic resolution of the SNARK verification key collisions in the key registration, the progressive rollout strategy of the IPFS distribution, the new mithril-setup crate, and the findings of the M1.1 milestone audit.

Finally, they worked on the upgrade to Cardano node 11.2, the renaming of DeprecatedCommand to RemovedCommand in the client CLI, the cleanup of the mithril-test-lab directory, and the investigation of the blocks and transactions verification failure on the testing-preview network.

Low level overview​

Features​

  • Completed the issue Publish the immutable archives directory under an IPNS name in the aggregator #3606
  • Completed the issue Identify a crate to use for the user interaction (TUI) of the setup command #3618
  • Worked on the issue Resolve SNARK verification key collisions deterministically in the key registration #3591
  • Worked on the issue Define the progressive rollout strategy of the IPFS distribution #3607
  • Worked on the issue Create a new mithril-setup crate #3616
  • Worked on the issue Address the findings of the M1.1 milestone audit #3635

Protocol maintenance​

Plutus Core Team Update

· 2 min read
Ziyang Liu
Software Engineering Lead

High level summary​

The Plutus team has enabled multiIndexArray (CIP-0156) and the new Value builtins policies, assetCount, keepPolicies and dropPolicies (CIP-0168) at Dijkstra for all Plutus ledger language versions. These require the Dijkstra hard fork before they can be used on-chain. We've also added conformance tests for multiIndexArray, brought the specification's versioning section up-to-date, and added casing on Data to the Agda metatheory.

The guardrail script now supports optional parameters that governance proposals can set or unset, and the Plinth compiler can report timings for individual compilation stages. Work in progress includes generating Agda typechecking tests from conformance tests, and CEK machine optimizations.

Key Pull Requests Merged​

Pull Requests In Progress​