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.
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.
regenerateCommittee is called in GenerateCandidateMessage but its return value is never used.
p.MemberAt(i) in extractCommitteeMember would return nil member making the sortition panic, when a provisioner public key starts with zeros.
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.
A skeleton implementation of Consensus algorithm in rustlang.
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.
Tools for debugging running modules.
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.
We want the hash of the snapshot independent of volatile areas of memory such as the argument buffer.
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.
When users create a new address they should be given the option to name this address.
Direct the user to create one single wallet, instead of multiple wallets to simplify and align with web-wallet.
The prover and state server should have the capability to have a different ipc method.
Recovering a wallet works but prints an unexpected message at the end.
Restoring a wallet should discover all consecutive addresses that have funds in them, or provide an option to manually start such a discovery process.
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.
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.
When running the wallet CLI under Windows, the selection chevron is not showing up as expected and instead displays an unknown encoding symbol.
While creating a wallet the seed phrase is not shown to the user.
Running rusk-wallet v0.11.0 with pre-existing wallet data makes the exec die silently.
An on-chain mechanism to allow staking whitelist.
To allow dusk-blockchain to run test-harness with dummy keys.
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.
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
- 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
- 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
- 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
- Default configuration values loading #1419
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.
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.