Dusk | Release Cycle Update #25

Release Cycle Update #25

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.


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

Re-enable consensus task on a failed block acceptance #1537



The Dusk's Smart Contract Platform.


Consensus: Address the issue of a non-deterministic certificate for single round/iteration  #1030

Node: Re-enable consensus task on a failed block acceptance  #1029

Node: Broadcast block on a verified certificate  #1028

Consensus: Include ratification signature and bitset in block certificate #1027

Consensus: Create a distinctive signature for the agreement #1026

Make use of the feed import in the stake contract #972

Make use of the feed import in the transfer contract #971

Make Rusk VM sessions parallel #970

Change finalize to only squash commits #967

Add events hash to the block #962

consensus: Ensure that the candidate verification is executed for a minimum duration of N seconds #950

Use new circuit compression to store circuits #949

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


node-data: Make ledger::Block fields private #1024

Remove prev_hash field from NewBlock message #1021

Dockerize Rusk #1012

consensus: Improve block time in a situation of unsynced provisioners #1011

consensus: Allow voting on empty block hash #1010

consensus: Enhance debug level logging details #1004

node: Ensure state_hash from accept/finalize call is equal to block.header state_hash #957 

Add prover crate #954 

consensus: Cache and reuse verified candidate blocks in Reductions #951 

Introduce fixed gas for transfers #939 

Enable fallback procedure in rusk node #938

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

Modify transfer contract to use dusk-merkle #932 

Unable to decode blocks containing multiple transactions #930 

Update to plonk version with circuit compression capabilities #929 



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.9.0 was released on August 30th. This release introduces crumbles 0.1.0.

Crumbles is intended to solve the problem of mapping WASM memories onto virtual address space.

It is built to support tracking dirty pages and creating memory snapshots to which it is possible to revert to. This is required if we want to remove re-execution in piecrust, as well as allowing for the removal of diffing in the storage process of state commits.

piecrust 0.9.0 


  • Change commit write behavior to write dirty pages instead of diffs [#253]
  • Change memory backend to use crumbles instead of libc directly [#253]


  • Remove Session::squash_commit since it's irrelevant with the new commit behavior [#253]
  • Remove libc dependency [#253]
  • Remove flate2 dependency [#253]
  • Remove qbsdiff dependency [#253]

crumbles 0.1.0 


  • Initial release

Opened issues

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

Closed issues

Remove diffing by employing a marking strategy #253




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.15.0 was released on August 30th.


  • Fix panic when creating proof for circuit with different circuit size [#760]
  • Fix panic when testing in debug mode [#763]


  • Remove 'setup' funcion from common test module [#763]


  • Change range and logic component to be generic over the const BIT_PAIRS [#763]

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. 

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.

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.