Dusk | Release Cycle Update #28

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 Dus 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

In the latest  Release Cycle Update, the Dusk ecosystem has seen significant improvements across various projects. 

Two pivotal developments significantly advancing our roadmap progress are as follows:

In Piecrust, we've successfully introduced support for 64-bit size contracts, enabling contracts to accommodate state sizes greater than 4 GB, extending up to 4 TB. This milestone ensures the long-term viability and future-proofing of our blockchain network.

Furthermore, in Kadcast (and Rusk), we've introduced the concept of a network ID. This innovation allows us to effectively segregate different instances of running Dusk networks, facilitating enhanced network management and operational versatility.

It's important to note that while these advancements are crucial, they represent just a fraction of the ongoing progress within the Rusk project. A multitude of new issues have been opened, primarily addressing the final requirements for a mainnet candidate.

Rusk focused on optimizing consensus performance and enhancing system functionality, while Citadel introduced version 0.5.1 with various enhancements and adjustments. Piecrust released V0.12.0, offering support for memory64 smart contracts and significant changes in the runtime. Wallet-core resolved compatibility issues, improving the reliability of transactions. In the Plonk library, updates focused on code structure streamlining and enhancing code quality. Kadcast released version 0.6.0, introducing new functionalities and improvements in network management, and Schnorr introduced version 0.15.0, featuring structural changes and comprehensive documentation. 

If you want to learn more about the specific updates and advancements, scroll down for detailed summaries of each GitHub repository’s progress.

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 newly opened issues, we're focused on improving system functionality and addressing bugs. Notable updates include a single vote for the iteration module within the consensus component, integration of the prev_certificates module in consensus, and the introduction of short-circuiting for timed-out iterations to optimize performance. We're also working on a solution to request missing blocks when a node enters the on_idle state, enhancing consensus efficiency, and implementing recovery checkpoints in the node component. We've resolved a significant issue related to unrecoverable consensus state post a split event in the consensus module. In the node module, we're minimizing block storage, optimizing transaction execution, and enabling synchronization only with nodes that can prove their integrity. Additionally, we're aligning license contract tests with Citadel 0.5.0 and enhancing Dockerfile to support various network environments.

Among the closed issues, achievements include resolving the inability to load provisioner keys, fixing an InstantiationError linked to self_id, and addressing the default enablement of HTTP_Listener. Furthermore, the Core team has introduced the Component Handshake feature in the node module.

Opened

Single vote for iteration module:consensus #1109

Introduce prev_certificates module:consensus #1108

Shortcircuit timed out iterations module:consensus #1107

node: Request missing blocks if node enters on_idle state #1103

consensus: Enable reaching a quorum for any candidate from a former iteration within the same round.module:consensus #1097

node: Implement checkpoints for recovery procedures #1094

consensus: Unrecoverable consensus state after a split event fix:bug module:consensus #1093

node: Minimize the block's storage requirements within the persistence layer. Fix:bug #1086

node: Mitigate the impact of offline nodes over message propagation #1085

node: Optimize transaction execution upon block acceptance #1084

node: Permit synchronization exclusively with nodes that proves to be honest fix:bug fix:vulnerability #1083

Adjust license contract tests to Citadel 0.5.0 area:testing module:license-contract #1082

Allow Dockerfile to support various network environments area:conf&build type:enhancement #1080

Closed

Cannot load provisioner keys fix:bug #1101

InstantiationError self_id #1088

HTTP_Listener is not enable by default fix:bug #1087

Implement Component Handshake module:node team:Core type:feature #1072

Dusk-blockchain

This repository contains the legacy Golang implementation of the Dusk protocol. This implementation is deprecated and no longer maintained.

For an up-to-date node implementation, consider using our Rust-based Rusk client.

Why is it Deprecated?

We have transitioned to a Rust-based implementation for improved interoperability, security, and ease of contribution.

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

Citadel v0.5.1 was released on November 1st. Introducing the following changes:

Changed

• fixed benches
• Change attr to attr_data[#80]

Closed

Document the Application Layer #84

Change attr to attr_data type:docs #80

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

Piecrust V0.12.0 was released on November 1st. Introducing significant changes, including added support for memory64 smart contracts, additional Error variants, and integration of the once_cell dependency. Changes involve upgrades to dusk-merkle, contract tree modifications, and a transition from wasmer to wasmtime as the runtime. Several dependencies and minimum memory requirements have been removed. An issue related to loading compiled contracts from different platforms has been resolved. No new issues were opened in the past three weeks, while two issues have been closed, addressing state loading from different architectures and supporting memory64 in the Core team's efforts. 

Added

• Support memory64 smart contracts [#281]
• Add some Error variants:
  • InvalidFunction
  • InvalidMemory
• Add once_cell dependency

Changed

• Upgrade dusk-merkle to version 0.5
• Change contract tree to be arity 4 and height 17 [#159]
• Maximum contract size is now 4TiB [#159]
• Change Error::RuntimeError variant to contain dusk_wasmtime::Error,
  and changed From implementation
• Switch runtime from wasmer to wasmtime

Removed

• Remove parking_lot dependency
• Remove colored dependency
• Remove 4 page - 256KiB - minimum memory requirement for contracts
• Remove Clone derivation for Error
• Remove some Error variants, along with From implementations:
  • CompileError
  • DeserializeError
  • ExportError
  • InstantiationError
  • InvalidFunctionSignature
  • MemorySetupError
  • ParsingError
  • SerializeError
  • Trap

Fixed

• Fix loading of compiled contracts from state transported from different
  platforms [#287]

Closed issues

Cannot load state form different archs fix:bug #287

Support memory64 in piecrust team:Core type:feature #281

Build contracts for wasm64-unknown-unknown team:Core type:feature #280

Wallet-core

A WASM library to provide business logic for Dusk wallet implementations.

Update Summary

Recent updates in Wallet Core have centered on resolving compatibility issues and bugs. Specifically, Issue #92 was tackled, addressing compatibility concerns within Wallet Core. Furthermore, Issue #91, involving a bug related to MakeFile sed errors, has been successfully rectified. Lastly, Issue #84 has been addressed, focusing on the creation of transactions by Wallet Core that couldn't be verified on the Rusk side.

Opened issues

Wallet-core compatibility issues fix:bug #92

Fix the MakeFile sed error fix:bug #91

Current wallet-core creates transactions which cannot be verified on rusk side fix:bug #84

Closed issues

In the past 3 weeks, no issues were closed in the wallet-core repository.

Libraries

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 recent updates, an issue was opened to streamline the library's structure by hiding modules and types other than the prelude. Among the closed issues, enhancements included the addition of the JubJubScalarMalformed error type and improvements in the CI workflow. Issues addressing code quality, test failures, and verification of the zero-knowledge property before-mainnet were successfully resolved.

Opened

Hide modules and types other than prelude #782

Closed

Add JubJubScalarMalformed error type:enhancement #784

Test fails when using rng before-mainnet fix:bug #777

Improve CI workflow area:conf&build #776

Fix clippy warnings #774

Check the zero-knowledge property of PlonK before-mainnet #773

Kadcast

Implementation of the Kadcast Network layer according to the latest version of the paper to date (2021). Kadcast is an UDP-based peer-to-peer protocol in which peers form a structured overlay.

Update Summary

Kadcast v0.6.0 was released on November 1st. This update introduced a new facade function 'new' for creating an RwLock based on feature flags, addressing Issue #94. Additionally, NetworkId was incorporated into the configuration, enhancing network management as specified in Issue #123.

Changes in this update also involved modifications to the RwLock API to support the diagnostics feature flag, enhancing functionality and diagnostics support as described in Issue #94. Furthermore, network wire encoding was adjusted to ensure compatibility with NetworkId, as discussed in Issue #123.

Added

• Add new facade function new to creating RwLock based on feature flag [#94]
• Add NetworkId in configuration [#123]

Changed

• Change RwLock API to support diagnostics feature flag [#94]
• Change network wire encoding to support NetworkId [#123]

Closed issues

Add Network ID for Network Segregation team:Core type:feature #128

Add cargo feature for diagnostics #94

Other

bls12_381

This crate provides an implementation of the BLS12-381 pairing-friendly elliptic curve construction.

Update Summary

bls12_381 v0.12.3 was released on November 1st. Introducing the following changes:

Added

• Add uni_random scalar generation [#125]

Changed

• Change Hash derive on Scalar to explicit implementation [#106]

Closed

Add a random scalar generation that is uniformly distributed #125

Scalar derives Hash but explicitly implements PartialEq #106

Merkle

A sparsely populated Merkle Tree, parameterized over its height and arity.

Update Summary

rkyv serialization is achieved by custom implementations of Archive, Serialize and Deserialize for the Node struct, avoiding the internal RefCell.

Closed

rkyv serialization doesn't work on Tree fix:bug #73

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

Schnorr v0.15.0 was released on November 1st. Introducing the following changes: These include the relocation of 'SecretKey' and 'PublicKey' to 'NoteSecretKey' and 'NotePublicKey' from 'dusk_pki' (Issue #80). The update also added comprehensive library and module level documentation (Issue #49).

In terms of structural changes, 'double_key::Proof' has been renamed to 'double_key::Signature,' and the 'Proof' public struct has been deprecated (Issue #89). Additionally, 'double_key::Proof' has been re-exported as 'DoubleSignature.'

Added

• Move SecretKey & PublicKey from dusk_pki and renamed them to NoteSecretKey & NotePublicKey [#80]
• Add lib and module level documentation [#49]

Changed

• Rename double_key::Proof struct to double_key::Signature [#89]
• Deprecate Proof public struct [#89]
• Re-export double_key::Proof as DoubleSignature [#89]

Opened

Change module name key_variants to signatures #96

Deprecate PublicKeyPair #95

Fix benchmarks #94

Closed

Improve double_key::Proof naming #89

Move PublicKey and SecretKey from dusk-pki to dusk-schnorr #80

Add docs at lib/module level #49

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.0 was released on November 1st. In this update, the REQUIRED_RUSK_VERSION has been revised to 0.7.0-rc, ensuring alignment with the latest Rusk version. The Staking Address generation process has undergone significant transformations as per Issue #214, enhancing the platform's functionality.

Furthermore, the update includes an upgrade of dusk-wallet-core to version 0.22.0-plonk.0.16, keeping the system in sync with the latest releases and innovations, as also highlighted in Issue #214.

Changed

• Change REQUIRED_RUSK_VERSION to 0.7.0-rc
• Change the Staking Address generation. [#214]
• Change dusk-wallet-core to 0.22.0-plonk.0.16 [#214]

Closed issues

Upgrade to plonk 0.16 #214

Allow to specify different MAX_ADDRESSES #210

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.