Skip to main content

· 3 min read
Damian Nadales

High level summary​

During the past two weeks we got the results from the system level benchmarks for UTxO HD. They showed a substantial performance regression, so we spent some time analyzing the results. We found out the frequency at which ledger snapshots were taken was too high, so we requested the benchmarking team a new run with a more realistic snapshotting policy. We continued refactoring and improving the prototype, and we released UTxO-HD related packages to CHaP.

We met with IOG researchers and networking specialists to discuss the Genesis design, which was well received. We continued working on testing and benchmarking different Genesis prototypes.

We are also working on solving a test failure related to iterators. This work derived in several improvements such as better documentation, a framework for writing unit (and regression) tests, and the possibility of debugging QuickCheck counter examples in the REPL.

Finally, we released ouroboros-consensus 0.2.0.0 and ouroboros-consensus-cardano 0.3.0.0 to CHaP

Workstreams​

UTxO HD Prototype​

We got the results of the first system level benchmarks for UTxO HD. They seemed to indicate a significant regression in performance. After looking into the benchmark logs we found that the benchmark runs took ledger state snapshots too often, due to the default snapshotting policy depending on k, and k being so small in the benchmark runs. Therefore, the next step is to re-run the benchmarks with a snapshotting policy that more closely resembles the one from mainnet.

At the same time, we continued refactoring and cleaning up the prototype.

Also, we prepared the anti-diff packages (fingertree-rm, diff-containers, simple-semigroupoids) and the lmdb related packages (cardano-lmdb and cardano-lmdb-simple) to CHaP.

Genesis​

The Genesis design was presented to the IOG researchers and Peter Thompson from NSol. It was well received. They pointed out one blindspot, but we think it'll be relatively simple to mitigate.

In parallel, we continued developing test and benchmarks for the Genesis prototypes. I particular we tested and implemented a potential fix for increased ChainDB dequeue timings, which partly behaved as we expected, but still needs further investigation. Also we obtained new benchmarking data for the prototype.

Technical debt​

Related to #4183, we developed a DSL for specifying ChainDB unit tests. This will allow us to better understand the counter-examples returned by QuickCheck tests, and to write regression tests for them. Also, we added a module to enable QuickCheck counter-examples to be run on the REPL, allowing for faster debugging feedback. Also, we improved the documentation related to followers (#4372).

We are also working on a design for optimizing the way we handle blocks from the future.

Support​

We released ouroboros-consensus 0.2.0.0 and ouroboros-consensus-cardano 0.3.0.0 to CHaP. Remember that we decided to split the packages related to Consensus into two bundles, one with the core functionality, Cardano-agnostic code, and another bundle with instantiations specific to Cardano.

· 2 min read
Jordan Millar

2023-02-22 - 2023-03-07

High level summary​

General bug fixes

Completed​

docs​

CI & project maintenance​

Developer experience​

cardano-cli​

cardano-api​

cardano-node​

cardano-testnet​

In Progress​

Documentation​

CI & project mainteance​

cardano-cli​

cardano-api​

cardano-node​

cardano-testnet​

· One min read
Kostas Dermentzis

High level summary​

The db-sync team created a new tag 13.1.0.2 which is ready to release. We also investigated and had the first working UTxO-HD integration which is one of the potential future risks for db-sync.

Low level summary​

  • Integrated the UTxO-HD feauture branch in kderme/utxo-hd-1. This doesn't use the full on disk storage but keeps things in memory and the plan is to keep it this way for the first iteration. The integration still has some performance issues which we investigate
  • Created tag 13.1.0.2 which upgrades the dependencies of db-sync
  • Fixed an issue related to errors appearing in SMASH #1353
  • Continued with ghc-9.2 integration #1339
  • Worked on an new fixing procedure for #1348. We try to make these procedures work also on older schema version, without the need to migrate to newer schema, which can be very useful for fixing existing snapshots.

· 2 min read
Iñigo Querejeta Azurmendi

High level summary​

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

  • Mithril: Helper functions finished. Continue preparing a RFP for an audit of mithril's core library (decided to add audit of KES). Design proposal for viable registration.
  • cardano-base: Praos to PraosBatchCompat ready. KES secure forgetting finished, but holding merge for delivery strategy (breaking changes). Tested real world SNARK verification on plutus.
  • KES agent: using snockets and making things testable in IOSim
  • MuSig2: started implementation in rust.

Low level summary​

Mithril​

  • Transmute helpers merged PR#722
  • We have progressed with the RFP document for the mithril-stm library. Progressing with description of octopus algorithm. Included KES in scope.
  • We are working in a modification of KES to require caller to allocate the secret key buffer.
  • Proposed a solution for signer registration of Mithril.

cardano-base​

  • Progressing with BLS12-381. Worked with plutus team to have a plutus script verifying a Groth16 proof.
    • Results are promising, with using only 23% of the execution budget to verify a realistic proof.
    • Next step is to build a real world use case (and not use a dummy proof). Projects being considered are Sidechains, Hydra or Mithril.
  • KES secure forgetting merge is being held off, due to breaking changes. We are considering handling several branches in cardano-base for this.
  • Conversion finally merged PR#344.

KES agent​

  • Figuring out how to use sockets to write directly into the file descriptor. Digging into the sockets implementation
  • Figuring out how to go from fake file descriptor to write the raw bytes

MuSig2​

  • Started implementing MuSig2 in Rust using the Ristretto prime order group. Still experimental.

· One min read
James Chapman

The team works on applied research and consulting in formal methods that is directly applicable to evidence based engineering in Core Tech and beyond.

High level summary​

This sprint the team has been working on drafts of two papers and one technical report, distributivity properties of deltaQ, and consulting on performance design with the Marlowe team.

Details​

  • Processing reviews on performance engineering paper and planning paper revisions accordingly

  • Investigating distributivity properties of DeltaQ

  • Preparing sections on the thorn calculus and idempotency laws for draft paper about verifying design refinements for distributed system design

  • Consulting on performance design with Marlowe team