Testnet DayLight | Release Cycle Update #16


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.

release_cycle_2023.pngFor 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

Provide coverage for non-unique diffed module commit ids #152

Rusk's wallet_grpc test provides a scenario in which module commit ids are appearing repeatedly in a commit history. This requires diffed commits to be stored independently in the presence of multiple repeating ids and not overwrite each other.

Closed issues

Switch diffing implementation to qbsdiff #150

Crate bsdiff is not reliable and we need to switch to qbsdiff.


Open issues

Allow users to mint NFT notes #828

We are working on deploying the NFT model in Rusk. For that reason, new note types will be used, and are being implemented already in phoenix-core:

0 - Transparent note

1 - Obfuscated note

2 - Transparent NFT note

3 - Obfuscated NFT note

4 - Transparent Message note (this one is NOT appended to the Merkle tree)

5 - Obfuscated Message note (this one is NOT appended to the Merkle tree)

We want Rusk to accept those notes created by the user. Basically, a user will create those, and will add them into a transaction. The ZKP of such a transaction will prove that the user has enough money to pay for the gas, but the new NFT note's commitments will not be part of that ZKP. Actually, NFT notes have no commitment. We can consider setting them to 0 in the code, or creating a new struct.

node: Add TOML configuration support #831

Add the possibility to specify the configuration using a TOML file

Upgrade tar-rs dependency #832

Current used version of tar-rs has 2 major vulnerabilities:

node: Share common structs and functionalities in a distinct crate #834

It is advisable to consider encapsulating common data structures and functionalities in a distinct crate. The new crate should allow both Consensus library and Node library to use any global data structs (like Ledger Block and Ledger Transaction) together with any common traits definitions.

Change broker to be a PublicKey (not a bls one) #845

At the moment the broker is not used in the contract, but it should be.

node: Add transactions merkle tree root to the block header #847

This is needed in order to reflect protocol changes made in dusk-network/dusk-blockchain#1499

node: Add Iteration field to Block header #848

​​This is needed in order to reflect protocol changes made in dusk-network/dusk-blockchain#1500

Closed issues

node: Add node library crate to rusk CI #821

Node crate should be compiled and unit-tests executed on any CI.

node: Implement basic DB operations to be used by Mempool service #822

It's worth considering utilizing the same RocksDB instance to store verified transactions of the Mempool and take advantage of the low write-latency provided by L0 (memtable). The Mempool can also benefit from other features of RocksDB

Add integration tests to the governance contract #833

Currently the governance contract source does not have integration tests. We need at least a bare minimum to ensure the logic is correct.

Remove allowlist from governance contract #838

The allowlist is not required, since the authority is the only entity that perform operations

Rusk doesn't compile anymore #842

Looks like yesterday they updated async-stream from 0.3.3 to 0.3.4 causing major breaking changes.

I'm going to fix our version to 0.3.3 so we can compile again, at least for the time being.

governance-contract: optimize signature verification #844

Currently the signature and seed verification are done in all methods in a slightly different way, in addition we perform two hashes while the Poseidon one is redundant.


Open issues

Improve Documentation #1490

Code documentation needs to be improved as a whole.

This is a macro-Issue, tracking single items/components to be documented.

Improve Succinct Attestation Documentation #1492

Documentation of the Succinct Attestation code should be improved.

Sortition Hash is not compliant with specification #1494

createSortitionHash returns H(round||iteration||step||seed), but the specification states it should be H(seed||round||step||iteration).

Logically speaking, the concatenation order should follow round->step->iteration, like in the specification.

Technically speaking, this does not affect correctness/security, as long as all nodes calculate the same hash.

Improve Chain Documentation #1495

This is part of #1490

Improve Mempool Documentation #1496

This is part of #1490

Improve Consensus Documentation #1497

This is part of #1490

Improve Network Documentation #1498

This is part of #1490

Closed issues

Improve Sortition Documentation #1491

Documentation of the Deterministic Sortition code should be improved.

Reintroduce block.header.TxRoot #1499

This is a required health check to be performed in order to waste time/cpu processing an invalid block.

Include step into certificate header #1500

The step should be included into the hashable fields used to generate the block hash.


Open issues

Integrate node-common crate #42

Replace Block and Transaction struct with definitions from node-common crate.

Closed issues


Open issues

Refactor and add tests for logic components #734

Add in-circuit tests for the composer methods

  • append_logic_and
  • append_logic_xor
  • append_logic_component

Refactor and add tests for component_range #735

Add in-circuit tests for the composer methods

  • component_range

Add tests for gate_add and gate_mul #736

Add in-circuit tests for the composer methods

  • gate_add
  • gate_mul

Add tests for append_gate #737

Add in-circuit tests for the composer methods

  • append_gate

Refactor and add tests for component_decomposition #738

Add and refactor in-circuit tests for the composer methods

  • append_gate

Circuit verification doesn't fail when wires selectors are different than the ones in the circuit description #742

When we test a circuit, we first create a circuit description for both the prover and the verifier. This circuit description essentially is the compressed blueprint of the circuit and when we verify certain circuits, they should only pass when they have that same circuit description.

But what seems to happen in the implementation is that only the witness, public input values and the constants are crosschecked with the circuit description, but not the wire selector values.

Closed issues

Restructure integration tests #731

Restructure integration tests and add common setup and verification functions that all tests can use.

Add tests for assert_equal and assert_equal_constant #733

Add in-circuit tests for the composer methods

  • assert_equal
  • assert_equal_constant


Open issues

Define the NFT types #125

We are working on deploying the NFT model in Rusk. For that reason, new note types will be used in phoenix-core:

0 - Transparent note

1 - Obfuscated note

2 - Transparent NFT note

3 - Obfuscated NFT note

4 - Transparent Message note (this one is NOT appended to the Merkle tree)

5 - Obfuscated Message note (this one is NOT appended to the Merkle tree)

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.


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]