Status Update

Weekly Development Report

DAEDALUS

Wallet

This week the team continued working on the implementation of UI designs for the Shelley delegation for stakeholders features.

The implementation of the ‘Rewards’ screen has been finalized, while work on the ‘Staking Pools’ screen is still ongoing. The team has also started with the implementation of the designs for the ‘Staking polls’ screen. This screen has the most complex UI, which will be broken down into smaller, reusable components to be used later in building other screens.

App Platform

This week the team completed initial work on the server-side JavaScript execution engine for the smart contract backend, which uses a Chromium process to isolate the untrusted contract execution, restricting the use of NodeJS to trusted operations during initialization. A security assessment was initiated in coordination with the Plutus and tools team, which will be completed along with boundary and load tests next week. A remodel of the smart contract server was also completed, strengthening the foundation before moving onto the contract off-chain state management.

BACKEND OPTIMIZATION

The team has made significant progress with testing and reliability this week. In doing so, the continuous integration setup and workflow have also been improved, allowing for better and faster feedback.

A stable implementation for the new SQLite persistent backend is almost done, and the team is looking into some deep testing techniques to improve confidence in the new implementation. This includes state-machine testing, time and space benchmarking, and fault-tolerance testing.

Meanwhile, available packages have been extended, with a deeply-tested Haskell implementation for Bech32 encoding which will power the new encoding format for addresses in Shelley. This is a positive contribution to the Haskell eco-system with some very useful features for users to prevent typing errors when entering an address by hand.

And finally, the team has also been polishing documentation and error feedback from both the API and the command-line interface.

NETWORKING

This week the team worked on improving generators and shrinkers in the property-based test suite. On the block fetch front, engineers are working on chain prioritization. The consensus layer gives us input on how to order forks, and which blocks are orchestrated for downloading.

Work was also done to merge a branch with a high-level interface for the ouroboros-network, and the team is in the process of integrating the initial handshake protocol into byron-proxy.

Additionally, a new stream of work has begun on DNS connection management, which will be important in the initial phase of the Shelley release. The team has implemented byte limits on incoming and outgoing connections. While the latter one is optional, the former limit is essential in early detection and prevention of DDoS attacks.

The team has also been improving documentation, including updating the transaction submission and handshake protocols descriptions, and working on improving CDDL tests for CBOR codecs of protocol messages.

DEVOPS

No updates this week

CARDANO DECENTRALIZATION

This week the team has been working on property testing the Byron implementation. A number of good properties to test for the ledger rules have been identified and the process of implementing them has begun. An important aspect of property testing is generating test cases: we've been building on concepts discussed in this blog by Edsko de Vries to come up with some powerful generators for UTXOs that give us good counterexamples to aid debugging. This all contributes to high-assurance code and will increase our confidence putting the rules onto mainnet.

The Windows-specific parts of the storage layer are now implemented and tested. The mempool has been implemented, although we still lack integration with the network layer to actually accept transactions. The integration with the ledger layer is cleaned up, updated for the mempool, and almost ready to merge. Apart from that, we made progress on the storage layer itself; since the storage layer is split into three parts (immutable part of the chain, that is, storing the part of the chain that will never be rolled back; volatile part of the chain, storing blocks near the tip; and storing the state of the ledger), the layer that unifies these three components requires careful thought.

GOGUEN

Updates have been made by the Plutus team to the game and vesting use cases to make them both multi-currency aware. The team also made changes to the validity range parameters and the Plutus wallet API to make things easier for script authors.

This week the Marlowe team continued working on Meadow in the cloud. The team is planning some minor edits to the Marlowe Udemy course to improve the audio in some sections, and a plan for updates to the Plutus course is underway. Positive feedback was received from internal staff on these courses in recent days.

The Education team are finalizing their plan for the remainder of 2019 and are ready to present to the executive team next week along with their Education strategy. The working group was busy with the initial chapters of the Plutus ebook.

ANNOUNCEMENTS

IOHK is currently looking for talented people to work with us. Please see the IOHK Careers page for more details.