Testnet DayLight | Release Cycle Update #9
By Yannick Planteijdt

Sep 29, 2022 - Amsterdam

Our development planning features a Release Cycle of three weeks, providing a consistent stream of updates to the community, developers, and businesses relying on Dusk technology.

The publicly available Dusk Network GitHub contains over 18 active repositories, each focused on a different technical subject. Progress in each is ongoing and can be followed in real-time. The Release Cycle process is currently applied to some of our most active repositories.

Release Cycle planning has not yet been applied to all repositories. When they are, future installments of the Release Cycle updates will see an expansion of repositories in the spotlight.

For the community's benefit, we’ve chosen a selection of some (but not all) of the work that is being done in our repositories, including recent advancements.


Open issues

Create Badge component #736

Create a new atom component that presents text in a Badge.

The Badge must support a standard set of variants: 'success', 'warning', 'danger' and 'brand'.

Reinstate Draw component #735

This is needed for developing applications with slide-out sidebar menus.

Add cms-connector models and schemas in published UI Kit #719

The models and schemas that are generated and maintained in the cms-connector repository are to be published with the UI Kit packages. This can be achieved by removing the private property from the package.json.

Improve and expand test coverage #715

The goal is to increase the number of tests that we run on the components. This will result in the ability to see property values changing and testing for the correct output. Testing for visual differences can also be explored with Chromatic (or alternative, if deemed more suitable).

Closed issues

Navbar needs to support networks and navigation props #712

The Navbar component needs to support networks and navigation as additional props and render the appropriate UI when these values are set.

DateText component throwing errors #737

The underlying date library (dayjs) throws errors relating to commonJS loading. Attempts to exclude the library from the optimized dependencies have failed.


Closed issues

Remove genesis consistency checks #1464

At the moment of writing, dusk-blockchain repo is used to hardcode the values of rusk's state-root and the derived genesis-hash.
These were introduced in order to mitigate the possibility of being error-prone after a breaking change upgrade.
Since we introduced the protocol and rusk versions, the genesis consistency checks should not be required anymore.


Open issues

Panics should propagate to the caller #79

When performing an inter-contract call, a panic occurring in the called module should inform the caller that the module panicked, as opposed to stopping the execution.

This ensures the calling module is able to handle panics of modules whose code it has no control over.

Missing features and improvements #76

This issue is meant to describe the things still missing from this VM implementation vs. the previous implementation at rusk-vm, and remaining necessary improvements.

Closed issues

Do not mandate weealloc #68

At the moment weealloc is hardcoded in the uplink communication library, this is unnecessarily restrictive and it should be up to module authors to choose allocation strategy.

Provide debug information to be easily used in modules. #53

Tools for debugging running modules.


Open issues

Implement interactive mode for staker allow transaction #98

Since #85 is merged, we should allow the user to do the same operation in interactive mode

Add context to errors #95

By Providing the user with more specific error context, the reason why the program fails will be more understandable for the non(technical) user(s).

Notify the user if he tried to create more than 256 addresses for one wallet #92

We decided to support a maximum of 256 addresses for each wallet (seed), however there is no error message once the user reaches such a limit.

Document more in detail the configuration for multiple networks #89

To let the user understand how to configure the wallet's network – however the default values are the one used the most.

Prover and State server should have the capability to have different ipc method #77

The prover and state server should have the capability to have different ipc methods.

Closed issues

no cancel option available #97

When an action is initialized, users can't cancel it. The only possible way to come back is to close the wallet, reopen it, unlock it, then retry the action.

Implement stake allow command #83

This is required in order to support by dusk-network/rusk#732.

Quit program if 3 times wrong recovery phrase is given during recovery process #49

The program should quit after 3 times a wrong phase phrase

If the user is not able to fill in the correct recovery phrase, the program will exit

Option to correct/ re-enter password if 3x wrong recover wallet #46

Implement an option to correct the password / re-enter password.

Wrong refund_addr description #86

The argument refund_addr for the withdraw command has the following description:

"Address to which the reward will be sent to"

Implement anyhow and thiserror #87

Implementing anyhow and this error into the error handling.

Wrong condition involved `gas.is_enough() #91

gas.is_enough() will always return Error::NotEnoughGas.

Restoring a wallet prints an unexpected message #78

Recovering a wallet works but prints an unexpected message at the end.

BLS keys exported with wrong extensions #84

When exporting the bls keys, 2 different file should be produced

  • .key - Encrypted BLS key pair for provisioners in dusk-blockchain compatible format
  • .cpk - Binary file with the Consensus Public Key

Currently, the extensions are switched

Move focus to single wallet creation #72

Direct the user to create one single wallet, instead of multiple wallets.

Improve config.toml #57

A better configuration file for the wallet.


Open issues

Use tar to handle state's compression instead of zip #740

Our servers are *nix base and there is no reason to use zip instead of tarball files, plus the ergonomics of the tar crates is better than zip crates.

Allow to export a state from rusk-recovery #738

After that rusk is able to get a custom state as input [#734] there is the need to generate such a state.

Closed issues

Instruct rusk-recovery to generate custom genesis state #737

rusk-recovery should be able to receive a struct containing the desired state

rusk: Allow to run rusk in "ephemeral" mode #734

Rusk should be able to run in a sort of ephemeral mode, deleting every change applied to the state after it quit.

This means that if the user launches rusk twice in a row using this custom state, any change performed by the first execution should be discarded.

In addition, the user should be able to pass a "custom" state to use (without using a different rusk_profile_dir). The custom state should be a single file.

stake-contract: implement allowlist #732

An on-chain mechanism to handle staking allowlist.


Open issues

Store the root of a branch separately to the levels #189

At the moment the root of the PoseidonBranch is stored in the last level of the branch at index 1. Ideally we want the root stored separately to the levels and not as an additional level.

This is also an issue due to the rkyv implementations. Since it is now a Vec, PoseidonBranch<17> would parse in the exact same way as PoseidonBranch<16> for example.

Use component_boolean in the our merkle opening circuit #188

Use component_boolean to check for the index bits in our merkle opening circuit.

Restructure crate features #184

The features of a crate should be named according to the features they enable, and not the names or technicalities of its dependencies. I propose a restructuring of the features of this crate.

Closed issues

Update CHANGELOG #191

Some versions are not properly tagged and fix other minor issues.

Implement rkyv for PoseidonBranch #186

The rkyv-related traits should be implemented for PoseidonBranch, and the resulting types be made public.

Fix merkle opening circuit #181

Fix the merkle opening circuit and add tests that catch this in the future. For people using the repository please be aware of this fix.

PoseidonTree is only available behind canon #180

The PoseidonTree struct - one of the main features of this library, and a very important component for the genesis contracts - is only available behind the canon feature.

This means to write a smart contract one is required to bring in the canonical library even though this is in principle not required.

As you can see, development is continuous and this list is not exhaustive. For example, minor issues and advancements concerning the Kadcast element have also been opened and resolved. The complete series of repositories can be found on GitHub.

Breakthrough developments will receive a separate spotlight, such as our latest deployment of Daylight. Thank you very much for your understanding and feedback as we continue to find the best way to provide the community with transparency and development information.

In A Nutshell: Release Cycle planning

Release Cycle development planning has been adopted by major companies including Google, Mozilla, and during the development of products such as Ubuntu, Kubernetes, and many more. The reason for this is clear: Release Cycle planning improves the predictability of software development for developers and the community alike.

For a more detailed explanation of the concept (along with frequently asked questions) please scroll down to the bottom of this article.


We’ve included a small FAQ section below to make sure the community understands our intention with Release Cycles.

What is Release Cycle planning?

Release Cycle planning means that developmental updates are published at consistent intervals on GitHub; in the case of Dusk Network, every three weeks. These releases describe the latest additions, changes, fixes, and assets added to the tech stack by the development team.

Dusk Network currently has over 18+ active repositories on GitHub, each repository covering a different technical project. Release Cycle planning has not yet been applied to all repositories; the current focus on a single GitHub repository for clarity does not mean there are no ongoing developmental efforts occurring in other areas.

Does being featured in a Release mean Deployment?

The Release Cycle updates does not mean immediate deployments on our testnet. It is a release detailing additions, changes, and fixes to the repositories that we are ready to share with the public. All released content is considered stable, consistent, reviewed, and cross-checked with other repositories.

Are Release Cycle updates a spotlight for major deliverables?

No. The Release Cycle approach is strictly a way to provide a consistent shape for publication of our work in the clearest terms possible. They are not deadlines to be made, nor are they tied to specific development sprints. Release Cycle updates aim to raise attention with the community, and give proper coverage to, publishable GitHub releases. Major deliverables will be given their proper publication in dedicated articles.

[Read more about our Release Cycle planning here]

About Dusk Network

Dusk Network is the privacy blockchain for financial applications. A new standard for compliance, control, and collaboration. Our mission is to enable any size enterprise to collaborate at scale, meet compliance requirements and ensure that personal and transaction data remains confidential.

Share this post

Subscribe to our newsletter

Dusk on GitHub Download Whitepaper