9 + 1 Open Problems In The Privacy Space

Part one of our privacy series covered the “what, why, and how” of privacy in blockchain networks. Part two examined the endgame for privacy infrastructure, arguing that all roads ultimately lead to MPC. 

In the third (and final) part of the series, we explore nine open engineering problems in the blockchain privacy space in addition to touching on the social/regulatory challenges. We’ve also included a small bonus at the end for eager hackers and app developers looking for inspiration.

If you are thinking about any of these problems or are already building a solution, we’d love to hear from you! Equilibrium partners with ambitious founders through R&D, engineering support, or funding through our venture arm (Equilibrium Ventures).

Additional thanks to Ais (Taceo), Lisa (Aztec), and Olli (Equilibrium) for their input and review!

1. Private Proof Markets

ZK-based privacy solutions - both specialized and general-purpose - have two broad options when it comes to generating the ZKP: 

1. Client-side proving: Users generate the ZKPs on their own devices (maximizing privacy guarantees), but performance is limited to consumer hardware.

2. Outsourcing to a third party: This enables better performance and faster proof generation, but sacrifices privacy as the user needs to send information to the third-party prover who generates the proof.

Private proof markets provide a compromise between these two solutions: The proof generation is delegated to an MPC committee, but no single prover sees the entire information (secret input). The privacy guarantees boil down to those of the MPC committee and it relies on them not colluding. 

The main problem with private proof markets is how to reduce the communication overhead of MPC protocols and make the e2e flow more efficient. A team already working on this is Taceo, which recently published a blog post detailing optimizations that reduce the required communication drastically (achieved constant communication, i.e., independent of the number of R1CS constraints). This results in MPC performance being very close to non-MPC performance!

Once an implementation is mature enough, it could be integrated into an existing proof market to enable easy delegation of private proofs. The main question is whether the gains in latency are worth the loss in privacy guarantees, as there is no way to prevent collusion in a fully provable way. The answer to this question will depend on the application.

Key challenge: Increasing efficiency and getting a mature enough implementation that can be integrated into existing proof markets.

Additional resources:

• Taceo: Private Proof Markets using MPC

• Taceo: The Surprising Efficiency of Honest-Majority MPC for coSNARKs

• ZK11: MPC-Enabled Proof Markets - Daniel Kales (talk)

• EOS: Efficient Private Delegation of zkSNARK Provers

• zkSaaS: Zero-Knowledge SNARKs as a Service

• Scalable Collaborative zk-SNARK: Fully Distributed Proof Generation and Malicious Security

2. Private Shared State For ZK-Based Privacy Blockchains

While ZK-based privacy solutions offer strong individual privacy guarantees, they don’t enable multiple parties to compute over the same piece of private state. This is important for many applications and use cases.

Private shared state can be achieved by combining ZK with MPC (collaborative proving), FHE, and/or TEE. However, combining multiple privacy-enhancing technologies (PETs) introduces additional overhead, complexity, and trust assumptions. In addition, any solution that aspires to provide private shared state without a single point of failure ultimately falls back to the trust assumptions of MPC. 

The main challenges here lie in both increasing efficiency to make more use cases practically feasible and building tools so that application developers can easily leverage the technology without having to bother with the underlying cryptography. Directionally, we are on the right track, but there is still a long way to go.

It’s worth noting the difference between private proof delegation (point 1) and private shared state. In private proof delegation, you're doing very specific "MPC-friendly" operations, which means the overhead can be almost zero. Private shared state, on the other hand, is more general-purpose compute and requires a much broader set of operations. This leads to more overhead. 

Key challenge: Reducing overhead to make more use cases practically feasible and strengthen privacy guarantees (e.g. by increasing the number of nodes part of the MPC committee).

Additional resources:

• Noir Request: Private Shared State

• Taceo: A First Look at Collaborative Noir

3. Accelerating Client-Side Proving On Smartphones

86% of the global population have smartphones today (~7.1bn) and particularly in emerging markets, smartphones are the dominant way for people to access the internet. Conversely, most blockchain applications today still cater to a browser extension on a laptop or desktop computer. 

How does this relate to privacy use cases? ZK-based privacy applications rely on client-side proving (proof generated locally on the user’s device). Unless we also focus on smartphones, which can have much worse hardware specs than the average laptop, the UX may be unusable. The heavy proof aggregation work, on the other hand, can be delegated to an external server without sacrificing privacy guarantees.

This is less of a concern for FHE, MPC, or TEE-based private applications where the private computation is delegated. This would also be true for ZK in the case of private proof markets (point 1), but giving users the option to generate proofs client-side is still important.

Existing private applications that are mobile-first are relatively simple (in terms of proof complexity), which is how they achieve low enough e2e latency (proving and verification) so it doesn’t affect the user experience. 

One example is the private payments app Payy, which achieves e2e latency of <5s on recent iPhone models and somewhat longer for cheaper Android models. This is primarily due to the small proof size (2^16 constraints), whereas proofs for more complex programs are typically >2^21 constraints. These would take much longer to generate and require more efficient proving algorithms. 

Key challenge: Optimizing client-side proving so it's performant enough even with the constraints of lower-end smartphones and cheaper hardware.

Additional resources:

• ZPrize: Accelerating MSM on mobile

4. Hardware Acceleration

Of the PETs that are most relevant to blockchains, ZK and FHE face the biggest compute bottlenecks and would benefit the most from hardware acceleration:

• The current overhead on FHE computation is several orders of magnitude higher than plain execution. This excludes the additional overhead from the MPC decryption network (and potentially verifiability with ZKPs). Examples of teams working on FHE hardware acceleration include Optalysys, fhela, and Niobium.

• ZK-based privacy protocols would also benefit from hardware acceleration since only the initial proof needs to be done client-side (or collaboratively with MPC). The generation of aggregation proofs can be outsourced e.g. to a proving network. Teams working on ZK hardware include Fabric Cryptography, Ingonyama, and MayaZK.

The challenge with hardware acceleration for both FHE and ZKP is that the space is still evolving at such a rapid pace that any custom-designed hardware would likely become obsolete quickly (potentially even before it’s released). Therefore, we’ll likely see more focus on software optimization before proving systems become more ossified and the pace of research breakthroughs slows down.

MPC is mainly constrained by communication overhead, which can be reduced with more efficient MPC schemes, preprocessing, and reducing the number of parties included in the cluster. Computation is not a bottleneck for MPC.

Trusted hardware or trusted execution environments (TEEs) already require specialized hardware, so they don’t fit into the discussion here. In addition, TEEs' compute overhead is already relatively low compared to other PETs. Instead, research questions are more about enhancing the privacy and trust guarantees that TEEs can provide.

Key challenge: Balancing the rapid pace of software innovation with the demand for hardware acceleration to make more use cases practically feasible.

Additional resources:

• Ingonyama: Revisiting Paradigm’s “Hardware Acceleration for Zero Knowledge Proofs”

5. Scaling Reads For UTXO-based Privacy Chains

Querying and indexing state (such as account balance) in UTXO-based privacy chains is more complex than sending a request to an RPC node. Telling a public node how to view your data is similar to trusting a third party, significantly weakening privacy guarantees. At this level of privacy guarantees (trusted privacy), other solutions are simpler and more efficient (e.g. A validium with a centralized party storing the data).

Rather than relying on an RPC provider, users sync locally by scanning for records that exist in the append-only database and haven’t yet been used (i.e. don’t exist in the nullifier tree). This is resource-intensive and becomes increasingly difficult as the append-only database (private note tree) grows. 

Zcash faced this issue in 2022 when it experienced a massive increase in shielded transaction volume and wallets had trouble syncing. Aztec expects to face similar problems and is taking preventative measures to find a solution. Some proposed solutions include private information retrieval, oblivious message retrieval, or fuzzy message detection.

Key challenge: Ensuring that users and wallets are still able to sync to the chain without having to rely on centralized third parties.

Additional resources:

• Zcash: Scalable Private Money Needs Scalable Anonymous Messaging

• Aztec RFP: Note Discovery Protocol

6. Private Bridges

While the demand for bridging between private chains has been limited thus far, we are now seeing multiple privacy-focused chains launch or be close to launching their mainnet (Namada, Penumbra, Mina, Aleo, Aztec, Polygon Miden…). The future will likely be multi-chain and private (although varying privacy guarantees), requiring bridging between private chains (for example, between Aleo and Aztec).

Most information leaks when moving between shielded sets, yet all solutions today require unshielding before bridging and re-shielding on the other chain. A private bridge would enable bridging between chains without unshielding in between, aiming to maximize privacy and make it harder for unwarranted outside observers to track. This area remains under-explored.

Key challenge: Enabling briding between shielded sets without having to unshield and re-shield in between (leaking information).

Additional resources:

• Private bridge protocol design rationale, constraints, and brainstorming (Anoma)

• Private blockchain bridge - Iraklis Leontiadis

7. Proof of Passport with Biometric Identification

Identity solutions and proof of personhood enable us to leverage real-world identities for on-chain applications, opening the door to new use cases and richer social graphs. However, considering the sensitivity around identity and its misuse, strong privacy guarantees are non-negotiable.

Besides biometric identity methods such as World, another approach that’s gained recent traction is ZK passports. Scanning your passport with NFC and generating a ZKP enables you to prove some aspects of your identity, such as that you own a valid passport and additional metadata (e.g., age, or country of birth), without revealing all the information to the verifier. Protocols working in this category include Rarimo and ZK Passport. 

However, existing ZK passport implementations don’t enable proving that it’s your passport or that you are the valid owner of it. This can lead to potential problems around identity theft or markets where malicious parties can buy/rent a digital identity for a specific purpose.

Proving that you are the valid owner of a passport would require some additional biometrics, such as fingerprint or face-ID recognition, to match the data on the passport. The two main challenges with this are:

1. Computationally intensive: Generating the proof client side on a smartphone is challenging (high complexity). This is particularly true for lower-end smartphones, which are more prevalent in emerging markets.

2. Existing hardware is not accurate enough: Even if the performance was sufficient to generate a ZKP, smartphone cameras are not necessarily accurate enough for this scanning. Hence, we would require custom hardware such as the Orb by World.

Key challenge: Incorporating biometric identification into the ZKP and proving that you are the valid owner of the passport by using a smartphone (rather than relying on third-party hardware solutions).

Additional resources:

• OpenPassport: Docs and GitHub

• Rarimo ZK Passport: Docs and GitHub

8. Improving Developer Tooling, Standards, and Testing

Existing tooling, libraries, and standards from public chains can’t be imported directly to private chains due to differences in available data, account structure, etc. This makes it much more challenging for developers who want to build private applications since they don’t have familiar tools to rely on (from initial prototyping to developing production-ready code and testing).

While the founding team will often build some of these, in most cases the community and third-party developers are more effective in accelerating the development and diversifying the available toolings. 

Companies like Venture23 or Obscura are already working on tooling, oracles, APIs, and various SDKs to simplify the process of building private dApps on Aleo, Aztec, Dusk, and Mina. An example of an independent contributor is Aleo hackathon winner Leology, a Rust-based testing framework that aims to make it faster, easier, and safer to develop programs on Aleo. However, more is needed.

Given that application developers are crucial to making an ecosystem come to life and offering users a wide range of applications, making the developer experience as smooth as possible should be a top priority for all new ecosystems! 

Key challenge: Improving developer experience and ensuring developers have all the necessary tools to build private applications.

Additional resources:

• Venture23 GitHub for ZK primitives and tooling

• Obscura Docs

• Zama Bounty Program

9. Compiler for zkDSLs To Enable Writing Private Applications In Common Languages

Most ZK-based programmable privacy protocols have a purpose-built domain-specific language (DSL) for building private applications. These higher-level languages aim to abstract away the complexity of writing ZK circuits. 

Some examples of ZK-DSL include Leo by Aleo, Noir by Aztec, and o1js by Mina. While they are built to resemble common languages, like Rust or Typescript, they still require developers to learn a new language and rewrite their codebase. What if you could instead just use a common language?

This is already true for some approaches to programmable privacy. For example, Zama’s fhEVM enables writing private applications in Solidity, meanwhile, Arcium’s MPC-compute network is Rust-based. There is also already a Noir compiler for Solidity. 

Key challenge: Balancing the loss in efficiency with removing barriers of entry for new developers.

10. Social, Compliance, and Regulatory Challenges

Privacy is both a social and a technical problem to solve. While a lot of work remains on the technical side, we have a relatively good idea of the roadmap.

The main challenge on the social and regulatory side is particularly for stronger privacy guarantees (non-intermediated) and financial use cases. A secondary challenge is to get people to experiment with privacy in fun ways, such as what Cursive is doing. There are a few approaches to tackle this, which are not mutually exclusive:

1. Aim for weaker privacy guarantees as an intermediary step: Most privacy projects within crypto today aim for the strongest level of privacy guarantees, i.e. privacy from other users, service providers, and governments/governmental bodies. However, most blockchain interactions today are fully public and visible to all external observers. Perhaps a reasonable first step would be to aim to at least get privacy from other users (“web2 privacy”) rather than jumping straight to the far end.

   

2. Work with regulators to educate them: Many organizations and individuals are already working hard on this, including general privacy-focused (such as Electric Frontier Foundation and Internet Society), those focusing on privacy in blockchains (such as web3 privacy and DC Privacy Summit), and those focusing on blockchain more generally (such as Blockchain Association and Crypto Council For Innovation). However, more policy efforts globally will be needed to educate regulators and lawmakers about how privacy-enhancing technologies can be used in blockchains to protect users and enable more innovation.

3. Challenge existing regulation by building applications with hard privacy guarantees: Any new technology will face resistance from decision-makers, particularly if it risks reducing their power. The most rebellious approach is to do things first and ask for forgiveness later. With enough momentum and user adoption, one can be in a much better position to negotiate and affect the regulatory landscape. This is how technology typically evolves.

Bonus: RFPs and Ideas From Projects and Ecosystems

If you are looking for inspiration on applications to build or a hackathon project, the list below can act as a guide:

• Noir Research Grant proposals: NRG #1 zkEmail and NRG #2: Private Shared State

• ZK Email: Product, infrastructure, and research ideas

• Web3 Privacy: Privacy Idea Generator