Testnet DayLight | Release Cycle Update #22

Release Cycle Update #22

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 this 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. This is truly a tremendous development. Previously, if you wanted to test a Zero-Knowledge proof in your browser, you had to download a file of +100MB. With this change, that file can become significantly smaller. This means that you can now perform in-browser proving locally on your own devices, if desired. You could even embed them directly in the blockchain itself.

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.


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


Official reference implementation of the DUSK Network protocol in Golang.

Opened issues

In the past 3 weeks, no issues were opened in the blockchain repository.

Closed issues

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



The Dusk's Smart Contract Platform.

Update Summary

In an effort to make our codebase more efficient, and allow for properly walking the notes, we ported the transfer contract to use the dusk-merkle tree.  We upgraded the version of dusk-poseidon, removed microkelvin and related deps and added dusk-merkle. Using Microkelvin resulted in our state growing much faster than it should due to its immutable nature, this is fixed by using the dusk-merkle tree and  since it's much easier to walk the dusk-merkle tree, we should have no more problems there.


Introduce fixed gas for transfers #939

Enable fallback procedure in rusk node #938

Remove txs from mempool after being included in a block #935

Clients should be able to execute contracts to retrieve data #933

Allow clients to listen to events due to block transition #931

Unable to decode blocks containing multiple transactions #930

Update to plonk version with circuit compression capabilities #929

Replace rusk.persist() method #924

Resolve any incompatibility issues between rusk and golang node implementations #921


Modify transfer contract to use dusk-merkle #932

Upgrade merkle dependency #926 

Reload most recent block from persisted ledger state on startup #915 

node: Create a complete synchronization procedure that can download and validate any missing blocks #898 

Update to piecrust version 0.5 #883 

Error message should specify the missing argument #871  

Using base_state generates corrupted state #754 



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

Piecrust V0.6.0 was released on June 28th. Implementing the needed changes to solve the below mentioned issue(s).

piecrust-uplink 0.6.0 


  • Add Event struct according to spec
  • Impl fmt::Display for ContractError
  • Emit debug line on panic handler [#222]
  • Add debug feature [#222]



  • Change emit extern to include topic
  • Expose externs only on feature abi [#222]
  • Rename std feature to abi [#222]
  • Rename host_debug to hdebug and use arg buffer [#222]



  • Remove unused height extern. [#222]
  • Remove unused snap extern. [#222]


piecrust 0.6.0


  • Add debug feature, gating debugging capabilities. [#222]



  • Change event handling to emit piecrust-uplink::Event.
  • Change emit export to include topic.
  • Remove Into<PathBuf> bound in VM::new.
  • Rename host_debug export to hdebug [#222]



  • Fix memleak due to last contract instance not being reclaimed
    in session.



  • Remove Event struct.
  • Remove __heap_base requirement from contracts.


Opened issues

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

Closed issues

Structure piecrust-uplink features to build correctly for all targets #222



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.16.0 was released on June 28th. Implementing the needed changes to solve the below mentioned issue(s).


  • Change cached Note's key to be the nullifier instead of hash [#144]
  • Update cache for all the possible addresses at the same time [#144]


Opened issues

Remove all instances of panic in the codebase #154

Port the library to be piecrust-enabled #151 

Closed issues

Use nullifier as key for note's store #144 




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

Plonk v0.14.1 was released on June 28th. This version introduces Compiler::compress and Compiler::decompress, two functions that will create a compressed representation of a circuit that can be used to generate prover and verifier keys.


  • Add compress to compiler [#752]


Opened/Closed issues

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



Implementation of the Kadcast Network layer according to the latest version of the paper to date (2021)Kadcast is an UDP-based peer-to-peer protocol in which peers form a structured overlay.

Opened/Closed issues

In the past 3 weeks, no issues were opened or closed in the kadcast 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.


Design, implement and document Citadel request authoring process #60  


Fix compute parameters #59 

Remove local state #54 

Address code reuse of Citadel data structures and test utilities #36 



A sparsely populated Merkle Tree, parameterized over its height and arity.

Update Summary

After the poseidon implementation moved into its own crate, the implementation with Serializable is not possible anymore (or better, not possible without the use of a macro and the creation of a lot of unused code). This is due to the fact that we can not implement Serializable for Item<T> with a generic T.

We decided to implement a custom serialization that works with vectors instead.


Implement custom serialization for Opening and poseidon_merkle::Opening #60


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



Reference implementation for the Poseidon Hashing algorithm.

Update Summary

Poseidon252 v0.30.1 was released on June 28th. This releases fixes the missing rkyv feature.


In the past 3 weeks, no issues were opened in the Poseidon252 repository.


Add sponge framework over fixed size input #215 

Add benchmarks for poseidon opening #226 

Re-introduce the merkle tree in this crate #222 



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

Schnorr v0.13.0 was released on June 28th. Introducing the following changes:

  • Update dusk-pki from 0.11 to 0.12
  • Update dusk-poseidon from 0.28 to 0.30
  • Update dusk-plonk from 0.13 to 0.14
  • Update rust-toolchain from nightly-2022-08-08 to nightly-2023-05-22


Opened/Closed issues

In the past 3 weeks, no issues were opened or closed in the Schnorr repository.



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

Dusk-PKI v0.12.0 was released on June 28th. Introducing the following changes:

  • Update dusk-poseidon from 0.28 to 0.30
  • Update rust-toolchain from nightly-2022-08-08 to nightly-2023-05-22


Opened/Closed issues

In the past 3 weeks, no issues were opened or closed in the Dusk-PKI repository.



A library for generating and dealing with transactions.

Opened/Closed issues

In the past 3 weeks, no issues were opened or closed in the Wallet-core repository.



Implementation of Hades252 permutation algorithm over the Bls12-381 Scalar field.

Update Summary

Hades252 v0.21.0 was released on June 28th. Introducing the following changes:

  • Update dusk-plonk from 0.13 to 0.14


Opened/Closed issues

In the past 3 weeks, no issues were opened or closed in the Hades252 repository.

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.