High level summary​

In last sprint the team focused on preparations for the conference talk at OPODIS 2022. We also worked on preparations to publish io-sim and related packages on Hackage (PR #57, PR #60).

We also started reviewing:

• ouroboros-network
• cardano-node
• cardano-ledger repositories for open-source readiness (PR #4128).

We prepared a PR which changes how node-to-node and node-to-client protocol versiones are serialised in cardano-node log (PR #4691).

High level summary​

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

• MuSig2: We were blocked with a CI issue, that we finally resolved. Similarly, we merged the redesig of the API to mantain consistency.
• Mithril: Merged the reformat of the signle signature. Similarly, we started working in ensuring KES implementation in rust is safe.
• cardano-base: VRF and BLS are still waiting to be merged, as we have some problems with the CI. Moreover, we started experimenting how rust can be included in the cardano-base code-stack.
• KES agent: We keep progressing with KES secure forgetting implementation as well as the KES agent.

Low level summary​

MuSig2​

• [Still in progress] We are introducing a more granular error handling mechanism PR#33
• We merged the API redesig PR#35
• We were blocked for a while with a CI issue, for which we are currently simply using a simpler version of Ubuntu. We'll probably circle back to this in the future PR#36

Mithril​

• We merged the individual signature PR#620
• We are modifying important parts of the KES mplementation to guarantee there are no unnecessary copies during Ser/Deser (kes repo)

cardano-base​

• Nothing new to report. Still working in merging these PRs.
• We started experimenting on how we can use cabal-pack to create haskell libraries out of rust libraries, and how this would affect the cardano-base fork. We encountered what seems to be a bug in GHC

KES agent​

• We keep progressing in the secure forgetting PR and resolving some bugs on memory handling PR#255
• Fixed a 'use-after-free' bug in the KES agent.

High-level summary​

This week, the Hydra team has worked on completing to "Validate coordinated head protocol against formal model", this is a huge step to verify the implementation is secure. They also worked on implementing ADR21 related to bounded tx validity which is now under review. HydraPay project, from Obsidian Systems, is coming to an end of the first phase at least, so team did a review and submitted couple of issues they found in the process. The team had a meeting with the Director of CyberSecurity - topic was the RFP that is currently in flight that should scope the work of future auditors. Also, the team completed the hydra-tutorial review created by our colleague Thomas Vellecoop from the education team, and we are close to integrate it to our official site. From the development side, they have fixed a bug on the CI when running the benchmark jobs to calculate the cost of abortTx and a flaky spec which checks a plutus merkle-tree is always balanced.

What did the team achieve this week​

• Document model based testing #194 & #641
• Got ADR21, reducing gaps between implementation and specification, under review.
• Complete review on hydra-tutorial.
• Complete first round of review on HydraPay work #634
• Meeting with Director of CyberSecurity frio IOG to unblock "the RFP prepared for the external audit" #606
• Remove vasil-dev and testnet from smoke-test because they were not working #630
• Fix flaky plutus-merkle-tree test #642
• Refactor NetworkSpec to improve legilibility.
• Fix benchmark cost for abortTx #631
• Adapt nix.conf to the recent hydra-ci nix cache migration.

What are the goals of next week​

• Get ADR21 accepted & close tx validity gap in our implementation.
• Integrate the hydra-tutorial.
• Have a LaTeX write-up of the HeadV1 (Coordinated Hydra Head) spec.
• Get Cicero (new CI) working.
• Use reference inputs to reduce the cost of the commitTx.

High level summary​

The Plutus tools team at IOG has started helping the ledger team to build out a user friendly cardano-ledger-api package! A GitHub project will be filled out in the days ahead, people interested in the API can use it to follow along and join in on the conversations.

The ledger team has started using architectural decision records to leave a record of important decisions that the team makes. We will retroactively go back through past decisions and make ADRs for them.

The logic to track individual deposits is now nearly in place. We are prioritizing correctness with our first pull request, and will follow up with performance optimizations and general cleanup next.

Pointer addresses are being deprecated with the Cardano major protocol version 8. See CPS-0002 for more context.

Lower level summary​

Cardano ledger API​

The Plutus tools team has taken our minimal cardano-ledger-api package and started filling it out and adding much needed documentation. They have also added doctests! In the days to come, the Plutus tools team will map out a lot more work for the API and record it in this GitHub project.

See

• pull-3182
• pull-3188

Architectural Decision Records (ADRs)​

We are now providing more context and leaving a record of important decisions that are made in the ledger. The first ADR explains the very lightweight process.

See

• pull-3177 (rendered here)

Tracking individual deposits​

See ADR-3 for background. We now have the logic in place to track individual deposits, and a host of property tests to make sure that the logic is correct. The current implementation uses more memory than it needs to, and we will address that next, with our hope being to only use one word (8 bytes) per registered stake credential. There is a fair amount of other cleanup needed for general maintainability.

See

• pull-3127
• pull-3195
• pull-3202

Removing pointer addresses​

Pointer addresses, which have never seen any real use (there are something like eleven on mainnet), are being deprecated starting at Cardano major version 9. CPS-0002 gives the context. We are disabling them by first preventing transaction outputs containing them from being serialized by the node at the moment we switch to version 9. At the hard fork after that, we will translate the existing few pointer addresses to enterprise addresses.

See

• pull-3174

Technical debt​

• pull-3162 - Sometimes we have to put safeguards in place for hard forks which may never be exercised. After we have passed the given hardfork, we are able to clean up the code and simplify our logic. We removed all of the ones that we are currently easily able to.
• pull-3165 - We improved the type safety of our code while also discovering and fixing a serialization bug.
• pull-3172 - We removed dead code.
• pull-3175 - The Allegra and the Mary code used to be coupled in a particular way the we grew to dislike. We made these two ledger eras now uniform with the rest of our code base.
• pull-3184 - We organized our property testing code.
• pull-3200 - The Plutus tools teams fixed an outstanding bug in the translation from the ledger state to the Plutus script context.

High-level summary​

This week, the Hydra team has worked on cleaning up several things in progress after last week's summit. They have extended their model-based testing (MBT) approach with transaction creation & observation #410, solved AcquirePointTooOld problems of the hydra-node with by changing the wallet initialization #439. Also, the Hydra researchers updated the security proofs of the Coordinated Hydra Head, which are bound to be included in the Hydra HeadV1 specification.

What did the team achieve this week​

• Monthly review & report - will also be published on our website #644
• Extended the model-based testing (MBT) with transaction creation/observation #410
• Solve AcquirePointTooOld problems with new wallet initialization #439
• Fixed our hydraw deployments (EC2 instances)
• Created & discussed ADR21 within tx validity work
• Received & discussed security proofs of Coordinated Hydra Head (requires more work)

What are the goals of next week​

• Get ADR21 accepted & close tx validity gap in our implementation
• Complete review & integrate the Hydra tutorial
• Review latest hydra-pay work
• Have a LaTeX write-up of the HeadV1 (Coordinated Hydra Head) spec
• Get Cicero (new CI) working