Accountable Privacy in Web3 (4/4)

While blockchains have revolutionized transparency and decentralization, privacy remains an open challenge. Most privacy solutions today are either experimental research proposals or early-stage software projects under active development. The landscape is rapidly evolving, influenced by breakthroughs in cryptography, shifts in regulatory frameworks, and advances in computational power.

Having covered most of the foundational concepts in previous articles, this piece serves as a structured introduction to the current state of blockchain privacy. It highlights different approaches, their advantages and tradeoffs, and offers a high-level mental model of the space.

The Privacy Trilemma

In his paper on decentralized e-cash, Dr. Ittai Abraham introduces three important properties for privacy-preserving solutions in the blockchain space:

• Trust: Users should be able to place a high degree of trust in their “coins” and the encryption schemes used to secure them.
• Scalability: Privacy solutions should aim for minimal performance overheads, ensuring efficient use of both computational time and space.
• Accountable Privacy: While certain information should be securely hidden, the network should also be accountable and regulation-friendly.

Fig 1: Impossibility trilemma for privacy protocols

Unfortunately, no existing solutions are able to cover all 3 properties simultaneously. Instead, they balance tradeoffs between trust, privacy, and performance overheads. To do so, they rely on commitments, ZK proofs, homomorphic encryption and so on.

Lastly, each solution is optimized for the two main blockchain models—UTXO or account-based.

UTXO vs. Account Model

The transaction model of a blockchain dictates how balances are represented, transactions are processed, and how different privacy mechanisms can be applied to it.

UTXO-based blockchains (e.g., Bitcoin, Zcash) represent balances as discrete transaction outputs.

• Each private key “owns” a certain number of unspent transaction outputs (UTXOs).
• A transaction consumes existing UTXOs and creates new UTXOs for the sender and receiver.
• UTXO models allow for more tractable privacy solutions on blockchains.

Account-based blockchains (e.g., Ethereum, Solana) maintain a global state where each account holds a balance, and transactions update this state directly.

• Each private key controls an account that has a single, continuously updated balance.
• A transaction directly modifies the sender’s and receiver’s account balances in the global state.
• It is harder to implement privacy solutions over this design, as we will discover later.

Privacy in Transactions

At first, blockchains were meant only for processing token transfers (e.g. Bitcoin). While Web3 may have moved onto putting arbitrary programs on a blockchain, trustless transactions are still a key value proposition of blockchain technology.

We begin by looking at how privacy mechanisms can be applied to transactions.

Confidential Transactions

Confidentiality refers to obscuring transaction amounts while keeping sender and receiver addresses visible. This is done using two cryptographic techniques:

• Pedersen Commitments: The transaction contains a homomorphic commitment to the amount, which can be added and subtracted without revealing individual values. This ensures the total value inputted matches the total output without exposing the amounts.
• ZK Proofs: Since naive commitment schemes can allow for hidden inflation (e.g., negative values or arbitrary minting), ZK proofs are used to prove a committed amount is within an expected range (e.g., non-negative values).

How It Works:

1. The sender constructs a transaction with Pedersen commitments for input and output amounts.
2. A range proof (ZK) is generated to ensure the values are within acceptable limits (more than zero, less than the user’s balance).
3. The transaction is broadcasted, and validators confirm its validity without learning the amounts.

Do note that while amounts are private, addresses remain exposed, meaning a transaction graph analysis is still possible. Moreover, some ZK-proof schemes require an initial trusted ceremony (as covered in article 2) which can potentially be a security risk.

Fully Anonymous Transactions

Fully anonymous systems extend confidentiality by concealing both transaction amounts as well as the identities of the senders and receivers. This is achieved using the following techniques:

• ZK Proofs: These allow a user to prove they own some unspent funds and are authorizing a transaction without revealing which specific UTXO (or the amount, in the address model) is being used.
• Commitment Schemes: Each UTXO is assigned a unique cryptographic commitment. When spending a UTXO, this marker is revealed publicly on the network. This prevents double-spending.
• Anonymity Sets: Instead of a direct P2P system, transactions are linked to a group of senders and receivers. This helps preserve the privacy of the individual user.

How It Works:

1. The sender creates a zero-knowledge proof, proving they are part of a set, they own the funds and that the transaction is valid.
2. The proof is included in the transaction and broadcast to the network.
3. Validators confirm the proof’s correctness without learning any details about the transaction’s sender, receiver, or amount.
4. A nullifier is generated, marking the coin as spent without revealing which UTXO it corresponds to.

Do note that this approach introduces some challenges for the UTXO model. Firstly, since the coins are private, the network must store all the spent coin identifiers forever to prevent double spend. The size and creation of the anonymity sets is also a matter of research.

Account-based blockchains, unlike UTXO-based ones, maintain a global state where account balances persist across transactions. Implementing privacy in this model is more complex since each transaction modifies a shared state, making balance updates potentially visible.

Dual Key Stealth Addresses

Stealth addresses provide recipient privacy by generating unique, one-time addresses for every transaction. Unlike commitments and ZK proofs, which focus on hiding transaction amounts or sender identities, stealth addresses protect recipient anonymity in both UTXO-based and account-based blockchains.

By extending existing protocols like Bitcoin and Ethereum, stealth addresses allow for privacy-enhanced transactions without modifying the core blockchain architecture.

They are built on the following primitives:

Dual-Key Stealth Address Protocol (DKSAP)

• The recipient generates two keys:
• Scan Key: Used to detect and retrieve transactions.
• Spend Key: Used to spend received funds.
• The sender derives a one-time address from these keys for each transaction, preventing multiple payments from being linked.

Elliptic Curve Diffie-Hellman (ECDH) Key Exchange

• Allows the sender to generate a stealth address without direct interaction with the recipient.
• Ensures that only the recipient can recognize and access the transaction.

Commitment Schemes

• Stealth addresses can be combined with Pedersen Commitments to obscure transaction amounts.
• This is particularly useful when integrating stealth addresses with Confidential Transactions (CT) or Fully Anonymous Transactions (FAT).

DSKAs also struggle to scale as recipients must scan the blockchain to identify payments, adding computational overhead. Moreover, stealth addresses only hide recipient identities—amounts remain public unless combined with ZK proofs or commitments. In the case of Ethereum and other account-based blockchains, DSKAs require more complicated custom smart contracts to work.

Privacy in Smart Contracts

Smart contracts introduce programmability to blockchains, allowing the creation of decentralized applications (dApps), However, smart contract interactions are publicly visible, including inputs, outputs, and computational logic.

Privacy in smart contracts is generally classified into two key areas:

• I/O Privacy – Hiding the inputs and outputs while still proving correctness.
• Functional Privacy – Concealing the contract’s internal computation logic while maintaining verifiability.

I/O Privacy

I/O privacy ensures that while a smart contract can process user inputs and generate outputs, external observers cannot see the data being processed. The following techniques are useful for I/O privacy:

ZK Proofs (Off-Chain):

• Users perform computation offline on some plaintext inputs, and generate a ZK proof verifies correctness without revealing data.
• The encrypted inputs, encrypted outputs, and a proof of correct execution is stored on-chain.

Homomorphic Encryption (On-Chain):

• Users encrypt their inputs and provide them to a program on the network
• The network performs computations on the encrypted inputs and broadcasts a set of encrypted outputs.

Trusted Execution Environments (Delegation):

• Programs execute inside hardware-enforced secure enclaves
• The enclave signs the output and broadcasts it to the network

I/O privacy is challenging to implement, no matter the approach. While the ZK approach encumbers users with having to generate their own proofs and perform trusted setups, the homomorphic approach creates complexity for the network’s nodes. TEEs are able to balance user experience with security, but compromise privacy since the user has to reveal their inputs in plaintext to them.

Moreover, since most programmable blockchains employ the account model, I/O privacy mechanisms suffer from concurrency issues too. Assume a user tries to send a proof based on some property of their state to a smart contract. However, they receive a transaction from another user which modifies this state, before the first proof can be verified. Since the proof no longer holds on the underlying state, their transaction is rejected.

Many I/O privacy protocols deal with the issue of concurrency and double-spend by only allowing users to make a fixed number of function calls within an epoch. However, this negatively impacts the user experience.

Functional Privacy

Functional privacy ensures that not only the inputs/outputs but also the computation logic itself remains hidden. This prevents external observers from analyzing the execution path or inferring contract behavior. As of now, functional privacy remains a niche area, with most proposals relying on off-chain ZK or TEE models.

Auditability and Accountability

Privacy-preserving blockchains must support selective disclosure, enabling compliance and oversight without undermining user confidentiality to the whole network. Two core concepts address this:

• Auditability: External auditors verify compliance without revealing user data. Viewing keys allow controlled transparency, while ZKPs prove adherence to regulations without exposing private details.
• Accountability: Enforces predefined compliance rules before accepting a transaction on the network. This may include solutions such as pre-defined private spending limits or stopping transactions with blacklisted addresses.

These techniques allow blockchain transactions to be verified without exposing a user’s sensitive information to other, non-designated users on the network.

Mind Map

In general, the UTXO model pioneered by Bitcoin is superior to the account model in most respects of privacy. However, it is far more challenging to support general compute for smart contracts on UTXO than it is for accounts. Regardless of models, the following heuristic applies:

Goal	Approach	Tradeoffs
Trust	Homomorphic Encryption, TEEs	FHE can be expensive
Performance	Off-Chain ZK Proofs, TEEs	TEEs lose privacy
Privacy	Homomorphic Encryption, ZK Proofs	Computational overhead

It may also be reasonably implied that currently, performant privacy-preserving solutions are mostly limited to private transactions, not general compute, and tend to lean towards UTXOs and off-chain ZK proofs.

Conclusion

Privacy in Web3 operates across a spectrum of tradeoffs. ZKPs remain dominant in balancing privacy and efficiency, while HE and FHE present long-term solutions. TEE-based models trade stronger guarantees of privacy for performance. No single approach optimally satisfies all constraints—hybrid architectures integrating cryptographic and hardware-based solutions will probably define the next phase of accountable privacy.