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.
kadcast
Open issues
Remove unnecessary expect/unwrap #115
The codebase is full of unwrap/expect.
dusk-ui-kit
Open issues
Toggle component breaks the web #763
We can't set value attributes on Toggle components (e.g. radios and checkboxes).
add DropDown scrollable options list #758
Add functionality to the DropDown component that will allow the list of options to be scrollable and with a fixed length. This should be turned on and off based on a new prop.
Closed issues
Create new DatePicker component #750
A DatePicker component, as specified here.
Create a new atom component that presents text in a Badge. According to this Figma: #735
The Badge must support a standard set of variants: 'success', 'warning', 'danger' and 'brand'.
Improve and expand test coverage #715
I want to increase the number of tests that we run on the components. I want to see property values changing and testing for the correct output. Testing for visual differences can also be explored with Chromatic (or alternative, if deemed more suitable).
Add cms-connector models and schemas in published UI Kit #719
The models and schemas that are generated and maintained in the cms-connector repository are to be published with the UI Kit packages. This can be achieved by removing the private property from the package.json.
DateText component throwing errors #737
The underlying date library (dayjs) throws errors relating to commonJS loading. Attempts to exclude the library from the optimized dependencies have failed.
wallet-core
Closed issues
Add a method to execute generic contract calls #66
Currently we can call only the genesis contract (transfer and stake); those two contracts have ad hoc calls.
We should implement a more general purpose method to execute any contract, once the contract id and the data to pass to it are provided.
wallet-cli
Open issues
The user needs to know which staking address (BLS Public Key in base58) belongs to his wallet.
This is required in order to let the staking owner to allow the staker on chain.
The current implementation simply quit the program.
To be more precise, some parts of the code can easily handle the cancellation, but the current implementation simply catches it and shades it.
Improve gql code structure #102
Optimize code, improve error handling so it will align with the rest of the code.
Closed issues
Handle properly requestty::prompt response #100
The current use of requestty doesn't handle properly when the OS interrupts the current process.
If the users try to quit while the client is waiting for a user feedback (e.g: the user press CTRL+C in almost any menu) the executable panics.
dusk-blockchain
Closed issues
GQL: Search txs for blocks range #1468
Add a blocksrange filter to lookup transaction (similar to the range filter for blocks lookup)
Harness tests won't work after rusk-recovery changes #1466
Now rusk-recovery requires an input file to generate the genesis state, and dusk-blockchain doesn't support it yet.
Poseidon 252
Closed issues
Store the root of a branch separately to the levels #189
Rethink the way we store the root in the PoseidonBranch.
consensus
Open issues
Implement request-candidate-block procedure #7
Request, provide and collect a candidate block routines are not currently supported. This makes it impossible to create a winning block on reaching consensus.
Implement AggrAgreement message build, publish and collect #6
Current version of consensus implementation does not support AggrAgreement message. This should be added in order to be compatible with the impl in golang.
Closed issues
Use a cached version of BLS public keys compressed form #18
The implementations of PartialOrd and Ord of PublicKey wrapper are based on the CPU-intensive dusk_bls12_381_sign::PublicKey::pk_t()::to_bytes(). This was spotted as a bottleneck on CPU profiling. To avoid frequent serialization into compressed form (to_bytes) , a cache field should be used instead.
Enable CI #15
Enable CI checks.
Optimize agreement messages verification #14
As per the golang impl, consensus (Accumulator) should be capable of verifying agreement messages concurrently or in parallel. By the default, golang impl spawns 4 workers. This could be achieved by implementing any of the following approaches:
1 .Run a separate tokio::runtime with 4 dedicated threads to perform solely agreement message verification.
2. Use tokio::spawn_blocking() or native thread::spawn()
3. Use data-parallelism library (e.g Rayon)
NB. For options 2 and 3, we'll need to bridge with sync code.
Execute EST and VST calls in selection and reductions steps #11
A trait that defines EST calls (execute_state_transitions, verify_state_transition) should be passed to consensus from outside so that block generators can execute state transition and reductions steps can verify state transition.
Update step timeout value on any occurrence of timeout event #9
None of the steps process time-out events.
Support consensus cancellation #8
On receiving a valid future block, the synchronizer should be able to cancel a running consensus instance.
Use task:abort to terminate both agreement_loop and main_loop tasks #5
Instead of having an additional oneshot channel to sync up both tasks, we should consider deprecating it in favor of a more idiomatic and efficient task:abort.
Migrate consensus implementation #2
hatchery
Open issues
Documentation of the project #103
It would be extremely useful to have a document to refer to explaining how the virtual machine works in broad terms including, but not limited to:
- Virtual machine ABI. The higher level concepts of the ABI, such as the argument buffer, host calls, serialization, etc... should be detailed in such a document.
- Workings of the VM. How the virtual machine works internally to execute modules, how it "reacts" to modules calling the host, how it commits and restores, etc...
- Certain concepts need to be detailed like host queries, metering, etc...
Implement Diffing for Commit/Restore Mechanism #100
Currently, modules' memories are committed without diffing, so even a modest change will require a full memory storage. This is suboptimal for disk usage in the long run. Diffing will enable to decrease disk usage by the order of magnitude.
Improve Last Commit Mechanism #99
Last commit mechanism is a way to distinguish a commit that should be loaded into modules' memories on instantiation. Currently,the last commit file is a copy of an original commit file. This approach is wasteful as it duplicates the file for the mere purpose of marking it as "last". More efficient mechanism should be used.
There should be a way to provide modules some data on deployment, which is then used to initialize the state. Currently it is only possible to "bake in" the initial state in the WASM bytecode. This precludes the module writer from writing a module once, and then reusing the same bytecode with different initial states. This use-case should become possible.
Panics should propagate to the caller #79
When performing an inter-contract call, a panic occurring in the called module should inform the caller that the module panicked, as opposed to stopping the execution.
This ensures the calling module is able to handle panics of modules whose code it has no control over.
Closed issues
Usage example and build instructions in README #102
To ensure viewers of the project can build, run, and test the project as well as understand how to use it, I would like the following sections added to the README:
Last commits loaded only into (session's) fresh module' memories #91
Current implementation loads last commit's memories into session's memories on every instantiation, which implies incorrect semantics when last commit is present.
Session Commits Persistence #89
After the system is restarted, we need to be able to find and restore session's commits that have been performed in the past.
Replace workarounds for skipping WASM module memory initialization #86
Modules should be able to query the call stack #84
Modules should be able to query who they are being called by. This is necessary to allow modules to decide what to do based on who they are being called by. There should also be a way to tell if the module is the first in the call chain.
Meter execution of modules and provide host calls #83
A transaction path should be metered and it should be possible to set a limit to the number of "points" used during the path of a transaction.
Some host calls should also be made available. In particular the module should be able to query the point limit and the points spent.
This is necessary to be able to charge gas on transaction.
Support an event mechanism #82
Modules should be able to emit events during transactions. This is necessary to signal external applications that "something" happened. Downstream they should be included in a block in the form of a bloom filter.
Support the height host call #81
A module should be able to query the host for the current height. This is necessary for use cases relying on time like the staking-module.
Missing features and improvements #76
This issue is meant to describe the things still missing from this VM implementation vs. the previous implementation at rusk-vm, and remaining necessary improvements.
We need to persist module states. When a session is dropped and then created again, or system is restarted, modules should be in a state which was present at the last session's commit (or if there was no commit, at their initial state).
Upgrade to wasmer latest version #44
Upgrade the wasmer dependency to the newest version.
Snapshot meta-persistence - storing collections of per-world and per-module'...#38
In addition to actual snapshots, also lists of snapshot ids need to be stored. This includes world snapshot ids for the global context, and module snapshot ids for the module contexts. Snapshots should be "restorable" with no regard if the system was restarted or not after they were created.
World persist and restore refinement #33
Persisting the world state should also persist the currently deployed modules.#26
When restoring a persisted world state, the modules deployed in that world should be available.
Port self-snapshot test from rusk-vm #24
The self-snapshot test should be ported from rusk-vm.
Persist and restore VM state on disk. #1
Persistence of VM memory on disk.
rusk
Open issues
Migrate to piecrust #760
We should port rusk to use piecrust instead of rusk-vm. This is necessary to make full use of the new contract ABI and the improvements to speed and disk-space efficiency provided by piecrust.
Port the rusk library to use piecrust #759
Migrate rusk to make use of piecrust instead of rusk-vm. This will allow rusk to be faster at executing contracts, and use less disk space - together with a number of other improvements, i.e. less gas per TX.
Port stake contract to piecrust #758
The stake contract needs to be ported to the new way of writing contracts defined by piecrust-uplink. This is a necessary step to a full port of rusk to use piecrust instead of rusk-vm.
Port transfer contract to piecrust #757
The transfer contract needs to be ported to the new way of writing contracts defined by piecrust-uplink. This is a necessary step to a full port of rusk to use piecrust instead of rusk-vm.
Using base_state generates corrupted state #754
Using rusk-recovery-state with an init toml that manipulates a base state, results in a corrupted state.
The above mentioned state is working properly for transacting, but raises an error as soon as the stake contract is called.
Automatically add the wasm32 toolchain when using toolchain #751
Add a clear and concise description of the reason why this needs to be worked on. Focus on the big picture rather than implementation details. What use case does it support? What is the expected outcome?
Closed issues
Change default state of rusk-recovery to use a prebuilt state #755
Current implementation of rusk-recovery uses a "genesis" base_state to manipulate.
But this won't work as per #754
Use external base state for rusk-recovery-state #750
The current impl of rusk-recovery-state generates a local state with some init configuration applied on top of that state. Hence, the generated state suffers for a non-deterministic state-root depending on which LLVM generated the wasm contracts bytecode.
Makefile: re enable the state recipe #747
On previous PR the recipe for the state make state has been removed due to the need to specify an input-file for rusk-recovery-state.
Rusk won't build with new rustc_tools_utils #745
Rusk and rusk-recovery won't build anymore after upgrading rustc_tools_utils to the latest version.
Specify genesis state as toml configuration #741
The idea is to deprecate the --testnet flag of rusk-recovery.
This flag is used to identify if the state that is going to be generated should be compatible with testnet or just a local genesis state for unit tests.
Allow to export a state from rusk-recovery #738
After that rusk is able to get a custom state as input [#734] there is the need to generate such a state.
As you can see, development is continuous and this list is not exhaustive. For example, minor issues and advancements 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.
wallet-cli - V0.12.0
The wallet-cli repository has now advanced to version 0.12.0
Added
- Add default.config.toml for the default configuration settings [#57]
- Add settings subcommand to show the current settings [#57]
- Add --password as global argument [#57]
- Add --skip-recovery to create subcommand [#57]
- Add --file to restore subcommand [#57]
- Add Settings type to merge Config (from toml) and WalletArgs (from CLI) [#57]
- Add address module
- Add gas module
- Add settings module [#57]
- Add is_enough method to Gas
- Add Create, Restore and Settings for both Command and RunResult enums [#72]
- Add LogFormat and LogLevel enums to enforce the set of value from args [#57]
- Add From block and Last block during fetching
- Add missing documentations
- Add Seed type in store module
- Add stake-allow command [#83]
Changed
- Change program behavior to quit if wrong seed phrase is given [#49]
- Change program behavior to have three attempts for entering a password [#46]
- Change error handling to use the anyhow crate in bin[#87]
- Change error handling to use the thiserror crate in lib[#87]
- Change config.toml format [#57]
- Change from multiple wallets to one wallet for a single profile dir [#72]
- Rename dusk module to currency module
- Rename address subcommand to addresses
- Change set_price and set_limit for Gas to works with Option
- Change part of the functions to either receive the password or the settings [#57]
- Move config module outside io [#57]
- Change few UI strings
- Update rust-toolchain from nightly-2022-02-19 to nightly-2022-08-28
Removed
- Rename --data-dir argument option to --profile [#57]
- Remove --wallet-name argument option [#72]
- Remove --network argument option to choose the network to connect with [#57]
- Remove interactive subcommand [#57]
- Remove --skip-recovery as global argument [#57]
- Remove --wait-for-tx (now all the transaction wait by default) [#57]
- Remove merge method from Config in favour of Settings type [#57]
- Remove Command::NotSupported [#57]
- Rename DEFAULT_GAS_LIMIT, DEFAULT_GAS_PRICE, MIN_GAS_LIMIT
- Remove Addresses type in favour of Vec<Address>
- Remove refund-addr arg in withdraw command [#86]
Fixed
- Fix wrong condition involved gas.is_enough()[#91]
- Fix balance subcommand: it didn't work because the address given wasn't claimed
- Fix BLS keys exported with wrong extensions [#84]
plonk - V0.13.0
The plonk repository has now advanced to version 0.13.0
Added
- Add support for rkyv-impl under no_std
Changed
- Update dusk-cdf to 0.5 #709
Poseidon252 - V0.27.0
The Poseidon252 repository has now advanced to version 0.27.0
Added
- Add support for rkyv-impl under no_std
- Add ranno version 0.1 to dependencies #180
Changed
- Change PoseidonBranch to have two fields - root and path. The path is
now a fixed length array. #189 - Change PoseidonTree to build only with the alloc feature #180
- Change PoseidonTree to take a generic Keyed over the leaf type
instead of a PoseidonAnnotation #180 - Make PoseidonTree::new const #180
- Update microkelvin from 0.15 to 0.17 #180
- Update nstack from 0.14.0-rc to 0.16 #180
Removed
- Remove PoseidonBranch Default implementation #189
- Remove std feature #180
- Remove canon and persistence features #180
- Remove Error struct #180
- Remove canonical and canonical-derive from dependencies #180
- Remove PoseidonMaxAnnotation #180
Fixed
nstack - V0.16.0
The nstack repository has now advanced to version 0.16.0
Added
- Add annotations specific to the nstack
Changed
- Update to use ranno annotations
- Update microkelvin from 0.13.0-rc.0 to 0.17. The wide range is due to experimentation with rkyv in microkelvin.
- Change rust-toolchain to stable
microkelvin | Release V0.17.0
The microkelvin repository has now advanced to version 0.17.0
Change
- Use ranno in lieu of the previous annotations.
Removed
- Remove Link
- Remove annotations
- Remove persistence feature
schnorr | Release V0.11.1
The schnorr repository has now advanced to version 0.11.1
Added
- Add support for rkyv-impl under no_std
phoenix-core | Release V0.17.1
The phoenix-core repository has now advanced to version 0.17.1
Added
- Add support for rkyv-impl under no_std
dusk-pki | Release V0.11.1
The dusk-pki repository has now advanced to version 0.11.1
Added
- Add support for rkyv-impl under no_std
jubjub | Release V0.12.1
The jubjub repository has now advanced to version 0.12.1
Added
- Add support for rkyv-impl under no_std
bls12_381 | Release V0.11.1
The bls12_381 repository has now advanced to version 0.11.1
Added
- Add support for rkyv-impl under no_std
- Add wrapper type for subtle::Choice
Change
- Derive manual implementations of rkyv trait by introducing a wrapper for the
subtle::Choice type.
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.