Testnet DayLight | Release Cycle Update #9
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-ui-kit
Open issues
Create Badge component #736
Create a new atom component that presents text in a Badge.
The Badge must support a standard set of variants: ‘success’, ‘warning’,
‘danger’ and ‘brand’.
Reinstate Draw component #735
This is needed for developing applications with slide-out sidebar menus.
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.
Improve and expand test coverage__ #715__
The goal is to increase the number of tests that we run on the
components. This will result in the ability 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).
Closed issues
Navbar needs to support networks and navigation props #712
The Navbar component needs to support networks and navigation as
additional props and render the appropriate UI when these values are
set.
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.
dusk-blockchain
Closed issues
Remove genesis consistency checks #1464
At the moment of writing, dusk-blockchain repo is used to hardcode the
values of rusk’s state-root and the derived genesis-hash.
These were introduced in order to mitigate the possibility of being
error-prone after a breaking change upgrade.
Since we introduced the protocol and rusk versions, the genesis
consistency checks should not be required anymore.
hatchery
Open issues
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.
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.
Closed issues
Do not mandate weealloc #68
At the moment weealloc is hardcoded in the uplink communication library,
this is unnecessarily restrictive and it should be up to module authors
to choose allocation strategy.
Provide debug information to be easily used in modules. #53
Tools for debugging running modules.
wallet-cli
Open issues
Implement interactive mode for staker allow transaction__ #98__
Since #85 is merged, we should allow the user to do the same operation
in interactive mode
Add _context___ to errors____ #95__
By Providing the user with more specific error context, the reason why
the program fails will be more understandable for the non(technical)
user(s).
Notify the user if he tried to create more than 256 addresses for one
wallet__ #92__
We decided to support a maximum of 256 addresses for each wallet (seed),
however there is no error message once the user reaches such a limit.
Document more in detail the configuration for multiple networks__ #89__
To let the user understand how to configure the wallet’s network –
however the default values are the one used the most.
Prover and State server should have the capability to have different ipc
method #77
The prover and state server should have the capability to have different
ipc methods.
Closed issues
no cancel option available__ #97__
When an action is initialized, users can’t cancel it. The only possible
way to come back is to close the wallet, reopen it, unlock it, then
retry the action.
Implement _stake allow___ command__ #83
This is required in order to support by dusk-network/rusk#732.
Quit program if 3 times wrong recovery phrase is given during recovery
process #49
The program should quit after 3 times a wrong phase phrase
If the user is not able to fill in the correct recovery phrase, the
program will exit
Option to correct/ re-enter password if 3x wrong recover wallet__ #46__
Implement an option to correct the password / re-enter password.
Wrong _refund_addr___ description____ #86__
The argument refund_addr for the withdraw command has the following
description:
“Address to which the reward will be sent to”
Implement anyhow and thiserror__ #87__
Implementing anyhow and this error into the error handling.
Wrong condition involved `gas.is_enough()__ #91__
gas.is_enough() will always return Error::NotEnoughGas.
Restoring a wallet prints an unexpected message__ #78__
Recovering a wallet works but prints an unexpected message at the end.
BLS keys exported with wrong extensions__ #84__
When exporting the bls keys, 2 different file should be produced
- .key - Encrypted BLS key pair for provisioners in dusk-blockchain
compatible format
- .cpk - Binary file with the Consensus Public Key
Currently, the extensions are switched
Move focus to single wallet creation__ #72__
Direct the user to create one single wallet, instead of multiple
wallets.
Improve config.toml__ #57__
A better configuration file for the wallet.
rusk
Open issues
Use _tar___ to handle state’s compression instead of ____zip____ #740__
Our servers are *nix base and there is no reason to use zip instead of
tarball files, plus the ergonomics of the tar crates is better than zip
crates.
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.
Closed issues
Instruct rusk-recovery to generate custom genesis state #737
rusk-recovery should be able to receive a struct containing the desired
state
rusk: Allow to run rusk in “ephemeral” mode #734
Rusk should be able to run in a sort of ephemeral mode, deleting every
change applied to the state after it quit.
This means that if the user launches rusk twice in a row using this
custom state, any change performed by the first execution should be
discarded.
In addition, the user should be able to pass a “custom” state to use
(without using a different rusk_profile_dir). The custom state should be
a single file.
stake-contract: implement allowlist #732
An on-chain mechanism to handle staking allowlist.
Poseidon252
Open issues
Store the root of a branch separately to the levels #189
At the moment the root of the PoseidonBranch is stored in the last level
of the branch at index 1. Ideally we want the root stored separately to
the levels and not as an additional level.
This is also an issue due to the rkyv implementations. Since it is now a
Vec, PoseidonBranch<17> would parse in the exact same way as
PoseidonBranch<16> for example.
Use _component_boolean___ in the our merkle opening circuit__ #188
Use component_boolean to check for the index bits in our merkle opening
circuit.
Restructure crate features #184
The features of a crate should be named according to the features they
enable, and not the names or technicalities of its dependencies. I
propose a restructuring of the features of this crate.
Closed issues
Update CHANGELOG__ #191__
Some versions are not properly tagged and fix other minor issues.
Implement _rkyv___ for ____PoseidonBranch__ #186
The rkyv-related traits should be implemented for PoseidonBranch, and
the resulting types be made public.
Fix merkle opening circuit #181
Fix the merkle opening circuit and add tests that catch this in the
future. For people using the repository please be aware of this fix.
PoseidonTree is only available behind __canon__ #180
The PoseidonTree struct - one of the main features of this library, and
a very important component for the genesis contracts - is only available
behind the canon feature.
This means to write a smart contract one is required to bring in the
canonical library even though this is in principle not required.
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.
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.