Status Update

WEEKLY DEVELOPMENT REPORT

Daedalus

Wallet

This week the team has been working on integrating pending delegation preferences into the API, as well as adding an ‘experimental feature’ notification and UI tooltip to alert users to potentially unreliable features that have yet to be stabilized. The team has also improved the coverage of the end-to-end automated tests for Daedalus by introducing acceptance tests for wallet delegation features.

App Platform

There is no update from the app platform team this week since they’ve been helping out with general Daedalus development.

Cardano Explorer

The team has been working on QA and testing tasks this week to prepare for the upcoming Cardano Explorer Byron release.

Wallet backend

The team has been doing some housekeeping and maintenance this week, including finding a proper, reliable fix for a longstanding bug. Improvements have also been made to the reporting of wallet delegation statuses. Changes to delegation preferences only take effect after a delay of one epoch, and this is now properly reflected in the wallet backend, allowing the Daedalus frontend team to create a better end-user experience.

Networking

The networking team continued to work on the connection manager this week, finishing the refactoring of the NTP client and merging the refactored mux layer, which allows on-demand starting of mini-protocols. An external reviewer found an issue with the Windows API, which has now been fixed, and the team is currently working on adding functionality to cancel asynchronous I/O requests on Windows.

DevOps

This week the DevOps team completed the deployment and testing of the new Cardano node (1.5.0) and explorer (1.3.0) releases. They’ve also been working on upgrading all the repositories involved in the new stack to the latest haskell.nix version.

To better stress test the new node, the team started working on a custom Amazon Machine Imagine (AMI) for Amazon Web Services (AWS) this week. It will allow the emulation of around 10,000 Daedalus clients connecting to the new node, which will enable the team to identify any potential issues that might arise with high loads. Some automation that will push Docker images to Docker Hub for the new node has also been created, with plans to do the same for the explorer components next week.

Finally, the team has scheduled the OBFT transition on mainnet for February 20, 2020 at 21:44:51 UTC. With the latest 1.5.0 release, all remaining memory leaks have been resolved, and the node staging clusters that have been migrated have remained stable since their initial deployment. The OBFT transition on February 20 will mark the first significant step to a Shelley mainnet launch.

Cardano Decentralization

The team continued work on the generators this week, which are getting tricky now that they’ve reached a significant level of complexity as the team pushes for more and more realistic generation. Work is being done to better represent key-evolving signatures and how they evolve over time, as well as ensure that transactions that generate multiple certificates do so in a valid way.

Elsewhere, work has been progressing on adding transaction metadata to the Shelley ledger, with a pull request now waiting for review. Some of the details of how best to format the metadata still need to be ironed out, and the team plans to discuss this next week.

Goguen

This week the Plutus team made improvements to the performance of the PureScript parser and pretty printer, as well as unifying the Haskell default-extensions to ensure consistency. The team also reorganized the presentation of validity rules within the EUTXO paper to improve navigation and readability.

The Marlowe team investigated ways to improve the performance of large Marlowe contracts within the Marlowe Playground. They also worked on how to effectively calculate constant negative payments in the Marlowe editor, so that warnings can be provided to the user in real-time. Last but not least, the team also studied how to include a Marlowe version in a contract, as well as a way to identify a Marlowe validator from its address, so that a node can implement the interpreter natively and increase the speed of contract execution.