July saw several significant advancements within Dusk that will contribute to a more robust, complete, and powerful mainnet.

The introduction of Moonlight as a new transaction model gives us more speed (higher TPS) and compliance on the protocol layer. A new block explorer has been released, offering users an intuitive and comprehensive tool for navigating the network data, while the completion of third-party smart contracts will allow developers to deploy dApps on Dusk from day one.

Let’s dive into these updates and understand what they mean and how they positively impact the protocol. There will also be dedicated posts about the updates that will go into more detail, with this article providing a general overview.

Moonlight

Moonlight is a new transaction model within Dusk, made for compliance, high TPS use cases, and enhancing interoperability and flexibility. We needed this to integrate our mainnet with exchanges due to new regulations. Not only were we able to abide by new regulations with Moonlight but we found new promising opportunities that arose from it, thanks to the increased transaction speed and interoperability. This is another step forward for Dusk to lead the way in regulated infrastructure for financial markets and shows Dusk’s ability to adapt to changing regulatory environments.

Moonlight is fully transparent, leveraging an account-based model where user addresses and their corresponding DUSK balances are publicly listed. It is fully compatible with Phoenix, meaning users can seamlessly convert between their Phoenix notes and Moonlight balances.

When a user deposits Phoenix notes into their Moonlight account, the Transfer Contract processes the notes and increases the balance of the specified account by the equivalent value.

Similarly, when converting funds from a Moonlight account to Phoenix notes, the Transfer contract decreases the balance of the account by the specified value and a note is created with the equivalent value, and sent to a given stealth address.

Dusk can rely now on two different transaction types that are incorporated into an enum named Transaction:

• MoonlightTransaction
• PhoenixTransaction

The conversion system has been updated to ensure that users can handle funds in both Moonlight and Phoenix transactions. The convert function is leveraged to atomically swap Dusk between the Phoenix and Moonlight models, and the user can prove ownership of either the account or address being converted between.

The Transfer Contract now supports Moonlight, as a map between public keys and their respective DUSK balance. The Stake Contract now supports Moonlight.

Contract Deployment

Based on feedback from partners and the community, we decided to make contract deployments part of our mainnet release. Up until now,  the deployment of smart contracts was supported only at the genesis block, preventing any post-genesis smart contract deployments.

With the introduction of a contract deployment transaction type, smart contract deployments can now be executed via transactions by anyone. The new transaction type includes:

-The owner of the transaction, identified by a BLS Public Key.

-The contract

-The constructor arguments.

The contract ID is deterministically generated for each deployed contract, meaning that the ID generation mechanism is based exclusively on the contents of the deployment transaction.

The size of a contract ID is 32 bytes, and Blake2 has been chosen as the hashing function.

The gas fees relative to the contract deployment are proportional to the amount of bytes of the contract's bytecode. If a transaction cannot pay for the requested amount, it is considered invalid and fails.

More specifically, the gas fees are equal to:

Total Cost=Bytecode Length × GAS_PER_DEPLOY_BYTE × Current Gas Price

Consensus

In Proof-of-Stake (PoS) systems, like Dusk’s Succinct Attestation, validators are selected to create new blocks and validate transactions based on the number of tokens they stake. There are two natural incentives to participate in consensus:

1. The rewards from validating transactions, creating blocks and voting for blocks
2. Behave according to the consensus rules to avoid penalization (Slashing)

Slashing

Slashing is the penalization of bad behavior from node operators, either by directly taking from their stake (hard slashing) or by reducing their voting power and moving it to their reward balance (soft slashing). It’s a fundamental game theory mechanism that incentivizes validators to act honestly. Any malicious behavior directly impacts their staked tokens or their rewards.

Hard slashing, on the other hand, addresses severe misbehavior that directly threatens the network’s integrity and security and burns tokens from the offending node. When running the official Dusk client, hard slashing should not occur.

In the previous engineering update, soft slashing conditions were introduced, 

July saw the addition of the hard slashing conditions, which include:

• Producing a block attested as Invalid;
• Producing two different candidates for the same round/iteration;
• Producing two conflicting votes for a single candidate;

A hard slashing scenario is individuated by witnessing two conflicting headers and their corresponding signature, while block generators need to include proofs of hard faults.

The slashed amount gets burned, and the provisioner is also suspended for an incremental number of epochs (similar to the soft slashing mechanism).

Exclusion of the next iteration generator from current voting committees

When a provisioner is selected in a Voting Committee for an iteration, but is also the block generator of successive iteration, it can be strongly incentivized to omit its vote in the hope of getting to produce the block at the next iteration.

If this happens, the provisioner is now excluded from the voting committee.

Split Block Generator-Voter reward

The block generator reward has been split into a reward portion for creating a block and a reward portion for voting on a block. This improvement incentivizes the block generator to include all known votes in the block certificate and for voting provisioners to vote on blocks. The collection of votes is allowed to continue until the generation of the next block. The voting rewards will be assigned depending on the number of votes included.

Rusk enhancements

Refactoring

Rusk benefited from a refactoring, including the split of the ledger module into submodules and the refactoring of the Attestation Verification

Adding BLS signature cache

Previously, the cache definition for BLS signatures was “abstracted” with a macro, allowing different cache types according to in-code parameters.

The hash used as a cache key is now computed using the argument buffer contents, instead of the deserialized parameters. This allows for a cleaner and more performant implementation.

Incremental Nonces

Instead of monotonically increasing (sequential) nonces, both the transfer and stake contracts now use Incremental nonces. 

Incremental nonces avoid the need to explicitly manage the ordering logic and situations where clients could exhaust the bit space in a single transaction.

Rusk ABI

The previous random method for the bls scalar was not uniformly distributed, as some scalars in the field were “hit” more often than others.

To avoid breaking backwards compatibility or relying on two different implementations of the random scalar generation, an instance of a random number generator that generates only canonical scalars has been introduced.

The Field trait implementation from src/scalar.rs has been removed, and the trait has been implemented instead in src/scalar/dusk/rs.

Block Explorer

The new Block Explorer has been released.

The newly launched Block Explorer represents the culmination of months of dedicated effort, featuring a complete rewrite and redesign. Adhering to the latest Dusk design language, it seamlessly aligns with the user experience provided by the Web Wallet. Additionally, the new Explorer boasts significantly improved responsiveness, ensuring faster data loading and smoother navigation.

Users can look at all the relevant network data at: https://explorer.dusk.network/

Ecosystem

Open RFPs

There are currently two open RFPs waiting for proposals:

• Archival Nodes APIs Infrastructure
• Hardware Wallet Integration

Applications can be submitted via the Thesan application form.

Resources

Hard slashing mechanism

Enabling generators to include proofs of hard faults

Add BLS signature cache

Hard slash during proposal if any faults (change EST/VST/AST)

Exclude next generator from both ratification and validation com… #1942

split ledger module into submodules 

Refactor Attestation verification

consensus: Exclude generator of next iteration from current voting committees #1834

Add deposit to remainder-note and remove bool return for mint 

Split Block Generator reward into fixed reward and extra reward

execution-core: add Moonlight and rework withdrawals

Add mechanism to transfer Dusk between Moonlight and Phoenix

Allow converting between Phoenix and Moonlight Dusk

Implements contract deployment via a transaction.

Implement contract ID generation mechanism #1884

Incremental nonces

Following up on the discussion on hashing to a BlsScalar

Inject uniformly distributed randomness into Scalar::random #129

Added gas settings validation (Unstake / Widthdraw Rewards flows)