Testnet DayLight | Release Cycle Update #10
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.
kadcast
Open issues
Remove unnecessary expect/unwrap__ #115__
The codebase is full of unwrap/expect.
dusk-ui-kit
Open issues
Toggle component breaks the web #763
We can’t set value attributes on Toggle components (e.g. radios and
checkboxes).
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.
Closed issues
Create new DatePicker component #750
A DatePicker component, as specified here.
Create Badge component__ #736__
Create a new atom component that presents text in a Badge. According to
this Figma: #735
The Badge must support a standard set of variants: ‘success’, ‘warning’,
‘danger’ and ‘brand’.
Improve and expand test coverage #715
I want to increase the number of tests that we run on the components. I
want 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).
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.
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.
wallet-core
Closed issues
Add a method to execute generic contract calls__ #66__
Currently we can call only the genesis contract (transfer and stake);
those two contracts have ad hoc calls.
We should implement a more general purpose method to execute any
contract, once the contract id and the data to pass to it are provided.
wallet-cli
Open issues
Display staking address__ #105__
The user needs to know which staking address (BLS Public Key in base58)
belongs to his wallet.
This is required in order to let the staking owner to allow the staker
on chain.
Handle SIGTERM properly__ #104__
The current implementation simply quit the program.
To be more precise, some parts of the code can easily handle the
cancellation, but the current implementation simply catches it and
shades it.
Improve gql code structure__ #102__
Optimize code, improve error handling so it will align with the rest of
the code.
Closed issues
H__andle properly requestty::prompt response____ #100__
The current use of requestty doesn’t handle properly when the OS
interrupts the current process.
If the users try to quit while the client is waiting for a user feedback
(e.g: the user press CTRL+C in almost any menu) the executable panics.
dusk-blockchain
Closed issues
GQL: Search txs for blocks range__ #1468__
Add a blocksrange filter to lookup transaction (similar to the range
filter for blocks lookup)
Harness tests won’t work after rusk-recovery changes__ #1466__
Now rusk-recovery requires an input file to generate the genesis state,
and dusk-blockchain doesn’t support it yet.
Poseidon 252
Closed issues
Store the root of a branch separately to the levels__ #189__
Rethink the way we store the root in the PoseidonBranch.
consensus
Open issues
Implement request-candidate-block procedure #7
Request, provide and collect a candidate block routines are not
currently supported. This makes it impossible to create a winning block
on reaching consensus.
Implement AggrAgreement message build, publish and collect #6
Current version of consensus implementation does not support
AggrAgreement message. This should be added in order to be compatible
with the impl in golang.
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.
Enable CI__ #15__
Enable CI checks.
Optimize agreement messages verification__ #14__
As per the golang impl, consensus (Accumulator) should be capable of
verifying agreement messages concurrently or in parallel. By the
default, golang impl spawns 4 workers. This could be achieved by
implementing any of the following approaches:
1 .Run a separate tokio::runtime with 4 dedicated threads to perform
solely agreement message verification.
2. Use tokio::spawn_blocking() or native thread::spawn()
3. Use data-parallelism library (e.g Rayon)
NB. For options 2 and 3, we’ll need to bridge with sync code.
Execute EST and VST calls in selection and reductions steps__ #11__
A trait that defines EST calls (execute_state_transitions,
verify_state_transition) should be passed to consensus from outside so
that block generators can execute state transition and reductions steps
can verify state transition.
Update step timeout value on any occurrence of timeout event__ #9__
Support consensus cancellation__ #8__
On receiving a valid future block, the synchronizer should be able to
cancel a running consensus instance.
Use task:abort to terminate both agreement_loop and main_loop tasks__
#5__
Instead of having an additional oneshot channel to sync up both tasks,
we should consider deprecating it in favor of a more idiomatic and
efficient task:abort.
Migrate consensus implementation__ #2__
hatchery
Open issues
Documentation of the project__ #103__
It would be extremely useful to have a document to refer to explaining
how the virtual machine works in broad terms including, but not limited
to:
- Virtual machine ABI. The higher level concepts of the ABI, such as
the argument buffer, host calls, serialization, etc… should be
detailed in such a document.
- Workings of the VM. How the virtual machine works internally to
execute modules, how it “reacts” to modules calling the host, how it
commits and restores, etc…
- Certain concepts need to be detailed like host queries, metering,
etc…
Implement Diffing for Commit/Restore Mechanism__ #100__
Currently, modules’ memories are committed without diffing, so even a
modest change will require a full memory storage. This is suboptimal for
disk usage in the long run. Diffing will enable to decrease disk usage
by the order of magnitude.
Improve Last Commit Mechanism__ #99__
Last commit mechanism is a way to distinguish a commit that should be
loaded into modules’ memories on instantiation. Currently,the last
commit file is a copy of an original commit file. This approach is
wasteful as it duplicates the file for the mere purpose of marking it as
“last”. More efficient mechanism should be used.
Module constructors__ #93__
There should be a way to provide modules some data on deployment, which
is then used to initialize the state. Currently it is only possible to
“bake in” the initial state in the WASM bytecode. This precludes the
module writer from writing a module once, and then reusing the same
bytecode with different initial states. This use-case should become
possible.
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.
Closed issues
Usage example and build instructions in README__ #102__
To ensure viewers of the project can build, run, and test the project as
well as understand how to use it, I would like the following sections
added to the README:
Last commits loaded only into (session’s) fresh module’ memories__ #91__
Current implementation loads last commit’s memories into session’s
memories on every instantiation, which implies incorrect semantics when
last commit is present.
Session Commits Persistence__ #89__
After the system is restarted, we need to be able to find and restore
session’s commits that have been performed in the past.
Replace workarounds for skipping WASM module memory initialization__
#86__
Modules should be able to query the call stack__ #84__
Modules should be able to query who they are being called by. This is
necessary to allow modules to decide what to do based on who they are
being called by. There should also be a way to tell if the module is the
first in the call chain.
Meter execution of modules and provide host calls__ #83__
A transaction path should be metered and it should be possible to set a
limit to the number of “points” used during the path of a transaction.
Some host calls should also be made available. In particular the module
should be able to query the point limit and the points spent.
This is necessary to be able to charge gas on transaction.
Support an _event___ mechanism____ #82__
Modules should be able to emit events during transactions. This is
necessary to signal external applications that “something” happened.
Downstream they should be included in a block in the form of a bloom
filter.
Support the _height___ host call____ #81__
A module should be able to query the host for the current height. This
is necessary for use cases relying on time like the staking-module.
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.
Module State Persistence__ #50__
We need to persist module states. When a session is dropped and then
created again, or system is restarted, modules should be in a state
which was present at the last session’s commit (or if there was no
commit, at their initial state).
Upgrade to _wasmer___ latest version____ #44__
Upgrade the wasmer dependency to the newest version.
Snapshot meta-persistence - storing collections of per-world and
per-module’…#38
In addition to actual snapshots, also lists of snapshot ids need to be
stored. This includes world snapshot ids for the global context, and
module snapshot ids for the module contexts. Snapshots should be
“restorable” with no regard if the system was restarted or not after
they were created.
World persist and restore refinement__ #33__
Persisting the world state should also persist the currently deployed
modules.#26
When restoring a persisted world state, the modules deployed in that
world should be available.
Port _self-snapshot___ test from ____rusk-vm____ #24__
The self-snapshot test should be ported from rusk-vm.
Persist and restore VM state on disk.__ #1__
Persistence of VM memory on disk.
rusk
Open issues
Migrate to __piecrust____ #760__
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.
Port the _rusk___ library to use ____piecrust____ #759__
Migrate rusk 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.
Port stake contract to piecrust__ #758__
The stake contract needs to be ported to the new way of writing
contracts defined by piecrust-uplink. This is a necessary step to a full
port of rusk to use piecrust instead of rusk-vm.
Port transfer contract to __piecrust____ #757__
The transfer contract needs to be ported to the new way of writing
contracts defined by piecrust-uplink. This is a necessary step to a full
port of rusk to use piecrust instead of rusk-vm.
Using _base_state___ generates corrupted state____ #754__
Using rusk-recovery-state with an init toml that manipulates a base
state, results in a corrupted state.
The above mentioned state is working properly for transacting, but
raises an error as soon as the stake contract is called.
Automatically add the wasm32 toolchain when using toolchain__ #751__
Add a clear and concise description of the reason why this needs to be
worked on. Focus on the big picture rather than implementation details.
What use case does it support? What is the expected outcome?
Closed issues
Change default state of rusk-recovery to use a prebuilt state__ #755__
Current implementation of rusk-recovery uses a “genesis” base_state to
manipulate.
But this won’t work as per #754
Use external base state for rusk-recovery-state__ #750__
The current impl of rusk-recovery-state generates a local state with
some init configuration applied on top of that state. Hence, the
generated state suffers for a non-deterministic state-root depending on
which LLVM generated the wasm contracts bytecode.
Makefile: re enable the state recipe__ #747__
On previous PR the recipe for the state make state has been removed due
to the need to specify an input-file for rusk-recovery-state.
Rusk won’t build with new rustc_tools_utils__ #745__
Rusk and rusk-recovery won’t build anymore after upgrading
rustc_tools_utils to the latest version.
Specify genesis state as toml configuration__ #741__
The idea is to deprecate the –testnet flag of rusk-recovery.
This flag is used to identify if the state that is going to be generated
should be compatible with testnet or just a local genesis state for unit
tests.
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.
____As you can see__, development is continuous and this list is not
exhaustive. For example, minor issues and advancements 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.12.0
The wallet-cli repository has now advanced to version 0.12.0
Added
- Add default.config.toml for the default configuration settings [#57]
- Add settings subcommand to show the current settings [#57]
- Add –password as global argument [#57]
- Add –skip-recovery to create subcommand [#57]
- Add –file to restore subcommand [#57]
- Add Settings type to merge Config (from toml) and WalletArgs
(from CLI) [#57]
- Add address module
- Add gas module
- Add settings module [#57]
- Add is_enough method to Gas
- Add Create, Restore and Settings for both Command and RunResult
enums [#72]
- Add LogFormat and LogLevel enums to enforce the set of value from
args [#57]
- Add From block and Last block during fetching
- Add missing documentations
- Add Seed type in store module
- Add stake-allow command [#83]
Changed
- Change program behavior to quit if wrong seed phrase is given [#49]
- Change program behavior to have three attempts for entering a
password [#46]
- Change error handling to use the anyhow crate in bin[#87]
- Change error handling to use the thiserror crate in lib[#87]
- Change config.toml format [#57]
- Change from multiple wallets to one wallet for a single profile dir
[#72]
- Rename dusk module to currency module
- Rename address subcommand to addresses
- Change set_price and set_limit for Gas to works with Option
- Change part of the functions to either receive the password or the
settings [#57]
- Move config module outside io [#57]
- Change few UI strings
- Update rust-toolchain from nightly-2022-02-19 to nightly-2022-08-28
Removed
- Rename –data-dir argument option to –profile [#57]
- Remove –wallet-name argument option [#72]
- Remove –network argument option to choose the network to connect
with [#57]
- Remove interactive subcommand [#57]
- Remove –skip-recovery as global argument [#57]
- Remove –wait-for-tx (now all the transaction wait by default) [#57]
- Remove merge method from Config in favour of Settings type [#57]
- Remove Command::NotSupported [#57]
- Rename DEFAULT_GAS_LIMIT, DEFAULT_GAS_PRICE, MIN_GAS_LIMIT
- Remove Addresses type in favour of Vec<Address>
- Remove refund-addr arg in withdraw command [#86]
Fixed
- Fix wrong condition involved gas.is_enough()[#91]
- Fix balance subcommand: it didn’t work because the address given
wasn’t claimed
- Fix BLS keys exported with wrong extensions [#84]
plonk - __V0.13.0__
The plonk repository has now advanced to version 0.13.0
Added
- Add support for rkyv-impl under no_std
Changed
- Update dusk-cdf to 0.5 #709
Poseidon252 - __V0.27.0__
The Poseidon252 repository has now advanced to version 0.27.0
Added
- Add support for rkyv-impl under no_std
- Add ranno version 0.1 to dependencies #180
Changed
- Change PoseidonBranch to have two fields - root and path. The path
is
now a fixed length array. #189
- Change PoseidonTree to build only with the alloc feature #180
- Change PoseidonTree to take a generic Keyed over the leaf type
instead of a PoseidonAnnotation #180
- Make PoseidonTree::new const #180
- Update microkelvin from 0.15 to 0.17 #180
- Update nstack from 0.14.0-rc to 0.16 #180
Removed
- Remove PoseidonBranch Default implementation #189
- Remove std feature #180
- Remove canon and persistence features #180
- Remove Error struct #180
- Remove canonical and canonical-derive from dependencies #180
- Remove PoseidonMaxAnnotation #180
Fixed
- Fix merkle opening circuit #181
- Fix CHANGELOG version links #191
nstack - __V0.16.0__
The nstack repository has now advanced to version 0.16.0
Added
- Add annotations specific to the nstack
Changed
- Update to use ranno annotations
- Update microkelvin from 0.13.0-rc.0 to 0.17. The wide range is due
to experimentation with rkyv in microkelvin.
- Change rust-toolchain to stable
microkelvin | Release [V0.17.0__
__](https://github.com/dusk-network/microkelvin/releases/tag/v0.17.0)
The microkelvin repository has now advanced to version 0.17.0
Change
- Use ranno in lieu of the previous annotations.
Removed
- Remove Link
- Remove annotations
- Remove persistence feature
schnorr | Release __V0.11.1__
The schnorr repository has now advanced to version 0.11.1
Added
- Add support for rkyv-impl under no_std
phoenix-core | Release __V0.17.1__
The phoenix-core repository has now advanced to version 0.17.1
Added
- Add support for rkyv-impl under no_std
dusk-pki | Release __V0.11.1__
The dusk-pki repository has now advanced to version 0.11.1
Added
- Add support for rkyv-impl under no_std
jubjub | Release __V0.12.1__
The jubjub repository has now advanced to version 0.12.1
Added
- Add support for rkyv-impl under no_std
bls12_381 | Release __V0.11.1__
The bls12_381 repository has now advanced to version 0.11.1
Added
- Add support for rkyv-impl under no_std
- Add wrapper type for subtle::Choice
Change
- Derive manual implementations of rkyv trait by introducing a wrapper
for the
subtle::Choice type.
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.