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.
dusk-ui-kit
Open issues
Create a new atom component that presents text in a Badge.
The Badge must support a standard set of variants: 'success', 'warning', 'danger' and 'brand'.
This is needed for developing applications with slide-out sidebar menus.
Add cms-connector models and schemas in published UI Kit #719
The models and schemas that are generated and maintained in the cms-connector repository are to be published with the UI Kit packages. This can be achieved by removing the private property from the package.json.
Improve and expand test coverage #715
The goal is to increase the number of tests that we run on the components. This will result in the ability to see property values changing and testing for the correct output. Testing for visual differences can also be explored with Chromatic (or alternative, if deemed more suitable).
Closed issues
Navbar needs to support networks and navigation props #712
The Navbar component needs to support networks and navigation as additional props and render the appropriate UI when these values are set.
DateText component throwing errors #737
The underlying date library (dayjs) throws errors relating to commonJS loading. Attempts to exclude the library from the optimized dependencies have failed.
dusk-blockchain
Closed issues
Remove genesis consistency checks #1464
At the moment of writing, dusk-blockchain repo is used to hardcode the values of rusk's state-root and the derived genesis-hash.
These were introduced in order to mitigate the possibility of being error-prone after a breaking change upgrade.
Since we introduced the protocol and rusk versions, the genesis consistency checks should not be required anymore.
hatchery
Open issues
Panics should propagate to the caller #79
When performing an inter-contract call, a panic occurring in the called module should inform the caller that the module panicked, as opposed to stopping the execution.
This ensures the calling module is able to handle panics of modules whose code it has no control over.
Missing features and improvements #76
This issue is meant to describe the things still missing from this VM implementation vs. the previous implementation at rusk-vm, and remaining necessary improvements.
Closed issues
At the moment weealloc is hardcoded in the uplink communication library, this is unnecessarily restrictive and it should be up to module authors to choose allocation strategy.
Provide debug information to be easily used in modules. #53
Tools for debugging running modules.
wallet-cli
Open issues
Implement interactive mode for staker allow transaction #98
Since #85 is merged, we should allow the user to do the same operation in interactive mode
By Providing the user with more specific error context, the reason why the program fails will be more understandable for the non(technical) user(s).
Notify the user if he tried to create more than 256 addresses for one wallet #92
We decided to support a maximum of 256 addresses for each wallet (seed), however there is no error message once the user reaches such a limit.
Document more in detail the configuration for multiple networks #89
To let the user understand how to configure the wallet's network – however the default values are the one used the most.
Prover and State server should have the capability to have different ipc method #77
The prover and state server should have the capability to have different ipc methods.
Closed issues
no cancel option available #97
When an action is initialized, users can't cancel it. The only possible way to come back is to close the wallet, reopen it, unlock it, then retry the action.
Implement stake allow command #83
This is required in order to support by dusk-network/rusk#732.
Quit program if 3 times wrong recovery phrase is given during recovery process #49
The program should quit after 3 times a wrong phase phrase
If the user is not able to fill in the correct recovery phrase, the program will exit
Option to correct/ re-enter password if 3x wrong recover wallet #46
Implement an option to correct the password / re-enter password.
Wrong refund_addr description #86
The argument refund_addr for the withdraw command has the following description:
"Address to which the reward will be sent to"
Implement anyhow and thiserror #87
Implementing anyhow and this error into the error handling.
Wrong condition involved `gas.is_enough() #91
gas.is_enough() will always return Error::NotEnoughGas.
Restoring a wallet prints an unexpected message #78
Recovering a wallet works but prints an unexpected message at the end.
BLS keys exported with wrong extensions #84
When exporting the bls keys, 2 different file should be produced
- .key - Encrypted BLS key pair for provisioners in dusk-blockchain compatible format
- .cpk - Binary file with the Consensus Public Key
Currently, the extensions are switched
Move focus to single wallet creation #72
Direct the user to create one single wallet, instead of multiple wallets.
A better configuration file for the wallet.
rusk
Open issues
Use tar to handle state's compression instead of zip #740
Our servers are *nix base and there is no reason to use zip instead of tarball files, plus the ergonomics of the tar crates is better than zip crates.
Allow to export a state from rusk-recovery #738
After that rusk is able to get a custom state as input [#734] there is the need to generate such a state.
Closed issues
Instruct rusk-recovery to generate custom genesis state #737
rusk-recovery should be able to receive a struct containing the desired state
rusk: Allow to run rusk in "ephemeral" mode #734
Rusk should be able to run in a sort of ephemeral mode, deleting every change applied to the state after it quit.
This means that if the user launches rusk twice in a row using this custom state, any change performed by the first execution should be discarded.
In addition, the user should be able to pass a "custom" state to use (without using a different rusk_profile_dir). The custom state should be a single file.
stake-contract: implement allowlist #732
An on-chain mechanism to handle staking allowlist.
Poseidon252
Open issues
Store the root of a branch separately to the levels #189
At the moment the root of the PoseidonBranch is stored in the last level of the branch at index 1. Ideally we want the root stored separately to the levels and not as an additional level.
This is also an issue due to the rkyv implementations. Since it is now a Vec, PoseidonBranch<17> would parse in the exact same way as PoseidonBranch<16> for example.
Use component_boolean in the our merkle opening circuit #188
Use component_boolean to check for the index bits in our merkle opening circuit.
Restructure crate features #184
The features of a crate should be named according to the features they enable, and not the names or technicalities of its dependencies. I propose a restructuring of the features of this crate.
Closed issues
Update CHANGELOG #191
Some versions are not properly tagged and fix other minor issues.
Implement rkyv for PoseidonBranch #186
The rkyv-related traits should be implemented for PoseidonBranch, and the resulting types be made public.
Fix merkle opening circuit #181
Fix the merkle opening circuit and add tests that catch this in the future. For people using the repository please be aware of this fix.
PoseidonTree is only available behind canon #180
The PoseidonTree struct - one of the main features of this library, and a very important component for the genesis contracts - is only available behind the canon feature.
This means to write a smart contract one is required to bring in the canonical library even though this is in principle not required.
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.
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 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.