Status Update

Weekly Development Report

DAEDALUS

Wallet

This week the team fixed all the issues discovered during first QA phase of the upcoming Daedalus 0.12.0 and Cardano 2.0.0 release.

The fixes include:

• a fix for a problem with maximizing the Daedalus window on Linux, where the application menu would be hidden in the maximized state

• a fix for an issue with orphaned Daedalus processes after trying to launch multiple Daedalus instances on Windows

• a fix for launcher misconfiguration which caused the wrong error message to be displayed when a second Daedalus instance was launched

The team has removed the "Antivirus software performance impact" notification shown on Windows during wallet restoration. The performance issues have been resolved in the upcoming Cardano 2.0.0 release.

An error message for "Not enough disk space" has been implemented, reviewed, and tested. This message is shown during Daedalus startup if there is not enough disk space available on the user's machine for Daedalus to run successfully.

In the scope of regular maintenance tasks, the team has cleaned up the Daedalus theme directory and fixed a failing Cardano Node "Apply Node update" acceptance test. The team has also started to work on quarterly Daedalus dependencies updates. This task will continue throughout the upcoming week, since the team has more than 140 dependencies to update.

App Platform

This week the team continued with the access control layer, making changes to the UI to present granular service operations at the point of application install, which is used to control API access for the defined service. A couple of configuration issues with the Docker-based Cardano demo cluster were identified, reported to DevOps, and new versions tested. A strategy for building out the platform-based wallet app past a prototype was determined, and work started to use existing components from the Daedalus codebase.

WALLET BACKEND

The team have confirmed the hard fork mechanism (HFM) to work on a devnet cluster. The engineers have cleaned up the code so it’s suitable for production, and are rerunning tests to double-check the results.

NETWORKING

Last week the team settled on the comms protocol design, although there might be some alterations in the future. Currently, the team is focusing on implementation.

The engineers have the protocol in Sim, but are currently switching to a framework which uses a type system to ensure the client and server sides of the protocol match.

DEVOPS

The team continued nix-tools integration work for building the cardano-shell repo.

Engineers added some tooling to simplify PR review, build, and merge workflow for the cardano-chain repo. Automated build and test proof of concept work continued in the Plutus repo, and the team also integrated an improved CI build and test scheduler for Plutus. During testing, the team experienced more Windows CI build issues, including timeouts and MAX_PATH limit, which were later addressed.

The engineers also finished an initial proof of concept fallback strategy using Windows servers, and resolved GitHub rate limit breaches by reducing a regular status check footprint.

Furthermore, the team deployed additional utility for the Support Portal, and started work on a backend for nixops. Team members updated Hydra server to support jobsets involving git submodules.

In terms of operational maintenance, the team fixed websockets on Cardano testnet explorer, and provided operational support for IELE and Mantis testnets.

Also, the team fixed a port collision bug when running multiple editions of Daedalus for different clusters, and cleaned up stale benchmarking logs from a shared deployer machine.

CARDANO DECENTRALIZATION

Design

The first prototype of the consensus layer was written in a process calculus style; this prototype can be found in the ouroboros-prototype GitHub repo. The team designed it to match as closely as possible the style of formal specification that will ultimately be used for formal verification.

The networking team, however, implemented their algorithms in a different style. Since the consensus layer will be sitting on top of the network layer, it made sense to restructure the consensus layer to use abstractions provided by the network layer. The team’s first attempt resulted in a coupling between the two layers that was a little too close, however. The initial attempt was nonetheless useful to understand the issues at hand (and they spotted a bug in the network protocol in the process too).

As of the end of last week, it was decided to decouple the two layers further, introducing some abstractions into the network layer that will allow the network layer and the consensus layer to be developed independently, and yet use the network layer in the consensus layer. This redesign is not fully complete yet, but we're close.

Meanwhile, a team member is working on some integration with a mock ledger layer. Although the ledger sits on top of the consensus layer, the consensus layer needs to be aware of the ledger layer since some decisions at the consensus layer depend on the state of the ledger. A mock ledger layer allows us to implement such decisions without being blocked on the work done by the ledger layer team. It works on the back of the UTxO model that has been previously developed for the wallet.

Finally, a senior researcher is working on designing some concrete crypto primitives that are needed in the Ouroboros implementation. These are not necessarily intended to be final, but are to explore the design space, and identify the interface to these crypto primitives, and which assumptions we can and cannot make.

The team is converging on a design in which we can easily swap in and out

• various representations of blocks

• various Ouroboros flavors (BFT, Praos, ..)

• various ledger layers (real, mock)

• various crypto implementations (real, mock)

This allows to focus on key design without pinning us down to concrete decisions that might later be changed.

Development

Last week a senior team member helped find and fix a performance regression, wrote some docs, and reviewed the new cardano-chain project. Another team member worked on the sl-formal-spec and will continue this week. Additionally, the developers are preparing for implementation of Ouroboros BFT in the existing code.

ANNOUNCEMENTS

IOHK is currently looking for talented people to work with us as a Rust Software Engineer, Haskell Trainer as well as several others. Please see the IOHK Careers page for more details.