Fermat's Library | Nomos Privacy Whitepaper (v0.1) annotated/explained version.

... at the foundation by default. (maybe mention that you can alway...

or _a_ user

~~increasing~~ increase

Here you use the acronym TE, later you use TED

~~mitigating~~ mitigate

I assume you meant "per se"

sorry I didn't finish the sentence: basically I have to express pr...

May be similar to NervOS's "Cell" construction: https://github.com/...

Note to myself: add a reference to FuelV2, since this is learnt fro...

I need to add an extra paragraph explaining how having both public ...

Note to myself: probably BlockSTM is a good reference here. Research.

Nomos Privacy Whitepaper

(v0.1)

Alvaro Castro-Castilla

Nomos

April 2023

1 Introduction

At the core of blockchains is the principle of transparency, which allows partici-

pants to view and verify transactions within the network. While transparency is

one of the key strengths of blockchain technology, it also raises important privacy

concerns that must be addressed to ensure widespread adoption and trust.

Privacy is a fundamental human right, and the protection of personal informa-

tion has become increasingly important in today’s digital age. As blockchains are

being used for various applications, maintaining privacy becomes crucial to safe-

guard sensitive information, protect users from malicious activities, and maintain

regulatory compliance. Privacy has two equally important but distinct aspects:

1. Conﬁdentiality: Transactions on a blockchain can involve sensitive infor-

mation, such as ﬁnancial transactions, medical records, or personal identi-

ﬁcation data. Ensuring conﬁdentiality is critical to protect users’ privacy

and prevent unauthorized access to this information. Conﬁdentiality refers

to the hiding of the action being conducted (ie. the what of an on-chain

action).

2. Anonymity: The ability to transact anonymously is essential for preserving

individual privacy rights. While some blockchain networks, such as Bitcoin,

oﬀer a level of pseudonymity, the public nature of their transaction history

can still lead to the identiﬁcation of users. Adequate privacy measures can

provide stronger anonymity and protect users from potential surveillance or

targeted attacks. Anonymity refers to the hiding of the identity conducting

an action (ie. the who of an on-chain action).

Nomos Privacy Paper (internal - work in progress)

1.1 A blockchain for the Network State

The importance of anonymity and conﬁdentiality in a blockchain designed for

the Network State is paramount. A Network State is a concept that envisions

a decentralized, digital, and self-governing system where citizens, organizations,

and institutions interact within a distributed network. In such a system, ensuring

anonymity and conﬁdentiality plays a crucial role for various reasons:

1. Individual Privacy: In a Network State, protecting the privacy rights of

individuals is of utmost importance. Users should have the ability to con-

trol their personal information and maintain anonymity, allowing them to

participate in the network without fear of surveillance, proﬁling, or discrim-

ination.

2. Conﬁdential Transactions: To encourage broader adoption and trust in

a blockchain-based Network State, it is essential to ensure the conﬁdentiality

of transactions. By concealing transaction details such as sender, receiver,

and transaction amounts, users can securely exchange assets, conduct busi-

ness, or engage in other activities without revealing sensitive ﬁnancial infor-

mation.

3. Secure Communication: A Network State relies heavily on communi-

cation between its participants. Ensuring the conﬁdentiality of messages

exchanged between users is vital to maintain privacy, protect sensitive in-

formation, and prevent unauthorized access or manipulation.

4. Political Freedom: Anonymity and conﬁdentiality play a key role in pre-

serving political freedom within the Network State. By enabling anonymous

participation in decision-making processes, such as voting or policy propos-

als, the blockchain ensures that individuals can freely express their opinions

without fear of inﬂuence from external forces. Furthermore, mechanisms to

limit power accumulation can be implemented.

5. Censorship Resistance: Ensuring anonymity and conﬁdentiality in a

blockchain-based Network State helps maintain its censorship-resistant na-

ture. By preventing the disclosure of user identities and data, the system

can resist attempts by centralized authorities to censor or control the ﬂow

of information.

1.2 Privacy requirements for Nomos

A blockchain can have privacy concerns at various layers, each with its unique

set of challenges. In this document we will elaborate the diﬀerent approaches

employed to ensure privacy at the various components of the system.

Nomos Privacy Paper (internal - work in progress)

1. Network Layer: At the network layer, privacy concerns arise from the

exposure of users’ IP addresses, which can be used to link transactions to

speciﬁc users. Membership of the p2p network is also ideally concealed

under a larger anonymity set to avoid identiﬁcation and targeted attacks to

any node simply for its participation in the protocol.

2. Mempool Layer: Privacy concerns at the mempool layer involve the ex-

posure of transparent transaction data, such as sender, receiver, amounts,

or contract call data. Participation in the mempool (identity and dissemi-

nation) are also to be considered from a privacy perspective.

3. Consensus Layer: We want to protect the privacy of the participants

in the consensus mechanism (validators or other roles). This includes both

concealing the role itself, as well as the actions they perform and the opinions

or decisions they take as part of the distributed protocol.

4. Execution Layer: Privacy concerns at the application layer arise from

the potential leakage of sensitive information through interactions with de-

centralized applications (dApps) or smart contracts. This layer cannot be

completely solved at the protocol level (since any developer can design an

application incorrectly, or an user can perform actions that actively leak

information that is meant to be private). In this layer, Nomos attempts to

provide good defaults and a ﬂexible (and ideally extensible) set of privacy-

preserving technologies to build apps with the highest degree of control and

customizable privacy.

5. Inter-chain communication: Transferring assets in and out of the blockchain

can reveal patterns that undermine privacy. By analyzing this transaction

history in sender and receiver blockchains, it may be possible to identify pat-

terns of behavior that can reveal sensitive information about the owner of

the address. Other information leakages, like time of the performed actions

can help statistical analysis to extract patterns about the Nomos blockchain

usage.

Nomos Privacy Paper (internal - work in progress)

Nomos Privacy Map

Network

Anonymous

P2P

networking

Anonymous

Membership

Communication

conﬁdentiality

Unlinkability Traﬃc analysis

resistance

Censorship

resistance

Mempool

Short-lived

transaction

conﬁdentiality

Consensus

layer

Validation

Validator

anonymity

Staking

privacy

Anonymous

rewards

Anonymous

slashing

Voting

conﬁdentiality

Random

beacon

Inter-chain

communication

Input/output

transfer

unlinkability

Multiple input

(or output)

transfer unlinkability

Execution

layer

Extensibility

Distributed

computations

Cryptographic

primitives

and tools

Hybrid

public/private

contracts

Transparent

anonymous

computations

(public data,

stealth addresses)

Conﬁdential

computations

(Zero-knowledge

predicates)

Function

privacy

Mitigation of

contract-level

privacy leaks

Anonymous

and conﬁdential

transfers

Figure 1: Map of privacy requirements for Nomos

1.2.1 Network layer privacy

Privacy at the network level refers to the protection of user data and commu-

nication as it traverses the network infrastructure, concealing the identity of the

users, the content of their communication, and their interactions with other nodes

or services. This type of privacy aims to prevent eavesdropping, traﬃc analysis,

and other forms of surveillance by unauthorized parties or malicious actors. It

involves several aspects:

• Anonymity: Protecting the identities of the users participating in the

network. This can be achieved by using anonymizing network protocols,

such as Waku or Nym, that route data through multiple nodes to obscure the

origin and destination of the communication. For anonymity to be achieved,

Nomos Privacy Paper (internal - work in progress)

the network is disguised within a larger set of completely unrelated networks

(the anonymity set), which are eﬀectively indistinguishable even for the

network participants.

• Communication conﬁdentiality: Ensuring that the content of the com-

munication, such as transaction details or messages exchanged between

nodes, remains private and cannot be intercepted or read by unauthorized

parties. End-to-end encryption and secure communication protocols, can be

used to maintain conﬁdentiality.

• Unlinkability: Preventing the ability to correlate diﬀerent transactions,

messages, or interactions involving the same user, making it diﬃcult for an

attacker to build a proﬁle of the user’s activities on the network, eventually

deanonymizing an individual or a group of them. Mix networks, onion

routing, or zero-knowledge proofs can be employed to make this harder or

impossible for an adversary to do.

• Traﬃc analysis resistance: Protecting against the analysis of commu-

nication patterns, such as the frequency, timing, or size of data packets,

which can reveal information about users even if the content is encrypted.

Network-level privacy mechanisms like constant-rate communication, traﬃc

obfuscation, cover traﬃc, or dummy traﬃc can be used to mitigate traﬃc

analysis risks.

• Resistance to censorship: Ensuring that users can access and participate

in the network without being blocked, ﬁltered, or restricted by governments,

ISPs, or other entities. Decentralized networks, domain fronting, and alter-

native routing methods can help bypass censorship eﬀorts and maintain

network-level privacy.

References: Waku, Nym

1.2.2 Mempool layer privacy

A mempool refers to a collection of unconﬁrmed transactions that are not yet pub-

licly visible on the blockchain network. These transactions are generally trans-

parent, as they need to be validated and ordered by the validator. Building a

private mempool can help increasing the censorship resistance of the blockchain,

and additionally, act as a powerful MEV protection mechanism. However, it is

important to note that a private mempool is not a long-term privacy-preservation

mechanism, since the transaction data will be exposed as it is committed on-

chain. This is the reason why its eﬀect is limited to censorship resistance and

Nomos Privacy Paper (internal - work in progress)

MEV protection, which beneﬁt from this short-lived conﬁdentiality. Conversely,

the transaction data that is encrypted doesn’t beneﬁt from mempool privacy.

The fundamental concept involves enabling users to submit transactions that

are encrypted. To execute an encrypted transaction, a user ﬁrst encrypts the

transaction and broadcasts it to the network. The encrypted transaction is then

committed to by the network. The transaction is later decrypted, and the re-

sulting plaintext is used to execute the transaction. In other words, To achieve

this, block producers commit to these transactions before decrypting them. The

commit, decrypt, and execute phases can potentially be performed in a single

step, depending on the network’s design, to preserve user experience. There are

diﬀerent approaches to implementing this:

• Enclaves. One approach is to use trusted hardware to process plaintext

data. The trusted hardware can operate on the data without decrypting it

publicly until after the transactions have been committed to the blockchain.

• Threshold Encryption/Decryption (TE) is a method that involves a

committee of signers who are jointly responsible for decrypting ciphertext

data. A minimum number of signers, or threshold, are required to decrypt

the data. For example, a threshold of 2/3 of the validator set may be

required to agree to decrypt the data.

The downsides of threshold encryption/decryption (TE) include lack of ac-

countability, a strong honest majority assumption, destabilization of the

protocol, and weakened liveness. TED can lead to malicious behavior with-

out attribution, and external agents outside the validator set could inﬂuence

the process. TED also relies on a truly honest and altruistic majority, which

increases incentives for centralization and malicious behavior. A higher de-

cryption threshold improves safety but weakens liveness, making it vulner-

able to massive network outages that can halt the protocol.

• DED (Delay Encryption/Decryption) is a method where encrypted in-

formation is automatically decrypted after a certain amount of time, and it

requires VDF (Veriﬁable Delay Function) ASICs for practical implementa-

tion. Ethereum Foundation and Protocol Labs have been working on pro-

ducing VDF ASICs, which are capable of fast sequential computation and

also work for time-lock puzzles and DED. However, producing SNARKs

(Succinct Non-Interactive Argument of Knowledge) for VDFs also require

specialized ASICs. Compared to TED, DED is preferred because it doesn’t

require trusting a committee, but specialized hardware and delays may add

latency to the system.

Nomos Privacy Paper (internal - work in progress)

References: Shutterized Beacon Chain, Chainlink FSS, Ferveo, The Ethereum Foun-

dation and Protocol Labs references

1.2.3 Consensus layer privacy

In PoS systems, validator anonymity, voting privacy, and stake privacy are critical

aspects of the network privacy preservation:

• Validator Anonymity: Maintaining validator anonymity is crucial in PoS

systems to prevent targeted attacks and protect validators’ real-world iden-

tities. There are two aspects to consider for this:

1. Network-level anonymity: Anonymous networks provide an additional

layer of privacy and security by routing validator traﬃc through a series

of intermediate nodes. This makes it diﬃcult for an adversary to trace

the origin of the messages back to the validator node.

2. Secret Validator Registration: Using zero-knowledge proofs or group

signatures, validators can register their nodes in a privacy-preserving

manner, proving their eligibility without revealing their actual stake or

identity.

• Voting Privacy: In PoS systems, validators often participate in voting

processes to reach consensus or as part of some secondary protocol (such

as the Random Beacon). Ensuring privacy in these voting processes is es-

sential to avoid revealing validators’ preferences. One example technique to

achieve this is the use of Somewhat Homomorphic Encryption (SHE). This

cryptographic method allows validators to encrypt their votes such that

they can be combined and tallied without decrypting the individual votes,

maintaining vote privacy while still enabling accurate vote aggregation.

• Stake Privacy: In PoS systems, preserving stake privacy is vital to avoid

exposing users’ wealth. Diﬀerent approaches to achieve this include leverag-

ing conﬁdential assets, such as the Sapling scheme, or coin mixing protocols

applied to staking.

TODO: Elaborate further. References: Sapling

1.2.4 Inter-chain communication privacy

There are several risks associated with analyzing the ﬂow of transfers between

interconnected blockchains. Linking transfers in and out of a private blockchain

can lead to various levels of account de-anonymization. The aim is to provide

protection against:

Nomos Privacy Paper (internal - work in progress)

• Correlating input and output transfers. When considering the cor-

relation of input/output (I/O) transfers between two privacy-preserving

blockchains, the risk of exposing sensitive information is mitigated but not

entirely eliminated.

• Correlating multiple input (or output) transfers of the same ac-

count. Similar approaches to those employed for correlating inputs with

outputs can potentially be used also for multiple inputs.

References. Analysis of Address Linkability in Tornado Cash on Ethereum

These problems are akin to the privacy leakages incurred when transferring

from shielded to unshielded environments in blockchains that support both types

internally, as the transfer between diﬀerent (sub)-systems is performed without

the same privacy-preservation measures as the shielded system. As a consequence,

adversaries have the possibility of analyzing the transaction graph to uncover

patterns, relationships, and ﬂows of assets, potentially leading to the identiﬁcation

of high-value targets or sensitive business operations.

• Timing Analysis: By analyzing the timing of transfers into and out of

the private blockchain, adversaries can establish correlations between trans-

actions. If the timing of transfers is distinctive or if there are only a few

participants, the adversary can infer relationships between transactions and

potentially reveal user identities.

• Amount Correlation: If the amounts involved in transfers into and out

of the private blockchain are unique or follow a pattern, adversaries can

correlate these amounts to link transactions. This can lead to user de-

anonymization and expose the transaction graph.

• Intersection Attacks: If a user participates in multiple private blockchains

or engages in oﬀ-chain transactions, an adversary can perform intersection

attacks by analyzing the common elements in the diﬀerent systems based

on transaction patterns. This can enable the adversary to link transfers and

compromise user privacy.

• Side-Channel Information: Adversaries can leverage side-channel infor-

mation, such as IP addresses, metadata, or network traﬃc patterns, to es-

tablish connections between transfers in and out of the private blockchain.

By correlating this side-channel information with transaction data, adver-

saries can potentially uncover relationships between transfers and users.

Nomos Privacy Paper (internal - work in progress)

Some of the countermeasures that can be taken to protect against these risks

include timing and amount randomization. Introducing random delays in trans-

action processing or using decoy transactions with varying amounts can help

mitigate timing and amount correlation attacks. Additionally, the techniques

employed to provide execution-layer privacy help mitigating these risks during

inter-chain communications.

1.2.5 Execution layer privacy

The execution layer brings additional complexity to the pursuit of privacy on

blockchains. When the set of operations is limited (such as in cryptocurrency-

only blockchains), it is possible to design the system in such a way that privacy

leaks are completely eliminated, or at least their extent is well-known. In the

case of quasi-Turing complete execution environments, the space of possibilities

is much larger, leading to many potentially overseen privacy leakages entirely

caused by the application designs. This is particularly true when we intend to

build a partial privacy solution (required for many real world use cases, such as

decentralized exchanges), where certain information must be made public in order

for applications to become useful.

Consequently, the understanding of requirements for the execution layer is

much more nuanced and is highly dependant of the cryptographic tools at our

disposal. We will establish here the main requirements to satisfy in the design of

the protocol, in the ideal case.

• Enabling Transaction Conﬁdentiality and Anonymity: To achieve

transaction conﬁdentiality, privacy solutions should eﬀectively obfuscate

transaction details, such as sender, receiver, and transaction amounts. Gen-

erally speaking, there are two main ways in which this can be done:

(a) Encrypting and obfuscating transactions on-chain. All the information

pertaining a transaction can be published in the blockchain but its

privacy maintained by using diﬀerent encryption schemes. Generally

speaking, encrypted on-chain data can be further processed in several

ways, with the highest potential found in homomorphic encryption and

secret multi-party computation techniques. Furthermore transactions

can be obfuscated with cryptographic techniques to anonymize or con-

ceal aspects of it (such as ring signatures). The idea is that the data

is available on-chain, but protected.

(b) Proving oﬀ-chain computations. Cryptographic operations can be used

to ”commit” to a value while keeping it hidden. In a general sense, the

idea is to not make any data public even in an encrypted or anonymized

form, but just publish enough information to prove publicly that the

Nomos Privacy Paper (internal - work in progress)

operation is performed correctly oﬀ-chain. This can be achieved with

commitment schemes and Zero-Knowledge Proofs (e.g., zk-SNARKs

or zk-STARKs). These cryptographic constructions allow a prover to

demonstrate the validity of a statement without revealing any infor-

mation about the statement itself.

• Hybrid public/private contracts. A suﬃciently powerful execution layer

requires maintaining several conditions for privacy preservation. Many so-

lutions focus on only one or two, since enforcing all three can potentially

limit the usability of the system:

(a) Transparent anonymous computations. These computations are per-

formed openly and can be veriﬁed by anyone, while preserving the

anonymity of the parties involved. This allows for trust in the compu-

tation process without revealing sensitive information about the par-

ticipants. In it by itself only provides partial privacy (ie anonymity),

but is a fundamental component of a comprehensive solution.

(b) Conﬁdential computations. Enabling secure computations on encrypted

or private data. This could be solved using FHE in the former case,

ZK proofs in the latter. The aim in both approaches is to allow data

privacy to be maintained while still enabling the necessary calculations

to be performed.

of which function is being called in a given computation. By keeping

the function call private, it becomes more diﬃcult for outside observers

to determine the exact nature or purpose of the computations being

performed.

• Extensibility. The third core requirement of the execution layer is the

ability to incorporate new privacy-preserving primitives with relative ease.

While unlimited extensibility is not something that can be accounted for,

there are some considerations that we can take from the beginning, by look-

ing at the expectations of certain cryptographic technologies of becoming

practical. We divide the concept of extensibility into two more speciﬁc areas:

(a) Distributed computations. We need to support new operations that

might require distributed algorithms or network operations. An exam-

ple would be threshold encryption (TE) or multi-party computations

(MPC), which require network communicate as part of the protocol.

(b) Cryptosystems. Similarly, cryptographic systems such as fully or some-

what homomorphic encryption (FHE/SHE) are either practical today

Nomos Privacy Paper (internal - work in progress)

or have a high chance of becoming practical in the near term, making

the consideration of extensions support them relevant for the design of

Nomos.

TODO:

Plausible deniability enables a party to disclaim involvement in a conﬁden-

tial transaction. Both Monero and Quisquis facilitate this characteristic, as the

individual initiating the transaction can select any public key within the system

to be included in the anonymity set, regardless of the key owner’s consent. How-

ever, Zerocash lacks this feature, as its anonymity set comprises all private coins

in the system. Consequently, in Zerocash, a user consents to be included in the

anonymity set as soon as they possess a private coin.

Nomos Privacy Paper (internal - work in progress)

2 Network layer privacy

TODO

Current thoughts:

1. Describe requirements.

2. Describe how Waku solves them

3 Mempool privacy

TODO?

1. Describe requirements.

2. Purpose: MEV protection and censorship resistance, not privacy preserva-

tion.

3. Probably not necessary to elaborate much, as we might not implement this.

4 Consensus layer privacy

TODO

Current thoughts:

1. If delegation: manual choice of where to delegate is a problem if the stakes

are private, and other reputation data like reliability. Idea: random assig-

nation.

2. If no delegation (or equivalent, such as random assignation of delegations):

just need to hide validator IDs. Verify this claim.

3. Does the consensus algorithm use explicit or implicit voting? If the vote is

implicit (ie. a Yes vote is casted by attesting the block for example), no vot-

ing conﬁdentiality needs to be implemented beyond hiding the participation

of the validator.

Nomos Privacy Paper (internal - work in progress)

4. Secret Leader Election. Not a privacy measure, but a security one. If the

validator identities are already private, secret leader election becomes less

critical in the context of PoS blockchains. In this case, the main goals

of secret leader election (privacy, security, and censorship resistance) are

already addressed by the anonymity of the validators.

On random assignation of delegated stakes. Two potential lines of re-

search:

1. Distribute such that the equal delegation takes place just initially when

committed

2. Readjusts dynamically based on the set of current validators every period.

The diﬀerence is that the latter just treats every validator the same regardless of

history, the former generates a variation in staked tokens per validator implicitly

via slashing over time (for which you can compensate with higher block rewards),

so it is an ”opt-out” in a way and also leads to higher allocation to reputable

validators.

Current best idea: the end state would be something like an in-protocol pri-

vate liquid derivative, with uniformly random distribution of the delegated stakes

across all validators. Could work as a hybrid between both able to home stake and

buy the staked derivative asset. This gives the best of both worlds and enables

privacy.

Incentives should be put in place to favor home stakers, perhaps by setting a

minimum fee for delegated rewards.

5 Inter-chain privacy preservation

TODO

Research: are there mitigation techniques?

Nomos Privacy Paper (internal - work in progress)

6 Execution layer privacy

The execution layer is, due to its programmability, the most complex layer to

design for privacy purposes. It’s also highly exposed to the rapid advances in

cryptographic protocols, allowing it to beneﬁt directly from advances in FHE,

MPC and ZK proofs.

6.1 Introduction

In previous sections we have reviewed the requirements for this layer, so we will

explore the main options we have to achieve our purposes.

UTXO Model vs. Account Model. The choice of the underlying blockchain

model can have a signiﬁcant impact on the privacy properties of a protocol. Each

model has its own implications for privacy:

(a) UTXO Model: Used by Bitcoin and its derivatives, the UTXO (Unspent

Transaction Output) model represents the transaction history as a set of

unspent outputs that can be spent by a valid signature. This model en-

ables better privacy by allowing for transaction mixing protocols, such as

CoinJoin, which obfuscates the relationship between inputs and outputs by

combining multiple transactions into one, making it diﬃcult to trace the

ﬂow of tokens.

(b) Account Model: Used by Ethereum and similar blockchains, the account

model maintains a global state that tracks each account’s balance and asso-

ciated data. This model may require more complex privacy solutions, such

as fully-homomorphic encryption, or a combination of regular encryption

and zero-knowledge proofs.

Add references, based on enumerated examples. Add more examples.

Oﬀ-chain vs on-chain privacy. Closely related to the underlying data model

is the pursuit of two diﬀerent approaches for privacy depending on where the data

lives and the computations are performed:

(a) Oﬀ-chain: The data is held at the user’s device, and the computation is

privately performed there with no need for encryption. In this case, the

user needs to provide the system with a proof in zero knowledge that the

operations were performed and satisfy certain predicates. The proofs go

on-chain, and allow consensus on the computations performed by the user,

that they were done correctly and satisfy certain constraints. This is done

Nomos Privacy Paper (internal - work in progress)

without revealing any information about the user’s data thanks to Zero-

knowledge proofs.

Another approach to compute with oﬀ-chain is Multi-party computation.

In this approach, multiple devices can contribute to a computation, without

knowledge of the entire computation or all the inputs. This collaborative

approach to secure computation is generally not enough per so to provide

privacy-preservation, but is a powerful oﬀ-chain computation mechanism

that can unlock certain use cases.

(b) On-chain: The data is stored encrypted on-chain. This is made possible by

using homomorphic encryption. Homomorphic encryption enables privacy-

preserving operations on blockchain by allowing users to encrypt sensitive

data before submitting it to the public ledger. Validators can then perform

computations directly on the encrypted data, with the results remaining

encrypted. Once computations are completed, the encrypted results can be

shared with relevant parties who possess the appropriate decryption keys,

ensuring that only those with proper permissions can access the decrypted

data.

Describe more aspects that matter in the design, current state of the art, etc

6.2 Design rationale

Given the complex landscape of solutions available and recent progress in all the

cryptosystems involved, as well as current eﬀorts in building practical systems with

them, it is reasonable to assume that any system designed with a very strong set

of assumptions is bound to be obsolete quite soon. Taken this into account, we

will attempt to design a system that

(a) is founded in strong design principles that solve fundamental problems in

privacy and are consistent with state-of-the-art approaches (even if not com-

pletely practical yet),

(b) is ﬂexible enough to accommodate improvements in such cryptosystems over

time without requiring a major re-design,

application designs.

Taking these over-arching principles, there are some speciﬁc requirements that

we can derive as a starting point. These are:

Nomos Privacy Paper (internal - work in progress)

• Avoid contention issues naturally arising from oﬀ-chain computation. All

transactions performed over shared data need to be totally ordered, which

is complicated by the fact that oﬀ-chain computation doesn’t happen in the

same environment than the ordering is.

• Enable separation between public/private in some form between parts

of the transaction, to account for hybrid models. It is not possible to build a

practical decentralized application where users interact without any public

information at all. Consequently we need to account for hybrid models that

allow app developers to decide which parts need to be made public. Note

that this requires some eﬀort from the developer’s side in understanding

that public data can leak knowledge of the private side if the application is

not carefully designed.

• Support account abstraction in the data model. This allows for both

externally owned accounts and contract wallets to have the same functional-

ity, unlocking a series of use cases otherwise impossible. Some examples are:

customizable security rules, account recovery options, shared security across

trusted devices or individuals, gas payment ﬂexibility, batched transactions,

and enhanced innovation opportunities for dapps and wallet developers.

• Support authorization keys, to enable a private data owner to delegate

the execution of a speciﬁc.

TODO: Research pending. Unclear.

6.3 Design overview

The design of the data and execution models is approached throughout the pro-

gressive addition of features that can be built atop the previous ones. We will

start solving the most fundamental problems (such as the concurrent state issues)

and progressively add features in a manner that allows tackling diﬀerent problems

separately. Following this structure, there are four aspects that we will focus on:

1. Shared and owned state separation. Achieving hybrid public/private

contracts (in other words, contracts where some data is made public but

some remains private though still respects the rules of the contract), is

a nuanced topic. Both extremes of the spectrum (all computations are

public, or all computations are private) deﬁne a clear model. Once we

want to introduce partial privacy, the boundary between the private and the

public becomes fuzzy, primarily as a consequence of public data eﬀectively

leaking part of what is intended to be private. An example of this are public

Nomos Privacy Paper (internal - work in progress)

DEXes, which by providing a pair price, make it particularly hard to conceal

the values of each swap (even if they are never published), unless speciﬁc

measure to mitigate this are taken.

The solutions to handle this boundary between public and private data,

and the way they are crossed (such as re-keying, threshold encryption or

homomorphic batching), are multiple and oﬀer potential for research. As a

consequence, in the design we focus on the aspect that really matters for the

data model: ownership of the data. By ownership we refer speciﬁcally to the

ability to access and compute the data within the context of the blockchain.

In other words, it refers to two possible options: the data is shared among

several entities (and thus requires coordination), or is exclusively owned by

one. This is implemented with a data cell model, a straightforward extension

of the UTXO model that tags outputs as owned or shared.

This simple approach oﬀers the ﬂexibility to employ diﬀerent public-private

hybrid models based on one or several cryptosystems. Note that this separa-

tion opens up the possibility of optimization at the consensus layer for owned

data, as well as a generalization of what private means (such as in MPC, in

which a single entity is comprised of multiple subentities that achieve the

computation collaboratively).

Reference: Cardano, Nervos

Think of other potential naming, such as local/global, single/multiple

2. User-level privacy with ZK proofs. Once we have deﬁned the generic

data model based in ownership, we can start identifying which cryptosystems

can help us achieve certain privacy qualities on top. We will start with the

private data processing model, and base our design on a model considered

robust and eﬃcient enough, based on Zexe, Aleo.

The model, in its essence, can be summarized like this: the private data is

living oﬀ-chain in the user’s device. Any creation or destruction of private

data needs to satisfy two predicates: a creation predicate and a destruction

predicate, which constraints the computations that can be performed by the

user in his or her device. Transforming the data is the process of destroying

old data and creating new one (very much in the UTXO classic model from

Bitcoin).

Satisfying these predicates is only part of the answer, as the data is in-

tended to be kept private so these proofs aren’t trivial. To solve the privacy

part, proving these constraints needs to be done in zero-knowledge, to avoid

revealing any information about the computation performed by the user,

Nomos Privacy Paper (internal - work in progress)

and just proving to the network that the computation is done within the

allowed terms. Zero-knowledge proofs, commitments and nulliﬁers, com-

bined provide a strong level of privacy in which it is possible to perform

private p2p transactions as well as private user-level computations. These

are hardly enough to build the kind of generic environments we would re-

quire for Nomos, but with a little help from other cryptosystems, we can

get much further.

Reference: Zexe, Aleo

3. Actor model. The third building block of the execution layer tackles

the computation happening on-chain, at the validators. This data isn’t

necessarily private (although it could be as we will see). Regardless of the

visibility of the data, as soon as the data is owned by multiple entities (ie

is on-chain), access and modiﬁcation of this data needs to be coordinated.

For this purpose, we base our execution environment on the actor model,

inspired by asynchronous programming. The purpose of an actor is to handle

on-chain computations (as well as deciding their order), while checking the

validity of these with the constraints proven by the ZK proofs. There are

two key components to the actor model in Nomos:

(a) Batched processing of message. Batching is a key enabler of our

architecture. There are two critical reasons to perform batching: con-

struct per-block anonymity sets to avoid leaking private information

in the individual transactions, and handle concurrent operations on

shared state within the same block. At the actor (handles anonymity,

concurrency and increases performance).

(b) Asynchronous programming. In certain cases, one of the compli-

cations of batching multiple operations is that the result will either be

incompatible with the private data computations (as provided in the

zk proofs). For example, a zk proof will try to mint a new value equal

to an expected trade’s output. However, this output is not known until

after the batch is processed. To solve this, the private computations

need to be deﬁned in terms of intents, which will then be ﬁnalized in a

second step that materializes the transaction from the outcome of the

batch. This is usually done proportionally to the participation in the

batched operation, but that is highly dependent on the application.

The implementation of this is done via NFTs of the intermediate state,

that is used to prove afterwards the participation in the batched pro-

cessing within the block. A second transaction to spend the NFTs

using the public data after the batch processing is required. However,

Nomos Privacy Paper (internal - work in progress)

this second transaction doesn’t need a new signature so the user agent

can handle that automatically.

Reference Penumbra for async and actor model. Reference Anoma for

intents.

At this point, with a foundational data model, and an execution model

for user-centric privacy as well as for transparent shared data, many use-

ful real-world applications are viable already. We have all the building

blocks to build an execution layer for Nomos capable of supporting basic

private/public contracts.

4. Multi-user private computation with encrypted shared state. The

possibility of performing computation over encrypted data in a way that is

protected from the execution environment itself, is known as fully-homomorphic

encryption. Furthermore, if we require that the encryption is done to a

shared key with a threshold (like in threshold encryption schemes), this

cryptosystem is a Threshold Fully-Homomorphic Encryption. With this

functionality, plus the ability to re-key, we gain much more control on the

kind of data that we can publish. This in turn unlocks a whole new set of

hybrid applications where private computations between parties can be per-

formed without requiring online MPC protocols directly between the users.

This fourth stage of the design is arguably not feasible yet. But there are

high chances that the THFE technology will be practical in the next 2-5

years, so considering its feasibility a very real possibility within a reasonable

time-frame, inspired us to introduce it as the last component.

Reference Zama

6.4 Data model

The data model serves as the foundation of the execution model. It enables storage

of arbitrary blobs of data, where computation may or may not be performed.

Extended Unspent Transaction Output model. The eUTXO model is a

variation of the traditional UTXO model used in cryptocurrencies like Bitcoin.

The eUTXO model aims to provide enhanced functionality and programmability

while preserving the beneﬁts of the original UTXO model. In the UTXO model,

a transaction consumes one or more unspent transaction outputs (UTXOs) and

creates new ones. Each UTXO represents a speciﬁc amount of cryptocurrency and

can be associated with a locking script that deﬁnes the conditions under which

the UTXO can be spent.

Nomos Privacy Paper (internal - work in progress)

The eUTXO model extends the UTXO model by introducing the concept of

extended transaction outputs. These extended outputs can contain not only a

value and a locking script but also custom data and state information. This

additional data allows for more complex and expressive smart contracts to be

built on top of the eUTXO model, similar to what can be achieved using the

account-based model found in Ethereum.

One of the advantages of the eUTXO model is that it maintains the ability

to process transactions concurrently, as each transaction input operates indepen-

dently of the others. This results in better scalability and parallelism, as nodes

can process multiple transactions simultaneously without waiting for others to

complete. However, in its naive implementation this can only be achieved over

data owned by a single party. If multiple parties try to modify shared state si-

multaneously, only one can succeed per block. To solve this, we will employ a

two-signing process described later on.

Data cells. The Nomos Data Model operates on data units known as cells. It

aims at decoupling the notion of private/public state with that of ownership of

the data. The purpose of this is to tackle concurrency ﬁrst, and enable the con-

struction of a ﬂexible execution model on top by combining several cryptosystems.

The design consequently distinguishes between two types of cells:

• Owned cells: stores state that can only be modiﬁed by a single party.

• Shared state: contains state that is modiﬁed by multiple party, and thus

needs to be coordinated.

Owned cells can be used arbitrarily to store any data, but they have always to

satisfy one of two predicates in every transaction: a create predicate if they are

created anew, or a destroy predicate if they are being spent. Valid transactions

generate and consume records. A transaction is considered valid if, when provided

with the transaction’s local data as input, all the destroy predicates of consumed

records and the create predicates of generated records are satisﬁed simultaneously.

TODO: Elaborate details, serial numbers, replay protection, function privacy, etc

TODO: Diagram of data cell types and contents

Code cells. Code cells are shared cells that contain executable code. They can

• Arbitrary contract code as deﬁned by the Virtual Machine (see corre-

sponding section).

• Predicates are functions that return a boolean.

Nomos Privacy Paper (internal - work in progress)

• Scripts facilitate sophisticated on-chain interactions that do not need to

be permanent. Complex transactions usually involves several steps, such as

voting on proposals, staking tokens, and claiming rewards. With the help

of scripts, these intricate transactions can be carried out more seamlessly in

a single step.

Script

shared

data

cell

owned

data

cell

shared

data

cell

owned

data

cell

shared

data

cell

Figure 2: A script running a transaction consuming both shared and owned data,

and generating new ones. The script itself calls arbitrary contract code and cre-

ate/destroy predicates

Reference: Sway language

Transactions. Transactions can be comprised of either owned and shared data

cell transformations. If these need to be combined, a script can be used to tie

together arbitrary contract code for modifying public state, as well as predicates

validating private transformation. Chaining these operations can be performed

freely, as long as each step is valid.

Nomos Privacy Paper (internal - work in progress)

Script

shared

data

cell

Contract ID

create cell

predicate

owned

data

cell

destroy cell

predicate

Private

Transaction

Transparent

Transaction

ON-CHAIN

OFF-CHAIN

Transparent

Record

shared

data

cell

new record

commitment

old record

nullifier

Private

Transaction

Commitment

private

data

spending

key

Private

Record

ZK Proof

private

data

spending

key

New Private

Record

owned

data

cell

Figure 3: A complex transaction in the Nomos data model involving both public

and private computations

Nomos Privacy Paper (internal - work in progress)

6.4.1 Stealth addresses

TODO

Open questions:

1. Maintain privacy of participants in protocol (ie their addresses shouldn’t be

reused by others)

2. Mechanism to easily generate new addresses for each transaction, that only

the sender and receiver can identify

6.4.2 Fuzzy Message Detection

TODO

Open questions:

1. Mechanism for receivers to privately detect messages for them.

6.4.3 State growth mitigation

TODO

Open questions:

1. Study the problem of state growth.

2. Research accumulators.

3. Research state pruning.

6.4.4 Other privacy-preservation measures

TODO

Open questions:

1. With a proving system with no constant size proof, there is the possibility

of larger private chunks (data cells) forming an identiﬁable pattern. Study

the possibility of splitting in several in order to obfuscate.

6.5 Execution model

The ﬁrst component of the execution model that will focus on is on purely private

computation, on one single user. From there we will work on ways to combine that

with computation of shared states, using the UTXO framework describe before.

The last step is to bring multi-user privacy to shared state.

Nomos Privacy Paper (internal - work in progress)

6.5.1 User-level privacy using ZK proofs

Private computation on a blockchain using zero-knowledge proofs (ZKPs) enables

secure and conﬁdential processing of data without revealing the underlying infor-

mation. ZKPs allow a prover to demonstrate the validity of a statement without

disclosing any additional information, ensuring that sensitive data remains undis-

closed during on-chain computations. However, the use of ZKPs for privacy comes

with its own set of limitations.

One such limitation is the need for concurrent-access-to-state. In smart con-

tract chains like Ethereum and Solana, the state of an application is shared be-

tween all users, and any transaction can modify it. This shared state poses a

challenge for applications that require privacy. When users attempt to modify

the shared state on the client side, conﬂicts can arise between diﬀerent users,

leading to race conditions.

To overcome this limitation, an intermediary agent, known as the prover, can

be introduced. Users can send transactions to the prover, who orders and exe-

cutes the transactions oﬀ-chain before advancing the state on-chain. While this

approach can address the concurrent access to state problem, it’s less than ideal

for privacy reasons, since the prover needs access to the cleartext, while also intro-

ducing a centralized point of failure. This is not an option that we can consider

for our purposes.

References: Aleo, Zexe?

Another, previously discussed, limitation of ZKPs is that they provide single-

user privacy. This means that the user must generate their own proof, if they

want to preserve full privacy, as opposed to delegating the task to a third party.

Additionally, the need for a user to know all private inputs relevant to the proof

to generate the proof further complicates matters.

To address these limitations, we need to design on-chain applications with

user-level privacy in mind. Instead of a shared global state that everyone can

modify, we can use a fragmented state model where individual state fragments

are owned by individual users. This approach ensures that users can execute

their transactions on the client side without conﬂict, as each fragment is owned

by a single user. The problem with this is that it limits the design space for

many applications. For example, it is possible to design decentralized AMMs

using only user-level privacy by bypassing the need for users to interact with

each other. Instead of transacting with each other, users can transmute one asset

type to another, which updates their private state in a provable manner without

interacting with other users’ private state. However, to achieve this, users burn

their input assets privately and encrypt the amounts to validators, which would

require additional mechanisms like threshold encryption. The validators then

aggregate the encrypted amounts, decrypt the batch total, compute the eﬀective

Nomos Privacy Paper (internal - work in progress)

clearing prices (inclusive of fees), and commit them to the chain state. Users

can then privately mint output funds of the new type in a later block, proving

consistency with the inputs they burned.

As we can observe, user-level privacy alone has several limitations that need

to be overcome by the use of additional cryptographic mechanisms for relatively

complex applications. It is however a powerful tool that can be used as a founda-

tional building block of a ﬂexible execution model.

Predicates are zero-knowledge veriﬁers. User-level privacy based on Zero-

knowledge proofs is supported directly by our data model, via the create and

destroy predicates. While there is no fundamental restriction on how those pred-

icates need to perform computations as long as they return a boolean value, their

power is revealed through the user of Zero-knowledge proofs.

TODO: Elaborate mechanism

References. Shielded transitions: https://github.com/anoma/taiga

6.5.2 Actor model: batching and asynchronous programming

In the context of smart contracts on Unspent Transaction Outputs (UTXOs), the

contention problem is a well-known issue that can arise when multiple transactions

within a block attempt to spend the same contract UTXO. This problem can occur

when using certain decentralized applications, such as Automated Market Makers

(AMMs), where many transactions may attempt to swap into the same pool.

In ﬁrst place, we introduce batching in order to solve two main problems:

concurrency and conﬁdentiality.

Concurrency: Two-party signing process. A solution to the problem of

concurrency required for batching is to implement a two-party signing process,

where users only sign over the contract ID rather than the contract UTXO when

initiating a transaction. By doing so, users can indicate which contract they want

to interact with without forcing the contract to be in a particular state before or

after execution. This approach is intuitive because users do not actually know the

state of the contract at the time of execution, as the ﬁnal order of transactions is

not determined by them. Block producers, on the other hand, can determine the

order of transactions and know the state of the contract at execution time. This

allows them to sign over the exact input (contract UTXO) that the transaction

will spend. By doing so, they can avoid contention and ensure that the smart

contract functions eﬃciently. Upon execution, the contract UTXO is consumed

and replaced by a new UTXO that represents the post-state of the contract.

Nomos Privacy Paper (internal - work in progress)

Overall, implementing a two-party signing process and having block producers

determine the order of transactions can help mitigate the contention problem when

using smart contracts on UTXOs. This approach allows for eﬃcient and reliable

execution of smart contracts in a decentralized environment.

TODO: Elaborate technically. Make diagrams.

Conﬁdentiality: Somewhat Homomorphic Encryption. The aforemen-

tioned two-party signing mechanism solves the concurrent execution aspect. But

batching needs to be introduced for yet another reason: protecting the private

information to be extracted from public data updates in the same transaction.

The problem goes as follows. Take again the AMM example, in which pricing is

a public piece of data so users can choose whether to swap assets or not. Even if

transactions keep the amounts private, the price change after the execution of a

swap reveals enough information to know how much was traded, even if that infor-

mation was never directly exposed. When batching several transactions together,

this problem can be solved to a certain degree, since only the price change after

all the transactions are performed can be observed. In other words, traders’ con-

tributions to batches and pooled liquidity are kept private, whereas the aggregate

values such as total value in batches and liquidity pools remain public.

For this to be possible, however, we need to introduce another cryptographic

tool: Threshold Additive Somewhat Homomorphic Encryption. This would allow

us to threshold encrypt transactions to a committee of validators, and homomor-

phically aggregate the values into an encrypted total sum. Assuming a threshold

of committee validators are honest, they will distribute their decrypted shares of

this sum to the network to ﬁnalize the committed block.

Note that while this process introduces a new step, it can be avoided for data

that doesn’t require to be kept private throughout the batching. Batching is both

a concurrency and conﬁdentiality solution, but conﬁdentiality of the public

data is only required if it exposes private data.

TODO: explain in technical detail how decrypted shares are distributed after the

block is committed, following threshold decryption

Note that this solution while powerful, is only as good as the size of the set

of transactions in the block pertaining to the same contract. This will work well

when the app is popular, but in the case of a single transaction per block per

contract, this mechanism is rendered useless. For this purpose, and especially

initially when an app has little user adoption, a separate mechanism should be

introduced for the case of low transaction count. Some options to explore in the

future include:

1. Introducing an MPC-generated noise perturbation on the public value.

Nomos Privacy Paper (internal - work in progress)

2. Delay transactions until there are enough to guarantee some degree of pri-

vacy. Note that this introduces the challenge that anyone listening to the

mempool can activate the inclusion by crafting known transactions, and

derive the public values of the single transaction that is being targeted.

However this vulnerability is limited in time and only possible before com-

mitting on-chain.

3. Introduce decoy transactions

References of papers by Tarun and Guille on AMM privacy

Reference similarities with MEV-mitigation mechanisms with batching

Block

Transaction

zk proof

transparent contract ID

signature

Owned data

Shared data

order transactions

sign block

Owned data

Shared data

Owned data

Shared data

Owned data

Shared data

Transaction Transaction Transaction

Client

Block builder

Figure 4: Processing of concurrent transactions in the Nomos data model.

6.5.3 Completing the sequence: asynchronous programming

Batching solves the two problems described above, but introduces a new one:

when operations are batched together, the outputs of the computation cannot be

obtained until after the batching, since those public values are aggregated and

split proportionally among participants.

The solution to this is to use a two-step mechanism, postponing the ﬁnal

computation to after the batch is committed on-chain. In a manner akin to

futures in asynchronous programming, the ﬁrst step would act as a promise of a

computation, while the second step would resolve the computation.

TODO: Elaborate mechanism with NFTs. Make diagram.

Transaction processing.

TODO: Describe how everything ﬁts together here

Nomos Privacy Paper (internal - work in progress)

1. Separation of owned computation (oﬀ-chain by user), and shared computa-

tion (on-chain, batched on validators).

2. Two-party signing process.

3. Create an NFT of the future.

4. Batching + TE acting similarly to anonymity sets, hiding the eﬀect of each

transaction on the public data, and collectivizing the eﬀect, so that only the

aggregate change is known. At least Somewhat HE is required for this.

5. Resolve the NFT to extract computation output. This doesn’t require a

second signing.

On parallelization An account-based model can be designed to enable parallel

execution of transactions, but this requires additional considerations such as the

use of strict access lists. In contrast, a UTXO model inherently allows for parallel

execution since each transaction speciﬁes which UTXOs it intends to spend, and

transactions that spend non-overlapping UTXOs can be executed simultaneously.

This is a signiﬁcant advantage of the UTXO model, as it allows for the beneﬁts

of multi-core processing to be fully leveraged, enabling faster and more eﬃcient

execution of transactions. Moreover, parallelized execution not only applies to

transactions within a block but also to transactions across blocks, which can speed

up the syncing process for nodes that are joining or re-entering the network.

6.5.4 Multi-user level privacy: TFHE

With user-level privacy and the ability to use threshold-encrypted batching, we

are able to considerably expand the possibilities for the decentralized application

developer, opening the door to building complete privacy-preserving apps with

multiple users. However, there are still several limitations with this functionality:

• While it is possible to perform computations with per-user privacy, and also

to keep those computations safe from being extracted by the simultaneous

updates on public state thanks to threshold-encrypted batching, it is not

possible to perform computations that involve private data of multiple users

at the same time.

• All user-level private computations need to be performed by the client, but

it is possible to imagine scenarios in which we would desire those private

computations to be performed on-chain. For example, this data can be used

both for single-user computations as well as multi-user seamlessly, be made

public directly but only after transformation, or be encrypted to a diﬀerent

user as a form of on-chain messaging.

Nomos Privacy Paper (internal - work in progress)

Fully-homomorphic encryption is certainly not practical today, but is its fea-

sibility is in a reasonable timeline. This component of the privacy-preserving

execution model of Nomos will be implemented after the others, in a manner that

could be considered as an extension of the previously described components.

Threshold Fully Homomorphic Encryption scheme.

TODO

Overview of solution:

1. Users encrypt their input with the THFE public key of a validator commit-

tee.

2. Users generate a proof of validity of the input data (to avoid providing

random bits).

3. The transaction sent by the user to the mempool includes both the encrypted

data and the proofs.

4. The block builder checks the proofs and executes the transactions in the

block.

5. The network agrees and commits the block.

6. The committee nodes exchange decryption shares of the result. Check how

this is done to not expose values to nodes. Is it possible to decrypt only the

public parts and then do the key switches in the user private parts?

7. The committee nodes run a threshold keyswitch of the user states.

8. The user states are either delivered to the user or stored encrypted on-chain

(TODO).

9. The users are then able to decrypt their own state.

Keep in mind that data cannot remain THFE-encrypted on-chain, since the com-

mittees are changing over time.

Nomos Privacy Paper (internal - work in progress)

7 Construction of privacy-preserving apps

TODO

Elaborate:

1. These apps have been selected as foundational for a Network State. We will

explore how they can be built on the platform described above.

(a) The ability to exchange assets p2p (transfers)

(b) An open marketplace for assets (DEXes)

(d) A structure for governance and organization (DAOs)

2. How can apps be designed with this paradigm.

7.1 P2P token transfers

TODO

How is a Zcash-style private transfer implemented on Nomos?

7.2 Decentralized Exchanges: Automated Market-Makers

TODO

Privacy of an AMM in the ideal scenario

1. Maximally private: swapped values, swapped denominations, users, liquidity

providers, LP positions (if concentrated liquidity)

2. Necessarily public: available pools, price of each asset, liquidity or slippage

calculation per pool.

Challenges

1. Price discovery leaks information about the private transactions:

In private AMMs, changes in pricing over time can potentially reveal trans-

action values, undermining the privacy of the participants. This issue arises

because the price of assets in an AMM is determined by the ratio of the

assets in the liquidity pool. When users trade assets on the platform, they

change the balance of assets in the pool, which in turn aﬀects the price. If an

Nomos Privacy Paper (internal - work in progress)

adversary closely monitors the pricing data of the AMM, they can observe

the ﬂuctuations in the prices of the traded assets. By analyzing the timing

and magnitude of price changes, the adversary may be able to deduce the

approximate transaction values, even if the transaction details are encrypted

or obfuscated. This is particularly concerning in private AMMs, where users

expect a high level of conﬁdentiality and anonymity. To mitigate this risk,

private AMMs can implement various strategies to obscure the relationship

between transaction values and price changes:

(a) Introduce time delays: By introducing random time delays in pro-

cessing transactions or batching multiple transactions together, the

direct correlation between individual trades and price changes can be

weakened, making it more challenging for adversaries to identify spe-

ciﬁc transaction values.

(b) Price slippage controls: Limiting the maximum allowable price slip-

page for each transaction can reduce the impact of individual trades on

the overall pricing, making it more diﬃcult for adversaries to deduce

transaction values based on price changes.

varying amounts and timings can help obfuscate the relationship be-

tween real transactions and price changes, making it more challenging

for adversaries to link transactions to price ﬂuctuations.

2. Liquidity values per pool leak information about positions: Simi-

larly to price discovery leaking information about individual trades, liquidity

positions can be be exposed by changes in pool liquidities. Similiar solutions

to those of the price changes can be applied, further improved by the use

of a Multi-asset AMM where all positions are conﬁned to the same global

anonymity set.

TODO: References for Multi-Asset Automated Market Maker (Namada)

3. Timing Analysis: Examining the timing of transactions enables adver-

saries to correlate and identify patterns that might disclose information

about the parties involved in private transactions. The process usually in-

volves observing transaction timestamps or block inclusion times to detect

unusual patterns. These patterns can be particularly revealing when the

timing of certain transactions is unique or when there are a limited num-

ber of participants engaging in the private transactions. Adversaries can

then use these observations to uncover relationships between addresses, po-

tentially leading to user de-anonymization or exposure of sensitive business

operations.

Nomos Privacy Paper (internal - work in progress)

4. Volume and Flow Analysis: By analyzing the volume and ﬂow of assets

in a DEX, adversaries can identify high-value transactions or targets, even

when transaction details are encrypted. This method involves monitoring

patterns in the frequency, size, and direction of transactions within the DEX

ecosystem. For example, an adversary might notice that large transactions

tend to occur at speciﬁc times or that certain assets frequently move between

a set of addresses. By establishing these patterns, the adversary can poten-

tially infer the underlying private transactions or identify strategic targets

for further analysis or exploitation.

Construction of a private AMM in Nomos. Description. Elaborate how

each components tackles the challenges above.

1. Anonymity of users and LPs: ZK

2. Conﬁdentiality of tx: need batching, or randomness in price. Describe the

problem of changes on the pricing in time, being enough to derive transaction

values.

3. Batching only possible with enough transactions. Otherwise randomness.

4. Batching works with HE of speciﬁc amounts, and decryption of total.

Describe other constructions brieﬂy

1. ZKP+SHE-based: Penumbra

2. MPC+ZKP-based: Renegade

7.3 Lending protocols: Private Money Markets

TODO

7.4 Governance: Private DAOs

TODO

Explore:

1. Private creation.

2. Private proposals

3. Private voting.

Nomos Privacy Paper (internal - work in progress)

8 Nomos Virtual Machine

TODO. Description of requirements and how to approach multiple VMs / computa-

tion models

8.1 Owned/shared data types

VM and language that can describe both. References: Sway, Move

8.2 Transparent computations

Language for transparent computations that is compatible with private and TFHE

computations

8.3 Private computations

References: Zeestar. Zkay.

8.4 Additive Somewhat Homomorphic Encryption

TODO. Used for batching

8.5 Public value MPC randomness

TODO. Used for conﬁdentiality when batches are too small

8.6 Threshold Fully-Homomorphic Encryption computa-

tions

Based on Zama’s libraries?

9 Futuristic ideas

TODO

Nomos Privacy Paper (internal - work in progress)

9.1 Intents and solver markets

Intents, also known as expressive bidding or preferences, can encompass a wide

range of scenarios. For example, a buyer might value a package of goods A and B

at $10, but only $4 for each item individually. A logistics company could quote

X dollars for a route if they secure a bidder for the return route at Y dollars. Or,

one’s willingness to pay more for a ski resort trip could depend on a favorable

weather forecast.

In theory, more expressive intents can lead to greater market eﬃciency. How-

ever, implementing this in practice has been challenging due to the complexity of

ﬁnding feasible and near-optimal solutions at the speed and scale of capital mar-

kets. AI oﬀers the potential to create highly eﬃcient intent-based smart markets

by leveraging AI-powered solvers to optimally match complex intents. Blockchain

technology can then be employed for veriﬁcation and settlement purposes.

Here you use the acronym TE, later you use TED ~~increasing~~ increase sorry I didn't finish the sentence: basically I have to express properly that the computation when is batched cannot be known in advance, since all values will be aggregated and then shares distributed proportionally Note to myself: probably BlockSTM is a good reference here. Research. or _a_ user ~~mitigating~~ mitigate ... at the foundation by default. (maybe mention that you can always choose to release information, but you can't hide it afterwards, so it being there at the start is a requirement for _any_ level of practical privacy or anonymity. I assume you meant "per se" Note to myself: add a reference to FuelV2, since this is learnt from them I need to add an extra paragraph explaining how having both public and private computations under the same script causes the function privacy property of the Zexe model to be lost. There is no way around that. As long as you touch public data, the knowledge that you are calling a function to modify that public data is leaked and this cannot be avoided for obvious reasons. However, you don't know which function that is (though it's gonna be trivial most of the time). On the other hand, if a script doesn't touch public data the function privacy property is preserved. May be similar to NervOS's "Cell" construction: https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0019-data-structures/0019-data-structures.md

Comments

Products

Project