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.
ModuleError enum has Archive derivation but lacks CheckBytes derivation, which is causing serialization to fail in Rusk.
Move structures from rusk transfer-contract-types into this crate as they are fundamental to the phoenix protocol and possibly reused by wallet-core.
Add a new props to the Table component that will:
- disable the highlight on selected rows
- disable the style pattern on rows
- add delimiter lines between rows
Add a new prop that allows the user to change the radius of the pin used on the Map Chart.
When having unlocked the provided wallet, it crashes on retrieving the balance of the first address.
It is important to NOT access any other address. Doing so will fix the issue as a workaround.
Current linux wallet-cli release is built on ubuntu-latest (ubuntu-20.04) that uses libssl.1 shared library.
In order to let the wallet-cli run on OS that target the latest libssl version (like ubuntu-22.04) a new target should be added.
Provisioner keys are currently exported with the .key extension, while the node configuration expects a provisioner key-pair with the .keys extension. To prevent ambiguity and confusion, it makes sense to align the extensions to the correct .keys extension.
The default gas limit is currently set to 500M LUX. For transfer operations this is sufficient. For other operations like staking and unstaking this leads to out of gas transaction failures. Users need to explicitly set a correct value.
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.
Missing block detection #1470
Logging of missed and produced blocks in base58, along with the public key belonging to the provisioner.
Add benchmarks for the merkle-opening circuit
- Circuit compilation
- Proof creation
- Proof verification
We need benchmarks in order to track performance throughout the development.
We need benchmarks in order to track performance throughout the development.
Create benchmarks for:
- ZK Merkle opening.
- PoseidonCipher ZK and non-ZK.
In the direction of having both Golang and Rust implementations working together in one cluster, we should be able to preload the same list of provisioners (so called genesis state provisioners) in rust example node
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.
Current serialization of consensus messages (NewBlock, Reduction, Agreement) does not match fully the serialization of the dusk wire protocol.
Migrate rusk test infrastructure to make use of piecrust instead of rusk-vm. This will allow rusk to be faster at executing contracts, and use less disk space - together with a number of other improvements, i.e. less gas per TX.
Upgrade kadcast #771
The new kadcast version uses a better error handling while processing UDP packets.
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.
Wallet-cli - v0.13.0
The wallet-cli repository has now advanced to version 0.13.0
- Changed fn signature in gas::new to include the gas limit [#116]
- Change request_gas_limit fn signature to accept a gas limit option [#116]
- Change (un)stake, allow stake and withdraw default gas limits to sane defaults [#116]
- Change exported consensus keys extension to .keys [#114]
Itn-installer - v0.0.2
The itn-installer repository has now advanced to version 0.0.2
- Fixes and improvements in #1
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.