Testnet DayLight | Release Cycle Update #19
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 for piecrust-uplink::state #189
Add documentation to a number of functions in the state module of piecrust-uplink like: host_query, query and transaction.
Add crate level docs for Piecrust Uplink #190
Provide crate level documentation for Piecrust Uplink, by adding a proper description in the lib.rs file.
Add documentation for piecrust::imports #195
Add documentation to the module imported functions in the imports module of piecrust.
Closed issues
Add documentation of piecrust-uplink::types #139
Add crate level documentation for the types module of piecrust-uplink.
Alloc error handler removed #192
In the latest nightly build (rustc 1.71.0-nightly (f5559e338 2023-04-24) the alloc_error_handler attribute has been removed. handle_alloc_error defaults to panic now for no_std environments.
As a result, the CI breaks and divulges from the nightly specified in the repository itself.
consensus
Open issues
Add CHANGELOG #54
Add CHANGELOG.
Closed issues
Resolve VoteSetTooSmall error in consensus accumulator #53
Once consensus has been running smoothly and producing blocks for a few rounds, some of the nodes encounter the VoteSetTooSmall error. This problem is only observed after activating block re-broadcast on the node side.
merkle
Open issues
Remove positions map from the tree structure #24
Given the fact that we can arbitrarily walk the tree, it shouldn't be necessary to include existing positions since we could use a walker to determine both how many positions in the tree are filled (Tree::len()), as well which positions are filled (Tree::contains).
Closed issues
Add Merkle opening verification #1
It should be possible to verify that an item is the leaf of the MerkleOpening.
Repeated computation of zero_item for a given height is needlessly expensive, since they cannot depend on any state of the Aggregator. Since these items are likely to be hashes, it would be nice to cache the result for a given height and reuse when appropriate.
Add Aggregate impl for blake3::Hash #11
Add merkle tree using blake3 behind a blake3 feature.
derive built-in traits for Tree and Opening #13
Derive the built-in traits Debug, Clone, PartialEq, Eq and Hash for Tree and Opening.
CheckBytes<DefaultValidator<'_>> is not implemented #15
Add a Walker for the merkle tree that iterates through the leaves of the tree.
jubjub
Closed issues
JubJubExtended - No Default implementation #63
The extended point can't ever be derived from default because it will always be an invalid point with z = 0.
Add CHANGELOG #90
Add a CHANGELOG.
Add tests for compute_windowed_naf #104
Add more unit tests for the compute_windowed_naf method for scalars. Test different scalars and window-sizes.
bls12_381
Closed issues
Update CHANGELOG #84
dusk-blockchain
Open issues
Make Sortition code consistent with new naming system #1521
The new README on Committees and Sortition change the naming convention used so far.
For instance, 'size' is referred to as 'voting credits'.
The code should reflect the description by updating the corresponding variable names.
citadel
Open issues
Research on the computation of k_lic #35
Right now, we compute a value k_lic = G · H(lsk), where lsk is the license secret key, and H() is a hash function. k_lic is a symmetric key used to encrypt data using Poseidon, and shared between two parties. Likewise, the other party should never learn lsk.
We should research if this approach is correct, and in that case, if using a truncated hash function (either Blake or Poseidon) is secure in this scenario.
Plus, it is important to remember that this approach was followed because, if we provide kdh as done in Phoenix, the SP can recover the public key of the user from kdh and lpk.
rusk
Open issues
We need to write the contract that handles the Citadel licenses, following the Citadel specs.
node: Ensure consensus shutdown code is executed on aborting #866
On canceling a consensus task due to an event of accepted block, it turns out that child (tokio) tasks are not aborted. After investigating, it was found out that the act of aborting the main consensus task does not trigger the calls for aborting agreement and main loop tasks.
node: Enable collecting telemetry data of tokio runtime state #868
We should allow tokio_console to collect telemetry data of tokio runtime state.
Create smart contract documentation #870
Create comprehensive and well-structured documentation for the Piecrust smart contract platform to enable third-party developers to easily understand, build and deploy smart contracts while ensuring they follow best practices and are aware of any platform caveats.
node: Implement DataBroker service to expose ledger data in Kadcast Network #872
DataBroker component should run as background tokio task handling following messages from Kadcast network.
- GetCandidate
- GetData
- GetBlocks
- GetMempool
On occurrence of any of them we should filter invalid requests in a fast manner and spawn a concurrent task to retrieve data and response.
With this issue we should provide a handler for GetCandidate message request.
Closed issues
node: Implement block header verification #863
We should extend the block acceptance procedure with full verification of the block header. This should cover block certificate verification as well.
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.
We’ve included a small FAQ section below to make sure the community understands our intention with Release Cycles.
FAQ
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.
