Dusk | Release Cycle #29
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 Update Summary
During the most recent 3 week Release Cycle, the Rusk repository has seen significant progress. Developments include enhancements, such as license contract methods, block detection, timing of block acceptance, refining consensus mechanisms, and optimizing components. Notably, issues like adding a prover feature to Rusk, resolving test block inconsistencies, and enhancing security in the OutOfSync state have been addressed successfully.
In the Piecrust segment, a test implemented during dusk-network/rusk#1125 revealed a root display discrepancy between sessions with erroring calls and those with successful calls. This highlights an important aspect of system behavior under different conditions.
For Wallet-Core, the focus has been on introducing features for offline transaction signing, improving log, warning, and error handling, and updating WebAssembly in continuous integration tests, all aimed at bolstering security and testing efficiency. The resolution of issues pertaining to error reporting and transaction verification between wallet-core and rusk is a notable achievement.
The Plonk repository's recent updates include proposals to improve code modularity and error handling, particularly in the component_mul_generator. The absence of closed issues suggests ongoing efforts to tackle these new challenges.
The Schnorr repository underwent changes with multiple issues opened and closed, focusing on naming conventions, documentation updates, and refinements in the signature and proof systems.
Lastly, the Dusk-PKI repository has been deprecated, with all keys now integrated into either dusk-schnorr or phoenix-core, streamlining the Dusk Network ecosystem.
Overall, these updates demonstrate a strong commitment to advancing our blockchain infrastructure with a focus on security, efficiency, and system robustness towards our Mainnet in 2024.
For the community's benefit, we have divided our repositories in 3 categories, main, libraries and other. Below you will find a selection of some (but not all) of the work that is being done in our repositories, including recent advancements.
Main Repositories
Rusk
The Dusk's Smart Contract Platform.
Update Summary
In the past three weeks, the Rusk repository has seen notable developments.
Among the opened issues, key focuses include renaming the License Contract's noop method, addressing missing block detection, investigating block acceptance timing, refining consensus mechanisms, and optimizing components by removing specific dependencies.
A number of issues have been closed, including the addition of a prover feature for rusk, resolution of non-deterministic behavior in test blocks, improved security and stability in the OutOfSync state and fallback procedure, and the successful addition of various features like deterministic winning certificates and enhanced API documentation.
Opened
Rename License Contract noop method to request_license #1151
Missing block detection #1150
Investigate block acceptance timing #1149
Consensus: accept block from single Agreement #1148
Remove anyhow from http handler #1146
Allow rusk to be prover-only #1144
Remove phoenix-core from rusk-recovery #1139
Remove phoenix-core from stake-contract #1138
node: Maintain a set of eligible provisioners of previous epoch/block #1124
Change block's finality definition #1118
Add failed_iterations fields #1116
Document API #1114
Single vote for iteration #1109
Closed
Add prover feature for rusk #1145
Test blocks are not deterministic #1141
Add clippy check for smart contracts #1140
Add hash header to the CRS-via-HTTP api #1135
Remove rusk-recovery binaries #1128
node: Improve security and stability of OutOfSync state and fallback procedure #1127
Add rusk-recovery capability to rusk #1126
CRS is not cached properly #1121
Enrich Rusk ABI and License Smart Contract with a method to provide PLONK setup #1119
Start iteration from 0 instead of 1#1117
Add Deterministic winning certificate #1115
Introduce prev_certificates #1108
Shortcircuit timed out iterations #1107
node: Request missing blocks if node enters on_idle state #1103
Piecrust
Piecrust is a Rust workspace containing two crates, piecrust and piecrust-uplink, that together form the WASM virtual machine for running, handling and creating Dusk smart contracts.
Update Summary
During the implementation of dusk-network/rusk#1125, a test was added that makes an erroring call, and then subsequently executes another call. Another session is then instantiated that only runs successful calls, which then displays a different root than before.
Opened issues
Inconsistent root after erroring calls #296
Closed issues
In the past 3 weeks, no issues were closed in the piecrust repository.
Libraries
Wallet-CLI
Library providing functionalities to create wallets compatible with Dusk Network
This library is used to implement the official Dusk CLI wallet.
Update Summary
Wallet-CLI v0.20.1 was released on November 22nd. Introducing the following changes:
Added
- Add spending_keys to wallet impl [#218]
Opened issues
interactive stake-allow doesn't work #222
Closed issues
Implement a method to get the SSK from another module #218
Wallet-core
A WASM library to provide business logic for Dusk wallet implementations.
Update Summary
Three new issues have been opened in the past three weeks. These include requests to add a feature enabling offline transaction signing (#96), the provision of handles for log, warnings, and errors (#95), and the compilation of fresh WebAssembly (wasm) during integration tests on Continuous Integration (CI) (#94). These issues collectively indicate a focus on enhancing security, error management, and testing procedures within the Wallet Core library.
On the closed issues front, two matters have been successfully addressed. The first involves the addition of error reporting and hooks for handling errors (#97), while the second pertains to resolving a concern where transactions created by the current wallet-core could not be verified on the rusk side (#84).
Opened issues
Add a way to offline sign transactions #96
Provide handles for log, warnings and errors #95
Compile fresh wasm when running integration tests on CI #94
Closed issues
Add error reporting and hooks for onerror #97
Current wallet-core creates transactions which cannot be verified on rusk side #84
Plonk
This is a pure Rust implementation of the PLONK proving system over BLS12-381
This library contains a modularised implementation of KZG10 as the default polynomial commitment scheme.
Update Summary
In the recent updates to the Plonk repository, two new issues have been opened in the past three weeks. The first issue (#788) proposes the separation of the component_mul_generator into two distinct methods, one for G and one for G_prime. The second issue (#787) suggests making the component_mul_generator infallible, emphasizing a focus on code modularity and error handling within the Plonk repository.
During this period, no issues have been closed, indicating that the development team is actively addressing new concerns and enhancements without recent resolutions in the Plonk repository.
Opened issues
separate component_mul_generator into two methods, one for G and one for G_prime #788
make component_mul_generator infallable #787
Closed issues
In the past 3 weeks, no issues were closed in the plonk repository.
Other
Citadel
This repository contains the implementation of Citadel, a protocol that integrates a self-sovereign identity system into the Dusk blockchain. An academic paper with further details about the protocol can be found here.
It also contains Shelter, a version of Citadel meant for non-Blockchain use cases. Documentation on this version will be provided soon.
Update Summary
No new issues were opened for Citadel, and one was closed (#87) to ensure that if the session fails the session verify doesn’t panic. It has been updated to return boolean instead of panicking.
Opened
No issues opened in the last 3 weeks.
Closed
Add a non-panicking method for verifying session #87
Poseidon252
Reference implementation for the Poseidon Hashing algorithm.
Update Summary
Two new issues have been opened. The first issue (#108) proposes the removal of the "Note" prefix from "NoteSecretKey" and "NotePublicKey," suggesting a refinement in naming conventions. The second issue (#225) involves the addition of a failing test to address incorrect openings, indicating a proactive approach to testing and ensuring the reliability of the codebase.
On the closed issues front, one matter has been successfully addressed. Issue #188 involved the utilization of component_boolean in the merkle opening circuit.
Opened
Remove Note prefix from NoteSecretKey and NotePublicKey #108
Add failing test for incorrect opening #225
Closed
Use component_boolean in the our merkle opening circuit #188
Schnorr
The Schnorr signature algorithm, given its namesake by its creator Claus Schnorr, is a digital signature scheme which provides a simple method of creating short signatures.
The implementation has been created using the Poseidon hash function, the paper for which can be found here.
For a reference to the algorithm, please see the docs.
Update Summary
There were a lot of updates to Schnorr in the past 3 weeks, with Schnorr v0.16.0 being released on November 22nd. Introducing the following changes:
Added
Changed
- Change the NotePublicKey tuple struct to directly be a tuple with two fields [#111]
- Change double and single signature creation to be a method on NoteSecretKey [#81]
- Rename internal key_variants module to signatures [#96]
- Rename the signatures method to_witness to append [#99]
- Update benchmarks to latest version of plonk [#94]
- Update test structure [#94]
- Move PublicKeyPair from DoubleSignature to public_keys [#95]
- Rename keys: NoteSecretKey -> SecretKey, NotePublicKey -> PublicKey [#108]
Removed
- Hide (Double)Signature::new() from the public API [#81]
Opened issues
Find a better name for PublicKeyPair #110
Rename crate to jubjub-schnorr #109
NotePublicKey derivation, signing and verification must also work with a custom Generator G #107
Closed issues
Remove Note prefix from NoteSecretKey and NotePublicKey #108
Change NotePublicKeyPair single field tuple struct to have two fields #111
Add docs to new key modules #105
Update README #104
Rename methods to_witness to append #99
Update benchmarks and zk tests #94
Change module name key_variants to signatures #96
Refactor Signature and Proof to be more consistent to bls12_381-sign #81
Dusk-pki
PKI stands for Public Key Infrastructure. This repository has been created so there's a unique library that holds the types and functions required to perform keys operations.
Update Summary
The Dusk-PKI depository is being deprecated. All keys moved into either dusk-schnorr or phoenix-core.
Opened
There were no issues opened in the last 3 weeks.
Closed issues
Add deprecated badge for crates.io #88
In A Nutshell: Release Cycle planning
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.
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 above noted additions/changes to the repository can be followed on GitHub, for further details on their status and their function in the stack.
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.
In the past Release Cycle we have seen various updates and improvements across multiple Dusk GitHub repositories. In the Rusk repository, significant progress has been made in enhancing the transfer contract by migrating it to utilize the dusk-merkle tree. This upgrade not only resolves problems related to defining a proper tree walk but also simplifies the process. Additionally, several new issues have been opened and closed, addressing concerns such as enabling fallback procedures, decoding blocks with multiple transactions, and resolving compatibility issues.
Moving on to the Piecrust repository, version 0.6.0 has been released, introducing changes and additions to the piecrust and piecrust-uplink crates. Notably, the implementation now includes an Event struct, improved debugging capabilities, and adjustments to event handling.
In the Wallet-cli repository, version 0.16.0 has been released, focusing on updates related to Note's key and cache. This release tackles issues such as changing the cached Note's key to be the nullifier instead of the hash and updating the cache for all possible addresses simultaneously.
Plonk saw the release of version 0.14.1, which introduces circuit compression capabilities through the Compiler::compress and Compiler::decompress functions.
Shifting our focus to the Citadel repository, several noteworthy developments have taken place. New issues were opened, including the design and implementation of the Citadel request authoring process, while existing issues regarding compute parameters, local state removal, and code reuse were successfully resolved.
Merkle repository saw the implementation of custom serialization for Opening and poseidon_merkle::Opening, with an associated issue opened to address this functionality.
In Poseidon252, version 0.30.1 was released, fixing the missing rkyv feature, and closed issues encompassed the addition of a sponge framework and benchmarks for poseidon opening.
The Schnorr repository released version 0.13.0, incorporating updates to dusk-pki, dusk-poseidon, and dusk-plonk dependencies. Lastly, Dusk-PKI version 0.12.0 was released, featuring updates to dusk-poseidon and rust-toolchain dependencies.
These updates reflect the ongoing efforts and progress within the Dusk ecosystem. Developers are actively addressing issues, improving code efficiency, and enhancing functionality across various repositories. As the network continues to evolve, these updates pave the way for a more robust and efficient Dusk protocol, benefiting developers and users alike.
