Skip to main content

· 3 min read
Michael Karg
  • Benchmarking: We performed benchmarks for the new tracing system, and started benchmarking for varying GHC RTS configurations.
  • New tracing: Backwards compatibility with legacy tracer nomenclature has been merged; we're currently improving documentation and creating setup guidelines for end users.
  • Analysis pipeline: Our refined metrics PR has been merged. We're working on including variance analysis to our reporting machinery.
  • Infrastructure: Support for Conway genesis in our workbench has been merged. At the moment, we're laying the groundwork for enabling GHC 9.2 in our benchmarks.
  • Open Sourcing: The API demo has reached prototype phase; work on documenting the API and providing exemplifying use cases is ongoing.
  • Nomad backend: The nomad-exec based task driver has been merged. The backend has been equipped with the capability for genesis distribution via S3 bucket.

Performance

New tracing​

The new tracing system has undergone various benchmarking runs with variance analysis, and comparison to a baseline using legacy tracing. We could observe a slight shift in the resource usage profile from memory to CPU, but no regressions in block propagation metrics. Variance was observed to be notably smaller, which gives the new system a much better predictability. From this angle, we consider the new system fit for production use.

GHC RTS parametrization​

We're currently prerforming various runs on the cluster to explore the space of different GHC RTS settings for running nodes. The main focus lies on different configurations for the garbage collector, as well as increasing the number of CPU cores the node may use.

Open Sourcing​

Our API demo has reached prototype stage, and operates on live data from the production database. Making use of the experience gained, we're refining version 1 of the API to provide optimized usability, and creating documentation that both is descriptive of the API endpoints, and focuses on practical, exemplary use cases.

Tracing

For the new tracing system we're currently undertaking an effort to multi-layered documentation: a condensed version, as well as a setup guide with pragmatical focus, will be provided alongside the in-depth documentation. This effort should cater to different audiences, and provide distinct entry points for users of the new system, depending on their wants and needs.

Infrastructure & Analysis

General​

Having included Conway genesis in the workbench, as a next step in future-proofing out benchmarking infrastructure, we're laying the foundation for a switch in compiler version to GHC 9.2. Additionally, we considered variance analysis of our runs to merit inclusion into our reporting pipeling - which will increase confidence in specific metrics.

Nomad backend​

We have implemented an appropriate mechanism for genesis distribution: Only after a benchmarking cluster has been deployed successfully, genesis is patched and uploaded to an AWS S3 bucket for the nodes to retrieve - as a final step before initiating the actual run. We're confident that this deferred approach will provide clearer evidence for genesis patches, as well as minimize startup time for all runs by factoring in deployment re-tries.

· 2 min read
Marcin Szamotulski

High level summary​

In the last spring we released cardano-node-1.35.6 with dynamic P2P functionality.

We received reports from some SPOs who encountered problems with their non P2P block producing nodes not being able to connect to their P2P relay. Karl Knutsson (from Cardano Foundation) reproduced this issue between two nodes (a non P2P and a P2P one) on mainnet. Karl and the IOG Networking Team analysed it and found a bug in the legacy non p2p code. The bug is only possible to trigger with a P2P node which is binding its outbound connection port to a fixed IP address and port (default in p2p). A possible solution was found. For more information see #4465.

We released cardano-ping-0.1.0.0 package to CHaP. cardano-ping is no longer available as a standalone binary, but instead it will become part of cardano-cli (see #4664)

We are testing cardano-node with peer sharing functionality (#4019).

We are working on eclipse evasion. We added new class of peers: big ledger peers to the outbound governor, implemented tests and fixed found issues (#4462). We also made the information if a given peer plays the role of a big ledger peer to the mini-protocols. This will allow to modify mini-protocol applications for such peers. As part of this functionality we refactored some core types in the network code which simplifies exposed API.

Together with Moritz Angerman we started to update io-sim to ghc-9.6.1 (see #73).

We merged a fix of configuration of accepted connections limit in cardano-node (see #4902).

· 2 min read
Iñigo Querejeta Azurmendi

High level summary​

The open fronts that the crypto team is working on are:

  • Mithril: RFP finished. Code ready for audit.
  • cardano-base: BLS12-381's PR approved, only blocker is Windows' CI. Preparing extensive testing strategy together with Plutus and Testing teams.
  • KES agent: Working on a desing on how to use IO sim in order to allow for proper network simulation testing.
  • Sidechains: Preparing proving system to use the curves needed for main-net PoC.

Low level summary​

Mithril​

  • Merged PR#783
  • RFP for crypto audit ready.

cardano-base​

  • BLS12-381 branch approved PR#266. Blocker is Windown's CI. Working on it
  • Testing strategy for BLS bindings:
    • Preparing test-vectors for Groth16, and simple BLS signatures
    • Finding community projects to help write their use cases
    • Designing AC, and expected tests for higher levels of development (Plutus team, E2E tests, etc)
  • Wrote blogpost on how using the same key for ed25519 and VRF completely breaks the security of both systems

KES agent​

  • Started integration of sockets interface used in consensus
  • Use that for de/ser
  • Resolving problems with block memory in IOSim. Can't use withForeignPtr in IOSim
  • Results in having to parametrise for IOSim in KES and DSIGN for testing

Sidechains​

  • Prepared an API for proof generation in sidechains, with it's C API for integration with JVM languages.
  • Design document and start interacting with researchers for concrete instantiation of SNARK-based ATMS.
  • EdDSA over JubJub ready

· 2 min read
Sebastian Nagel

High-level summary​

This week, the Hydra team has continued work on the mainnet compatibility of the hydra-node. They added a golden test suite for hydra-plutus scripts, added some detection of hydra-node misconfiguration, established a limit of 100 ADA per commit and other smaller tasks to prepare for a mainnet beta release.

Next week there will be a small team workshop to push for demonstrating a Hydra Head on the Cardano mainnet, ideally just in time for the monthly review meeting. See the hydra channels on the IOG Technical Community discord server for details.

What did the team achieve this week​

  • Implement a 100 ADA hard-coded commit limit in the hydra-node #763
  • Pay back funds to faucet after smoke-test run #773
  • Setup custom github runner for smoke-tests on mainnet #775
  • Created golden tests to assure the script hash stays the same between changes #772
  • Removed hardcoded error codes in plutus scripts #768
  • Detect misconfiguration of a hydra-node given persistent state #767
  • Met with potential users for hydra-pay
  • Prepared hydra workshop

What are the goals of next week​

  • Hydra monthly meeting
  • Open a multi-party head on mainnet
  • Complete mainnet compatibility feature

· 2 min read
Jared Corduan

High level summary​

We made further progress on the conway ledger era. In particular, we expanded the ledger API significantly, including lots of governance features. We also made progress on the specification and corresponding work in the Haskell implementation.

We also continued to integrate the latest ledger packages into cardano node and addressed technical debt.

Low level summary​

Expanded ledger API​

The ledger API was significantly expanded to include:

  • a lot of protocol parameter support
  • versioning support (type level ledger eras and protocol versions)
  • auxiliary data support
  • many new lenses
  • support for witnesses
  • support for conway governance

See pull-3328.

Conway ledger rules​

We have made progress on the formal ledger specification for the Conway era. Moreover, the corresponding Haskell updates were also completed:

Incremental SPO/DRep stake distribution computation​

We have a working (and correct) proof of concept for how to use the incremental lambda calculus to maintain several of the stake distributions incrementally. For the per-SPO distribution, this is a performance improvement. For the (conway) per-DRep distribution, this is will allow those who have delegated their votes to a DRep to have time to react to any votes that they disapprove of. (Sorry, no code to share just yet, more to come.)

Technical debt​