Status Update

WEEKLY DEVELOPMENT REPORT

Daedalus

Wallet

This week the team implemented three new features for the Incentivized Testnet version of Daedalus. First, stake pool ranking for ada holders looking to delegate. The ranking is based on desirability parameters, including stake pool profit margin, operational costs, performance, and rewards per epoch. Second, a stake pool saturation meter, which indicates how close a given stake pool is to being saturated (after which point it will provide diminishing returns). Finally, an option for users to resynchronize their wallet with the blockchain has been added to the wallet settings screen. For users who have been experiencing problems, such as the known zero-balance issue, this resynchronization option should fix those problems without the need to delete and restore a wallet.

In the scope of regular maintenance tasks, the team continued working on adding more automated tests for Shelley features.

App Platform

There is no update this week since the team was focused on helping out with Daedalus and Cardano explorer development.

Cardano Explorer

Work was done this week to separate application navigation from router implementation, which allows for better test cases and improvements in maintainability for the future. Decoupling these aspects of a web application makes it easier to reason about the path a user takes, so that ongoing development is faster and of better quality. The team also established full end-to-end integration testing this week, which has been used to run scenarios from the outside in, testing the UI as part of every codebase change.

Wallet backend

This week the team added support for new stake pool metrics on the Incentivized Testnet: desirability and saturation. These metrics will help ada holders decide which stake pools to delegate to, thereby supporting the decentralization of the network. On the side, the team has also been resolving some database issues and migrations from previous versions.

The team also reached a significant milestone this week: connecting the re-written Haskell nodes with the wallet backend and restoring mainnet wallets using the same API as on the Incentivized Testnet. Work has already begun on the next step of creating a launcher for Daedalus — once complete, it will mark the end of the old Cardano SL era and the beginning of the new Haskell nodes era!

Networking

This week the networking team has continued work on the connection manager: a component that sits between a server and the peer-to-peer governor to manage connections. The team has also been working on lazy mux, simplifying how it manages and controls threads. Finally, the team has been refactoring the NTP client and prepared a pull request to include a socket interface, a common API for Berkeley sockets and Windows named pipes.

DevOps

This week the team has been working on performance improvements for the upcoming 1.4.0 node release. Next week the team plans to do a full end-to-end test of a cluster upgrade from the legacy Cardano codebase to the new Cardano node.

In terms of the explorer, the team has improved the docker image so runit processes can be stopped and started, as well as adding a transaction endpoint into the docker image that can be used to send raw transactions to the network.

Cardano Decentralization

This week the team worked on more generators for testing purposes, making improvements to operational certificate generation, amongst others. They are now able to generate valid traces with operational certificates, provided the trace itself is not too long.

The team also uncovered a few small but important items that were missing from the executable specification, mostly to do with pointer addresses. These have now been fixed, along with a few issues that were discovered as a result of the work with the Isabelle automated theorem prover.

Goguen

This week the team added a Ledger.Constraints module for contracts, which resulted in changes to both the on-chain code and off-chain code. They also made changes to the rules for currency forging, by adding a new field to Tx, which contains the monetary policies that will be run against the transaction. For every currency forged, the corresponding monetary policy must appear in the transaction.

In addition, they researched how to increase efficiencies with error handling in Plutus Core, and a reference was added in the Readme file to link to the rendered ETUXO paper.

The Marlowe team investigated the optimization of symbolic maps this week. They wanted to establish whether there is a means of fixing the length of the lists that represent maps in symbolic execution, so that it is not necessary to use the symbolic versions of tail and head.