Owner: 🟢 @Thomas Lavaur

Supporters: @Mehmet @Giacomo Pasini

Reviewers: 🟢 @Mehmet, 🟢 @David Rusu, 🟡 @Giacomo Pasini , 🟡 @Álvaro Castro-Castilla

Introduction

This document aims to explore the best way to represent the state of objects within the Nomos blockchain, specifically objects (like funds) located in the native zones of our blockchain (encapsulated in the form of notes), while providing certain guarantees, such as privacy.

• This ensures that the content of the notes is not revealed, and it is impossible to link different transactions (updates to the state of various objects), thus ensuring anonymity, data confidentiality, and untraceability.

The architecture used to represent this data, known as the ledger, in most blockchains is either UTXO-based or account-based.

• UTXO (Unspent Transaction Output) is a model where transactions consume previously unspent outputs to create new ones. Each output represents a specific amount of value, and the system tracks which outputs have not been spent yet.
• Account-based models, on the other hand, keep a running balance for each account, where transactions update these balances directly.

The ledger architecture must meet several criteria. The first is that it must fit within the overall architecture of the Nomos blockchain. The blockchain ledger representing the notes is divided into different zones, each updated by an executor. Wallets submit transactions requesting changes to the ledger, and the executors validate these transactions and correctly update the ledger for their respective zones. At no point should the blockchain (nodes and validators) be required to participate in any specific zone. Therefore, the ledger architecture must allow executors to produce efficient update proofs for their zone’s ledger for verification.

However, to guarantee privacy, an account-based model is not suitable because it would require the use of advanced cryptographic techniques like homomorphic encryption, which is difficult to combine with zero-knowledge proofs without incurring excessive costs.

We will therefore adopt a UTXO model, which prevents linking consumed notes to created ones. This model relies on deriving two unique and deterministic values from a note using a hash. The first value, the commitment, is derived when the note is created and serves as proof that the note exists. Using this, a wallet can prove that the note it wants to modify is already in the ledger of a given zone. The second value, the nullifier, is an anti-note, and it is added to the ledger when the note is consumed. This allows the system to check if a note has already been spent, without needing the original commitment.

In order to prevent an observer from being able to link different transactions (i.e., linking the outputs of one transaction with the inputs of another), the issuer of a transaction must prove that the consumed commitments exist without revealing them. This ensures that the output of a previous transaction is not disclosed but proves that it exists. Additionally, the transaction must also prove that the note has not yet been consumed.

To prove that the commitment exists, the note holder must produce a proof of membership for the commitment in the set of already published commitments. To prove it has not yet been consumed, then it has two options:

• Prove the removal of the commitment from the set. This is difficult in most representations because updating the set can only be done by one entity at a time. Since transaction issuers cannot coordinate, this step would have to be delegated to the executor, which would reveal the removed commitment. ⇒ That’s why a commitment removal scheme doesn’t work.
• Prove that a nullifier has not yet been included in the set of published nullifiers. Nullifiers are derived from notes in a deterministic way as commitments. Each note, therefore, has two unique representations: the nullifier and the commitment. If the commitment is revealed first, the generation of the note can be proven and integrated in the set of valid spendable notes. Revealing the nullifier allows it to be inserted into a set of already consumed notes and checked to see if it was already included:
  • Since the nullifier cannot be linked to a commitment by an observer (except with cryptographic probability), proving that the nullifier hasn’t been included yet can be delegated to the zone executor. To prove that a nullifier has not yet been added to the set, the executor can prove to the chain that it is not in its list. This requires that the executor have a copy of the entire list of nullifiers emitted since the start of the zone.
  • The note holder itself (ie the “wallet”), like with the commitment, can produce a proof of non-membership proving that the nullifier has not yet been introduced into the set. Unlike the commitment, the proven nullifier is not yet in the set and must be able to be added by the executor using the information from the proof. This requires note holders to update their nullifier witness (at the same time as their commitment) after each issued transaction.

Our goal is to keep this ledger as lightweight as possible, balancing the load between wallets and executors. Executors can be considered as running on powerful machines, unlike wallets. Key parameters to optimize include computational complexity for each entity (wallets, executors and validators), storage complexity and wallet connection frequency.

What do we need?

Desired properties