On Nomos, network states are implemented as rollups known as zones, which rely on the common infrastructure provided by the Nomos Bedrock layer. Nomos zones come in two main forms, which have different degrees of interoperability and therefore differ in the way they process transactions. While zone creators have the freedom to make custom zones with better performance and their own unique properties, these sovereign zones have minimal interoperability between each other.

On the other hand, native zones have a common framework that makes them appear to work as one cohesive execution space, and benefit from the collective security of the entire Nomos Network. Native zones adhere to a common standard that allows for the assignment and transfer of information between participants in the form of notes, which are recorded on what is known as the common ledger. This ledger is partitioned between the different zones in the Nomos ecosystem, with global rules to ensure they can process notes originating from other zones.

In this article, we will explore how Nomos implements notes, the partitioned common ledger, and how this structure facilitates cross-zone transactions.

Nomos Notes

Nomos native zones use notes as a way to attach information to fungible assets, with this information being private by default. Notes are bound to their owners and the zone they are in, and only the owner can spend a note. In order to enable cross-zone interactions, notes must represent information in the same way and adhere to common rules. At the same time, they must be represented in ways that keep their information and owners private.

Rather than being linked to its owner directly, a Nomos note has a secret key generated by its owner, along with a corresponding public key derived from it via a hash function. While a note’s secret key is necessary for spending the note or modifying its contents, the public key is used as a public address for receiving notes. An owner can show their ownership of a note by proving that they know this secret key.

In addition to the above, some Nomos notes are used by the Cryptarchia consensus protocol to select the party that will be eligible to propose a block at a given time, known as a block proposer. Holders of notes eligible for leadership periodically check whether their note has won a recurring leadership election lottery. If it did, the note’s owner can add a new block to the chain, proving that their note won with a proof of leadership. More details on Cryptarchia, including the construction of the proof of leadership and how the secret keys are generated, can be found in this article.

Note Fields

While it is tempting to understand notes as representing financial assets, this is just one of many different use cases for Nomos notes. As a result of their versatility and the requirements of the common ledger, notes contain several different private data fields. These data, known only to the creator and owner of the note, include:

• \(state\): The private data attached to the note. The note state can contain any type of information, with no requirement for a specific interpretation or structure.
• \(v\): The value associated with the note. For an asset note, \(v\) represents the note’s asset value.
• \(U\): The unit tied to the value. This can be understood as the “type” of the note.
• \(nonce\): An arbitrary value to ensure the uniqueness of each note.
• \(ZoneID\): The identifier of the zone where the note resides.

The unit field will determine the specific rules, known as covenants, that govern spending notes and creating or destroying note value via minting and burning, respectively. In fact, the unit field is computed by hashing the concatenation of the three covenants associated with the note. Whenever a note owner wants to create, spend, or destroy a note, they must create a covenant proof to show that their desired operation is valid for the note. Keeping the covenant logic within the wallet allows for private token creation and opaque integration into the ledger, providing strong privacy guarantees. Additionally, the unit will determine whether the note can participate in consensus.

The Common Ledger

Nomos native zones maintain a ledger that keeps track of the notes held in that zone. Despite each ledger being unique to that zone, zone executors process the three basic note operations described above (minting, spending, and burning) according to a universal set of rules. It is this standard that allows for information and value in the form of notes to be transferred between zones, and enables the ledgers of each zone to act as one common ledger. The standard is enforced by the Nomos Bedrock, ensuring correctness and interoperability.

The UTXO Model

The foundation of the Nomos common ledger is the Unspent Transaction Output (UTXO) model. This model, pioneered by Bitcoin, represents the value held by a party by the outputs of transactions that have not been spent as transaction inputs. Transferring value involves the sender consuming UTXOs with the desired transfer value as input to a transaction directed to the recipient, with any leftover value returned as new UTXOs to the sender. This is in contrast to the account-based model used by Ethereum, where each address is associated with a balance that is updated with each transaction.

To better understand the differences between the UTXO and account-based transaction models, consider the differences between transferring cash and sending money between bank accounts. Cash is usually stored in a variety of different denominations, based on how their owner received them. For example, a person with $10 could have one $5 bill, four $1 bills, and four $0.25 coins - or any other combination, depending on their transaction history. For this person to transfer $7.30, they must give their $5 bill, two $1 bills, and two $0.25 coins and receive $0.20 worth of change from the recipient. On the other hand, transferring $7.30 from a bank account holding $10 just requires subtracting $7.30 from the sender’s account and adding the same amount to the recipient’s account.

The UTXO model was chosen for Nomos notes in order to facilitate private transactions. In Nomos zones, this model is implemented by having notes be “used up” when they are spent. Instead of transferring a note to a recipient, a sender spends a note they own and creates a new note of equivalent value belonging to the recipient. A spent note can never be spent again. To keep track of the notes that can be spent and those that cannot, each Nomos zone maintains two Merkle trees: one for commitments of notes eligible for spending, and another of nullifiers representing spent notes. The root of both of these trees has a size of 32 bytes.

Commitments

The commitment to a note is calculated by taking the hash of its concatenated private data (see above) appended to the note’s public key, creating a unique, binding identifier for the note without revealing its data. A zone’s commitment set contains commitments to every note created in that zone. The commitment set is organised as a Merkle Mountain Range (MMR) tree, which arranges the data into a set of the largest possible full binary Merkle trees, whose roots are then hashed together to create the MMR tree’s root. Zone executors only need to store the roots of these subtrees, known as frontier nodes, in their commitment set, resulting in a “compressed” set that does not balloon in size as the amount of zone notes grows. A visual example of an MMR is shown below.

Proving that a note exists in a zone requires a Merkle proof of membership in the commitment set.

Nullifiers

To represent spent notes, nullifiers are created by taking the hash of the note’s secret key appended to its commitment. This scheme enforces privacy due to the unlinkability between commitments and nullifiers created by the hash function. Nullifiers for all notes spent in a zone are stored in that zone’s nullifier set, and therefore a note nullifier’s absence in a zone’s nullifier set means that the note has not yet been spent. It is therefore necessary to prove that a note’s nullifier is not a member of the nullifier set in order to be able to spend a note.

The nullifiers in a nullifier set are organised as an Indexed Merkle tree (IMT). This type of Merkle tree inserts leaves in a sorted way, with each leaf also including a pointer to the next-highest value leaf. Due to the presence of these pointers, IMTs are especially convenient for computing proofs of non-membership. More information on the properties of IMTs that make them well-suited for Nomos nullifier sets can be found here.

Transactions and Ledger Updates

Native zones support the full array of Nomos notes and enable private, atomic cross-zone transactions (PACTs). “Atomic” here means that the transaction must be executed on several zones within the same block, or not at all. So long as a transaction does not violate the common ledger rules and the note covenants, native zones have considerable freedom to create transactions modifying their commitment and nullifier sets as they see fit. The correctness of a zone’s ledger updates is ultimately enforced by Nomos validators on the Bedrock layer.

Before a transaction can be accepted as valid, it passes through five stages. Each of these stages is the responsibility of a different party in the Nomos architecture, traveling from the end user or wallet, to the zone executor, and ultimately to validators on the Bedrock. These stages, every claim of which is demonstrated using a zero-knowledge proof and verified in the following stage, are described below:

1. First, a transaction is generated and issued by a note owner to an executor. A note can only be consumed in a transaction if:
   • The owner’s transaction proof also includes the balance of value created or destroyed as a result of the transaction. If this is not zero, it must be shown to be balanced by other transactions in the next stages.
   • The transaction submitter owns the note being spent. This is verified by demonstrating knowledge of the note’s private fields, including its secret key.
   • The note was previously created as the output of a past valid transaction. That is, it has a valid commitment in a zone’s commitment set.
   • The note has not been spent already. This is shown by proving that the note’s nullifier, calculated by its owner, is not in the nullifier set.
   • The spending covenant linked to the unit of the note is satisfied. In other words, the note can only be spent according to the rules defined in its covenant.
2. Several transactions are aggregated by the zone executor into a bundle. This bundle must have a neutral (zero) overall balance, with the result appearing to be one big balanced transaction. A transaction spanning multiple zones requires the note owner to submit that bundle in every affected zone.
3. The zone executor then processes bundles to effect a ledger update that would modify the commitment and nullifier sets of the zone. The ledger update proof guarantees the validity of the processed bundle and the correctness of the bundled transaction in a similar manner to the proof described in stage 1. Importantly, for cross-zone transactions, the ledger update proof outputs the sync logs, which are a list of bundle ids together with their associated zones. The sync logs will be used to verify that every part of the bundle was executed in every zone and ensure their validity in stage 5.
4. Parallel to stages 2 and 3, a zone executor may also create a proof for the update of the internal zone state, known as a state transition function (STF) proof. Zones have complete freedom over how they define their state and the rules for modifying it, only requiring that it gets verified by validators in a zero-knowledge way in the last stage.
5. Finally, validators on the Bedrock receive and verify ledger and STF proofs from zones. They keep track of any sync logs created in these proofs and ensure that all involved zones have processed their share of a cross-zone transaction. Without this step, the transaction might not be atomic or the result could be unbalanced because only some parts of the transactions of the bundle would be processed. Additionally, validators participating in NomosDA will verify the availability of zone state data published by every zone.

Conclusion

Nomos presents a robust and secure framework for implementing network states via its zone ecosystem, with native zones ensuring interoperability through a common ledger. By leveraging a unique take on the UTXO model combined with zero-knowledge proofs, Nomos enables efficient cross-zone transactions while maintaining strong security guarantees. The structured five-stage transaction process guarantees correctness while preserving privacy and decentralization. With these innovations, Nomos establishes an effective foundation for network states, paving the way for seamless and secure digital asset interactions across diverse zones.

Sources and Further Reading

• Nomos’ Cryptarchia: Improving on Ouroboros Crypsinous
• Designing Nullifier Sets for Nomos Zones: Sparse vs Indexed Merkle Trees