Dusk | Release Cycle Update #25
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.
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
Dusk-blockchain
Official reference implementation of the DUSK Network protocol in Golang.
Opened issues
In the past 3 weeks, no issues were opened in the blockchain repository.
Closed issues
Re-enable consensus task on a failed block acceptance #1537
Rusk
The Dusk's Smart Contract Platform.
Opened
Consensus: Address the issue of a non-deterministic certificate for single round/iteration #1030
Node: Re-enable consensus task on a failed block acceptance #1029
Node: Broadcast block on a verified certificate #1028
Consensus: Include ratification signature and bitset in block certificate #1027
Consensus: Create a distinctive signature for the agreement #1026
Make use of the feed import in the stake contract #972
Make use of the feed import in the transfer contract #971
Make Rusk VM sessions parallel #970
Change finalize to only squash commits #967
Add events hash to the block #962
consensus: Ensure that the candidate verification is executed for a minimum duration of N seconds #950
Use new circuit compression to store circuits #949
Remove txs from mempool after being included in a block #935
Closed
node-data: Make ledger::Block fields private #1024
Remove prev_hash field from NewBlock message #1021
Dockerize Rusk #1012
consensus: Improve block time in a situation of unsynced provisioners #1011
consensus: Allow voting on empty block hash #1010
consensus: Enhance debug level logging details #1004
node: Ensure state_hash from accept/finalize call is equal to block.header state_hash #957
Add prover crate #954
consensus: Cache and reuse verified candidate blocks in Reductions #951
Introduce fixed gas for transfers #939
Enable fallback procedure in rusk node #938
Clients should be able to execute contracts to retrieve data #933
Modify transfer contract to use dusk-merkle #932
Unable to decode blocks containing multiple transactions #930
Update to plonk version with circuit compression capabilities #929
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.9.0 was released on August 30th. This release introduces crumbles 0.1.0.
Crumbles is intended to solve the problem of mapping WASM memories onto virtual address space.
It is built to support tracking dirty pages and creating memory snapshots to which it is possible to revert to. This is required if we want to remove re-execution in piecrust, as well as allowing for the removal of diffing in the storage process of state commits.
piecrust 0.9.0
Changed
- Change commit write behavior to write dirty pages instead of diffs [#253]
- Change memory backend to use crumbles instead of libc directly [#253]
Removed
- Remove Session::squash_commit since it's irrelevant with the new commit behavior [#253]
- Remove libc dependency [#253]
- Remove flate2 dependency [#253]
- Remove qbsdiff dependency [#253]
crumbles 0.1.0
Added
- Initial release
Opened issues
In the past 3 weeks, no issues were opened in the piecrust repository.
Closed issues
Remove diffing by employing a marking strategy #253
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
Plonk V0.15.0 was released on August 30th.
Fixed
- Fix panic when creating proof for circuit with different circuit size [#760]
- Fix panic when testing in debug mode [#763]
Removed
- Remove 'setup' funcion from common test module [#763]
Changed
- Change range and logic component to be generic over the const BIT_PAIRS [#763]
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.
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.
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.