Testnet DayLight | Release Cycle Update #16
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
Provide coverage for non-unique diffed module commit ids #152
Rusk's wallet_grpc test provides a scenario in which module commit ids are appearing repeatedly in a commit history. This requires diffed commits to be stored independently in the presence of multiple repeating ids and not overwrite each other.
Closed issues
Switch diffing implementation to qbsdiff #150
Crate bsdiff is not reliable and we need to switch to qbsdiff.
rusk
Open issues
Allow users to mint NFT notes #828
We are working on deploying the NFT model in Rusk. For that reason, new note types will be used, and are being implemented already in phoenix-core:
0 - Transparent note
1 - Obfuscated note
2 - Transparent NFT note
3 - Obfuscated NFT note
4 - Transparent Message note (this one is NOT appended to the Merkle tree)
5 - Obfuscated Message note (this one is NOT appended to the Merkle tree)
We want Rusk to accept those notes created by the user. Basically, a user will create those, and will add them into a transaction. The ZKP of such a transaction will prove that the user has enough money to pay for the gas, but the new NFT note's commitments will not be part of that ZKP. Actually, NFT notes have no commitment. We can consider setting them to 0 in the code, or creating a new struct.
node: Add TOML configuration support #831
Add the possibility to specify the configuration using a TOML file
Upgrade tar-rs dependency #832
Current used version of tar-rs has 2 major vulnerabilities:
node: Share common structs and functionalities in a distinct crate #834
It is advisable to consider encapsulating common data structures and functionalities in a distinct crate. The new crate should allow both Consensus library and Node library to use any global data structs (like Ledger Block and Ledger Transaction) together with any common traits definitions.
Change broker to be a PublicKey (not a bls one) #845
At the moment the broker is not used in the contract, but it should be.
node: Add transactions merkle tree root to the block header #847
This is needed in order to reflect protocol changes made in dusk-network/dusk-blockchain#1499
node: Add Iteration field to Block header #848
This is needed in order to reflect protocol changes made in dusk-network/dusk-blockchain#1500
Closed issues
node: Add node library crate to rusk CI #821
Node crate should be compiled and unit-tests executed on any CI.
node: Implement basic DB operations to be used by Mempool service #822
It's worth considering utilizing the same RocksDB instance to store verified transactions of the Mempool and take advantage of the low write-latency provided by L0 (memtable). The Mempool can also benefit from other features of RocksDB
Add integration tests to the governance contract #833
Currently the governance contract source does not have integration tests. We need at least a bare minimum to ensure the logic is correct.
Remove allowlist from governance contract #838
The allowlist is not required, since the authority is the only entity that perform operations
Rusk doesn't compile anymore #842
Looks like yesterday they updated async-stream from 0.3.3 to 0.3.4 causing major breaking changes.
I'm going to fix our version to 0.3.3 so we can compile again, at least for the time being.
governance-contract: optimize signature verification #844
Currently the signature and seed verification are done in all methods in a slightly different way, in addition we perform two hashes while the Poseidon one is redundant.
Dusk-blockchain
Open issues
Improve Documentation #1490
Code documentation needs to be improved as a whole.
This is a macro-Issue, tracking single items/components to be documented.
Improve Succinct Attestation Documentation #1492
Documentation of the Succinct Attestation code should be improved.
Sortition Hash is not compliant with specification #1494
createSortitionHash returns H(round||iteration||step||seed), but the specification states it should be H(seed||round||step||iteration).
Logically speaking, the concatenation order should follow round->step->iteration, like in the specification.
Technically speaking, this does not affect correctness/security, as long as all nodes calculate the same hash.
Improve Chain Documentation #1495
This is part of #1490
Improve Mempool Documentation #1496
This is part of #1490
Improve Consensus Documentation #1497
This is part of #1490
Improve Network Documentation #1498
This is part of #1490
Closed issues
Improve Sortition Documentation #1491
Documentation of the Deterministic Sortition code should be improved.
Reintroduce block.header.TxRoot #1499
This is a required health check to be performed in order to waste time/cpu processing an invalid block.
Include step into certificate header #1500
The step should be included into the hashable fields used to generate the block hash.
consensus
Open issues
Integrate node-common crate #42
Replace Block and Transaction struct with definitions from node-common crate.
Closed issues
plonk
Open 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
Refactor and add tests for component_range #735
Add in-circuit tests for the composer methods
- component_range
Add tests for gate_add and gate_mul #736
Add in-circuit tests for the composer methods
- gate_add
- gate_mul
Add tests for append_gate #737
Add in-circuit tests for the composer methods
- append_gate
Refactor and add tests for component_decomposition #738
Add and refactor 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.
Closed issues
Restructure integration tests #731
Restructure integration tests and add common setup and verification functions that all tests can use.
Add tests for assert_equal and assert_equal_constant #733
Add in-circuit tests for the composer methods
- assert_equal
- assert_equal_constant
phoenix-core
Open issues
Define the NFT types #125
We are working on deploying the NFT model in Rusk. For that reason, new note types will be used in phoenix-core:
0 - Transparent note
1 - Obfuscated note
2 - Transparent NFT note
3 - Obfuscated NFT note
4 - Transparent Message note (this one is NOT appended to the Merkle tree)
5 - Obfuscated Message note (this one is NOT appended to the Merkle tree)
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.
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.
