Skip to main content

· 4 min read
Michael Karg

High level summary

  • Benchmarking: Release benchmarks for Node 8.12.0; DRep benchmarks with 100k DReps.
  • Development: Merged a performance fix on 8.11; kicked off development of governance action workload.
  • Workbench: Adjusted automations to latest 8.12 Conway features and Plutus cost model; implementation of CIP-69 and CIP-117 for our tooling is in validation phase.
  • Tracing: Work on metrics naming ongoing. Factoring out RTView component is completed and has entered testing.
  • IOI Tech Meetup: Our team contributed two presentations at the meetup in Zurich; worked on community report of UTxO scaling benchmarks.

Low level overview

Benchmarking

We've run and analyzed a full set of release benchmarks for Node versions 8.12.0. In comparison with the latest mainnet release 8.9.3, we could not observe any regressions. In fact, 8.12.0 was able to deliver equal network performance at a slightly reduced resource cost - both for CPU and memory.

Another benchmark of the Conway ledger with large amounts of DReps has been performed. This time, 100000 DReps were chosen - this amount aims to simulate a scenario where lots of self-delegation takes place. While a performance impact is observable in this instance, we can still see that the number of DReps scales well overall, and poses no concern for network peformance.

Development

We have contributed and merged a performance fix on 8.11 which adresses a regressing metric in the forging loop. The regression was only observable under specific conditions. Benchmarks on 8.12 have already confirmed the fix to be successful.

We've kicked off governance action workloads for benchmarking. This will be an entirely new workload type for Conway era, targeting performance measurements of its decentralized decision making process. The workload will feature registering proposals, acting as multiple DReps to vote on active proposals, vote tallying and proposal enactment. We're very grateful for the Ledger team's helpful support so far in creating a workload design for benchmarking - one that evenly stresses the network over extended periods of time.

Workbench

The workbench automations have been upgraded to handle Node 8.12 and the corresponding integrations of Cardano API and CLI.

Furthermore, we've updated to the latest PlutusV3 costmodel in our benchmarks - as well as implemented CIP-69 and CIP-117 for all our PlutusV3 benchmarking scripts, pending validation by the Plutus team.

Tracing

The work on aligning of metrics naming and semantics of new and legacy tracing is ongoing. Additionally, we're adding a handful of metrics to the new tracing system which currently exist in legacy tracing only.

Factoring out the RTView ("real-time view") component of cardano-tracer in the new tracing system has finished. This includes a considerable refactoring of cardano-tracer's codebase, so that we're currently running test on the new codebase. Isolating RTView is due to its being in prototype stage for too long, and the design decisions taken. In the short term, this will make several package dependencies optional, which have become troublesome for CI, as well as making cardano-tracer more lightweight. RTView remains as an opt-in.

IOI Tech Meetup

Our entire team traveled to Zurich, Switzerland to attend ZuriHac'24 and the IOI Tech Meetup. It was fantastic to meet everyone in person, and we all had an amazing and very productive time. A big Thank You to everyone involved in making that happen, and making it a success.

We contributed two presentations for the meetup: a thourough introduction of the new tracing system aimed at developers - as it's not tailored exclusively to cardano-node, but can be used in other (Haskell) services as well. And secondly, an overview over the benchmarking framework based on Quantitative Timeliness Agreements which we're building - as well as a show-and-tell of our prototype, implementing part of said framework. We're grateful for the great interest and feedback from all the participants.

Last not least, we worked on creating a community report of the UTxO scaling benchmarks performed during March and April - to be released soon.

· One min read
Carlos LopezDeLara

· 2 min read
Alexey Kuleshevich

High level summary

Major milestone was reached this period. We've implemented CIP-0069 that improves PlutusV3 functionality by making spending datums optional and enforcing all scripts to have exactly one argument. This feature allows for spending scripts to be usable for other purposes, like minting for example.

Couple of important bugs have been fixed:

  • Script execution for certificates with the same plutus script did not execute correctly.
  • Prevent delegation to a non-existent pool.

With this feature complete and a few bug fixes we were also able to mark Conway era and CIP-1694 as feature complete and ready for release. Naturally, testing of Conway era will continue all the way into the hard fork.

Low level summary

Conway

  • pull-4374 - CIP-0069
  • pull-4394 - Fix Certifying Redeemer issue
  • pull-4400 - Check that the pool being delegated to exists for ConwayDelegCert
  • pull-4409 - Update to plutus-ledger-api-1.30

Testing

  • pull-4384 - Re-enabled Full NewEpochstate test
  • pull-4397 - Add a lens to HasSubState
  • pull-4399 - New simple examples for maps
  • pull-4403 - constrained-generators: Add lookup_ for maps
  • pull-4414 - constrained-generators: Hotfix failing test
  • pull-4411 - constrained-generators: introduce a hook for naming variables

Infrastructure and releasing

  • pull-4424 - GHA: Downgrade the version of actions/upload-artifact
  • pull-4426 - Take care of all compiler warnings for GHC-9.8
  • pull-4407 - Change the default ghc version to 9.6.5
  • pull-4416 - Bump urllib3 from 1.26.18 to 1.26.19 in /doc

· 2 min read
Jean-Philippe Raynaud

High level overview

This week, the Mithril team continued implementing the certification of Cardano transactions in Mithril networks. They implemented a warmup strategy for the signer and aggregator to begin importing transactions as early as possible, thus minimizing the impact of network activation on certification. They also significantly improved the throughput of the prover route of the aggregator by addressing database access bottlenecks. Additionally, the team made progress on low-latency certification by completing the handling of chain rollbacks and nearly completing the retrieval of transactions using the chain sync mini-protocol and Pallas.

Finally, they made final modifications to the threat modeling explainer for the documentation website, which will be released shortly, and worked on a bug that occurs when parsing some blocks of the SanchoNet network.

Low level overview

  • Completed the issue Handle rollbacks in Cardano transactions #1724
  • Completed the issue Pooled resources should be reset when given back #1743
  • Completed the issue Lock signature of signed entity types during warm-up #1693
  • Completed the issue Warmup import Cardano transactions at node startup #1692
  • Completed the issue Build, test and package arm64 binaries in CI #1751
  • Worked on the issue Threat modeling and risk analysis #1350
  • Worked on the issue Import Cardano transactions with ChainReader #1705
  • Worked on the issue Import Cardano transactions by sequences of block ranges #1766
  • Worked on the issue Implement database connection pooling for Cardano transaction repository #1760
  • Worked on the issue Cardano signatures are not produced on testing-sanchonet #1750

· 2 min read
Jean-Philippe Raynaud

High level overview

This week, the Mithril team released the new distribution 2423.0, which includes the removal of the snaphot command of the client CLI, as well as bug fixes and optimizations. They also continued implementing the certification of Cardano transactions in Mithril networks and improved the throughput of the prover route of the aggregator by fixing some bottlenecks in the Merkle proof computation. Additionally, the team made progress on low-latency certification by working on the retrieval of the transactions with the chain sync mini-protocol and Pallas, as well as the handling of rollbacks of the chain.

Finally, they kept working on the threat modeling explainer for the documentation website and provided support for multiple TLS implementations in the client library thanks to a community contribution.

Low level overview

  • Released the new distribution 2423.0
  • Publication of a dev blog post about the removed Mithril client CLI 'snapshot' command
  • Completed the issue Client verification fails with an already stored but non certified yet transaction #1719
  • Completed the issue Computation of Merkle proof has bottleneck with multiple transactions #1730
  • Completed the issue Automatic rollback on SQL transactions #1741
  • Completed the issue Allow the underlying TLS implementation to be selectable when using a library. #1737
  • Completed the issue Release 2423 distribution #1695
  • Completed the issue Mithril Signer Local Error Policy : Error 182 - MuxError #1632
  • Worked on the issue Handle rollbacks in Cardano transactions #1724
  • Worked on the issue Pooled resources should be reset when given back #1743
  • Worked on the issue Threat modeling and risk analysis #1350
  • Worked on the issue Import Cardano transactions with ChainReader #1705