Taiga function privacy roadmap

Taiga currently does not have function privacy, but it will. The primary goal is to ensure the appropriate predicate(s) are satisfied in a transaction without publicly revealing which predicates they are. There is also a secondary goal of improving efficiency and scalability by potentially accumulating predicate proof verification. There is also a secondary goal of preparing for Taiga rollups.

The initial plan for function privacy is to build an accumulator circuit that takes as input:

  • Blake2s commitments to the required predicates
  • Commitments to the public inputs of those predicates
  • One or more accumulators

and ensures that predicate proofs are accumulated correctly. Currently, the plan is that every predicate circuit will share the same Halo2 configuration (an assumption that can be revisited later).

Function privacy depends on the following Halo2 issues:

Function privacy also depends on the Blake2s hash and commitment gadgets that are currently being implemented.


What is a rollup in this context?

I’m using it in a very general sense, where we want to use ZK proofs to provide some kind of proof of validity of the current Taiga (or chain) state, for example for light clients, and perhaps also for scalability.

But specifically, the goal here would be to allow a whole Taiga block to be compressed down to (probably) 2 proofs, which may then also (eventually) prove the validity of the entire history.

1 Like

After chatting with Joe and some investigation into the roadmap and the issues listed in [Halo2 IVC demo], optimistically, I may need three months to deliver a workable recursive proof verifier and integrate it to Taiga to achieve function privacy without distraction from other tasks.
I assume our priority is to make it work so that I may have some temporary workarounds and tradeoffs. Then, we polish the PRs to the upstream.