Testnet DayLight | Release Cycle Update #12
By Yannick Planteijdt

Dec 01, 2022 - Amsterdam

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.

[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.



Share this post

Subscribe to our newsletter

Dusk on GitHub Download Whitepaper