Skip to main content

· 2 min read
Iñigo Querejeta Azurmendi

High level summary

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

  • Mithril: We explored whether some uses of transmute could be removed, but it resulted in considerable regression.
  • cardano-base: Some issues with Nix are blocking merge of VRF update. BLS12-381 benchmarks where quite satisfactory. Next steps will be defined by cryptography strategic decision.
  • KES agent: An inconsistency between contra-tracer available in hackage and the one in cardano-haskell delayed our progress. Now we are adapting PRs to the contra-tracer used by consensus.

Low level summary

Mithril

  • We removed the usage of transmute in mithril-core (and exchanged it with ser/deser, as unfortunately there is no other way with the library we currently use). However, the benchmarks showed an important regression - ~30% worse on average PR#675. We decided to keep transmute, but instead group all its usage in helper functions, to facilitate auditing.
  • We are writing a RFP for the audit of the core library.

cardano-base

  • A problem with Nix is blocking merge of PR#341
  • Plutus team ran benchmarks of BLS12-381 built-ins. The results are satisfactory, and while we have yet not implemented SNARK verification in plutus, it all seems to point that we'll be able to verify some proofs in a single script execution.
  • Team is fully digesting the Plonk paper.
  • There's been a lot of discussions (with internal and external projects) regarding pairings in plutus, and what elliptic curve should be used.

KES agent

  • A little unforseen delay has been caused by a mismatch in the use of contra-tracer. The one in hackage and that in cardano-haskell are not compatible. Unfortunately, for secure forgetting we use that of hackage, and now realised. We are doing the change, but still the CI is not happy.
  • The same was needed for the KES agents prerequisites PR#317.
  • We've started working with the agent itself again, upgrading the cardano-base dependency and adding ouroboros-network-framework dependency

· 2 min read
Sebastian Nagel

High-level summary

This week, the Hydra team has been focusing on the write-up of the Hydra HeadV1 specification. Of which a first version has been aggregated and is currently under review. They aligned the on-chain scripts of reimbursing funds on abort like defined in the specification, improved the mutation test framework to have more control when testing plutus scripts. The added HeadId in the API and the TUI example client make hydra-node easier to use and a first experiment of a Hydra Head explorer was showing the utility of this - see what Heads exist on the preview network here.

What did the team achieve this week

  • HeadId to API and display in the TUI #678
  • Experiment of creating a hydra explorer, first result hosted here
  • Improved mutation framework allowing to fail for the right reason #679
  • Correctly reimburse funds in abort (matching the spec) #670
  • Finished a first write-up of the Hydra HeadV1 spec: Read it on overleaf (Communication channels for feedback)

What are the goals of next week

  • Monthly review meeting with a broader audience
  • Groom & plan actions required for a maintainable Head explorer
  • Break “align gaps” feature into smaller chunks (at least on- /off-chain) and groom it
  • Review the spec & discuss individual aborts with researchers (a bigger open question)

· 2 min read
Marcin Szamotulski

High level summary

We have been working towards cardano-node-1.35.5 release. QA & benchmarking teams gave a green light for the release, and we made decent progress with some CI problem which we encountered on the way (PR #4612). We are also working on peer sharing, making improvements in our testing infrastructure, reducing technical debt and making progress towards io-sim-1.0.0.0. Galois is making progress on Handshake improvements.

Low level summary

Our diffusion simulation network now includes a mixed network of initiator only and initiator and responder nodes. issue #4222

We are now reviewing the peer sharing pull request.

We are also reviewing pull request which introduces handshake query flag. PR #4256

We fixed a bug in our network simulator. The bug was triggered when a node died when performing a simultaneous TCP open (a corner case of a corner case!). PR #4265

We also refactored Snocket interface and removed the bearer construction from its methods. PR #4260

We are working towards releasing io-sim-1.0.0.0 on Hackage, which includes reviewing two PRs: PR #57 and PR #60 as well as writing an announcement blog post.

· 2 min read
Michael Fellinger

High level summary

The SRE team continues work on Cicero, Tullia, and Bitte, as well as providing support for cardano-world.

Lower level summary

Cicero

  • Fixed various race conditions around transformers.
  • Brought our CI up to date.
  • Migrated to the Nomad exec driver with Nix support for many actions.
  • Moved Nix builds to the Nomad clients for much better cache locality.
  • Ongoing work on vastly improving the action matching and evaluation speed.

Tullia

  • Made it easier to support cloning from a PR's fork
  • Update to latest std
  • Add workaround for cgroup issue: nomad#12877
  • github preset: add github.ci.remote and (read|get)Repository functions
  • Fix various issues around CUE handling

Bitte

  • Upgrade to NixOS 22.11
  • Prototype usage of Colmena for deploys instead of deploy-rs
  • Finalized work on Equinix Metal support
  • Prototype better secrets management with ragenix instead of sops-nix
  • Improve CI and bring it up to date

cardano-world

  • Fixd various OOM issues on preview and preprod
  • Rotated KES keys on preview and preprod
  • Optimize mainnet db-sync to cope with higher load
  • Fix an issue where PostgreSQL would fail after a reboot

bitte-world

  • Updated to NixOS 22.11

ci-world

  • Updated to NixOS 22.11
  • Added Equnix cluster
  • Improve caching of Nix builds

· 3 min read
Jared Corduan

High level summary

The ledger team completed some preliminary ground work in preparation for CIP-1694 (restructuring the ledger state), fixed the PDF hosting problem (mostly the formal specs), built out more of the new user-friendly ledger API, finished a proof of concept for constraint-based generators for property tests (with the hopes of being able to replace our trace generators one day), and addressed technical debt.

Lower level summary

Restructuring the ledger state

The existing governance structures will be replace in the conway ledger era, as described in CIP-1694. In particular, the ledger rules will be restructured as follows:

   BBODY
|
|-------------------------------|
v v
TICK LEDGERS
| |
|---------| |
v v v
RUPD ~NEWEPOCH~ ~LEDGER~
| |
|----------| |--------|-------------------|-----------|
v v v v v
~EPOCH~ +ENACTMENT+ DELEGS UTXOW +TALLY+
| | |
|---------|------------| v |
v v v DELPL v
SNAP POOLREAP -UPEC- | UTXO
|--------| |
v v v
POOL DELEG ~UTXOS~

-..- Removed
+..+ Added
~..~ Modified

Moreover, the ledger state will also be restructured in accordance with the new rules. In the conway code, we have now removed UPEC, added TALLY, and stubbed ENACTMENT. We have also adapted all the data structures in the ledger state.

See:

PDF hosting

We now build all of our PDFs using a GitHub action which is triggered by pushing a tag with a specific form, cardano-ledger-spec-YYYY-MM-DD. The action creates a GitHub release containing the PDFs. The links in the main ledger README now point to the PDFs in the latest release.

See:

Powering the new ledger API

We have now removed all the HasField instances from the protocol parameter data types, and replaced them with lenses. This is probably the last major restructuring that the ledger team will do on the code base for the API for a while (the Plutus tools team will be working on it next, see here). We also added a new helpful function ensureMinCoinTxOut.

See:

Constraint-based generators

Our largest scale property tests generate an initial ledger state and a long sequence of valid blocks which span several epochs, mimicking a real network. These tests are, in theory, excellent for checking properties. They are, however, very difficult to maintain and are not as random as we would like (a lot of bias has to be introduced to keep the ledger state in enough order to keep generating blocks).

We would like to switch to tests which instead generate a random ledger state representative of not just an initial state, generate a single random valid block, and then test our properties. The hope is that these will be much more random and easier to maintain.

We have finished a proof of concept are encouraged that this approach could work!

See:

Technical debt

  • pull-3244 massive CI speedup
  • pull-3249 better types for fees in the protocol parameters
  • pull-3264 move our annotator code to the cardano-ledger-binary package where it belongs
  • pull-3239 move the Wdrls type to the Core module.