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.

4 Likes

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.

2 Likes

I’m still struggling to understand how Halo2 is enough to achieve function privacy in Taiga but a folding scheme is not, and also have some questions about how we are applying Halo2 recursion in Taiga for function privacy.

The idea in Taiga is that we start with an application validity predicate that we want to hide and output a commitment instead, proving that the predicate hidden in the commitment is satisfied by the inputs hidden. As Joe said:

The primary goal is to ensure the appropriate predicate(s) are satisfied in a transaction without publicly revealing which predicates they are.

How are we doing this? From my understanding, given an application VK, we want a recursive scheme that outputs another VK’ that doesn’t reveal the original VK and is still satisfied with the inputs that are hidden (via a commitment) in the note. So, this VK’ is stored in the note (instead of the original VK) and verifies that there is a circuit (the application) that is satisfied whose VK we are not revealing given the witnesses hiding in the app_data_static, app_data_dynamic and value fields. Is this a correct understanding?

From looking at the recursion section in Halo2, how does it match to what we are trying to do in Taiga?

Again, what I understand is that G is a commitment to the polynomial that encodes the application and G' is another commitment that, if validated, it also validates the previous G. Does the function privacy property derives from not being able to link G and G'? If so, how is G and G' connected to VK and VK'?

The VK’ is a fixed verifying key of the verifier circuit, which checks the application proof and compresses and commits the application VK. The compressed/hashed application VK is stored in the resource as “resource_logic”.

In the action/compliance circuit, we publicize the application VK commitment. To guarantee the designated VP is executed without revealing it, we must check the consistency of the two vp commitments from action/compliance and verifier(the recursive one) public inputs.

IIRC, G is the polynomial commitment opening and may not encode the application. You can check the Halo2 accumulation scheme.

Could you elaborate on “we must check the consistency of the two vp commitments from action/compliance and verifier(the recursive one) public inputs.”?

I’m trying to understand the details of how Taiga does function privacy.

Also, where do you think a folding scheme fails to work for function privacy?