Status Update

WEEKLY DEVELOPMENT REPORT

Daedalus

Wallet

This week the team has been entirely focused on finalizing the new Daedalus rewards wallet for the Incentivized Testnet, which will hopefully be released soon. The integration of API endpoints for listing, joining, and leaving stake pools was finished, and all UI changes required to support stake delegation are now complete.

App Platform

There is no update this week since the team was focused on supporting the release of the new Daedalus rewards wallet for the Incentivized Testnet.

Cardano Explorer

This week the team has been working on preparing deployments, resolving edge-case integration issues, and performing full-scale performance auditing of the web application.

Wallet backend

The wallet backend team has been working around the clock this week to get everything ready for rewards on the Incentivized Testnet. In addition to the wallet available balance and total balance, a new wallet reward balance is now in place, which will automatically track the rewards earned when delegating stake to a productive stake pool.

A new reward-credentials command has also been added to the command-line interface to enable pool operators to use cardano-wallet (and by extension Daedalus) to track their own rewards and set up their stake pool using their existing wallet. Step-by-step guides are now available on the Cardano Foundation stake pool registry wiki.

Networking

This week the team has continued to work on peer discovery in the network and the features required to support it, including testing some of the newly-implemented peer discovery functionality over DNS on the current relays.

DevOps

The DevOps team has been working hard this week to support the work of the Daedalus team in preparing the release of the new Daedalus rewards wallet for the Incentivized Testnet.

Cardano Decentralization

As of this week, the team is close to having gone through all the serialization decisions up to an entire block. Transactions and block header bodies are done, all that’s left is packaging up the header body with the block body and transaction witnesses. Note that for all the serialization changes that have been made, corresponding deserialization changes also need to be made. The team is still finishing up the annotated serialization changes for the Byron codebase, and once that’s done they will be doing the same for Shelley.

The team also made two small changes to the specifications this week. For the purposes of integration with consensus, some checks need to be separated from the header transition. In particular, for transactions sitting in the mempool, there needs to be a way to move time along to see if transactions are still valid in the absence of a block header for those transactions (in the case where the node is trying to mint a new block from the mempool). The second change to the specification was suggested by the Ouroboros Praos authors, namely that certain proofs that they wanted to do would be easier if it was possible to include certain block header hashes into the epoch nonces. Both these changes have been made to the formal specification and the execution model.

On the testing side, writing the generators for all the certificates in Shelley is making progress, and the work could potentially be completed by next week. The goal for the next two weeks is to have all the generators needed to make transactions.

Finally, the team improved the validation mode of the database that stores the immutable part of the chain (ImmutableDB) so that it can detect any random bitflip in a block. CRCs are used to speed up this process, falling back to checking the signatures of blocks when the index file containing the CRCs is missing or corrupt.

Goguen

This week the Plutus team added a transaction validity rule for validity intervals to the EUTXO model document. They also added a timeout to 'handleBlockchainEvents' and merged the plutus-core-interpreter into language-plutus-core.

In addition, they worked on how to determine memory costs for scripts so that they could begin to predict memory requirements and investigated using MAST for Plutus Core.

The Marlowe team continued to fix some minor issues that were appearing in the Marlowe Playground.