Skip to main content

· One min read
Sebastian Nagel

High level summary

This week, the hydra team first re-deployed the latest Hydra scripts to the re-spun preview network, see 0.8.0 release notes. They also completed implementation of ADR18 and worked on the validators, but development got impacted by some CI flakyness. The team also met to discuss hard forks & protocol parameter updates #195 and alignment of the specification document with auditors.

What did the team achieve this week

  • Complete and merge ADR18 #579
  • Re-deploy hydra scripts to respun preview network, see 0.8.0 release notes #595
  • Have first gap of #452 in review.
  • Non-achievement: Flaky CI for TUI was impacting us, so we investigated this a lot.
  • Engineering meeting to discuss hard forks and protocol parameter updates #195
  • Met the internal audit team on the specification to set scope, expectations and collected requirements/open questions.
  • Drafted project scope for an external audit RFP.

What are the goals of next week

  • Implement event-sourced persistence #580
  • Answer the internal auditors questions
  • Have a draft RFP ready for a first review internally
  • Close some gaps #452

· 2 min read
Iñigo Querejeta Azurmendi

This sprint, the team has been working on the new continuous integration and delivery (CI/CD) pipelines and the automated deployment of environments as part of the new version of the release process. They also coordinated the migration of the pioneer SPO nodes to these new Mithril networks. They have been implementing the automatic data storage upgrade of the signer and the aggregator nodes. Finally, on the crypto side of things, we've implemented an efficiency improvement on the size of the mithril certificates.

Low level overview

  • We have been moving forward on the implementation of the release process #500:
    • Setup of the new hosted environments for testing-preview, pre-release-preview and release-preprod with their terraform and GitHub environments #542
    • Adapted the CI workflows to work with the new release process #543
    • Publication of an ADR3
    • Publication of a dev blog post about Mithril networks evolution
    • Releasing our first Mithril distribution 2244.0
  • Worked on the API versioning mechanism #565
  • Worked on the implementation of the stores migration process for the signer and aggregator nodes #562
  • Prepared a Mithril devnet video demo #526
  • Implemented a batch Merkle Tree proof, which reduces the size of certificates considerably #484

· 2 min read
Marcin Szamotulski

High Level Summary

  • We've been working toward publishing Cardano Backlog, currently its in review by the IOG communication team.
  • We identified a number of libraries which can be published.
  • We setup and enhanced cardano-updates.

Detailed description

I am glad to announce that I was given the role of open-source advocate for cardano project. In last few weeks we were making steps towards publishing our backlog. It's currently under review by the communication team, although most of the issues are already visible across various repositories.

The open-source initiatives have their own project. It is set up to help us track our major open-source activities. Right now there are two work streams:

We identifies a number of libraries across all the teams which contribute to Cardano which we would like publish to publish, see the following link. Arnauld Bailly recently published quickcheck-dynamic library on Hackage. The networking team is slowly progressing towards publishing io-sim and related packages, checkout the progress here.

Thanks to Arnaud Bailly our Cardano Updates website has a new look & feel! It's using docusaurus.io.

Christian Taylor carried recently a detailed analysis of our open-source repositories. He collected many interesting metrics, which allows us to see where we need to improve as an open-source project to make the Cardano project and many smaller related libraries which we maintain be more open and available for open-source contributors.

The graph below shows which documents the 55 most important Cardano repositories are missing the most: Documentation Adoption You can expect we will improve in these metrics in the coming weeks.

· One min read
Dorin Solomon

High level summary

We made good progress on most of the Action Items we agreed on Lisbon, like:

  • Cardano System Tests was fully open to public (tools, tests, results) See cardano-node-tests webpage
  • We defined an user-facing-functionality template that is used with the cardano-cli team
    • this includes acceptance criteria & user stories, and definition of done
  • We are in the process of running the cardano-node-tests at commit & PR level in cardano-node (we are affected by the Cicero migration right now but we did most of the work already)
  • We started to apply a labelling convention on cardano-node issues that will be used to generate some visual dashboards with some metrics [TBD]
  • Ziyand Liu started an End-to-End Development and Testing Process for Plutus Features

· 4 min read
Damian Nadales

High-level summary

During the past two weeks, the consensus team continued its work on testing the UTxO HD prototype. We completed the era-transition and backing store tests, and the mempool tests are advancing at a steady pace. Regarding our work in the Genesis design, we continued our collaboration with the research and networking teams, and we continue investigating strategies for making the chain-sync jumping prototype faster.

High-level status report

  • Finish the UTxO HD prototype: on track.
    • We worked on state-machine tests for the mempool, and spotted potential bugs in the implementation. Investigation is ongoing.
    • We have a set of property tests for the backing store. We still need to incorporate the improvements to the LMDB cursor API that these tests made possible.
    • We merged the era-transition tests PR.
  • Genesis: on track.
    • Design work around Genesis continues in collaboration with researchers and the networking team.
    • We continued trying to improve the performance of the chain-sync jumping prototype. We gained additional insight on which parameters to tweak next. In spite of the baseline still being faster, the current prototype already achieves a significant speedup when compared to the naive approach of simply running full chain-sync with all peers.
  • Tech debt: on track.
    • We clarified a common source of confusion around VRF tie-breaking and cross-era chain selection.

Workstreams

Finish the UTxO HD prototype

We continued working on property-tests for the UTxO HD prototype. In particular we merged the era-transition tests PR.

Backing store property tests

The backing store property tests PR has been reviewed. The next steps are:

  • Improve error handling and command generation.
  • Add coverage testing to check that we are not failing to cover interesting test cases.

The monadic cursor API went through its first review round. The API is in a relatively stable state. This PR also unifies the cborg and serialise-based interfaces to LMDB operations. The next steps are:

  • Write quickcheck-dynamic state-machine tests for this API.
  • Adapt the changes in the serialisation interface in the backing store property tests. This will involve adding boilerplate code in consensus to make up for the removal of the cborg-based interface.

LSM tree implementation

We worked on the LSM tree prototype. In particular, we focused on tuning the LSM tree design to the different workloads that consensus has (eg syncing, normal node operation, etc).

Benchmarking the CSJ prototype

Work on improving the chain-sync jumping performance is ongoing. In particular we compared the performance of different jump intervals, which, somewhat surprisingly, do not make a significant difference. In particular, we are seeing periodic "plateaus" where the chain-sync tip does not progress, but they are much longer for the prototype. Our hypothesis is that this seem to be due to a combination of the garbage collector (GC) pauses, and the actual time it takes the non-dynamo chain-sync peers to jump to the tip of the slot of the dynamo fragment.

In the coming weeks we will try to shorten these plateaus via a combination of tweaking GC options and less synchronisation in the CSJ governor.

The following plot shows the performance of the chain-sync jumping prototype using different jumping intervals. It compares the syncing progress by plotting the slots of adopted blocks against time. The baseline is still faster, however it is worth noting that the current prototype already achieves a significant speedup when compared to the naive approach of simply running full chain-sync with all peers.

The second plot shows the syncing progress sliced to a chosen ~5min interval, and includes, in addition to the slots of adopted blocks, the slots of the tip of the ChainSync fragment. This allows us to see how far ahead of the selected tip the CS dynamo is, i.e. how much room we have for BlockFetch not to get stalled. It shows periodic behaviour (due to the forecasting limit), and shows that the CS fragment tip is not progressing for significant periods ("plateaus").

Technical debt

We clarified a common source of confusion around VRF tie-breaking and cross-era chain selection. This PR involved correcting potentially misleading names of VRF-related functions, and providing context for a particular VRF value is used for tie-breaking.