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.
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.
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.
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).
The Navbar component needs to support networks and navigation as additional props and render the appropriate UI when these values are set.
The underlying date library (dayjs) throws errors relating to commonJS loading. Attempts to exclude the library from the optimized dependencies have failed.
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.
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.
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.
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.
Tools for debugging running modules.
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).
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.
To let the user understand how to configure the wallet's network – however the default values are the one used the most.
The prover and state server should have the capability to have different ipc methods.
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.
This is required in order to support by dusk-network/rusk#732.
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.
The argument refund_addr for the withdraw command has the following description:
"Address to which the reward will be sent to"
Implementing anyhow and this error into the error handling.
gas.is_enough() will always return Error::NotEnoughGas.
Recovering a wallet works but prints an unexpected message at the end.
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
Direct the user to create one single wallet, instead of multiple wallets.
A better configuration file for the wallet.
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.
After that rusk is able to get a custom state as input [#734] there is the need to generate such a state.
rusk-recovery should be able to receive a struct containing the desired state
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.
An on-chain mechanism to handle staking allowlist.
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 to check for the index bits in our merkle opening circuit.
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.
Update CHANGELOG #191
Some versions are not properly tagged and fix other minor issues.
The rkyv-related traits should be implemented for PoseidonBranch, and the resulting types be made public.
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.
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.
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.
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.