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-pki
Open issues
Rename Public/SecretKey into Note-Public/SecretKey and Public/SecretSpendKey into Public/SecretKey #77
We want to do a renaming of the PublicKey and SecretKey structures to NotePublicKey and NoteSecretKey, respectively, as well as rename the PublicSpendKey and SecretSpendKey to PublicKey and SecretKey, respectively.
This is to better reflect their usage in our transaction model, and avoid any confusion when comparing documentation with this code.
Closed issues
Derive Default for PublicKey #74
Citadel requires it for handling the License struct.
piecrust
Open issues
Fix Argument Buffer Corruption #118
When called by transfer contract and stage contract, contract methods receive argument buffer with initial 32 bytes set to zero.
Eliminate overlap between session's attributes: memory handler and callstack #123
In current piecrust implementation, memory handler (MemoryHandler) maintains a map of per-module-id memories (Linear), while call stack (CallStack) maintains a map of per-module-id instances (wasmer::instance via WrappedInstance). Both MemoryHandler and CallStack are attributes of a Session. This is suboptimal, as both maps perform the same state logic on structures which partly overlap. It is potentially dangerous as the overlap is not explicit. Should future maintainers un-sync the state logic of both maps, not easy to diagnose memory problems that could start reoccurring. Hence, it is important to make the overlap explicit and maintain only a single map so that for a given module id it is obvious which memory and which instance belong to it.
Closed issues
transact_raw sometimes corrupts the stack on recursive calls #122
Transact raw sometimes leads to stack corruption when a module calls itself recursively. This is visible in the raw-calls-layout branch in this repository. The self_snapshot test will produce an out of bounds access to the heap, which happens due to the pointer to the raw transaction buffer being corrupted.
Schnorr
Closed issues
Derive Default for Signature and Proof #77
Citadel requires it for handling the License struct.
Phoenix-core
Closed issues
Add structures from rusk transfer-contract-types #116
Move structures from rusk transfer-contract-types into this crate as they are fundamental to the phoenix protocol and possibly reused by wallet-core.
Dusk-ui-kit
Closed issues
Custom icons are not rendering #848
Icons don't render when they exist in the custom icons directory.
itn-installer
Closed issues
Currently, if the node software is installed, it gives you commands to run the node and view the logs. If you run the node, it'll always fail by default and tell you what steps to take next.
From a user experience point of view, it would be nice to give a number of pre-launch steps that need to be taken before a node can be run.
Update the Rusk wallet CLI from v0.12 to v0.13 to incorporate some of the UX improvements we've made as of late.
The repository currently makes no mention of how to use the installer.
wallet-cli
Closed issues
Incorrect balances displayed while in headless #123
Operations like "balance" "stake-info" etc reports the amount of dusk displayed in LUX instead of DUSK.
Display activation block for a stake #124
When getting stake-info, the wallet should display the block at which this becomes eligible.
Display stake maturity epoch #128
We use epochs within a certain context, but do not clearly display what epochs we're in.
plonk
Open issues
Circuit shouldn't be required to be Default #715
A circuit shouldn't be required to be Default to satisfy the Circuit trait. The proposal is to remove said bound, and adjust accordingly.
Expects negative public inputs #717
The current implementation will produce negative public inputs(PIs). This is incredibly confusing and unexpected. The proving algorithm in the Prover::prove functions produces PIs that are the negative of what is expected, and Verifier::verify expects them to be negative as well.
Dusk-blockchain
Closed issues
Fetch provisioners list from stake contract only if the list is updated #1479
GetProvisioners call consumes more than 4s (up to 15s on low-spec nodes) allegedly due to serialization in the VM. Although this is not supposed to be the case with the optimized VM (next version), this should be handled gracefully from client-side (Golang part).
GraphQL - expose raw transaction data#1481
Add a graphQL field to return the raw transaction binary.
consensus
Open issues
Update README with description of consensus phases #38
Add a short explanation of how SA works, describing the different phases.
Closed issues
Make the example node compatible with (golang) consensus implementation #33
Rust test-harness driven by the (example) node has demonstrated stable results on any run. It reaches quorum/consensus up to 1000 rounds without any issues. However this test is completely isolated from the ongoing Devnet/Testnet. As an ultimate test-scenario, an example node should join the golang test-harness cluster and participate in consensus correctly.
Document all major implementation details in form of a README #36
The README file should cover/depict:
Implementation details:
- HowTo set-up and run a consensus instance.
- Consensus static/dynamic config params.
- Usage of test-harness/example node.
- Design details of consensus implementation/diagrams.
- Overall component diagram of the example node.
Rusk
Open issues
Migrate 'Clap' to V4 #778
Migrate rusk clap to v4.
Specify version for path dependencies #779
Currently, all the path dependencies specified in the repository are specified using just the path
rusk-schema = { path = "../rusk-schema" }
Since we follow the semver rules, any update to a dependency that can be considered a "major" version should be reflected to the bin/lib version too.
However, the aforementioned dependencies are specified without the version, so cargo just build everything normally.
This can lead to some issues specially when any of these dependencies is not backward compatible anymore.
Add 'make all' and separate 'make test' #782
Add the alltarget in the Makefile and separate it fromtest.
This way, the building and testing processes can be run independently from each other.
As a result, building will be faster (as tests are not run) and testing can be made without re-building.
Poseidon252
Open issues
I would like that PoseidonBranch be made Copy, such that structures made including branches can also be made Copy. This is necessary to have proper default implementations of the dusk_plonk::Circuit trait for structures including arrays of branches.
I would like us to introduce Hash traits, for allowing for generic implementations of hashes producing BlsScalars.
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 v0.6.1
Added
- Add raw field to GQL transaction object [#1481]
- Add blocksrange filter to GQL transaction lookup [#1468]
Removed
Full Changelog: v0.6.0...v0.6.1
dusk-pki v0.11.3
Added
- Derive Default for PublicKey
schnorr v0.12.1
Added
- Derive Default for Signature and Proof
Itn-installer v0.0.4
What's Changed
- Added documentation to the README by in #9
- Change consensus participation check docs in #10
- Add logrotate by in #11
- Speed up block time in #12
- Fallback listen address to public address in #13
- Fix logrotate in #15
- Prompt for setting consensus keys password in #14
- Consensus pwd setup in #16
Full Changelog: v0.0.3...v0.0.4
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.
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.