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.
piecrust
Open issues
Add documentation of piecrust-uplink::types #139
Add crate level documentation for the types module of piecrust-uplink
Structure modules and memories to allow Session concurrency #145
To allow for multiple sessions to be executed in parallel, the way in which the modules are structured on disk needs to be changed to support it.
It should be possible to base sessions on top of different commits and have them execute concurrently, without interfering with each other.
This also means removing the concept of "current_commit" from the crate, since it no longer makes sense in the context of concurrent sessions.
Closed issues
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.
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.
Improve Piecrust Error Infrastructure to support conversions #132
Piecrust error needs to implement trait std::error::Error in order to be easily integrated with client's code.
Rename the wasm module tests #142
Rename the wasm module tests to the name of the module they are meant to be testing.
Automatic Module Redeployment after Session Restore #144
Information about which modules were deployed by the session is currently lost after the session is committed and destructed. When a session is restored from a commit, the user needs to manually deploy necessary modules. Automatic mechanism for redeployment is needed so that after restore the user of a session operates as if the session was not stored and restored.
Phoenix-core
Open issues
Avoid redefinition of types in different crates #121
We should try and avoid redefining types defined in other crates, or using "untyped" fields. Currently the Transaction::proof field is a Vec<u8>, when it really should be a dusk_plonk::Proof, and there is also a ModuleId type alias that really should be piecrust_uplink::ModuleId.
Closed issues
Add functions and data structures for interacting with the genesis contracts #119
During the rusk migration to piecrust, it has become clear that it is necessary to have a place for structures used as arguments for the genesis smart contracts. Since we've already included the concept of a Transaction in this crate, it also makes sense to include other components of the transaction model, such as sending and withdrawing value to and from a contract, or staking and unstaking.
Remove enc, nonce and R from the hash of a note #123
Currently, when we compute the hash of a note (in the circuit and in the Merkle tree of notes), we include the parameters named enc, nonce, and R (where R is a part of the stealth address). We figured that these three elements are not needed in this computation. Hence, they can be removed from the circuit. This change will affect the circuit and the storage of notes in the Merkle tree of notes.
Poseidon252
Closed 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.
Implement dusk_bytes::Serializable trait for PoseidonBranch #203
A PoseidonBranch is now constant size for a given depth. As such, it can implement dusk_bytes::Serializable making it easier to send through the wire. This might require other structures to implement the trait as well.
Dusk-ui-kit
Open issues
Skeleton Loader overflow is not hidden #902
When the 'rounded' prop is passed to the SkeletonLoader component the loader animation is not rounded around the corners.
Upgrade Storybook to version 7 beta #906
Upgrade Storybook to version 7 beta
xsc-governance
Open issues
Add a ref_id to the transactions generated by the app #1
As per the transfer contract, having a non mandatory ref_id per transaction might be useful for future reference.
Add all supported actions other than "Rebalance" #2
Currently only Rebalance is supported, however we also need to support Withdraw, Deposit and Fee.
Check if rebelance and deposits work over correct security when parsing json #4
Panic if it's wrong, else proceed.
plonk
Open issues
Add tests for assert_equal_public_point #727
Add tests for assert_equal_public_point method of the composer:
- sanity test
- fails when the points are not equal
- fails when only one of the coordinates are not equal
Add tests for component_mul_generator #729
Add tests that test malicious usage of component_mul_generator
Restructure integration tests #731
Restructure integration tests and add common verification functions that all tests can use. Also aim for one file per tested functionality.
Closed issues
Bug in point equality assertion #720
Point equality is not being done correctly. b's y component is being compared to itself here
Remove the 'src/circuit.rs' file since the module now exists under the 'composer' module but the original file seems to not have been deleted when the module moved.
Add more tests for point equality assertion #725
Add tests for assert_equal_point method of the composer:
- sanity test
- fails when the points are not equal
- fails when only one of the coordinates are not equal
Fix negation of public input in assert_equal_public_point #728
When asserting that a point is equal to a public point in-circuit, the coordinates of the public point are appended to the circuit in their negative form while they should be positive.
The fix requires to change append_equal_constant to append the constant in its positive form as well.
Dusk-blockchain
Open issues
Review Sortition code #1486
This issue tracks code reviewing related to Deterministic Sortition.
Closed issues
node: Implement basic DB operations to be used by mempool service #1489
citadel
Closed issues
The actions should be set up to run the tests after pushing commits.
The experimental and demo code should be removed as they are no longer used.
Add the badges of the CI and the github repository in the Readme.
rusk
Open issues
node: Integrate RocksDB as backend engine for blockchain db #806
This issue is an effort to investigate if rocksdb wrapper crate could serve as a back-end storage for storing blocks and blockchain metadata as we already do with goleveldb in dusk-blockchain.
governance-contract: add broker as entity to the contract #807
At the moment, we have only two entities in the contract, the owner (authority) and the shareholders.
However, we need to add a third one, called broker.
The role of the broker is to act as middle man between shareholders.
governance-contract: Allow authority and broker to be set at runtime #808
Currently the authority can be set only at compile time, this is an issue for rusk-recovery when it wants to deploy multiple governance contracts with different authorities (since the wasm already includes the authority).
governance-contract: Fix as_scalars implementation for Transfer #811
Currently, the to field is not being serialized as a Scalar in the as_scalar impl of the Transfer struct.
governance-contract: Perform signature verification for unit tests #814
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?
Remove enc, nonce and R from the hash of a note #815
Currently, when we compute the hash of a note (in the circuit and in the Merkle tree of notes), we include the parameters named enc, nonce, and R (where R is a part of the stealth address). We figured that these three elements are not needed in this computation. Hence, they can be removed from the circuit. This change will affect the circuit and the storage of notes in the Merkle tree of notes.
Change note_type to be a public input of the circuit #816
Currently, the transfer circuit has the type of a note as a private input. With Citadel, we allow the creation of other types of notes that store information that is not monetary. As a result, we should set note_type as a public input. This change will prevent from spending notes that do not hold a "monetary value" but other types of information (e.g. a personal attribute).
node: Add node library crate to rusk CI #821
Node crate should be compiled and unit-tests executed on any CI.
A few considerations to be taken into account:
- RocksDB static (C++) library may take a few minutes to compile. Build cache should be used to speed up CI.
- Check if libclang-dev should be pre-installed.
- Fix if any clippy warnings.
node: Implement basic DB operations to be used by Mempool service #822
It's worth considering utilizing the same RocksDB instance to store verified transactions of the Mempool and take advantage of the low write-latency provided by L0 (memtable). The Mempool can also benefit from other features of RocksDB
- Use of bloom filters in memtable may speed up finding out that a tx_hash does not exist.
- Use of WAL (Write-Ahead-Log) may provide durability on-demand.
- Use of flush-on-disk, if cumulative size of stored transactions is above a threshold.
Closed issues
Migrate rusk-recovery to use piecrust #795
Migrate rusk-recovery 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.
In particular, the genesis state generation needs to be properly ported.
Design and implement n-tier architecture to facilitate node development #798
Add database module as a persistence layer #803
node: Integrate RocksDB as backend engine for blockchain db #806
This issue is an effort to investigate if the rocksdb wrapper crate could serve as a back-end storage for storing blocks and blockchain metadata as we already do with goleveldb in dusk-blockchain.
rusk-recovery: add pre-allowed nodes to default testnet state #818
Add dusk nodes as pre-allowed stakers into testnet genesis state.
Rusk-recovery is unable to restore a tar state from the network #820
When rusk-recovery uses a base-state it's unable to restore the state.
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.
Poseidon252 v0.28.0
Added
- Implement dusk_bytes::Serializable for PoseidonBranch and PoseidonLevel [#203]
- Add benchmarks for merkle opening proof [#197]
Changed
- Derive Copy for PoseidonBranch [#200]
Phoenix-core v0.18.1
Added
- Add allow_signature_message, stake_signature_message,
unstake_signature_message, and withdraw_signature_message
to generate signature messages for stake contract interaction [#119] - Add stct_signature_message and stco_signature_message to generate
signature messages for transfer contract interaction [#119] - Add Stake, Unstake, Withdraw, Allow, and StakeData structs to allow
interaction with the stake contract [#119] - Add Stct, Wfct, Stco, Wfco, Wfctc, Mint, and TreeLeaf structs to
allow interaction with the transfer contract [#119] - Add Transaction structure [#116]
citadel v0.1.0
Added
- Initial version of the protocol, including the gadget and license modules.
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.