Dusk Engineering Update: June
Introduction
June saw a lot of development work, as well as business development outreach, and the highly anticipated announcement of our mainnet launch date. From the monumental work that’s been done on Phoenix 2.0 to ensure compliance with all regulations, to CEO Emanuele Francioni’s keynote speech at TokenFuture in Frankfurt, to announcing mainnet for September 20th, it has been a busy month at Dusk.
Let’s take a look at what has happened.
Engineering
Phoenix 2.0
The Phoenix transaction model has been updated to Phoenix 2.0, shifting from the murky waters of anonymity protocols into what is poised to be the first GDPR and MiCA-compliant privacy-preserving protocol. The change from anonymity to privacy-preserving means that while Phoenix 2.0 ensures that transaction details such as the sender public key are accessible only to the intended recipient. More specifically, Phoenix transactions now include the originator's sending address, which only the recipient can decrypt. This feature satisfies all currently applicable regulations (TRF, AMLD5, MiCA, GDPR) crucial for the compliance requirements of crypto-asset service providers (CASPs) and other obliged entities: users can always prove the origin of their funds, but without having to resort to public disclosures. As the CASPs can verify the sender's AML/KYC status and return funds if requirements are unmet, Phoenix 2.0 not only preserve regulatory compliance when users interact with cryptocurrency exchange, but it also eliminates the compliance risks associated to public transactions such as GDPR risks, and market manipulation risks.
To achieve the above, the existing Transfer circuits have been overhauled into novel Phoenix circuits, where the sender's data encryption has been incorporated into the zero-knowledge proof of transaction validity, simultaneously ensuring that the non-repudiation of the originator, the correctness of sender's information, and the capability of the recipient to decrypt it.
Rusk
Block time
Dusk can rely on very fast block times, which is great. However, having too fast of a block time can introduce issues such as:
- Excessive bandwidth usage
- Latency impacts
- Slower nodes face difficulties in producing blocks
A timestamp-based system has been introduced to limit those issues, and achieve the most effective block time.
Incremental rolling finality
Previously, Rolling Finality (RF) marked a block as final after a fixed number of consecutive attested blocks.
However, this approach did not take into account the number of lower-iteration (hence higher-priority) candidates that might have reached quorum. For this reason, the number of blocks for the RF now depends on the number of non-attested lower-iteration candidates in the same round.
A block is now marked as final after a variable number of blocks that depends on the number of previous non-attested iterations, while an attested block is now marked as final when receiving its attested successor.
Rewards for block producers / voters
Encouraging block generators (BGs) in future-iterations to vote on previous-iteration candidates helps boost participation in the consensus process. For this reason, voters of a block are now rewarded.
The set of voters, included in the Block Certificate, now receives 10% of the previous block's reward, while the Block Generator receives 90%. Voter rewards are distributed in the following block, meaning the 10% reward is held until the next block is generated. These rewards are proportional to the number of credits each voter has, rather than being equal for every vote. Specifically, the Voter Reward is divided into 64 quotas, with each voter earning a quota for each credit assigned to them in the committee.
This system ensures that both Block Generators and Voters are incentivized to participate actively in the consensus process, with rewards reflecting their contribution and involvement.
Add soft-slashing conditions
Slashing is a critical mechanism in Proof-of-Stake (PoS) networks designed to maintain the network's security and integrity, as it penalizes validators (provisioners), who engage in malicious or harmful behavior (e.g. nodes not responding or spamming the network with incorrect messages).
There are usually two main types of slashing penalties, which are based on the severity of the violation: hard-slashing and soft-slashing.
While hard-slashing is applied for severe violations that significantly harm the network, soft-slashing addresses less severe violations that have relatively minor consequences. As an example, not broadcasting a Block Candidate when selected as a Block Generator is a behavior that triggers soft-slashing. Soft-slashing is achieved by using a suspension mechanism that manages penalties using warnings, ensuring that provisioners have an opportunity to correct their behavior before facing more severe consequences.
Soft-slashing has been introduced to encourage provisioners to act honestly and efficiently without imposing overly harsh penalties for minor infractions. This mechanism reduces the impact of a provisioner’s stake rather than decreasing the actual stake.
The type of Soft-slashing that has been introduced in Dusk includes two primary mechanisms: suspension and penalization:
Suspension: temporarily disables the eligibility of a misbehaving Provisioner. Provisioners receive a certain number of warnings before being suspended.
Each fault decreases this warning count, with the current threshold set to one warning. When warnings reach zero, the Provisioner’s stake is suspended for one epoch. After this period, the stake becomes eligible again. If the Provisioner produces a block or a vote, the warning count is restored. However, if another fault occurs, the suspension period increases incrementally (e.g., two epochs for the second fault). This progressive suspension system gives Provisioners a chance to correct their behavior before facing harsher penalties.
Penalization: reduces a portion of the misbehaving Provisioner’s stake, moving the portion to the claimable rewards, in order to not lose DUSK. The penalty amount increases with consecutive suspensions, starting at 10% for the first suspension and increasing by 10% for each subsequent suspension. This method incrementally reduces the Provisioner’s weight in the sortition process without entirely forfeiting their stake. If the stake falls below the minimum value (1000 DUSK), it is frozen and must be recovered by un-staking and re-staking.
Naming conventions
The following naming system is now employed:
1) Proposal: the Block Generator broadcasts a Candidate message
2) Validation: committee members broadcast Validation messages
3) Ratification: committee members broadcast Ratification messages. If a quorum of Ratification votes is reached, a Quorum message is produced
Based on the above, the following naming system is now employed:
Attestation: is the collection of Validation and Ratification votes attesting the result of an iteration
A Valid Attestation is an Attestation containing a quorum of Valid votes
A Failed Attestation is an Attestation containing a quorum of non-Valid votes
Certificate: it is a Valid Attestation of a block included in a child block
It is produced by the block generator to certify the previous block
Each committee member is assigned one or more votes that can be cast, called Credits. The number of votes in the committee is called Committee Credits.
Piecrust and smart contracts
Piecrust 2.0
A new version of Piecrust has been released, which includes:
- Applying charging mechanism for host queries
- Adding HostQuery::execute and HostQuery::deserialize_and_price
- Adding support for metadata elements ( free limit and free price hint)
With this enhancement, the cost to event emission is proportional to the amount of bytes emitted (and at the same rate as a storage instruction). The reason is that, while nodes are not necessarily required by protocol to hold this data, it is still crucial data to hold for external applications to consume it, and contracts should be discouraged from emitting events that are "too large".
Towards enabling third-party deployments
In order to enable third-party smart contracts deployments, a deploy method that accepts constructor arguments in serialized form needs to be provided. This means that in addition to the existing deploy method, a new deploy_raw has been added as a step forward towards enabling the deployment of smart contracts from third parties
Block Explorer
For the block explorer to fetch statistics efficiently, the existing REST API calls have been replaced with GraphQL, providing flexible querying capabilities.
Additionally, there have been UI enhancements and removal of unnecessary dependencies. You can see the beta version here.
dusk-wallet-core / Web-wallet / dusk-wallet-js
dusk-wallet-core
Refactoring has disentangled dependency loops, allowing for fully atomic changes and simplifying the testing infrastructure. Protocol changes now depend solely on the work done in the rusk repository, without the need to modify the external wallet-core repository. dusk-wallet-core dependency has been replaced with a local test-wallet
dusk-wallet-js
The dusk-wallet-js has been updated to improve how it handles synchronization with the blockchain. The new version determines how the wallet should sync based on the state of its cache and parameters provided by the users.
Ecosystem
Open RFPs
There are currently two open RFPs waiting for proposals:
Applications can be submitted via the Thesan application form.
Marketing / Community
The highlight for marketing was announcing a date for mainnet! Other activities included an AMA with Emanuele Francioni in Telegram.
The Business Development team were out in full force at TokenFuture in Frankfurt, where they made some great connections and again saw how enthusiastic the industry is for what we’re building.
Resources
https://github.com/dusk-network/rusk/pull/1896
https://github.com/dusk-network/rusk/pull/1876
https://github.com/dusk-network/rusk/pull/1862
https://github.com/dusk-network/rusk/issues/1208
https://github.com/dusk-network/rusk/pull/1864
https://github.com/dusk-network/piecrust/issues/371
https://github.com/dusk-network/piecrust/pull/370
https://github.com/dusk-network/piecrust/issues/357
