Validating VK for function privacy

[kike]

Thanks for your thoughts.

One thing I wonder is what is the real purpose of hashing the verifying key. In the DP-only case, I believe is to avoid reading it from the compliance circuit. In the FP, if using a length-reducing commitment, it would give the same effect.

@vveiln

adjusting RM interfaces to be FP-friendly, which includes:

• including the required checks in the compliance circuit

In principle, or intuitively, the compliance checks should not be affected by whether we are in DP-only or in FP, (or as you put it, should be ‘free of side effects’). This is because the checks in the compliance and action units are orthogonal.

In the PR, @xuyang suggested this strategy:

1. The compliance circuit receives logic_vk_hash as a witness from resources and produces the commitment as an instance.
2. The logic proof is generated normally.
3. The recursive circuit generates the logic commitment using logic_vk and the same randomness as in the compliance circuit, verifies logic_vk_hash = hash(logic_vk), and computes c = commit(logic_vk_hash, r). The commitment goes to the instance as well.
4. Finally, check that the commitments from step 1 (compliance instances) and step 3 (recursive instances) are equal outside the circuit.

I wonder whether the compliance circuit could just read the commitment, the same way is done currently (@xuyang). Only in the augmented (outer) logic circuit correct generation of commitments is enforced.

@vveiln

Other approaches to achieve FP (e.g., for zkVMs) are pretty much isomorphic to this one,

Yes they are, esentially, the same. Receive as input a commitment of the (verifying key of the) circuit, enforce its correctness, and run the (verifier of the) circuit.

In the sentence above the recursive strategy includes parenthesis, the zkVM approach doesn’t. However, evil is in details. At this moment we are not even sure whether the zkVM approach works, or what’s needed to make it work.

@vveiln

The second part can be a bit difficult to do since we can’t “enforce” it. The user is incentivised to use the proposed circuit, but what to do with malicious third parties that use the “wrong” FP circuit instead? Since RM shouldn’t really differentiate between FP and DP-only cases, it is hard to check. One way I see to resolve this is to include a VK check somewhere, so that when the user is “offered” or chooses FP option, the VK of the outer circuit is checked against the VK of the circuit offered by the RM implementation.

Is this really a problem? Or in other words, it is our (Anoma/RM) responsability? I’d say we should only worry about developing sound code. That is, ‘standardize’ sound circuits by providing reference implementations for both, DP-only and FP cases. The verifying key of the FP outer layer can be hard-coded in code. That would the simplest, and more realistic, option, I think.