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.
Modules should be deployable with a ModuleId defined by the host. This is necessary for enabling modules whose IDs are known prior to deployment.
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 changes.
Upgrade to [email protected] #114
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.
Remove unnecessary expect/unwrap #115
The codebase is full of unwrap/expect.
Implement network blocklist #117
Add the possibility to block specific peers
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 #538
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.
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 checkboxes).
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, https://github.com/dusk-network/wallet-cli/blob/main/src/wallet.rs#L279. 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
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.
Missing block detection #1470
Logging of missed and produced blocks in base58, along with the public key belonging to the provisioner.
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 protocol.
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.
Port the transfer circuits to [email protected] #764
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.
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 stack.
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. This
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
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.