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.
dusk-blockchain
Open issues
Prevent "ghost" provisioners #1448
Implement a mechanism to prevent "ghost" provisioners to keep participating in the consensus.
Blacklist malicious nodes #1451
A mechanism for a node to stop receiving messages from well-known malicious nodes, to prevent malicisous messages to be received and trigger DOS attacks.
Evaluate efforts needed to migrate consensus from golang to rustlang #1554
Build a rust lib that encapsulates a rust implementation of golang package. This could be a major step toward having dusk-blockchain repo fully implemented in rustlang.
Old transactions not visible in block explorer #1455
Block explorer does not show older transactions in the block explorer.
Closed issues
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.
Investigate a lost quorum at first iteration when network is busy #1444
In rare cases, it was noticed that there could be a sudden increase in consensus time due to a failure to reach quorum at iteration 1.
Verify block certificate prior to broadcast #1446
On receiving a block from Kadcast network, we used to fully verify it before re-propagating it to the next bucket. Now to speed up block broadcast to all provisioners, we re-propagate it without any checks.
Propagate metadata through message lifecycle #1452
In order to implement malicious node detection, dusk-blockchain phases should be aware of the message sender.
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.
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
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.
Closed 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.
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.
Logging capabilities with customizable log_level and log_type #11
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.
Wallet CLI Release 0.11.0
The Wallet-cli repository has now advanced to version 0.11.0.
Added
- New public Wallet struct exposing all wallet operations as library #54
- New Address type to identify and work with addresses #54
- Logging capabilities with customizable log_level and log_type #11
Changed
- Project is now a public facing library #54
- Our reference implementation is included under src/bin #54
- UX flow is now address-based to match that of the web wallet #59
- Anything that's not strictly program output is redirected to stderr #11
BLS12_381 | Release V0.11.0
The BLS repository has now advanced to version 0.11.0.
Added
- Add rkyv-impl feature
- Add implementation of CheckBytes
Changed
- Move rkyv-related implementations behind the rkyv-impl feature
Removed
- Sized bound from G2Prepared rkyv::Serialize implementation #94
JubJub | Release V0.12.0
The JubJub repository has now advanced to version 0.12.0.
Added
- Add CheckBytes implementations on rkyved structures
- Add rkyv implementations on structures #95
Changed
- Update dusk-bls12_381 to version 0.11
Plonk | Release V0.12.0
The Plonk repository has now advanced to version 0.12.0.
Added
Changed
- Fix math latex rendering on docs.rs #567
- Update dusk-bls12_381 to version 0.11
- Update dusk-jubjub to version 0.12
Hades252 | Release V0.19.0
The Hades252 repository has now advanced to version 0.19.0.
Added
- Update dusk-bls12_381 from 0.8 to 0.11
- Update dusk-plonk from 0.9 to 0.12
Poseidon252 | Release V0.26.0
The Poseidon252 repository has now advanced to version 0.26.0.
Added
- Add rkyv implementation behind feature gate #175
Fixed
- Fix module injection for tree and cipher modules
Dusk-pki | Release V0.11.0
The Dusk-pki repository has now advanced to version 0.11.0.
Added
- Add rkyv implementations behind feature gate #66
- Add PublicKey::from_raw_unchecked and StealthAddress::from_raw_unchecked #63
Changed
- Update dusk-jubjub from 0.10 to 0.12
- Update dusk-poseidon from 0.24.0-rc to 0.26
- Update canonical from 0.6 to 0.7
- Update canonical_derive from 0.6 to 0.7
- Update StealthAddress::R and StealthAddress::pk_r to const fn #63
Phoenix-core | Release V0.17.0
The Phoenix-core repository has now advanced to version 0.17.0.
Added
- Add CheckBytes implementation to rkyved structures
- Add rkyv implementations behind feature gate #107
Changed
- Update dusk-bls12_381 dependency to 0.11
- Update dusk-jubjub dependency to 0.12
- Update dusk-poseidon dependency 0.26
- Update dusk-pki dependency 0.26
- Update nullifier to hash of pk' #96
Schnorr | Release V0.11.0
The Schnorr repository has now advanced to version 0.11.0.
Added
- Add CheckBytes impl for rkyved structs
- Add rkyv implementations behind feature #69
Changed
- Update dusk-poseidon from 0.23.0-rc to 0.26
- Update dusk-pki from 0.9.0-rc to 0.11
- Update dusk-plonk from 0.9 to 0.12
- Update dusk-bls12_381 from 0.8 to 0.11
- Update dusk-jubjub from 0.10 to 0.12
- Update canonical from 0.6 to 0.7
- Update canonical_derive from 0.6 to 0.7
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.