Introduction

We are pleased to bring you a monthly tech and ecosystem update in line with our commitment to keep the community informed and to abide by the higher standard of transparency. The format builds on the Release Cycle Updates in the effort to provide more information about what the updates mean in practice. 

You can still find the release updates every 3rd Wednesday on Github, and moving forward we will be giving a more layman's update here. 

We hope you like this format and find it helpful to understand what is going on, what it all means, and why it matters. 

Engineering

Block Explorer

A preview of the new block explorer has been released. The enhanced UI includes charts, detailed transaction data, overview of nodes’ location and much more. The block explorer can be run locally in connection with a local node, from which the data is gathered. This allows node operators to use the block explorer as an activity dashboard that provides real-time insights.

RUES

The client can now dispatch events and receive responses on the connected websocket, according to the RUES specification. This is especially important as RUES events are consistently used in Dusk’s architecture. 

RUSK-ABI

New ABIs have been introduced: owner_raw and self_owner_raw. This is an addition to the already available deserialized owner and self_owner ABIs. Having “raw” methods that do not perform deserialisation is a useful improvement, as developers can use the implementations of these ABIs.

Consensus

In the Consensus mechanism, resource discovery has been implemented using the 'Flood with Random Walk' algorithm.

Initially, when a peer did not have the requested block it would ignore the request_block request. Successively, instead of ignoring the request, the peer would reply with a handle_inv message indicating unknown_block. This explicit indication of absence allowed the requesting node to immediately seek other peers for the block, rather than waiting for a timeout period.

Having nodes requesting a block to their peers via a request_block would make them wait idly for either a handle_inv reply or a 30-second timeout. This flow introduced unnecessary delays in the synchronization processes.

Now, upon receiving an unknown_block response, the requesting node immediately proceeds to request the block from other peers in its list, rather than waiting for a timeout. This proactive approach ensures that the node can quickly find and synchronize the block, improving the overall efficiency of the network.

Nodes can now respond to request_block queries, and requesting nodes handle these responses in a way that minimizes the latency in block retrieval. This improves the resilience of the network against nodes with outdated or incomplete blockchain data.

More specifically, these improvements allowed:

• GetBlocks message flow to work without triggering a flood_request.
• GetData / GetResource to use flood_request to retrieve blocks and transactions from a distant peer.
• GetData / GetResource to limit a flood_request by hops_limit setting.
• Certificate cache to be cleaned up properly
• Bandwidth to not increase on GetResource message

Wallet / Web-wallet

The usage of types from stores has been simplified. Previously, external imports were used in stores.d.ts, forcing developers to import types from the definition file instead of just using them. By creating type aliases, types can now be used in the whole application without the need for imports.

Also, Dusk transitioned to Wasmtime for the entirety of its stack, taking out the Wasmer dependency. Errors are now thrown in the same way both debug and release modes. 

Transactions

The initial integrity check for a transaction in a block is performed by verifying the txroot field, which represents the root of a Merkle tree containing the hash of the transaction list in the order they are executed.

The previous implementation was using the transaction IDs as hashes, without incorporating zero-knowledge proofs.

Instead, the hash used for inclusion in the Merkle tree is now calculated over the entire transaction in its serialized form, thereby incorporating all relevant information (including the zero-knowledge proof).

Phoenix

When it comes to the transaction model Phoenix, there have been important upgrades. Previously, the ViewKey of the notes recipient was needed in order to generate a TxOutputNote, and that ViewKey could not be generated for the change-note.

The ViewKey parameter has now been replaced with the value and blinder used to generate the output note.

Economic Protocol

Dusk’s novel economic model allows contracts to pay transaction gas on behalf of the user. This has several implications on the capability of smart contracts to achieve an actual business model based on usage, but it also allows for higher flexibility in how users access the various services on Dusk. From a technical perspective, additional information needs to be conveyed from the contract to the caller (e.g. the decision that the contract is willing to pay on behalf of the user and how much).

As the willingness for a contract to pay on behalf of a user may be a result of a multi-factor decision, the additional information needs to be carried with every call, without being mixed with a contract’s method return value.

For these reasons, an extra buffer conveying this information has been added, allowing Dusk to lever a mechanism for "contract-pays-for-gas" scenario and a "contract-earns-fees" scenario.

Also, a method named "set_charge" is now available for contracts, which passes the charge down to the transfer contract. The transfer contract increases the contract's balance and passes down the signal for increasing the fee. If the fee is not paid, the transaction is rejected.

Piecrust and smart contracts

Contract ID migration

As the contract ID was lost upon migration, the SELF_ID is now migrated similarly to OWNER.

Enhance contract’s deploy method and metadata

In order to be able to execute deposit-free free transactions, gas limit and gas price need to be assumed, as they are usually paid by users. This implies that the block generator needs to be able to obtain a gas limit and to calculate gas price from a price hint (a ratio to the average gas price).

This feature has been achieved by making the deploy method to accept optional arguments for gas limit and gas price hint. This information is stored in the contract's metadata, along with the contract's owner.

Host Functions

Previously, host functions did not have a “fair” price attached to them, as storage was priced solely based on the computation of memory allocation. That approach did not account for the actual resource usage and the economic impact of host functions’ computational load. 

Host queries have been now modified to be able to specify their price, meaning that that there are two preliminary stages before execution:

• Deserializing
• Pricing

In between the two stages, Piecrust is able to make the choice of whether to continue with execution or not, based on the gas remaining for the execution.

To achieve this, the HostQuery trait has been modified by adding two functions:

• deserialize_and_price
• execute

This structure allows the implementer to price queries fairly, as well as preventing double deserialization. 

A single contract's compiled bytecode contains a header, encoded within its information about the cost per WebAssembly instruction. If these don't match the costs configured for the current Piecrust instantiation, the contract will be recompiled, just as what happens if the native instruction set doesn't match.

Ecosystem

Grants Program

The process for applying to a grant has been streamlined. Applicants can now refer to the docs for up to date grants information. 

Closed RFPs

Dusk’s Grants Committee has selected the providers for the following infrastructure pieces:

• Bridge
• DEX

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.

Marketing / Community

Dusk has been featured on Forbes.

A partnership with Bwre CAPITAL has been announced, and there has been an AMA on Telegram about it. Also, there has been a continued growth on all platforms.

Resources

https://github.com/dusk-network/phoenix/issues/191

https://github.com/dusk-network/rusk/pull/1712

https://github.com/dusk-network/rusk/pull/1704

https://github.com/dusk-network/wallet-core/pull/111

https://github.com/dusk-network/piecrust/pull/352

https://github.com/dusk-network/piecrust/pull/348

https://github.com/dusk-network/piecrust/pull/362

https://github.com/dusk-network/piecrust/issues/353