One of the key components in Bedrock design is the nonce, which ensures uniqueness and unlinkability across transactions. In this report, we analyze the nonce structure, its role in commitment derivation, efficiency trade-offs in reducing its size, and potential concerns regarding permissionless notes.

Note Structure in Bedrock

Each note in Bedrock is defined as:

$(state,v,U,nonce,ZoneID)$

where:

• $state \in \{0,1\}^{256}$ represents the note’s state.
• $v \in \{0,1\}^{64}$ is the note’s value.
• $U \in \{0,1\}^{256}$ is the asset unit identifier.
• $nonce \in \{0,1\}^{128}$ is a random value ensuring uniqueness.
• $ZoneID \in \{0,1\}^{256}$ identifies the zone in which the note exists.

The commitment of a note is computed as:

$cm = hash(\text{NOMOS\_NOTE\CM}||state||v||U||nonce||nf{pk}||ZoneID) \in \{0,1\}^{256}$

This cryptographically binds the note’s contents while maintaining privacy. The nullifier is derived as:

$nf = hash(\text{NOMOS\_NOTE\NF}||cm||nf{sk})$

ensuring that once a note is spent, it cannot be double-spent.

Efficiency Considerations in Nonce Size Reduction

Why Reduce Nonce Size from 256 to 128?

• Reducing the nonce size improves computational efficiency.
• Hashing operations for deriving commitments becomes less expensive in some cases.
• It improves circuit efficiency in membership proof.