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.
plonk
Question for the method "coset_fft" #692
A general inquiry to the tech team to pinpoint the source of a bug in the code.
plonkup
Apply patch from Plonk to fix the verifying time #2
Apply patch to fix a circuit compilation error #4
Two bugs common in Plonk have now been resolved in PlonKup.
Move Plonkup code to Plonkup repository #8
Update CHANGELOG #6
As we continue to reconcile Plonk with PLOOKUP, you’ll be seeing more administrative spring cleaning in regards to PlonKup to ensure all the repositories reflect the latest implementation of the proof system.
dusk-blockchain
Include the used block gas limit into the block header #1416
The block gas limit used to produce a block is currently hardcoded. However, it should be decided by the block producer, as to avoid resync issues when a new node joins the network after being compiled with a different block gas limit value. To resolve this issue, we’re moving from the hardcoded value to a configuration value, to be used as the gas limit only when producing a block.
Detect any occurrences of missed fallback procedure #1413
If a consensus split occurs (a rare occurrence, but one that should be taken into account), a fallback procedure will initiate. If the procedure does not execute, a subset of the network of the wrong branch may reach quorum and accept another block. This discrepancy (and missed fallback) should be detected, logged (see image below), and (ideally) prevented.
Investigate stake contract inconsistency #1408
A discrepancy between the state_hash of two nodes warranted attention, but the changes to be implemented alongside the upcoming Virtual Machine 2 are expected to resolve the issue. At the moment, this issue is open but on hold until then.
Check redundancy factor in kadcast broadcast impl #1406
When broadcasting a Kadcast message, only 3 receivers should be detected. However, we’re currently detecting 6 receivers. This issue is currently being resolved.
Reduce occurrences of firststep_verifyCandidateBlock warnings #1405
Although the cause of this issue can be found detailed on GitHub, the main issue is simple: an excess of error/warnings are polluting the log files. The issue is being investigated and the abundance of notifications is being addressed.
Mitigate pressure on socket send buffer #1402
Some one-to-one Kadcast messages are getting lost. Multiple options are being considered to fix this issue.
Closed issues
Investigate lost transactions on mempool state resync #1399
An interaction between mempool and the transactions performed on the blockchain led to transactions being discarded. This issue has been resolved.
Recover provisioners set upon a complete fallback #1409
A so-called ‘fallback’ is a contingency option that’s followed if the preferred choice is not available. Essentially, it details what the code needs to do if the request cannot be fulfilled. In this particular case, one of the fallback options now properly updates the provisioners on the chain.
Trace counts of both eligible and non-eligible provisioners #1411
Certain elements of provisioner (node) activity need to be properly logged. For instance, this part of the code detailed the length of all network provisioners. Now, after the resolution of this issue, it also shows the number of eligible provisioners for the round of the final accepted block.
Tune block gas limit #1415
To more easily and effectively test the block limit in a running cluster, we’ve lowered the block gas limit to allow for 20 transfers per block as opposed to the ~10.000 limit in place previously, for testing purposes.
rusk-vm
Open issues
Implement contract bytecode capacity beyond 64k #350
The persistence mechanism in the Virtual Machine currently supports contracts with bytecodes up to 64k. To properly scale, the VM will need to be able to persist and restore contracts with bytecodes of any size. Options are being considered, including increasing the capacity of Microkelvin (the toolkit engineered for implementation of zero-knowledge data structures) to handle nodes beyond 64k.
Remove fn init() {} from contract proc macros #356
A clarity issue. Every contract requires, for code generation purposes, an empty notation of fn init(). There are more efficient ways to handle this; ways that will reduce clutter and the possibility of leaky workarounds.
Refactor persist/restore state management along with Rusk #357
This issue concerns the network ‘debt’ created by the act of persisting and restoring network state members. A refactoring (read, restructuring of the existing code) that properly aligns the Rusk VM and Rusk repositories should resolve this issue.
Upgrade wasmer dependency #351
The current version of the Virtual Machine (which uses the deserialization framework rkyv) utilizes the wasmer 2.0 runtime software. However, a later version (2.3) is available which offers numerous compatibility benefits, such as singlepass compiler working on Apple Silicon. This upgrade has now been implemented.
forward-port: VM1 gas fix to VM2 #362
forward-port: placing bytecode behind link from VM1 to VM2 #363
forward-port: dusk-hamt test from VM1 to VM2 #364
These three resolved issues address feature parity between Virtual Machine 1 and Virtual Machine 2; key developments in the transition to VM2.
wallet-cli
Open issues
Option to correct/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.
Add option to return to an overview of your wallets #48
Give the user the option to exit program while recovering wallet #49
These issues concern self-explanatory user experience improvements.
rusk
Bump transfer-circuits version #719
A discrepancy in versions was discovered. The improper documentation of the necessary bump on GitHub of transfer-circuits to 0.5.0 has been noted and will be updated.
Enable gRPC tracing logs #722
Proper logging of code is vital to future bug resolutions. In this specific case, enabling gRPC tracing logs allows us to properly time the execution of each dusk-blockchain repository request among tech developers. In addition, it will allow for the investigation of block time issues related to the new lock mechanism.
Closed issues
Lower the prestaked nodes to 5 #720
Lowering the number of pre-staked provisioners to five will allow the test-harness to function properly in machines with lower-than-recommended technical capabilities.
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. Our scaling mechanism has resolved this issue.
rusk: RuskState drops unstaged commits too aggressively #713
The Rusk State was discarding not-yet-accepted and unfinalized changes far too aggressively/swiftly. This issue has been resolved.
As you can see, development is continuous and this list is not exhaustive. For example, minor issues and advancements concerning the bls12_381 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.
Plonk | Release 0.11.0 / PlonKup | Release 0.1.0
The Plonk repository has now advanced to version 0.11.0. As you can see above, extensive development has been ongoing in other repositories as well, but the majority of releases took place within the Plonk repository.
Besides the update to version 0.11.0, the team has also forked Plonk version 0.10.0 to create a separate repository for PlonKup, deemed version 0.1.0, in which old Plonk references have been replaced by PlonKup, or otherwise removed. Splitting the repositories is preferable, as it allows us to use both crates separately.
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.
Fixed
- Fix logic_gate for bit_num = 256 [#678]
An internal assert in two of the logic gates is failing for large inputs, yet the output appears to be correct regardless. The issue has been resolved and the logic_gate function no longer panics at an arbitrary input.
- Fix error when compiling some circuits [#690]
A bug that occurred when compiling circuits was identified and resolved by applying a patch.
Added
- Add the blinding factors to provide Zero-Knowledge [#650]
Round 1, 2 and 3 of the Plonk process includes code referring to blinding scalars, vital to the security of the protocol. However, they had yet to be implemented until now.
- Add the public inputs into the transcript [#676]
An implementation related to the Plonk vulnerability detected by Trail of Bits.
Changed
- Update CHANGELOG issue links and release dates [#688]
The changelog should (and now does) link issues across repositories to ensure consistency, along with release dates.
- Change variable names for more consistency with the paper [#631]
Discrepancies were found between the names of the variables in their implementation and the names of the variables as they appeared in the PlonKup research paper. You can find the exact terminology on GitHub through the link. This discrepancy has since been rectified.
- Change append_constant to accept generic input [#672]
- Change variable to witness in permutation functions [#681]
Both these implementations aim to create more consistency in both the capabilities of the composer and the terminology used therein.
- Change the prover and the verifier so that it reflects the original Plonk implementation and not Plonkup [#684]
Please refer to the explanation as written under the Removed section.
Removed
- Remove hash_tables module which had been moved to zelbet [#663]
- Remove all Plonkup related code [#684]
Some necessary digital record keeping. Implementation of Plonk and PlonKup need to be partitioned into their own repositories due to the expanded importance of PlonKup in the network.
You can learn more about PlonKup and how it relates to Plonk in this article.
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.