Dusk | Release Cycle #29

Release Cycle Update #29

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 Update Summary

During the most recent  3 week Release Cycle, the Rusk repository has seen significant progress. Developments include enhancements,  such as license contract methods, block detection, timing of block acceptance, refining consensus mechanisms, and optimizing components. Notably, issues like adding a prover feature to Rusk, resolving test block inconsistencies, and enhancing security in the OutOfSync state have been addressed successfully.

In the Piecrust segment, a test implemented during dusk-network/rusk#1125 revealed a root display discrepancy between sessions with erroring calls and those with successful calls. This highlights an important aspect of system behavior under different conditions.

For Wallet-Core, the focus has been on introducing features for offline transaction signing, improving log, warning, and error handling, and updating WebAssembly in continuous integration tests, all aimed at bolstering security and testing efficiency. The resolution of issues pertaining to error reporting and transaction verification between wallet-core and rusk is a notable achievement.

The Plonk repository's recent updates include proposals to improve code modularity and error handling, particularly in the component_mul_generator. The absence of closed issues suggests ongoing efforts to tackle these new challenges.

The Schnorr repository underwent changes with multiple issues opened and closed, focusing on naming conventions, documentation updates, and refinements in the signature and proof systems.

Lastly, the Dusk-PKI repository has been deprecated, with all keys now integrated into either dusk-schnorr or phoenix-core, streamlining the Dusk Network ecosystem. 

Overall, these updates demonstrate a strong commitment to advancing our blockchain infrastructure with a focus on security, efficiency, and system robustness towards our Mainnet in 2024.

For the community's benefit, we have divided our repositories in 3 categories, main, libraries and other. Below you will find a selection of some (but not all) of the work that is being done in our repositories, including recent advancements.



Main Repositories


The Dusk's Smart Contract Platform.

Update Summary

In the past three weeks, the Rusk repository has seen notable developments.

Among the opened issues, key focuses include renaming the License Contract's noop method, addressing missing block detection, investigating block acceptance timing, refining consensus mechanisms, and optimizing components by removing specific dependencies. 

A number of issues have been closed, including the addition of a prover feature for rusk, resolution of non-deterministic behavior in test blocks, improved security and stability in the OutOfSync state and fallback procedure, and the successful addition of various features like deterministic winning certificates and enhanced API documentation. 


Rename License Contract noop method to request_license #1151

Missing block detection #1150 

Investigate block acceptance timing #1149

Consensus: accept block from single Agreement #1148

Remove anyhow from http handler #1146

Allow rusk to be prover-only #1144

Remove phoenix-core from rusk-recovery #1139

Remove phoenix-core from stake-contract #1138

node: Maintain a set of eligible provisioners of previous epoch/block #1124

Change block's finality definition #1118

Add failed_iterations fields #1116

Document API #1114

Single vote for iteration #1109


Add prover feature for rusk #1145

Test blocks are not deterministic #1141

Add clippy check for smart contracts #1140

Add hash header to the CRS-via-HTTP api #1135

Remove rusk-recovery binaries #1128

node: Improve security and stability of OutOfSync state and fallback procedure #1127

Add rusk-recovery capability to rusk #1126

CRS is not cached properly #1121

Enrich Rusk ABI and License Smart Contract with a method to provide PLONK setup #1119

Start iteration from 0 instead of 1#1117

Add Deterministic winning certificate #1115

Introduce prev_certificates #1108

Shortcircuit timed out iterations #1107

node: Request missing blocks if node enters on_idle state #1103


Piecrust is a Rust workspace containing two crates, piecrust and piecrust-uplink, that together form the WASM virtual machine for running, handling and creating Dusk smart contracts.

Update Summary

During the implementation of dusk-network/rusk#1125, a test was added that makes an erroring call, and then subsequently executes another call. Another session is then instantiated that only runs successful calls, which then displays a different root than before.

Opened issues

Inconsistent root after erroring calls #296

Closed issues

In the past 3 weeks, no issues were closed in the piecrust repository.



Library providing functionalities to create wallets compatible with Dusk Network

This library is used to implement the official Dusk CLI wallet.

Update Summary

Wallet-CLI v0.20.1 was released on November 22nd. Introducing the following changes:


  • Add spending_keys to wallet impl [#218]

Opened issues

interactive stake-allow doesn't work #222

Closed issues

Implement a method to get the SSK from another module #218 



A WASM library to provide business logic for Dusk wallet implementations.

Update Summary

Three new issues have been opened in the past three weeks. These include requests to add a feature enabling offline transaction signing (#96), the provision of handles for log, warnings, and errors (#95), and the compilation of fresh WebAssembly (wasm) during integration tests on Continuous Integration (CI) (#94). These issues collectively indicate a focus on enhancing security, error management, and testing procedures within the Wallet Core library.

On the closed issues front, two matters have been successfully addressed. The first involves the addition of error reporting and hooks for handling errors (#97), while the second pertains to resolving a concern where transactions created by the current wallet-core could not be verified on the rusk side (#84). 

Opened issues

Add a way to offline sign transactions #96

Provide handles for log, warnings and errors #95

Compile fresh wasm when running integration tests on CI #94

Closed issues

Add error reporting and hooks for onerror #97

Current wallet-core creates transactions which cannot be verified on rusk side #84


This is a pure Rust implementation of the PLONK proving system over BLS12-381

This library contains a modularised implementation of KZG10 as the default polynomial commitment scheme.

Update Summary

In the recent updates to the Plonk repository, two new issues have been opened in the past three weeks. The first issue (#788) proposes the separation of the component_mul_generator into two distinct methods, one for G and one for G_prime. The second issue (#787) suggests making the component_mul_generator infallible, emphasizing a focus on code modularity and error handling within the Plonk repository.

During this period, no issues have been closed, indicating that the development team is actively addressing new concerns and enhancements without recent resolutions in the Plonk repository.

Opened issues

separate component_mul_generator into two methods, one for G and one for G_prime #788

make component_mul_generator infallable #787

Closed issues

In the past 3 weeks, no issues were closed in the plonk repository.



This repository contains the implementation of Citadel, a protocol that integrates a self-sovereign identity system into the Dusk blockchain. An academic paper with further details about the protocol can be found here.

It also contains Shelter, a version of Citadel meant for non-Blockchain use cases. Documentation on this version will be provided soon.

Update Summary

No new issues were opened for Citadel, and one was closed (#87) to ensure that if the session fails the session verify doesn’t panic.  It has been updated to return boolean instead of panicking. 


No issues opened in the last 3 weeks.


Add a non-panicking method for verifying session #87



Reference implementation for the Poseidon Hashing algorithm.

Update Summary

Two new issues have been opened. The first issue (#108) proposes the removal of the "Note" prefix from "NoteSecretKey" and "NotePublicKey," suggesting a refinement in naming conventions. The second issue (#225) involves the addition of a failing test to address incorrect openings, indicating a proactive approach to testing and ensuring the reliability of the codebase.

On the closed issues front, one matter has been successfully addressed. Issue #188 involved the utilization of component_boolean in the merkle opening circuit.


Remove Note prefix from NoteSecretKey and NotePublicKey #108

Add failing test for incorrect opening #225


Use component_boolean in the our merkle opening circuit #188


The Schnorr signature algorithm, given its namesake by its creator Claus Schnorr, is a digital signature scheme which provides a simple method of creating short signatures.

The implementation has been created using the Poseidon hash function, the paper for which can be found here.

For a reference to the algorithm, please see the docs.

Update Summary

There were a lot of updates to Schnorr in the past 3 weeks, with Schnorr v0.16.0 being released on November 22nd. Introducing the following changes:


  • Update README with keys structure [#104]
  • Add documentation to the new key structs [#105]


  • Change the NotePublicKey tuple struct to directly be a tuple with two fields [#111]
  • Change double and single signature creation to be a method on NoteSecretKey [#81]
  • Rename internal key_variants module to signatures [#96]
  • Rename the signatures method to_witness to append [#99]
  • Update benchmarks to latest version of plonk [#94]
  • Update test structure [#94]
  • Move PublicKeyPair from DoubleSignature to public_keys [#95]
  • Rename keys: NoteSecretKey -> SecretKey, NotePublicKey -> PublicKey [#108]


  • Hide (Double)Signature::new() from the public API [#81]



Opened issues

Find a better name for PublicKeyPair #110

Rename crate to jubjub-schnorr #109

NotePublicKey derivation, signing and verification must also work with a custom Generator G #107

Closed issues

Remove Note prefix from NoteSecretKey and NotePublicKey #108

Change NotePublicKeyPair single field tuple struct to have two fields #111

Add docs to new key modules #105

Update README #104

Deprecate PublicKeyPair #95

Rename methods to_witness to append #99

Update benchmarks and zk tests #94

Change module name key_variants to signatures #96

Refactor Signature and Proof to be more consistent to bls12_381-sign #81



PKI stands for Public Key Infrastructure. This repository has been created so there's a unique library that holds the types and functions required to perform keys operations.

Update Summary

The Dusk-PKI depository is being deprecated. All keys moved into either dusk-schnorr or phoenix-core.


There were no issues opened in the last 3 weeks.

Closed issues

Add deprecated badge for crates.io #88

Deprecate this repo #79



In A Nutshell: Release Cycle planning

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.

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 above noted additions/changes to the repository can be followed on GitHub, for further details on their status and their function in the stack.




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.

In the past Release Cycle we have seen various updates and improvements across multiple Dusk GitHub repositories. In the Rusk repository, significant progress has been made in enhancing the transfer contract by migrating it to utilize the dusk-merkle tree. This upgrade not only resolves problems related to defining a proper tree walk but also simplifies the process. Additionally, several new issues have been opened and closed, addressing concerns such as enabling fallback procedures, decoding blocks with multiple transactions, and resolving compatibility issues.

Moving on to the Piecrust repository, version 0.6.0 has been released, introducing changes and additions to the piecrust and piecrust-uplink crates. Notably, the implementation now includes an Event struct, improved debugging capabilities, and adjustments to event handling. 

In the Wallet-cli repository, version 0.16.0 has been released, focusing on updates related to Note's key and cache. This release tackles issues such as changing the cached Note's key to be the nullifier instead of the hash and updating the cache for all possible addresses simultaneously.

Plonk saw the release of version 0.14.1, which introduces circuit compression capabilities through the Compiler::compress and Compiler::decompress functions. 

Shifting our focus to the Citadel repository, several noteworthy developments have taken place. New issues were opened, including the design and implementation of the Citadel request authoring process, while existing issues regarding compute parameters, local state removal, and code reuse were successfully resolved.

Merkle repository saw the implementation of custom serialization for Opening and poseidon_merkle::Opening, with an associated issue opened to address this functionality. 

In Poseidon252, version 0.30.1 was released, fixing the missing rkyv feature, and closed issues encompassed the addition of a sponge framework and benchmarks for poseidon opening. 

The Schnorr repository released version 0.13.0, incorporating updates to dusk-pki, dusk-poseidon, and dusk-plonk dependencies. Lastly, Dusk-PKI version 0.12.0 was released, featuring updates to dusk-poseidon and rust-toolchain dependencies. 

These updates reflect the ongoing efforts and progress within the Dusk ecosystem. Developers are actively addressing issues, improving code efficiency, and enhancing functionality across various repositories. As the network continues to evolve, these updates pave the way for a more robust and efficient Dusk protocol, benefiting developers and users alike.