Testnet DayLight | Release Cycle Update #12
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 CheckBytes derivation to ModuleError__ #116__
ModuleError enum has Archive derivation but lacks CheckBytes derivation,
which is causing serialization to fail in Rusk.
Phoenix-core
Open 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
Add new style props to Table component__ #820__
Add a new props to the Table component that will:
- disable the highlight on selected rows
- disable the style pattern on rows
- add delimiter lines between rows
Add prop to change pin radius on Map Chart__ #824__
Add a new prop that allows the user to change the radius of the pin used
on the Map Chart.
wallet-cli
Open issues
Wallet access out of range panic__ #119__
When having unlocked the provided wallet, it crashes on retrieving the
balance of the first address.
It is important to NOT access any other address. Doing so will fix the
issue as a workaround.
Closed issues
Build rusk-wallet using libssl3__ #112__
Current linux wallet-cli release is built on ubuntu-latest
(ubuntu-20.04) that uses libssl.1 shared library.
In order to let the wallet-cli run on OS that target the latest libssl
version (like ubuntu-22.04) a new target should be added.
Align provisioner keys file extension__ #114__
Provisioner keys are currently exported with the .key extension, while
the node configuration expects a provisioner key-pair with the .keys
extension. To prevent ambiguity and confusion, it makes sense to align
the extensions to the correct .keys extension.
Increase default gas limit for expensive operations__ #116__
The default gas limit is currently set to 500M LUX. For transfer
operations this is sufficient. For other operations like staking and
unstaking this leads to out of gas transaction failures. Users need to
explicitly set a correct value.
itn-installer
Open issues
Node launch prerequisites__ #4__
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.
dusk-blockchain
Closed issues
Missing block detection__ #1470__
Logging of missed and produced blocks in base58, along with the public
key belonging to the provisioner.
Poseidon252
Open issues
Add benchmark for merkle opening__ #197__
Add benchmarks for the merkle-opening circuit
- Circuit compilation
- Proof creation
- Proof verification
We need benchmarks in order to track performance throughout the
development.
Add benchmarks for PoseidonCipher ZK and non-ZK__ #198__
We need benchmarks in order to track performance throughout the
development.
Closed issues
Poseidon252 benchmarks__ #81__
Create benchmarks for:
- ZK Merkle opening.
- PoseidonCipher ZK and non-ZK.
consensus
Open issues
Populate example testbed nodes with provisioners keys from external
files__ #30__
In the direction of having both Golang and Rust implementations working
together in one cluster, we should be able to preload the same list of
provisioners (so called genesis state provisioners) in rust example node
.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.
Closed issues
Make serialization of consensus messages fully compatible with dusk wire
protocol__ #22__
Current serialization of consensus messages (NewBlock, Reduction,
Agreement) does not match fully the serialization of the dusk wire
protocol.
rusk
Open issues
Port the Rusk Test Infrastructure to use Piecrust__ #773__
Migrate rusk test infrastructure 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.
Closed issues
Upgrade kadcast__ #771__
The new kadcast version uses a better error handling while processing
UDP packets.
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.
Wallet-cli - __v0.13.0__
__The wallet-cli repository has now advanced to version 0.13.0
Changed
- Changed fn signature in gas::new to include the gas limit [#116]
- Change request_gas_limit fn signature to accept a gas limit option
[#116]
- Change (un)stake, allow stake and withdraw default gas limits to
sane defaults [#116]
- Change exported consensus keys extension to .keys __[#114]
__
Itn-installer - __v0.0.2__
__The itn-installer repository has now advanced to version 0.0.2
Changed
- Fixes and improvements in #1
##
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.