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 these 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-blockchain
Open issues
Allow verifyFn to report errors correctly #1436
Currently, misleading VerifyFn errors are polluting the logs in the specific case of valid block acceptance. Said error should only be triggered for invalid candidate blocks.
Update README.md #1435
A call to arms for the tech team. Its rallying cry stating bluntly, “Why? Because it’s outdated."
Closed issues
Check redundancy factor in kadcast broadcast impl #1406
When broadcasting a Kadcast message, only 3 receivers should be detected. Over the past weeks, we’d been detecting 6 receivers instead. This issue has been resolved and defanged.
Detect any occurrences of missed fallback procedure #1413
If a consensus split occurred, a fallback procedure would initiate. If the procedure did not execute, a subset of the network of the wrong branch could reach quorum and accept another block. This discrepancy (and missed fallback) can now be detected, logged, and prevented.
Include the used block gas limit into the block header #1416
Make BlockGasLimit configurable #1418
Default config values are not loaded #1419
Improve mempool extraction #1421
These issues all concern the block gas limit. The block gas limit used to produce a block had previously been hardcoded. This limit is now configurable, allowing for the block producer to decide on the limit value themselves. This avoids resync issues when a new node joins the network after being compiled with a different block gas limit value. In addition, enhanced criteria have resulted in avoidance of unwanted gas limit scenarios.
Make consensus timeout configurable #1423
What first seemed to be a necessary adjustment of the consensus timeout configuration parameters was instead resolved when a bug was identified. The bug has been fixed and the consensus timeout is now configurable.
Drop topics.Block messages with invalid header.hash value #1425
Blocks received from the network were being processed even when the block.Header.Hash was invalid. Essentially, we needed to be able to detect if a received block originated from a fork. This has now been implemented.
Clean up deprecated dusk.toml configurations #1428
Spring cleaning! A number of configurations related to a deprecated or outdated features have been removed from configuration structures, profiles, and files.
Discard aggrAgreement messages with invalid StepVotes #1430
Check quorum target on certificate verification #1432
Additional checks and balances have been implemented to ensure wire messages are fully verified. Unless the so-called aggrAgreement from the wire is proven valid and the quorum target is checked, no winning block or certificate is created.
Clone message.Agreement on notifying the consumer #1433
In essence, this issue caused a data race to occur: multiple threads in a single process accessing the same memory location concurrently. This issue has been resolved, also resolving an error found on devnet.
dusk-ui-kit
Open issues
Add search filter to Table component #618
Users should be able to filter data in long tables. This new component would allow for a filter in the UI for mutating the content of the rows.
add row selection to Table component #622
When selecting a row, a visual cue will indicate to the user which row is currently selected.
rusk-vm
Open issues
VM2 Investigate Contract Code Size #374
Contracts within Virtual Machine 2 have grown in size when compared to Virtual Machine 1. While this issue is not currently a problem, it’s important to gather data for proper comparison, determine the reason for this growth, and ensure we’re able to influence and control the sizes of these contracts’ bytecodes for VM2.
Closed issues
Remove being able to set configuration #373
Initially, users of the Virtual Machine were given the ability to make certain adjustments to the configuration, which has now been replaced with a default configuration set. This was done to prevent compatibility issues and instances of indeterminism.
Make rusk-vm run on self-hosted CI server #316
A decision was made to transpose the Rusk Virtual Machine and have it run on our self-hosted CI server (Continuous Integration server, or build server) to improve performance. This has now been completed.
Design persist/restore interface between VM2 and its client, e.g. Rusk #319
The move from Virtual Machine 1 to Virtual Machine 2 means some parts of the backend are no longer supported. The previous backend code, which provided persistence and restoring capabilities, needed to be revisited for VM2. This has been achieved through a change in the construction and persistence of the NetworkState.
Measure contract storage usage #323
The Virtual Machine now measures the storage used per contract call. This is vital for the incentivization of efficient contracts, and also penalize overuse of storage space.
Remove state management #377
An efficiency change that puts the onus on the user to decide on whether to keep or discard a state when managing multiple states at the same time.
Refactor state management along with Rusk #357
This issue concerned the network ‘debt’ created by the act of persisting and restoring network state members. A refactoring has been conducted (read, restructuring of the existing code) that ensures Rusk VM and Rusk repositories are now properly aligned.
plonkup
Open issues
Include lookup gate in benchmarks #10
When a lookup gate is included in a circuit, it needs to be proven and verified that the gate is actually included in the lookup table. Doing so with larger lookup tables decreases performance. To find out more about this issue, we’re adding benchmarks to the circuit, with different size lookup tables.
Closed issues
Move plonkup code to plonkup repository #8
The PlonKup protocol used to be situated in the PLONK repository. With the closing of this issue, the PLONK repository only contains plonk code and the PlonKup code has been given its own repository.
wallet-cli
Open issues
Create Wallet lib and decouple CLI #54
Creating a wallet library that can be interfaced by any client. This means, not only will the current Wallet CLI be refactored to use the new library API, it will also open the door for a GUI (or any 3rd party software) to use it.
Test Strategy #53
Integration tests designed to evaluate the Wallet library are set to be implemented. This will ensure thorough testing and prevent previously resolved issues from arising once more.
Closed issues
The wallet-cli business logic should be testable #51
Previously, the Wallet CLI couldn’t be thoroughly tested because the business logic and binary were coupled, as opposed to the business logic being confined to its own library. This issue has now been resolved and integration tests can be performed.
rusk
Open issues
Enable logging in json format #725
Json provides a more practical alternative to the current log format, which utilizes colorized texts. Json will allow for clean, pre-tokenized formats for better automated observability.
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 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.
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.
Kadcast | Release 0.4.0
The Kadcast repository has now advanced to version 0.4.0.
Added
Removed
- `PeerBuilder` in favor of `Peer::new()`
Fixed
Wallet CLI | Release 0.10.0
The Wallet CLI repository has now advanced to version 0.10.0.
Added
- Add src/bin to gather the module related to the I/O ops [#51]
- Add autobins to Cargo.toml to prevent bins auto discovery [#51]
- Add [lib] and [[bin]] sections to Cargo.toml to decouple bin and lib [#51]
- Add src/bin/io to gather all modules related to I/O [#51]
- Add status mod as temp workaround to make the lib compile [#51]
- Add actions mod with all the actions previously in main [#51]
Changed
- Rename src/mod.rs to src/lib.rs to be compliant with 2018 edition [#51]
- Refactor main to be more readable [#51]
- Update imports in the code to reflect the new files structure [#51]
Assets
The Wallet CLI source code has been updated on our release page: https://github.com/dusk-network/wallet-cli/releases/tag/v0.10.0
In addition, the latest versions of the CLI Wallet for MacOS & Linux have also been uploaded for general download.
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.