Why we need Phoenix and Zedger

Phoenix: an industry-first to enable confidential spending of public outputs, and Zedger: providing UTXO’s with account-based capabilities that enable the functionality required for XSC.

Today we are proud to share two of our breakthrough transaction models that we’ve created to power Dusk Network.

TL;DR
As an industry-first to enable confidential spending of public outputs, Phoenix will replace the old UTXO/RingCT transaction model within Dusk Network. Phoenix is unique because it guarantees transaction confidentiality even when users spend public outputs such as blind-bid rewards for staking or gas change (when too much is paid).

Zedger is the cornerstone of Dusk Network’s core technology for XSC. Zedger complements Phoenix by providing UTXO’s with account-based capabilities that enable the functionality required for Dusk Networks’ Confidential Security Contracts (XSC).

The Roots

The publication of the Bitcoin whitepaper by Satoshi Nakomoto, introduced the notion of Unspent Transaction Output (UTXO). UTXO is an accounting model, where the balance is calculated by summing all values included in the transaction outputs, which may be spent by a user. To better understand how the balance calculation is performed, consider the following example. Alice desires to send 5 BTC to Charles. At the same time, Bob wants to send 3 BTC to Charles too. Thus, they create two transactions with 5 BTC output and 3 BTC output, to Charles’ public address. At that point, Charles’ is able to spend 8 BTC (i.e. the sum of 5 BTC + 3 BTC outputs of Alice’s and Bob’s transactions), which is his balance (assuming that Charles was not the recipient of any other transaction). Each node in the Bitcoin network stores a UTXO set, meaning a collection of all outputs not yet spent. When Charles spends his 8 BTC, the 5 BTC and 3 BTC outputs from Alice and Bob will be removed from the UTXO. This way, if Charles attempts to create another transaction, nodes in the Bitcoin network will easily detect that he no longer has outputs to spend and will reject such transaction. This way, the UTXO model prevents the so-called “double-spending”. It is important to note that the UTXO model does not allow output to be spent partially. In the example above, in case Charles would want to send 2 BTC to Dave, he is obliged to spend the whole 3 BTC output from Alice’s transaction. So, he creates 2 transactions: one with 2 BTC output to Dave’s public address and one with 1 BTC output to himself. The latter is called a “change output”.

Universal State Machine

A different paradigm for transactions, the “account model”, has been introduced upon the launch of the Ethereum blockchain. In an account model, rather than recording the whole set of unspent transaction outputs, a node directly stores a set of accounts and their corresponding balances. This way, the account owner does not need to create “change outputs” in order to spend parts of her balance. While this might sound more intuitive, in actuality, the account model is more taxing than the UTXO. In fact, the nodes are obliged to store accounts indefinitely together with their associated nonce. The nonce is a number that is updated every time a user submits a transaction and is crucial to provide an order to transactions and therefore prevent “double-spending” (since transactions are mined according to their order). The requirement of indefinitely tracking accounts and nonces is very burdensome, since it leads to acute storage problems which can only worsen with time. Alternative accounting models have been proposed, which work around the nonce tracking problem. Unfortunately, they are generally disregarded, due to the overly cumbersome operations they impose on end users.

Injecting Privacy

The crusade for privacy had begun with tumblers, which are centralized services born to prevent onlookers from linking the inputs and outputs of specific users, by combining them into a single transaction. Monero was the first to launch a trustless and non-interactive implementation of tumblers through the Ring Confidential Transactions (RingCTs) . Additionally, they introduce the capability to conceal the amounts transacted. To hide the amounts in the transactions, Monero uses commitments, cryptographic structures which enable users to hide and bind a value, and zero-knowledge algorithms to prove that the values being transacted are positive and within a given range (so not more can be spent than the actual balance). Protection from double-spending is achieved through the use of key images, which are unique to each output. Zcash takes an even different approach in rendering transactions private while providing protection from double-spending. Their approach foresees the storing of transaction outputs (called “notes”) on a Merkle Tree. The spender is thus required to prove the knowledge of the opening of the commitment and to prove the ability to satisfy the spending conditions. A unique “nullifier” is produced, to prevent the double-spending of outputs. Zether and Quisquis propose account models, in which the user is capable of updating the commitments of the decoys. The downside of the model is in the fact that the number of account updates grows superlinearly in respect of the number of transactions generated, which means the transactions require a lot of storage — which is expensive on the blockchain.

Phoenix: the Immortal Bird

Phoenix is our novel transaction model which evolves the UTXO model proposed by Zcash and extends the functionality to non-obfuscated outputs. Being the first to tackle privacy preserving smart contracts, Dusk Network has also been the first to experience the unsuitability of existing tx models to preserve privacy of the spenders of transparent outputs. In fact, the other tx models are used by either public smart contract platforms or by privacy-oriented networks that do not provide smart contract capabilities (and therefore do not handle public outputs such as gas refunds). To address this problem, we engineered Phoenix, which guarantees confidentiality even when users spend public outputs such as blind-bid rewards or gas change (through the inclusion of non-obfuscated outputs in a Merkle tree). Within Phoenix, both public and confidential outputs are stored within a Merkle tree. However, they are defined as different output types, so a user is prevented from spending committed outputs as transparent ones. The users need simply to provide proof of knowledge of the path to the root of the Merkle tree, and of the commitment’s opening. The use of Phoenix enables Dusk Network to achieve a higher level of privacy than Zcash. Phoenix will replace the UTXO/RingCT transaction model within Dusk Network.

Zedger: Account-based Privacy-preserving for XSC

Zedger is a hybrid transaction model created by Dusk Network. Zedger complements Phoenix by providing account-based capabilities to support Confidential Security Contract (XSC) functionality. Zedger combines UTXOs with accounts to create a compliant model enabling the issuer to exploit a wide range of functionality while simultaneously preserving the confidentiality of the transactors, without the need for any trusted third party. Zedger is the first transaction model with built-in support for trust-less, yet compliant, settlement and redemption of securities transaction. Additionally, Zedger prevents pre-approved users from owning more than one account, it supports dividend distribution and voting, and even handles capped transfers, where receivers are unable to exceed the ownership threshold for an asset, when such parameter is configured in the asset’s XSC contract. Zedger is the cornerstone of Dusk Network’s core technology for the security-related use-cases and will be the default transaction model for XSC.

Excited about Phoenix and Zedger? We will update this post with the links to the research papers and code upon release.

About Dusk Network
Dusk Network is an open-source and privacy-oriented blockchain based on years of academic research. You can use Dusk Network to create smart contracts that control digital assets and securities.