Testnet DayLight | Release Cycle Update #14
By Yannick Planteijdt

Jan 12, 2023 - 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

README: Add short description of Deterministic Sortition #41

Describe shortly how Deterministic Sortition works.

A link to a more extended description on the Wiki page should be provided.

Closed issues

Update README with description of consensus phases #38

Add a short explanation of how SA works, describing the different phases.


Open issues

Remove #![no_main] from modules #126

Remove #![no_main] tag from all modules. The modules are libraries hence cargo won't expect a main function anyway.



Brush up the docs.rs documentation of the piecrust package #129

Make sure that every exposed type, every function and every trait is properly documented. On top of that add explanations to the source code when needed.

Brush up the docs.rs documentation of the smart contract examples #130

Add a module description and explanations of each type and method.

Closed issues

Implement CommitId persistence and Cold Restart test in Piecrust #124

Cold restart functionality and test were present in Rusk-VM and we should provide equivalent functionality in Piecrust.


Closed issues

Expects negative public inputs #717

The current implementation will produce negative public inputs(PIs). This is incredibly confusing and unexpected. The proving algorithm in the Prover::prove functions produces PIs that are the negative of what is expected, and Verifier::verify expects them to be negative as well.


Open issues

Currency inflation on fee charge and block generator reward #790

Charging fees to the transactor currently happens in the push_fee_crossover function which is called right before the last call to update_root. This counts the gas used and produces a note containing the remainder of the fee and appends it to the tree.

The awarding of fees to a block generator is done by counting the gas used in executing each series of transactions and awarding it to the stake contract.

The problem is these two numbers are not the same due to the fact that some code gets executed after the measurement of gas used in the contract. This means a transactor gets charged slightly less than the gas used to execute the transfer contract, while the block generator gets awarded the totality of the gas used.

This leads to currency inflation favoring the block generator, effectively incentivizing them to pick a large number of small value transactions to reap more of an inflationary reward.

Update CI so it can read rust-toolchain.toml file #792

Use of unmaintained org actions-rs actions.

Migrate example node from consensus repo into rusk/node crate #794

We should integrate the code-base from the example node into rusk library. Basically this effort will add the following functionalities:

  • Kadcast reader and writer
  • Wire frame encode/decode
  • Consensus setup and bootstrap

As an outcome, we'll have a node library that exposes bootstrap API which can run a stateless and fully functional consensus.

Migrate rusk-recovery to use piecrust #795

Migrate rusk-recovery to make use of piecrust instead of rusk-vm. This will allow rusk to be faster at executing contracts, and use less disk space - together with a number of other improvements, i.e. less gas per TX.

In particular, the genesis state generation needs to be properly ported.

Make the 'make' command build sources #796

Currently, executing the 'make' command with no arguments will show the help message.

However, the standard convention is to have 'make' build all sources.

Closed issues

Port the Rusk Test Infrastructure to use Piecrust #773

Migrate rusk test infrastructure to make use of piecrust instead of rusk-vm. This will allow rusk to be faster at executing contracts, and use less disk space - together with a number of other improvements, i.e. less gas per TX.

Specify versions for local path crate dependencies #779

Currently, all the path dependencies specified in the repository are specified using just the path

rusk-schema = { path = "../rusk-schema" }

Since we follow the semver rules, any update to a dependency that can be considered a "major" version should be reflected to the bin/lib version too

However, the aforementioned dependencies are specified without the version, so cargo just builds everything normally.

This can lead to some issues especially when any of these dependencies is not backward compatible anymore.

Add 'make all' and separate 'make test' #782

Add the all target in the Makefile and separate it from test.

This way, the building and testing processes can be run independently from each other.

As a result, building will be faster (as tests are not run) and testing can be made without re-building.

Create a new library crate named node that should host all rust node functionality #791

A new crate should be part of rusk workspace and import both consensus and kadcast crates as dependencies.

Additionally, a binary should be added that will consume public node library APIs to bootstrap a node service.

Later on, node crate will import and use rusk library functionality in order to execute any EST-related call.

Any missing features will be added as a separate module.


Open issues

Tests fail in release mode #132

Tests are failing if release mode is used.

Closed issues

Add a method to execute generic contract calls #133

This is the high level API of the low level method in wallet-core, see: dusk-network/wallet-core#66

Without this, a consumer of the dusk-wallet library also needs to deal with wallet-core directly, breaking the encapsulation.


Open issues

Crossover is used too eagerly #73

The crossover is set in unstake and withdraw but its value is set to zero. Since the crossover is not necessary in these transactions, they will be taken at the end and a zero-value note generated and added to the transfer contract tree.

These notes are technically worthless and serve no purpose but to fill up the tree and slow down any sync procedure.

As you can see
, development is continuous and this list is not exhaustive. 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.

The below noted additions/changes to the repository can be followed on GitHub, for further details on their status and their function in the stack.

Wallet-cli v0.14.0


  • Add execute to create transaction for generic contract calls [#133]
  • Add transaction history [#12]
  • Add stake maturity epoch [#128]
  • Add staking address display [#105]
  • Add stake eligibility info [#124]


  • Fix headless balance display [#123]


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