Testnet DayLight | Release Cycle Update #13
By Yannick Planteijdt

Dec 22, 2022 - 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

Rename Public/SecretKey into Note-Public/SecretKey and Public/SecretSpendKey into Public/SecretKey #77

We want to do a renaming of the PublicKey and SecretKey structures to NotePublicKey and NoteSecretKey, respectively, as well as rename the PublicSpendKey and SecretSpendKey to PublicKey and SecretKey, respectively.

This is to better reflect their usage in our transaction model, and avoid any confusion when comparing documentation with this code.

Closed issues

Derive Default for PublicKey #74

Citadel requires it for handling the License struct.


Open issues

Fix Argument Buffer Corruption #118

When called by transfer contract and stage contract, contract methods receive argument buffer with initial 32 bytes set to zero.

Eliminate overlap between session's attributes: memory handler and callstack #123

In current piecrust implementation, memory handler (MemoryHandler) maintains a map of per-module-id memories (Linear), while call stack (CallStack) maintains a map of per-module-id instances (wasmer::instance via WrappedInstance). Both MemoryHandler and CallStack are attributes of a Session. This is suboptimal, as both maps perform the same state logic on structures which partly overlap. It is potentially dangerous as the overlap is not explicit. Should future maintainers un-sync the state logic of both maps, not easy to diagnose memory problems that could start reoccurring. Hence, it is important to make the overlap explicit and maintain only a single map so that for a given module id it is obvious which memory and which instance belong to it.

Closed issues

transact_raw sometimes corrupts the stack on recursive calls #122

Transact raw sometimes leads to stack corruption when a module calls itself recursively. This is visible in the raw-calls-layout branch in this repository. The self_snapshot test will produce an out of bounds access to the heap, which happens due to the pointer to the raw transaction buffer being corrupted.


Closed issues

Derive Default for Signature and Proof #77

Citadel requires it for handling the License struct.


Closed issues

Add structures from rusk transfer-contract-types #116

Move structures from rusk transfer-contract-types into this crate as they are fundamental to the phoenix protocol and possibly reused by wallet-core.


Closed issues

Custom icons are not rendering #848

Icons don't render when they exist in the custom icons directory.


Closed issues

Node launch prerequisites #4

Currently, if the node software is installed, it gives you commands to run the node and view the logs. If you run the node, it'll always fail by default and tell you what steps to take next.

From a user experience point of view, it would be nice to give a number of pre-launch steps that need to be taken before a node can be run.

Update rusk wallet to 0.13 #5

Update the Rusk wallet CLI from v0.12 to v0.13 to incorporate some of the UX improvements we've made as of late.

Documentation #8

The repository currently makes no mention of how to use the installer.


Closed issues

Incorrect balances displayed while in headless #123

Operations like "balance" "stake-info" etc reports the amount of dusk displayed in LUX instead of DUSK.

Display activation block for a stake #124

When getting stake-info, the wallet should display the block at which this becomes eligible.

Display stake maturity epoch #128

We use epochs within a certain context, but do not clearly display what epochs we're in.


Open issues

Circuit shouldn't be required to be Default #715

A circuit shouldn't be required to be Default to satisfy the Circuit trait. The proposal is to remove said bound, and adjust accordingly.

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.


Closed issues

Fetch provisioners list from stake contract only if the list is updated #1479

GetProvisioners call consumes more than 4s (up to 15s on low-spec nodes) allegedly due to serialization in the VM. Although this is not supposed to be the case with the optimized VM (next version), this should be handled gracefully from client-side (Golang part).

GraphQL - expose raw transaction data#1481

Add a graphQL field to return the raw transaction binary.


Open issues

Update README with description of consensus phases #38

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

Closed issues

Make the example node compatible with (golang) consensus implementation #33

Rust test-harness driven by the (example) node has demonstrated stable results on any run. It reaches quorum/consensus up to 1000 rounds without any issues. However this test is completely isolated from the ongoing Devnet/Testnet. As an ultimate test-scenario, an example node should join the golang test-harness cluster and participate in consensus correctly.

Document all major implementation details in form of a README #36

The README file should cover/depict:

Implementation details:

  • HowTo set-up and run a consensus instance.
  • Consensus static/dynamic config params.
  • Usage of test-harness/example node.
  • Design details of consensus implementation/diagrams.
  • Overall component diagram of the example node.


Open issues

Migrate 'Clap' to V4 #778

Migrate rusk clap to v4.

Specify version for path 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 build everything normally.

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

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

Add the alltarget in the Makefile and separate it fromtest.

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.


Open issues

Make PoseidonBranch Copy #200

I would like that PoseidonBranch be made Copy, such that structures made including branches can also be made Copy. This is necessary to have proper default implementations of the dusk_plonk::Circuit trait for structures including arrays of branches.

Introduce Hash traits #202

I would like us to introduce Hash traits, for allowing for generic implementations of hashes producing BlsScalars.

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.

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.

Dusk-blockchain v0.6.1


  • Add raw field to GQL transaction object [#1481]
  • Add blocksrange filter to GQL transaction lookup [#1468]


  • Remove hardcoded genesis checks [#1464]
  • Remove provisioners list updates at every block [#1479]

Full Changelog: v0.6.0...v0.6.1



  • Derive Default for PublicKey

schnorr v0.12.1


  • Derive Default for Signature and Proof


What's Changed

  • Added documentation to the README by in #9
  • Change consensus participation check docs in #10
  • Add logrotate by in #11
  • Speed up block time in #12
  • Fallback listen address to public address in #13
  • Fix logrotate in #15
  • Prompt for setting consensus keys password in #14
  • Consensus pwd setup in #16

Full Changelog: v0.0.3...v0.0.4


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.

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