Dusk Network Development Update — November

Dec 01, 2018

By: Toghrul Maharramov

monthly development update series created to embrace the transparency and inclusivity that we strive for at Dusk Network.


It’s that time again! The last Development Update before the launch of our much-anticipated devnet. An important upgrade to the cryptography module, testing-ready wiring module, as well as the near-complete state of the core consensus module alongside a Golang port of the Guru reputation module signal that this month has been the busiest we’ve ever had at Dusk.

An addition of BLS (Boneh-Lynn-Shacham) signatures based on the 256-bit BN-curve (Barreto-Naehrig curve) is vital to the improved security and space-efficiency of the consensus module. BN-256 belongs to a family of unique curves with an embedding degree small enough (12) to be considered pairing-friendly (as opposed to Curve25519, on which the Ristretto curve is based, which has an embedding degree of 1206167596222043702328864427173832373476186059896651267666991823047575708498). Elliptic curve pairings define a complex relationship between two points on a curve (or two different curves) that can be combined together through a bilinear map to yield a third point. Pairing-based cryptography is utilized in homomorphic hidings, which form the basis of zk-SNARKs/zk-STARKs (zero-knowledge Succinct Non-interactive ARgument of Knowledge/zero-knowledge Succinct Transparent ARgument of Knowledge). Let’s go back to our specific use case though. BLS signatures are elliptic curve points, not algebraic statements (which use a combination of scalars and vectors). The signatures are verified via bilinear pairings, implying that the signature point must map to the message hash and the public key to be considered valid. BLS signatures have another interesting feature that stems from their deterministic nature — the scheme enables non-interactive batching, so combining two valid signatures renders another signature that can be mapped to the combination of two corresponding public keys. Unfortunately, the mathematical complexity of BLS signatures affects the verification times, which is the reason why the scheme will be only utilized for deterministic seed generation and voter signature batching for the block certificates, while the rest of the platform will continue relying on the Ristretto curve.

Ton van de Ven, our latest addition to the development team, has been working hard on an implementation of a Ristretto-based VRF (Verifiable Random Function). VRFs are central to the lottery system used in both the block generation and committee election. The principle behind our VRF function is in the generation of a proof alongside the resulting score with no hidden inputs (aside from the private key, which can be verified through a corresponding public key) with a validator being able to verify the score with a proof and the public key.

As was discussed in the previous iteration of the Development Update, Dmitry Khovratovich, our Lead Cryptographer, has not only helped us research possible NIVSS (Non-Interactive Verifiable Shared Secret) alternatives but has already delivered a non-interactive and privacy-preserving alternative. The alternative mechanism utilizes zero-knowledge proofs to conceal the bid amount, while MLSAG (Multilayered Linkable Spontaneous Anonymous Group) signatures are used to probabilistically obfuscate the identity of the bidder.

With the release of the devnet looming, the team is planning to announce the date and the location for the presentation and the launch of the devnet closer to the occasion.


Our consensus protocol — SBA⋆ has already gone through a few iterations, with the latest one being the use of zero-knowledge proofs as opposed to NIVSS to propagate the bid score. The team feels that the consensus protocol can be improved even further, hence the reason for the great effort put into research. First and foremost, we are looking to improve the space-efficiency of the protocol by sharding the certificates or switching to a deterministic sortition to discard the need for block certificates altogether.

Another substantial part of our research agenda involves the cryptoeconomics of the protocol. Being the most difficult section of the platform to create a formal proof for, finding a perfect balance between decentralization, fairness and accountability will involve weeks of simulation testing with multiple distribution functions.


November has been a month of increased exposure for Dusk Network. Dusk Network Co-Founders, Emanuele Francioni and Jelle Pol have given interviews to Crypto Zombie, Crypto Lark, Ivan on Tech and Crypto Beadles.

How to learn more about Dusk Network
The Dusk Network is a project coordinated by the Dusk Foundation. We are a decentralized ecosystem entirely focused on providing the perfect trade-off between privacy and transparency. Dusk protects privacy and fits regulations in payments, communications and asset transfers.

Website: https://www.dusk.network
FAQ: https://www.dusk.network/faq
Telegram: https://t.me/dusknetwork
Twitter: https://twitter.com/duskfoundation
Reddit: https://reddit.com/r/dusknetwork
Linkedin: https://www.linkedin.com/company/duskfoundation/
GitHub: https://github.com/dusk-network

A monthly development update series created to embrace the transparency and inclusivity that we strive for at Dusk Network.

Share this post

Subscribe to our newsletter

Dusk on GitHub Download Whitepaper