Skip to main content

· 2 min read
Jean-Philippe Raynaud

High level overview

This week, the Mithril team released the 2537.0 distribution, which provides support for Cardano node v.10.5.1, stabilizes commands of the client CLI, provides support for ARM pre-built binaries, and includes various bug fixes and improvements.

The team also completed updating the CIP of the DMQ protocol and its implementation in Pallas and Mithril nodes, introducing changes to the message structure and the n2c local notification mini-protocol. They continued working on the preparatory phase of decentralizing configuration parameters and on supporting multiple proof systems in the STM library.

Finally, a part of the team attended the Node Diversity Workshop #2 event in Toulouse, France, and began testing the integration of the Haskell DMQ node with the Mithril nodes.

Low level overview

  • Released the new distribution 2537.0
  • Published a dev blog post about the Distribution 2537 availability
  • Published a dev blog post about the Linux ARM binaries availability
  • Completed the issue Release 2537 distribution #2625
  • Completed the issue Update the DMQ message structure #2670
  • Completed the issue Update the n2c Local Message Notification mini-protocol in DMQ #2673
  • Completed the issue Decentralization of configuration parameters - Phase 0 #2691
  • Worked on the issue Support multiple aggregation proof systems in STM library #2680
  • Worked on the issue Decentralization of configuration parameters - Phase 1 #2692
  • Worked on the issue Integrate the Haskell DMQ node #2674
  • Worked on the issue Enhance STM library readability #2568

· 4 min read
Michael Karg

High level summary

  • Benchmarking: Feature benchmarks for a new tx submission logic; generalized on-disk benchmark profiles.
  • Development: New tracing system for cardano-submit-api; Node conformance testing groundwork, being applied to metrics.
  • Infrastructure: Dijkstra era being incorporated into benchmark tooling.
  • Tracing: Creating a library package and API from cardano-tracer, facilitating dedicated trace consumer applications.
  • Team: Ruslan joins Performance & Tracing, will be aimed at Leios.

Low level overview

Benchmarking

We've performed and analysed feature benchmarks of TxSubmission protocol, version 2. It's designed to reduce redundant exchange of transactions between network nodes. To that end we've created a dedicated benchmark which is able to locally reproduce performance observations on the cloud cluster - and hence be executed with GHC profiling for tracking time and space usage.

The on-disk (LMDB) benchmarks for the cluster have been generalized into full-fledged benchmarking profiles that can be scaled for available RAM (and thus the pressure on the on-disk backing store to perform disk I/O) - and be applied to other backing store implementations as well. This will allow for direct performance comparisons with the lsm-trees solution, once it is integrated into the Node.

Development

There's a microservice, cardano-submit-api, which is run independently from the Node (if desired). It allows for Cardano transactions to be submitted via HTTP POST, instead of Cardano native protocols. It's still using the legacy tracing system, which is why we're currently porting its logging and metrics to the new one.

We're also laying groundwork for (multi-)node conformance testing. This entails creating a specification document for semantics of existing traces. These traces can then be emitted accordingly across diverse node implementations. Given the unified semantics, these points of evidence can then be evaluated against each other, against our Haskell reference implementation, or against a model of specified / expected behaviour, resulting in a quantifiable way to assess conformance across individual implementations. Currently, we're implementing a playground version of this in the tracing system's own test suite, where we assess whether the metrics a node exposes conforms to the trace evidence in its logs, and to the metrics it forwards to cardano-tracer.

Infrastructure

As a maintenance task, we're integrating the new Dijkstra ledger era into our performance workbench and all benchmarking tools. This will allow us to specify existing profiles in the new era (allowing us to comparatively benchmark its implementation against previous eras) as well as create new benchmarks making use of any Dijkstra-specific feature.

Tracing

The trace consuming / processing service cardano-tracer had been built as a monolithic application. We're currently redesigning it as a more modular one, splitting it up into a library and an application proper (which hosts all its current high-level functionality). The underlying library will be equipped with an API that meets community standards in the future. For now, we're focusing on making all library components safely restartable and reconfigurable, as well as providing abstract, clean intra-process communications (cardano-tracer is a highly multi-threaded app). These capabilities are also verified in the test suite.

This will facilitate rapid development of custom, specialized applications for trace consumption and processing: The library package will provide all mid-level abstractions, as well as the Cardano native multiplexed forwarding protocol. It will allow any application to focus exclusively on implementing the high-level features it aims to.

Team

Ruslan joined Performance & Tracing as a Software Engineer. He has a ton of functional programming experience under his belt, in Idris, in Haskell and in Scala. Additionally, he used to work as a perfomance engineer for a large, distributed commercial system. This all makes him an ideal candidate for Cardano performance engineering, and perspectively for all new Leios benchmarks and performance tests. Welcome, Ruslan!

· One min read
Damian Nadales

High level summary

The Consensus team is drafting an architectural design based on Leios CIP-0164 (draft). The design document is currently in draft form and can be found at this link.

The team has also completed augmenting the hardfork combinator to be Peras-aware (#1681).

· 2 min read
Jean-Philippe Raynaud

High level overview

This week, the Mithril team created the pre-release for the 2537.0-pre distribution, which provides support for Cardano node v.10.5.1, stabilizes commands of the client CLI, provides support for ARM pre-built binaries, and includes various bug fixes and improvements.

They kept updating the CIP of the DMQ protocol and its implementation in Pallas and Mithril nodes, introducing changes to the message structure and the n2c local notification mini-protocol. They also completed the prototyping of a SNARK proving circuit for Mithril certificates in collaboration with the innovation team. Additionally, the team completed a prototype of a Mithril/Cardano bundle within a Docker image, which allows for a seamless start of a Mithril signer when starting a Cardano node in block producer mode.

Finally, they began working on the preparatory phase of decentralizing configuration parameters and started implementing support for multiple proof systems in the STM library.

Low level overview

  • Pre-released the new distribution 2537.0-pre
  • Completed the issue Simple Aggregation Halo2 - Prototype #2526
  • Completed the issue Add verification of a tampered Cardano database in the CI #2678
  • Completed the issue Flakiness in e2e tests in CI #2687
  • Completed the issue Prototype Mithril/Cardano bundle in Docker image #2616
  • Worked on the issue Update the DMQ message structure #2670
  • Worked on the issue Update the n2c Local Message Notification mini-protocol in DMQ #2673
  • Worked on the issue Release 2537 distribution #2625
  • Worked on the issue Decentralization of configuration parameters - Phase 0 #2691
  • Worked on the issue Support multiple aggregation proof systems in STM library #2680
  • Worked on the issue Enhance STM library readability #2568

· One min read
Ziyang Liu

High level summary

  • We are in the process of implementing CIP-0153: the Value built-in type, and built-in functions operating on Values. The implementation is expected to finish in the coming weeks. These primitives will be enabled at the upcoming intra-era hard fork.

  • We continued developing the UPLC-CAPE benchmark, aimed to compare the performances of different surface languages targeting UPLC. A third scenario, two party escrow, has been added to the benchmark.

  • We have merged the implementation of the multi-scalar multiplication primitives (CIP-0133). They will be enabled at the upcoming intra-era hard fork.

  • We continued investigating more efficient ways of case analysis on Data in UPLC.

Low level summary

Key Pull Requests Merged

Issues and Pull Requests In Progress

  • Add deleteCoin, lookupCoin, valueContains
  • Built-in Value: conformance testing (in plutus-private)
  • Built-in Value: costing (in plutus-private)
  • MSM primitives: conformance testing (in plutus-private)
  • MSM primitives: property-based testing (in plutus-private)