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

Plutus Core Team Update

· 2 min read
Ziyang Liu
Software Engineering Lead

High level summary​

The Plutus team has continued work on the Dijkstra builtins and conformance testing. In particular we've finalized the cost models of the keepPolicies and dropPolicies builtins (CIP-0168). We've also added 65 conformance cases for the new Value builtins, and specified these builtins and multiIndexArray in the Plutus Core specification.

On the metatheory front, a new tool generates Agda typechecking tests from the conformance suite. We've also added the new builtins to the metatheory as postulates, and added support for casing on Data to the certifier's case-reduce pass.

Other than these, we've fixed the PIR and UPLC constant folding passes so they no longer fold builtin applications with impure arguments, which could incorrectly discard computations that fail. We've also fixed compilation of Plutus V4 context types and aligned the lookupCoin and valueContains memory models with the existing cost-model parameters.

Work in progress includes implementing arrays and bytestrings in the metatheory, fixing certification of the case-of-case pass, and further CEK machine optimizations.

Key Pull Requests Merged​

Pull Requests In Progress​

Consensus Team Update

· 3 min read
Damian Nadales
Consensus Team Lead

High level summary​

  • Leios implementation on main (Treasury Funding Initiative 4: Ouroboros Leios Implementation):
    • In the Dijkstra era, block producers now forge endorser blocks from the transactions that do not fit in the ranking block, and write them to the LeiosDB (#2377, #2442).
    • The ChainDB now opens the LeiosDB and drives its garbage collection (#2431). The LeiosDB no longer de-duplicates transactions, which makes its schema simpler (#2370).
    • Chain selection now checks the Leios certificate of a block when the block arrives. It waits to select the block until the node has the certified endorser block (#2439, #2433).
    • The node now relays Leios votes. It checks each vote once and disconnects from a peer that sends an invalid vote (#2430).
    • The Leios decoders now reject oversized hashes and endorser blocks. This ports the fix for audit finding LEI-004 from the prototype (#2440, #2458).
    • The LeiosDB benchmark now measures latency under load instead of throughput (#2422).
  • Leios prototype (Treasury Funding Initiative 4: Ouroboros Leios Implementation):
    • Released rc-2026w43. The LeiosDB writes endorser blocks faster, and block producers forge certifying blocks in milliseconds instead of up to 0.9 s (#2449, #2451).
    • Released rc-2026w44 with adaptive endorsements. If endorser blocks do not get enough votes, block producers forge smaller ones, so throughput goes down step by step instead of falling back to Praos levels (#2475, ouroboros-leios#1152).
    • The node now traces the time and cost to validate an endorser block, for our performance models (#2443).
  • Maintenance and support (Treasury Funding Initiative 17: Maintenance and Support):
    • Released ouroboros-consensus 5.3.0.0 (#2470). It lowers memory use when the node writes ledger snapshots (#2467, #2468). The forging traces no longer count the mempool snapshot time as block forging time (#2471).
    • cardano-node no longer reports a false configuration difference for the default LSM database path (cardano-node#6742).

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