Testnet DayLight | Release Cycle Update #11


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.


Closed issues

Implement deploy_with_id #108

Modules should be deployable with a ModuleId defined by the host. This
is necessary for enabling modules whose IDs are known prior to

Move deployment of modules to Session level #111

Currently the deployment of modules happens at the level of the VM
struct. This is undesirable since this means that a deployment is
“global” - meaning for all sessions. All changes of VM state should be
done via a Session and subsequent commitment.

Make Session borrow a mutable VM instead of cloning #113

At the moment, the VM is cloned into the session, this makes the API a
bit confusing, since it’s unclear what commiting the session actually


Closed issues

The dusk-poseidon dependency should be updated to version 0.28. This is
necessary to make use of the fixes and improvements made there, together
with the one made in dusk-plonk.


Closed issues

Remove unnecessary expect/unwrap #115

The codebase is full of unwrap/expect.

Implement network blocklist #117

Add the possibility to block specific peers


Closed issues

CI Action takes too long to execute #250

CI Action regularly takes > 5 mins to complete. This is too long given
the scope of work it does.

OS preference for dark mode is overriding user-preference for light mode

When the user has dark mode preferred on their operating system, but
changes to light then this preference will be overwritten when they
change to another app.

Reinstate Draw component #735

This is needed for developing applications with slide-out sidebar menus.

add DropDown scrollable options list #758

Add functionality to the DropDown component that will allow the list of
options to be scrollable and with a fixed length. This should be turned
on and off based on a new prop.

Toggle component breaks the web #763

We can’t set value attributes on Toggle components (e.g. radios and


Open issues

Expose rusk client to construct a wallet instance #108

To construct a core wallet instance, we need the rusk client struct to
connect to the network,
It needs to be pub instead of pub(crate)

Make install fails #110

\Cloning the repo and installing the wallet on my PC using the command
“make install” fails with the following logs:

cargo b –release

process_begin: CreateProcess(NULL, cargo b –release, …) failed.

make (e=2): The system cannot find the file specified.

make: *** [Makefile:5: build] Error 2


Open issues

Prover and Verifier are **not** type-safe #713

While these structures are type-safe while in memory, the moment they’re
serialized and subsequently de-serialized, they cease to be so. This
means that it is possible, for example, to de-serialize a Verifier<C1>
from a payload of Verifier<C2>with C1 != C2.


Open issues

Missing block detection #1470

Logging of missed and produced blocks in base58, along with the public
key belonging to the provisioner.


Open issues

Make serialization of consensus messages fully compatible with dusk wire
protocol #22

Current serialization of consensus messages (NewBlock, Reduction,
Agreement) does not match fully the serialization of the dusk wire

Closed issues

Use a cached version of BLS public keys compressed form #18

The implementations of PartialOrd and Ord of PublicKey wrapper are based
on the CPU-intensive dusk_bls12_381_sign::PublicKey::pk_t()::to_bytes().
This was spotted as a bottleneck on CPU profiling. To avoid frequent
serialization into compressed form (to_bytes) , a cache field should be
used instead.

Implement an example node that runs consensus in a Kadcast network #19

An executable that integrates both consensus and kadcast libraries
should be built as an example node. This node binary should accept a CLI
param of a provisioner unique ID.

Due to the lack of a genesis block, on start-up the example node is
supposed to generate up to N provisioners (also a CLI param) with
deterministic seeds (from 0 to N).

Additionally, this task should provide a Makefile target/Bash script
that can set up and run a test-harness of N nodes. Eventually, this
could turn into github action and serve as an end-to-end/system test.
This bash script may also deprecate the current single-process testbed.

Wrong serialisation of BlsPublicKey #20

Current codebase uses pk.pk_t().to_bytes() instead of pk.to_bytes()

Use and apply default rustfmt max_width #25

we should re-format all files with rustfmt.toml, max_width = 80.


Open issues

The circuits should be ported to use plonk version 0.13. The API has
changed significantly and numerous improvements in terms of speed and
memory efficiency have been made. It is better if our networks can make
use of them.

Closed issues

Port rusk-abi to be compatible with piecrust-uplink #761

Currently our smart contracts use rusk-abi which essentially wrap the
dusk-abi with specifics such as hashing, hardcoded contract addresses,
etc… This means this crate needs to be ported before the smart contracts
for them to work.

Migrate to piecrust #765

We should port rusk to use piecrust instead of rusk-vm. This is
necessary to make full use of the new contract ABI and the improvements
to speed and disk-space efficiency provided by piecrust.

CRS is not created #767

rusk-recovery-keys doesn’t create the common reference string.

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

Bls12_381__ - v0.11.2

The Bls12_381 repository has now advanced to version 0.11.2


-   Fixed rkyv-impl feature by bringing in rkyv/alloc on alloc feature
-   Make g1 and g2 Archived* structs only available on rkyv-impl

Plonk -  v0.13.1

The plonk repository has now advanced to version 0.13.1


-   Remove manual implementation of CheckBytes for ArchivedProverKey.
   is necessary since rkyv/validation was required as a bound.

dusk-pki - __v0.11.2__

The dusk-pki repository has now advanced to version 0.11.2


-   Update dusk-poseidon from 0.26 to 0.28

Poseidon252 -v0.28.0

The Poseidon252 repository has now advanced to version 0.28.0


-   Update dusk-plonk from 0.12 to 0.13
-   Update dusk-hades from 0.19 to 0.20

schnorr -  v0.13.1

The schnorr repository has now advanced to version 0.13.1


-   Update dusk-plonk from 0.12 to 0.13
-   Update dusk-poseidon from 0.26 to 0.28

FAQ __

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