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 al) of the work that is being done in our repositories, including recent advancements.
dusk-blockchain
Open issues
A call to arms for the tech team. Its rallying cry stating bluntly, “Why? Because it’s outdated."
Mitigate the occurrences of 'failed to receive candidate' error #1438
Currently, failed to receive candidate from the network" error is reported many times per a node. As an edge case in consensus, this is not a critical issue. However we may try to optimize it and reduce the chances of it happening.
Repropagate unvalidated messages #1440
Any message that cannot be validated should be repropagated. Right now, a network message is repropagated only if it's valid. This means that during the syncing up phase, any "live" message is discarded interrupting the network dissemination.
Investigate consensus delay when mempool is full #1441
We are experiencing block time (40-50 seconds) above the average (8seconds throttled) when the mempool is full. Atm, the block gas limit is set to ~3B, this means that we have 9-10 transfers per block. In this case, EST calls took up to 4 seconds, and VST/Accept calls took 2-3 secs.
Investigate and solve newblock msg errors #1443
Error "newblock msg is not signed by a block generator" is reported by devnet. This may happen if the seed has changed while sortition is running but more data is needed to confirm the hypothesis.
Closed issues
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.
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.
dusk-ui-kit
Open issues
Add row selection to Table component #622
When selecting a row, a visual cue will indicate to the user which row is currently selected.
Closed 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.
Create a MessageBanner component #625
A banner that spans 100% of the page, that is needed to announce messages to our users.
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 penalise overuse of storage space.
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.
wallet-cli
Open issues
Observations from two users sending batches of transactions for a while #60
Often: Insufficient balance to perform this operation, Often: Rusk returned an error: Nullifier(s) already exists in the state Rarely: Rusk returned an error: Proof verification failed.
The UX should be consistent with the Web Wallet UX #59
The current user experience in the wallet cli is totally different from the one provided by the web wallet. We should provide a consistent user experience across the dusk wallets apps.
Cache-related, persistent crash after sending two batches of transactions in short time #58
Send batches of transactions from a single wallet with a simple script. It works well if waiting for all calls to finish, but leads to a persistent error if executing the batch script before the last one is done.
Better configuration file for the wallet to specify multiple network (devnet / testnet) end points in order to properly store the cache and make the wallet connect to different net.
Currently there is only one global cache despite the network (devnet, testnet) and the wallet's addresses.That lead to bugs if the users switch network and/or wallet's addresses.
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.
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
Closed 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, 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.
Kadcast | Release 0.4.1
The Kadcast repository has now advanced to version 0.4.1.
Added
- Remove idle nodes during bucket mantainance #108
Fixed
BLS12_381 | Release V0.10.1
The BLS repository has now advanced to version 0.10.1.
Added
- rkyv implementation behind feature gate #90
- Derive Hash for BlsScalar
- Apply patches from zkcrypto to improve the efficiency #86
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.