Testnet DayLight | Release Cycle Update #17
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
push_callstack not storing module instances #162
It looks like every time push_callstack is called, a new module instance is created as existing instance is not found in instance_map
Store the merkle tree of contracts #166
Currently we use the index file to store the leaves of the tree, but we never store the full tree - meaning the leaves together with all the nodes. This would be useful for increasing the speed of root calculations, as well as an easy inspection of the state integrity.
Secure Persistent Metadata for Contracts#167
For contracts attributes such as contract's owner or contract's initialization state (meaning: contract needs-to-be initialized and contract is initialized) we have the ability of storing and accessing such attributes on a per module (contract) basis. A set of such attributes constitute a contract's metadata. Distinguishing feature of a contract's metadata is that it is managed by the VM and from the point of view of the contract it is immutable. Another way to look at it is that metadata constitutes a custom context for the contract.
Add crate-specific READMEs #174
Currently only the workspace has a README. This should be true for teach crate - piecrust and piecrust-uplink - as well.
Closed issues
Crossover doesn't behave as expected #155
If a contract fails - or panics - in its execution, the state that it has already modified will stay modified.
Events should not be emitted by panicked contracts #156
Currently, even if a contract panics, the events it emitted will be kept in the events list. This should not be the case.
Improve Atomicity description #171
citadel
Open issues
Right now we have a research paper for Citadel. We need to create a new document with the specifications to be implemented.
xsc-governance
Closed issues
Wait transaction confirmation before sending new txs #9
Transfers should be sent only when previous data are processed (to avoid Nullifier already spent error)
Add CI #11
Add Continuous integration
Specify the json input as CLI arg #13
The json path should not be hardcoded
Allow to override the transfer Timestamp #14
Processing the same file multiple times, results in the error "SeedAlreadyUsed". This is the right behavior. However, for testing purposes, we should have the possibility to "pretend" that those transactions are new.
Changing the timestamp should be enough to create a new seed.
plonk
Open issues
No range check when num_bits = 0 #746
When adding a range gate with zero bits, any witness always satisfies the circuit.
Closed issues
Refactor and add tests for logic components #734
Add in-circuit tests for the composer methods
- append_logic_and
- append_logic_xor
- append_logic_component
Add tests for append_gate #737
Add in-circuit tests for the composer methods
- append_gate
When we test a circuit, we first create a circuit description for both the prover and the verifier. This circuit description essentially is the compressed blueprint of the circuit and when we verify certain circuits, they should only pass when they have that same circuit description.
But what seems to happen in the implementation is that only the witness, public input values and the constants are crosschecked with the circuit description, but not the wire selector values.
Fix ProverKey::serialization_size #743
With the change from plonkup back to plonk #684 in the serialization size of the proverkey the poly_num were not adapted correctly, causing the serialization size to be bigger than needed.
Additionally the number of coefficients in a constraint also weren't updated. There used to be 13 coefficients but now that the lookupgate is gone, there are only 12 coefficients in a constraint.
Dusk-blockchain
Open issues
Update README on Deterministic Sortition #1507
Summarize Deterministic Sortition algorithm in this README.
Improve Generation code documentation #1508
Documentation of the Succinct Attestation code should be expanded and updated.
Fix createSortitionHash description #1509
In createSortitionHash, the i parameter is indicated as iteration number, which sounds mistakenly related to the SA iterations.
consensus
Open issues
Substitute msg-related structs with ones implemented in node-data crate #44
For better maintenance and interoperability, the wire message structures have been moved into the node-data crate together with AsyncQueue and ConsensusPublicKey.
Closed issues
Integrate consensus impl with node-data crate #42
Replace Block and Transaction struct with definitions from node-common crate.
Rusk
Open issues
node: Integrate Node library with Consensus crate #850
The Chain component within the Node crate should be responsible for initializing, running, and managing the Consensus mechanism. Several considerations need to be taken into account, including:
- Consensus keys are loaded from encrypted consensus.keys file
- Consensus reads/writes ledger data from/into the RocksDB backend
- EST and VST calls are mocked
- Inbound/outbound message queues are connected to the Kadcast reader/writer.
- Full cancellation of the Consensus routines happens on transition to out-of-sync state.
- Ledger accepts a block on Consensus_Achieved event after a sanity check.
Create example contract utilizing ZK-functions provided by host #851
Dusk virtual machine supports privacy yet we do not have an example contract that would utilize the ZK proof facility provided by the host. Such an example contract would showcase this feature of our protocol.
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.
piecrust | v0.1.0
The piecrust repository has now advanced to version 0.1.0.
- First piecrust-uplink release
- First piecrust release
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.
