Testnet DayLight | Release Cycle Update #11
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
Closed issues
Implement deploy_with_id #108
Modules should be deployable with a ModuleId defined by the host. This
is necessary for enabling modules whose IDs are known prior to
deployment.
Move deployment of modules to Session level #111
Currently the deployment of modules happens at the level of the VM
struct. This is undesirable since this means that a deployment is
“global” - meaning for all sessions. All changes of VM state should be
done via a Session and subsequent commitment.
Make Session borrow a mutable VM instead of cloning #113
At the moment, the VM is cloned into the session, this makes the API a
bit confusing, since it’s unclear what commiting the session actually
changes.
phoenix-core
Closed issues
The dusk-poseidon dependency should be updated to version 0.28. This is
necessary to make use of the fixes and improvements made there, together
with the one made in dusk-plonk.
Kadcast
Closed issues
Remove unnecessary expect/unwrap #115
The codebase is full of unwrap/expect.
Implement network blocklist #117
Add the possibility to block specific peers
Dusk-ui-kit
Closed issues
CI Action takes too long to execute #250
CI Action regularly takes > 5 mins to complete. This is too long given
the scope of work it does.
OS preference for dark mode is overriding user-preference for light mode
#538
When the user has dark mode preferred on their operating system, but
changes to light then this preference will be overwritten when they
change to another app.
Reinstate Draw component #735
This is needed for developing applications with slide-out sidebar menus.
add DropDown scrollable options list #758
Add functionality to the DropDown component that will allow the list of
options to be scrollable and with a fixed length. This should be turned
on and off based on a new prop.
Toggle component breaks the web #763
We can’t set value attributes on Toggle components (e.g. radios and
checkboxes).
wallet-cli
Open issues
Expose rusk client to construct a wallet instance #108
To construct a core wallet instance, we need the rusk client struct to
connect to the network,
https://github.com/dusk-network/wallet-cli/blob/main/src/wallet.rs#L279.
It needs to be pub instead of pub(crate)
Make install fails #110
\Cloning the repo and installing the wallet on my PC using the command
“make install” fails with the following logs:
cargo b –release
process_begin: CreateProcess(NULL, cargo b –release, …) failed.
make (e=2): The system cannot find the file specified.
make: *** [Makefile:5: build] Error 2
plonk
Open issues
Prover and Verifier are **not** type-safe #713
While these structures are type-safe while in memory, the moment they’re
serialized and subsequently de-serialized, they cease to be so. This
means that it is possible, for example, to de-serialize a Verifier<C1>
from a payload of Verifier<C2>with C1 != C2.
Dusk-blockchain
Open issues
Missing block detection #1470
Logging of missed and produced blocks in base58, along with the public
key belonging to the provisioner.
consensus
Open 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.
Closed issues
Use a cached version of BLS public keys compressed form #18
The implementations of PartialOrd and Ord of PublicKey wrapper are based
on the CPU-intensive dusk_bls12_381_sign::PublicKey::pk_t()::to_bytes().
This was spotted as a bottleneck on CPU profiling. To avoid frequent
serialization into compressed form (to_bytes) , a cache field should be
used instead.
Implement an example node that runs consensus in a Kadcast network #19
An executable that integrates both consensus and kadcast libraries
should be built as an example node. This node binary should accept a CLI
param of a provisioner unique ID.
Due to the lack of a genesis block, on start-up the example node is
supposed to generate up to N provisioners (also a CLI param) with
deterministic seeds (from 0 to N).
Additionally, this task should provide a Makefile target/Bash script
that can set up and run a test-harness of N nodes. Eventually, this
could turn into github action and serve as an end-to-end/system test.
This bash script may also deprecate the current single-process testbed.
Wrong serialisation of BlsPublicKey #20
Current codebase uses pk.pk_t().to_bytes() instead of pk.to_bytes()
Use and apply default rustfmt max_width #25
we should re-format all files with rustfmt.toml, max_width = 80.
Rusk
Open issues
The circuits should be ported to use plonk version 0.13. The API has
changed significantly and numerous improvements in terms of speed and
memory efficiency have been made. It is better if our networks can make
use of them.
Closed issues
Port rusk-abi to be compatible with piecrust-uplink #761
Currently our smart contracts use rusk-abi which essentially wrap the
dusk-abi with specifics such as hashing, hardcoded contract addresses,
etc… This means this crate needs to be ported before the smart contracts
for them to work.
Migrate to piecrust #765
We should port rusk to use piecrust instead of rusk-vm. This is
necessary to make full use of the new contract ABI and the improvements
to speed and disk-space efficiency provided by piecrust.
CRS is not created #767
rusk-recovery-keys doesn’t create the common reference string.
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.
Bls12_381__ - v0.11.2
The Bls12_381 repository has now advanced to version 0.11.2
Fixed
- Fixed rkyv-impl feature by bringing in rkyv/alloc on alloc feature
- Make g1 and g2 Archived* structs only available on rkyv-impl
Plonk - v0.13.1
The plonk repository has now advanced to version 0.13.1
Fixed
- Remove manual implementation of CheckBytes for ArchivedProverKey.
This
is necessary since rkyv/validation was required as a bound.
dusk-pki - __v0.11.2__
The dusk-pki repository has now advanced to version 0.11.2
Changed
- Update dusk-poseidon from 0.26 to 0.28
Poseidon252 -v0.28.0
The Poseidon252 repository has now advanced to version 0.28.0
Changed
- Update dusk-plonk from 0.12 to 0.13
- Update dusk-hades from 0.19 to 0.20
schnorr - v0.13.1
The schnorr repository has now advanced to version 0.13.1
Changed
- Update dusk-plonk from 0.12 to 0.13
- Update dusk-poseidon from 0.26 to 0.28
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.