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.
After the publication of our previous Release Cycle update, we noticed that the community was under the impression that these blog updates will detail any and all technical progress made by our development team over the past three weeks. This wasn’t the case.
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, with the majority of publishable releases finalized in the past three weeks occurring within the wallet-cli repository. This means that reporting about the repository is relevant, as the community will soon be able to test these features.
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, this time we’ve chosen to add a selection of some (but not all) of the work that is being done in our repositories, including recent advancements.
dusk-blockchain
Open issues
Register a vote locally before sending my own agreement #1383
This issue concerns an inefficiency in the Provisioner Committee process, a key part of the consensus mechanism. It’s currently being resolved.
Handle major version upgrades #1382
Software for node runners will be subject to upgrades and improvements over time. To ensure these mandatory updates are user-friendly and as automated as possible, notifications need to be implemented. The resolution of this issue will ensure that.
Investigate node syncing bottlenecks #1380
The synchronization of the active nodes is currently being hampered by an inefficiency in the node/network interaction. Resolving this issue will greatly improve the efficacy of user-run nodes once onboarded.
Closed issues
Optimize VST calls of a Provisioner per a consensus iteration #1371
Fix Consensus Max Step in Agreement verification #1375
The state_root on candidate block verification is not verified #1377
Check quorum per each reduction step on agreement message verification #1373
Each of these resolved issues optimize and/or resolve inefficiencies within the block verification process.
plonk
Closed issues
Assert in logic gate fails for larger input #678
A specific type of larger sized input caused a failure in the code’s logic gate. This issue has been fully resolved and no longer troubles the PLONK Zero-Knowledge Proof system.
Change variable to witness in permutation functions #681
Not all coding and documentation is paradigm shifting; in the case of this issue, all mentions of Variable in the refactor of PLONK had to be renamed to Witness. To avoid confusion, this change has been made in full.
rusk
Open issues
rusk: RuskState drops unstaged commits too aggressively #713
By design, unstaged changes to the RuskState are dropped or discarded once an instance goes out of scope. However, this issue is currently set to parameters that are too aggressive, capable of discarding unstaged changes even when in the middle of execution.
Allow to include an arbitrary state within rusk-recovery #711
The inclusion of a so-called ‘arbitrary state’ within rusk-recover would allow for multi-cluster selection. To make this happen, the state should be created at build time and then included in the recovery tool, as opposed to it being created when the rusk recovery tool is run.
Closed issues
Stream notes in GetNotesOwnedBy call #702
This particular streaming issue was causing large memory usage due to the syncing of wallets. This also led to out of sync nodes. These issues are now resolved.
State transitions (EST, VST) should fail if one tx is invalid #704
This concerns a suboptimal logic that would waste CPU cycles with transactions that can’t have the gas paid if it checked the validity of a block without checking if the nullifiers are unique. This could also allow for an attacker to pre-generate a number of transactions with the same nullifier and flood the network with them. This exploit has been resolved.
Allow to build rusk-recovery-state without contracts build prerequisite #706
The resolution of this issue allows for the building of rusk-recovery-state without build contracts, which in turn aids testing as it no longer requires the state to be built from scratch; the published one can be used instead.
rusk-vm
Open issues
Implement as-is state persistence for VM2 #318
Within the upcoming Virtual Machine 2, the state of a contract is stored in an array of bytes (a ‘state’) and in the host store. The interaction between these two elements is to be streamlined through a so-called ‘as-is state persistence’. This implementation is vital to reduce memory consumption significantly. An advanced tech description of this issue and the hypothesized resolution can be found through the link.
Design persist/restore interface between VM2 and Rusk #319
Virtual Machine 2 makes major changes/improvements to the previous Rusk VM. One of these alterations has necessitated an in-place update of state storage & a redesign of the persist/restore interface between Rusk and the new VM2.
As you can see, development is continuous and this list is not exhaustive. The complete series of repositories can be found on GitHub. The Release Cycle updates are a great way to stay up-to-date on the latest releases in full, focused on individual repositories.
Breakthrough developments will receive a separate spotlight detailing their importance in the tech stack. 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.
Wallet-CLI | Release 0.8.0
The wallet-cli repository has now advanced to version 0.8.0. This Command Line Interface iteration of Dusk Network's wallet is a building block towards a more extensive and user friendly (Web) Wallet and a key point of interaction for the community. The below noted additions/changes to the repository can be followed to GitHub for further details on their status and their function in the stack.
Added
- Block trait for easier blocking on futures [#32]
A wallet syncing improvement that takes some of the burden off of Rusk, as the previous method became quite taxing on Rusk when syncing from genesis. - Withdraw reward command [#26]
The staking contract has been updated to allow for withdrawing funds separately from the act of unstaking. Wallet functionalities such as these are being improved upon continuously.
Changed
- Upgraded cache implementation to use microkelvin instead of rusqlite [#32]
- Use streaming GetNotes call instead of GetNotesOwnedBy [#32]
The two changes noted here allow for the addition of the ‘block trait for easier blocking on futures’ addition mentioned prior. In this case meaning, a wallet syncing improvement. - Enhance address validity checks on interactive mode [#28]
Due to the fact the character a can be decoded from the base58 encoding scheme, wallet users were able to input random characters as a single a was considered a valid address. This issue has been resolved. - Prevent exit on prepare command errors [#27]
User Experience improvement that prevents an undesired wallet exit. - Adapt balance to the new State [#24]
An issue arose in the wallet’s balance retrieval, where the balance appeared as doubled if the cache was deleted. This has been remedied. - Rename withdraw-stake to unstake [#26]
To avoid confusion with the withdraw reward function, withdraw-stake is now renamed unstake - Introduce Dusk type for currency management [#4]
A temporary resolution to the need of a proper type for DUSK currency. This will be replaced by the Virtual Machine 2 structures at a later date.
Fixed
- Fix cache bug preventing adding all notes to it [#35]
- Fix address validation by parsing address first [#35]
Addresses previously printed would fail input validation in the wallet. Thanks to these fixes, an address printed will now always be valid and pass validation.
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.