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 the Release Cycle 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
Closed issues
Evaluate efforts needed to migrate consensus from golang to rustlang #1454
Build a rust lib that encapsulates a rust implementation of golang package github.com/dusk-network/dusk-blockchain/pkg/core/consensus/. This should follow the same design of the original package where golang runtime is substituted with tokio::runtime.
Remove deprecated committee keys from block generator #1456
regenerateCommittee is called in GenerateCandidateMessage but its return value is never used.
Add support in sortition for bls public keys that starts with zero #1457
p.MemberAt(i) in extractCommitteeMember would return nil member making the sortition panic, when a provisioner public key starts with zeros.
Support different genesis blocks #1461
Now that the state is built "more" deterministic, we can stop to always use the same state.
This means that we should start to handle multiple genesis block to support different scenario.
consensus
Open issues
Migrate consensus implementation #2
A skeleton implementation of Consensus algorithm in rustlang.
hatchery
Open issues
Snapshots meta-persistence #50
We need to persist not only snapshots but information about snapshots. After the system is restarted, we need to be able to find and restore snapshots, so we need stored information about how to find them.
Provide debug information to be easily used in modules. #53
Tools for debugging running modules.
Construct a tree from module memories #55
One of the most important features the VM should provide is the so-called "state root". The state root is the root of a Merkle tree, where the leaves of the tree are the hashes of the bytecode of the module and its linear memory. This root changes across snapshots, and would - optionally - make a great SnapshotId.
Closed issues
Exclude argbuf and other volatile memory areas from hash of the snapshot #48
We want the hash of the snapshot independent of volatile areas of memory such as the argument buffer.
Introduce the concept of a host module #49
Modules should have access to reserved queries through the query host call. These calls should be defined upstream the user using a trait named HostModule, and executed on the host.
wallet-cli
Open issues
Possibility to name your address #71
When users create a new address they should be given the option to name this address.
Move focus to single wallet creation #72
Direct the user to create one single wallet, instead of multiple wallets to simplify and align with web-wallet.
Prover and State server should have the capability to have different ipc method #77
The prover and state server should have the capability to have a different ipc method.
Restoring a wallet prints an unexpected message #78
Recovering a wallet works but prints an unexpected message at the end.
Restoring a wallet does not discover all addresses with funds #80
Restoring a wallet should discover all consecutive addresses that have funds in them, or provide an option to manually start such a discovery process.
Improvement of user experience with staking #81
It should be easy to stake the entire balance and it should be impossible to send a transaction with a value that is too low.
Closed issues
Separate the crate into two crates with a workspace #65
The [lib] and [[bin]] sections prevent this crate from being published separately. Separating this into a workspace would allow for this to happen, and would enable managing the dependencies of each crate separately.
Windows UTF-8 CLI improper display #68
When running the wallet CLI under Windows, the selection chevron is not showing up as expected and instead displays an unknown encoding symbol.
mnphrase not shown during wallet creation #70
While creating a wallet the seed phrase is not shown to the user.
Running v0.11.0 with pre-existing wallet data makes the exec dies silently #73
Running rusk-wallet v0.11.0 with pre-existing wallet data makes the exec die silently.
rusk
Open issues
stake-contract: implement whitelist #732
An on-chain mechanism to allow staking whitelist.
Closed issues
Use different keys for harness genesis contract #727
To allow dusk-blockchain to run test-harness with dummy keys.
Different Circuit's code hash changing the toolchain #729
Upgrading the toolchain results in a different code hash result for the Execute circuits. This happens only for the circuits declared using a macro. Seems to me that a bug was fixed starting with rust-1.63, and unlucky this changed the way the AST is represented.
Cannot compile using rust < 1.63 #730
Using a toolchain lower than 1.63 results in compilation error.
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.
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.
The below noted additions/changes to the repository can be followed on GitHub, for further details on their status and their function in the stack.
dusk-blockchain| Release V0.6.0
The dusk-blockchain repository has now advanced to version 0.6.0
Added
- Make BlockGasLimit configurable #1418
- Adapt to the new and improved reward strategy #1320
- Include BlockGenerator reward into the header #1368
- Search txs up to 10.000 blocks #1401
- Mempool updates its state at start-up automatically #1258
- Mempool discards any transaction with repeated nullifier #1388
- Detect any occurrences of missed fallback procedure #1413
- Send reduction concurrently without blocking votes broadcast #1442
Changed
- Extraction from mempool consider Gas expenditure estimation #1421
- Add GasLimit to the Block's header #1416
- Reduce wire messages needed for propagating an Agreement vote
- Improve fallback procedure to revert multiple ephemeral blocks #1343
- Disable provisioners records storing in api.db #1361
- Optimize VST calls of a Provisioner per a consensus iteration #1371
- Call VerifyStateTransition in Reduction 2 only if it is a committee member #1357
- Drop topics.Block messages with invalid header.hash value #1425
- Request candidate block from arbitrary active nodes #1359
- Allow verifyFn to report errors correctly #1436
- Clone message.Agreement on notifying the consumer #1433
- Solve newblock msg errors #1443
Security
- Ensure candidate block hash is equal to the BlockHash of the msg.header #1364
- Check quorum per each reduction step on agreement msg verification #1373
- Extend reduction 1 verification procedure with VST call #1358
- Verify block certificate prior to broadcast #1446
- Add support in sortition for bls public keys that starts with zeros #1457
- Discard aggrAgreement messages with invalid StepVotes #1430
- Check quorum target on certificate verification #1432
Fixed
- Default configuration values loading #1419
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.