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
Node should not discard any sent transaction silently #1399
An interaction between mempool and the transactions performed on the blockchain led to transactions being discarded. A solution has been hypothesized and will be implemented to prevent loss of transactions.
Closed issues
Retrieving list of latest transactions is extremely slow (graphql endpoint) #1400
The retrieval and presentation of recent transactions depends on the number of transactions already present on the latest blocks. When blocks don’t have enough transactions to perform this action, the node will cycle through thousands of blocks to accumulate enough transactions. This is a very slow process. While this will not be an issue during real-world blockchain use, where transactions are plentiful, for testing purposes this issue needed to be remedied.
Sync up mempool state with the network on bootstrapping a node. #1258
A syncing issue between transactions in the mempool and the Kadcast library has been resolved, ensuring the most recent transactions are synced when restarting a node.
Register a vote locally before sending my own agreement #1383
This particular optimization concerns the consensus algorithm participants known as ‘committee members’. More information on the specifics of these members can be found here. In a nutshell, the agreement required too many ‘wire messages’ to be propagated. This number has been reduced.
Investigate node syncing bottlenecks #1380
At one point, we noticed that nodes were taking too long to sync-up to the rest of the network. As an example, catching up on 100,000 blocks would take 4 hours; an unacceptable amount of time. We pinpointed the issue.
Wrong reward in GQL #1390
Resolution of a miscalculation in the stake distribution reward.
Mempool should discard any transaction with repeated nullifier #1388
Security fix to avoid provisioners CPU waste. Any transaction with a nullifier already present in the mempool shall be discarded.
Handle the rejected transactions after a EST #1381
Both these issues concern a now-implemented optimization that prevents the mempool from unnecessarily using resources for block acceptance. It does so by verifying whether the nullifier of a transaction is already in use or not.
rusk-vm
Open issues
Merge master VM2 into the VM1 master #346
We’re promoting VM2 as the default branch for Rusk VM repository: this is the first step to deploy the new Virtual Machine in the coming next version of testnet.
VM2 replace hash mocker with proper hash #344
Port VM1 contract code behind link to VM2 and add state behind link in VM2 contract #333
In VM1, the hash from Canonical was used, which VM2 is set to move away from. A proper hash needs to replace the Canonical hash for VM2. However, hash options (such as blake2b) have caused slowdown, so other solutions are being considered. Additionally, the contract code issue is another efficiency consideration that’s set to be ported to VM2.
VM2 Out of Gas processing #342
When VM2 runs out of gas, an error should be displayed. This functionality for an Out of Gas scenario is still missing. A graceful and controlled (to the user) solution is being developed.
Ensure VM2 master candidate builds in CI #332
As mentioned above, VM2 goes well beyond an incremental update of the VM1 master. Some issues that arise need to be resolved from scratch; the CI build setup is one of those issues. A linkage problem that isn’t present in VM1, but can be resolved in VM2 through native library installations or the specifying of paths.
Research virtual memory access #327
Research into a possible improvement to contract function, ideally mitigating the need to unnecessarily copy a lot of data. However, a system must be in place to ensure the data that needs to be copied does get copied.
Introduce Event System #326
Ideal for debugging, development tracking, and a myriad of other uses, this suggestion for a new type of event log in the Virtual Machine would make improvements and resolutions much easier and well documented. This is currently being implemented.
Port VMError implementation improvements from VM1 to VM2 #329
Forward port from VM1 to VM2 #325
These particular issues argue that a series of improvements implemented in VM1 should be ported over to VM2. They’re currently awaiting final approval.
Measure contract storage usage #323
Contracts with large bytecodes use more storage, which drains resources. Ideally, a metering system, similar to a Gas Meter, is put in place to disincentivize large bytecode contracts and make them more efficient. The exact parameters and methods of measuring these metering points are currently being considered.
VM2: implement gas usage benchmarks for both VM2 and VM1 #322
Tangentially related, the actual gas usage for typical scenarios needs to have a comprehensive benchmark to ensure gas usage awareness, while also being able to compare VM1 and VM2 gas performance.
VM2: assess feasibility and performance of the dynamic scratch buffer implementation #321
Dynamic scratch buffer or static buffer solution? That is the question. VM2 would function with either. However, feasibility and performance must be considered. These considerations are currently being made
Closed issues
Assess and implement moving persistence functionality from Microkelvin to Rusk-VM #343
An issue concerning the addition of substantial host store persistence functionality (in essence, a memory/cache-related improvement) was resolved more easily than hypothesized. Instead of moving the bulk of host store persistence functionality to Rusk-VM, simplification of MicroKelvin achieved the same desired results.
Use singlepass compiler on Apple Silicon too #337
A compatibility improvement to streamline work towards Virtual Machine 2: a singlepass compiler that functions on both x86 architectures and Apple Silicon.
Test for recursive structures across sessions #312
A new element necessary to ensure persistence within the VM2. A ‘test runner’ is created which utilizes recursive data structures. In effect, it allows for tests to be run over multiple sessions, testing the correctness of the persistence logic.
wallet-cli
Open issues
Option to correct password / re-enter password #46
A simple user experience improvement, ensuring that a user who enters an incorrect password isn’t tasked with starting the process all over again.
Closed issues
Add Rusk version to gRPC request headers #43
For debugging purposes, it is important to have a clear idea of what version of Rusk you’re operating on. This simple addition ensures that the version is explicitly stated at all times, server-side.
New cache fails to start properly #39
An old database/new database overlap was causing issues with the cache. The old cache has been removed, resolving the issue.
plonk
Open issues
Fix the verification time #686
The excessive usage of the value 0 in public inputs destined for the transcript are expanding the verification times and the circuit size. By only using real public inputs, we’re confident we can optimize this process.
Closed issues
Rebase the repository to the original Plonk #684
Some necessary digital record keeping; ‘to rebase’ means to move (or combine) a sequence of commits/changes to a different designation. In this case, benchmarking PLONK & Poseidon and PlonkUp & Zelbet required some reorganization.
rusk
Two prover calls result in OoM in infra #715
When two concurrent calls to the prover service occur in a memory constrained environment, the result will be an OoM error. The worst case should be that the calls take longer to process, not an error message. By experimenting with the memory allocation, this issue is being resolved.
As you can see, development is continuous and this list is not exhaustive. For example, minor issues concerning the Schnorr, Hamt, and MicroKelvin elements 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.
Wallet-CLI | Release 0.9.0 & bls12_381 | Release 0.10.0
The wallet-cli repository has now advanced to version 0.9.0. As you can see, extensive development has been ongoing in other repositories (especially in regards to VM2), but the wallet-cli is still a focus for the Release Cycle, in addition to the bls12_381 releases which has advanced to version 0.10.0.
For those unaware, the wallet-cli is a Command Line Interface iteration of Dusk Network's wallet and a building block towards a more extensive and user friendly (Web) Wallet. The bls12_381 is an implementation of the BLS12-381 pairing-friendly elliptic curve group with extra features needed by our team; it is the foundation of nearly all ZK operations and the library we're using in Dusk Network. Everything is built on top of it, so any improvement on the bls12_381 repo will affect all our stack, especially in terms of performance.
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.
Wallet-CLI | Release 0.9.0
Added
Changed
- Commands run in headless mode do not provide dynamic status updates [#40]
All of the above topics concern closed issue #40: the ability to change between different modes within the cli-wallet. Namely, interactive mode & headless mode.
bls12_381 | Release 0.10.0
Added
- invert Scalar function signature [#78]
Changed
- Commands run in headless mode do not provide dynamic status updates [#78]
All of the above topics concern closed issue #78: the calculation of the inverse of a BlsScalar, which is expensive computationally and has now been significantly improved.
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.