Research: Data & Function Privacy Architectures
Research: Data & Function Privacy Architectures
Thank you to Anna Rose, Christopher Goes, Awa Sun Yin, Tarun Chitra, Can Gurel, & Yulia Khalniyazova for valuable insights, guidance, feedback, and answering many of my questions. Without your assistance this article which looks much different than the early drafts would not have been possible. Errors are my own.
Intro
TLDR: In this article, we examine the architectures of Namada, Penumbra, Taiga, ZEXE & SGX.
Today the state of privacy on public blockchains sucks. Sovereign chains like Zcash or Monero provide strong privacy guarantees but limit users to interacting with ZEC & XMR exclusively. Also, these sovereign chains do not privately interoperate with other popular chains. Smart Contract based privacy preserving solutions like Tornado Cash, built on top of Ethereum, have proven vulnerable to censorship, stemming from regulatory misunderstandings. Users want both data and function privacy.
•Data privacy is privacy for user data, tx graph, e.g. Namada provides this with Sapling/MASP
•Function privacy is the program’s logic retains privacy, e.g. ZEXE-like systems, Anoma’s Taiga
Even given the existence of function privacy, It has been widely recognized that a truly private decentralized exchange (DEX) is not feasible. In the paper A Note on Privacy in Constant Function Markets Makers by Angeris, Evans, and Chitra found that:
•CFMMs have to post some public information (e.g. a price)
•Given a small set of data about a market’s initial state, one can use the public data to recover the private data
•Simply hiding reserves is insufficient
Amidst these constraints, we’ll take a look at the solutions emerging in the privacy design space by examining the data and function privacy architectures of Namada, Penumbra, Taiga, ZEXE & SGX.
Data Privacy
Namada
Namada is the first fractal instance of Anoma. Namada is a product, version 1 release line of Anoma. Namada uses a MASP to shield assets enabling multi-asset private transfers for any native or non-native assets; eg. ICS-20 & ERC-20.
TLDR
•Sovereign POS blockchain
•Tendermint BFT consensus
•MASP; Groth 16
•Full IBC protocol support
•Native Ethereum bridge
•Modern POS system
Namada has three phases of deployment
- Assets-agnostic privacy chain
- Privacy likes company – adds many bridges to interoperate with other systems
- Making privacy win-win – makes bridges private to make privacy win-win
Size Matters
As a heuristic, size matters, the larger the anonymity set the more utility all users receive. There exists a public benefit to transacting privately. Namada attempts to capture this with incentive design by incentivizing value at rest being private. The idea is to send flow of value that people get from the large shielded set back to participants who help maintain the size of the shielded set. Namada incentivizes value at rest with their convert circuit.
The convert circuit uses homomorphic Pederson commitments which enables minting and burning of assets according to fixed, public ratios. The cc distributes rewards proportional to the amount and length of time an asset is in the shielded pool. There are proof-of-stake epochs once per day. Users can use the convert circuit to upgrade their assets to the latest epoch allowing them to claim rewards. User assets in the shielded set earn a privacy yield over time which can be thought of as a subsidy for providing privacy for all as a virtue of holding value at rest.
Asset Movement
So how would a user interact with Namada to achieve privacy comparable to using a private DEX? In our example below, Alice, assuming she does not leak her IP address, is able to retain privacy while transferring funds throughout the interchain.
- Alice has 10 WETH and wants to purchase 10,000 ATOMs without revealing any information about her account. Alice bridges her 10 WETH to Namada then creates a fresh Osmosis account
- Alice bridges her WETH from the shielded pool to Osmosis via IBC
- Alice completes a swap of 10 WETH for 10,000 ATOMs
- Alice transfers her funds back to Namada via IBC. Alice may then later decide she wants to stake her ATOMs and participate in Cosmos Hub governance.
- Alice initiates an IBC transfer to a new cosmos hub address to delegate her ATOMs.
The above is only one possible example of how private swaps can be facilitated with Namada. On the surface, this process seems cumbersome for users wanting to execute steps 1-5 manually. Can this be abstracted away? Yes.
Shielded Actions
With shielded actions on Namada, the user signs a sequence of actions that get triggered automatically. This way, the user has traded privately.
•Shielded actions can be compatible with Ethereum DEXs & Cosmos DEXs, as in the example above
•Shielded actions can be used to split trades between multiple locations depending on the asset pair and user trust preferences
•Shielded actions also allow users to gain front-running protection by encrypting trade instructions to a threshold public key once Ferveo is live on Osmosis and Penumbra deploys their threshold encryption scheme
The Anoma foundation plans to coordinate with the Osmosis community to develop a version of the Osmosis frontend which gives users a great UX, but performs Namada shielded actions under the hood, so assets can be kept private at rest and available to be swapped whenever users like.
Roadmap
In Phase 2 of development, Namada will add bridges to more ecosystems allowing Namada to provide a unified privacy set for the interchain. In fact, recently, Christopher Goes of Heliax proposed a Zcash to Namada bridge using the FROST threshold multi-signature scheme.
Phase 3 entails making these bridges private so users can privately move funds to and from all privacy chains. This is tricky as privacy breaks fault isolation. Multiple solutions involving more cryptography are being investigated and not yet finalized.
Undoubtedly Namada offers privacy in a way that is simple enough for users to understand while providing incentives for users to keep their value at rest within Namada’s privacy set.
Penumbra
Penumbra is a private proof-of-stake network and shielded DEX, for the Cosmos ecosystem.
TLDR
•Users privately swap between any pair of assets (ZSwap)
•Architecture enables shielded swaps, shielded transfers, and shielded staking
•Penumbra records all values in a single MASP
•Uses sealed-bid batch swaps
•Individual trades do not reveal trade amounts
•Concentrated liquidity CFMM for market makers
•All peer to pool swaps in each block are executed in a single batch
•Only the total amount in each batch is revealed, and only after finality
Architecture
•Users privately burn their input assets off chain and encrypt the amounts to a threshold key on-chain controlled by the Penumbra validators.
•The threshold encryption is additively homomorphic, so the validators aggregate the encrypted amounts and decrypt the batch total
•Validators compute the effective (inclusive of fees) clearing prices and commit them to the chain state minting the user’s private output.
•User mints a private output by computing their new balance
The only data that is revealed is the aggregate flow of assets into the AMM in the particular block. This technique limits front-running prior to block inclusion, and produces privacy for individual trades up to the size of the batch. Flow encryption will ship after ABCI v2 is stable and live.
Asynchronous Execution
- User generates a swap NFT
- Swap NFT registers an intermediary off-chain status state
- NFT is merged with an on-chain condition to compute the balance for each user
Optimal Arbitrage
Another key property is that once batches are decrypted you can globally resolve all trading intent with optimal arbitrage. The protocol aggregates the amounts of all orders of a particular AMM and then executes these batches against the AMM as a single trade. Users do not experience additional trading latency from batch swaps because the batch swap occurs in every block, which is the fastest discrete time to finality. A longer batch latency could help improve privacy for market takers but would degrade user experience.
Interoperability
•Assets are transferred into Penumbra with IBC and then make private transactions for any arbitrary IBC assets.
•When Penumbra processes that IBC transfer, it mints a note to that address, whose amount and denomination match the IBC transfer and the receipt address.
•Inbound transfers shield value while outbound transfers expose value.
Future and Generalized Framework
There is a lot to like about Penumbra’s design. The initial design motivations were based on getting users to use a shielded DEX because it is strictly better than a non-shielded DEX, not just because it provides users with enhanced privacy. In the near-term the focus is on doing one thing well. However, there is a path towards a generalized framework in the future which supports more than one application.
Function Privacy
Taiga
Taiga is Anoma’s operating system for privacy-preserving distributed applications. Taiga provides a logic for privacy-preserving program execution, including intents, solvers, and transactions. Anoma is a tool for coordination. Anoma provides both counterparty discovery and settlement in a heterogeneous trust, privacy-preserving way.
TLDR
•Operating system for distributed applications
•Shield State Transitions – data & function privacy
•UTXO based – each tx is a list of input and output notes(resources)
•Validity Predicates- declarative smart contracts. A valid tx requires all relevant VPs to be satisfied
•Intent-centric – build around user preferences, intents
•Atomic state transitions of arbitrary complexity
•Counterparty discovery – matching intents is taken care of by solvers
Counterparty discovery & atomic matches
In Anoma’s framework users express their preferences with intents. Users describe what they want, the final State or the properties it should have, and Taiga tries to make sure their intents are satisfied with the help of a counterparty discovery layer. Matching intents is taken care of by solvers.
•Solvers take intents and make partially or fully matched transactions
•Solvers determine what/when to match, what to charge for partial solving, and how to deal with surplus
•Once a solver forms a fully balanced transaction they submit it to a mempool node which is part of the Typhon protocol
Taiga uses a notion of VPs which are declarative smart contracts. In more well known SC architectures you write down what you want to do and execute. With VPs you describe the final State or the properties it should have and Taiga makes sure the VPs are satisfied and doesn’t care how it’s done. For example when you go to a restaurant you don’t necessarily (though you may) care about how food was made. Instead you order off the menu and let the kitchen staff worry about making the meal. Conversely when you prepare food at home you have to take an interest in how the food is made.
Multi-Party Barter Example
There are users who want to get something and they have something, they can satisfy one of the other users, but need to be combined in a cycle; A wants what B has, B wants what C has, and so on before F closes the loop. Every user creates intent notes.
- Solvers 1-3 match the first layer of intents and pass the outputs, partial txs, to the next solver
- Solver 4 completes the matching of partial transactions which reveal less information than the initial intents
- Now because everyone is satisfied all intent notes can be destroyed and the tx can be sent to a mempool
Privacy
•Taiga achieves both data and function privacy
•Taiga keeps notes verifiably encrypted
•Taiga uses recursive ZKPs to achieve function privacy
For data privacy, Taiga publishes note commitments and people know some notes just started to exist. For transaction data, what notes are being transferred, created or destroyed, who participates, value of notes, and applications, Taiga uses ZKPs, hashes, and blinding to keep everything private.
Function privacy refers to validity predicates because they represent application functions. Taiga uses recursive ZKPs to achieve function privacy for Validity Predicates. The proof of a VP is hidden inside another proof so the outer verifier doesn’t know what’s inside the VP.
Proving & Benchmarks
The proving system is Halo 2 built by Zcash. The team at Heliax considered Plonk-based as well as other polynomial commitment schemes, but Halo 2 supports recursion and accumulation, has some helpful gadgets; eg. EC operations & Hashes. Halo 2 does not require a trusted setup which is important when you have a lot of circuits.
•Blake 2 hashes for field-independent commitments
•Poseidon is used for many things
•Sinsemilla commitment scheme for note commitments (same as Orchard)
•Pedersen commitment (or something very similar) for value commitments
•Zcash’s Pasta curves
Benchmarking the VP circuit performance, proving takes ~ 1.7 seconds to generate the outer proof (VP) and 32.2 ms to verify on an Apple MacBook Air M1 with 16 GB RAM.
While Taiga is still in the early stages of development it clearly has potential to standardize the interchain architectures for private counterparty discovery.In the future more privacy can be achieved with an MPC between agents or if the solving is done in FHE. However both of these approaches represent new challenges which are out of scope of this discussion.
ZEXE
TLDR
•Zexe is a ledger-based system where users can execute offline computations and subsequently produce transactions
•Offline computations in Zexe can be used to realize state transitions of multiple applications simultaneously running atop the same ledger
•Core cryptographic primitive Decentralized private computation (DPC) schemes
•The Zexe execution environment is called Record Nano-Kernel (RKN) which accepts records, birth and death predicates
•Several instances of Zexe exist including those built by for Anoma, Aleo, & Espresso
Zexe:Enabling Decentralized Private Computation is a groundbreaking paper published in 2020 by Bowe, Chiesa, Green, Miers, Mishra & Wu. Zexe (zero knowledge execution), is a ledger-based system where users can execute offline computations and subsequently produce transactions, attesting to the correctness of these computations,that satisfy two main properties:
•Privacy – transactions hide all information about the offline computations
•Succinctness – transactions can be validated in constant time by anyone, regardless of the offline computation
This means that users can carry out transactions without revealing the specifics of those transactions, ensuring privacy and security.
As expected, Zexe also offers rich functionality. Offline computations in Zexe can be used to realize state transitions of multiple applications simultaneously running atop the same ledger. Application users do not have to trust, or even know of, one another. Zexe supports this functionality by exposing a shared execution environment with three properties:
•Extensibility – users permissionlessly execute arbitrary functions of their choice
•Isolation- functions of malicious users cannot interfere with the computations and data of honest users
•Inter-process communication – functions may exchange data
The core of Zexe is a construction for a new cryptographic primitive called decentralized private computation (DPC) schemes which rely on cryptographic proofs, including succinct zero knowledge proofs and recursive proofs.
Instances of Zexe
Taiga is an instance of Zexe, in a way, tailored specifically for Anoma. There are several teams building their own version of ZEXE including Aleo & Espresso
•Zexe – Groth 16, trusted setup per circuit
•VeriZexe- UltraPlonk/TurboPlonk, universal trusted setup
•Taiga– Halo 2 (recursion), no trusted setup
Plato on Zexe
There will be many individual instances of which we can refer to as Zexe. What do we mean by the word Zexe? Obviously, something different for each particular instance of Zexe. An instance of Zexe is Zexe because it runs a common protocol general to all instances.
Language cannot be an effective substrate for communication without general words for things like Zexe, and such words therefore are not meaningless. But if the word Zexe means anything, it means something that is not this or that Zexe, but some kind of universal Zexeness. This is not born to exist when some new Zexe instance is launched, and does not die when a Zexe instance dies. In fact, Zexe has no position in space or time, it is eternal.
The word Zexe means the ideal version of the Zexe protocol, Zexe, created by Bowe, Chiesa, Green, Miers, Mishra & Wu. Particular instantiations of Zexe partake in the nature of Zexe, but more or less imperfectly; it is only owing to this imperfection that there can be many instances of the protocol. Zexe is real, particular instances are only apparent.
Trusted Execution Environments
Trusted Execution Environments (TEEs) like Intel’s Software Guard Extensions (SGX) provide an alternative approach for private computation on blockchains. SGX enclaves offer a protected space for sensitive data processing and storage, while remote attestation, such as Intel Attestation Service (IAS), verifies the integrity of these enclaves. Leveraging SGX alongside zero-knowledge proofs or FHE allows for secure and private transactions.
An SGX is useful when introduced as an added layer of security on top of cryptographic security. When combining these systems with a SGX you may be able to achieve a better outcome than using one system in isolation:
•SGX has a different threat model than the aforementioned protocols,the more layers of security the better, the threat model depends on the marginal cost of an SGX attack, not whether an SGX can be broken at all
•Each additional new attack cost should increase (assuming SGX is relevant), making the marginal cost of attack more expensive over time
•SGX can be made safer by only using a sealing key rather than a remote attestation key. Extracting the sealing key requires destroying the hardware
Generally, this line of thinking suggests that using an SGX for defense in depth may be a worthwhile pursuit when combined with cryptography.
Applications of SGX
The above diagram shows how a user might interact with SGX based privacy blockchain like the Secret Network. SGX can be used for a variety of applications. Examples of SGX in practice and upcoming deployments include:
•The Secret Network
•Avalanche Bridge
•Oasis Network ParaTime
•Flashbots block builder
•2 factor authentication for rollups
Key Risks
• Properly modeling and understanding the cost of an attack
• Regulation which halts production or bans use
• Difficult to run on consumer grade hardware
Conclusion
Data and Function privacy architectures are real. While most protocols are still under construction, one can see a clear path forward for developers and users to build function privacy into their applications. In the future cryptographic schemes like FHE, Witness encryption, and ZK/FHE combinations will enhance function privacy and take it to the next level.
In addition to the protocols mentioned in this article, teams like Manta Network, Aztec, Aleo and others are developing function privacy solutions.