ZKP in Baseline Protocol

Hi! I have some questions regarding several different areas in the baseline process itself ( mainly about zero-knowledge ), but if you could help me out with this one for a starter; could you clarify how in this diagram participant B has access to the circuit? Access as in he has the ability to generate a witness; which means participant A’s circuit should be shared amongst the parties, right? Am I missing something here?

1 Like

Yo! Thanks for the question…

You are talking about the BRI-1 reference implementation for baseline…

The idea behind BRI-1 was to create something end-to-end to showcase how baseline can be used in production. In order to accomplish that at scale-- in the context of ZKPs, we have created Provide Privacy. We are now in the process of adding Provide Privacy to BRI-1.

This will remove the dependency on ZoKrates and demonstrate how the circuit artifacts (i.e., r1cs, proving and verifying keys) are shared between parties and leveraged within a circuit registry for each party. This concept will work for workflows with any number of participants; if you only want certain participants to be able to verify proofs, they will only be provided with the verifying key, for example.

Check out this BRI-1 PR that demonstrates the new Privacy service…

Cheers,
kt

1 Like

Hey @kthomas ,

Thanks so much for the reply. I’ve currently noticed that information is all over the place regarding how to use ZoKrates and especially on how to use it in the context of Baseline. It’s good to hear that you guys are trying to add an improved privacy package to BRI-1, it’s exactly what I have been waiting for!

While looking at the PR I noticed that circuits are fetched through Provide Privacy; does this mean that when two/N parties establish business logic, they can just simply store the “to be used” circuits in the circuit registry you mentioned in your response? So In this sense when I need one of the parties to compute a witness, he/she will simply be able to access the registry instead of me having to manually send the circuit?

Thanks once again for the response! Can’t wait to see this in action!!

@Meuko no worries.

In the latest PR you will find that your intuition about circuits being shared is generally correct in the sense that the registry will store the circuit and references to related artifacts (i.e., proving/verifying keys are stored within Vault). The interface of Provide Privacy makes it such that the compiled R1CS of the circuit itself as well as the verifying and proving key binaries can be easily synchronized among the parties. This is implemented by the new Sync opcode. It is also possible to leverage Provide Privacy in a centralized manner in order to achieve the same functionality without the Sync opcode.

The Sync opcode in the BRI-1 branch as it provides the most distributed solution.

Thanks for the response @kthomas! Okay I think I get it. Just one last thing for now; say that I opt for storing all my compilation artifacts in a central location using Provide Privacy; exactly where will it be stored? Provide based servers? I know you guys also have a Vault service; so perhaps in some Vault instance?

See this architecture diagram:

If centralized, each party would reference the same Privacy service (i.e., running in our hosted environment). The hosted privacy service uses a hosted vault to persist proving/verifier artifacts.

Using the Sync opcode results in the artifacts being stored locally within each participant’s baseline stack.

There are some hybrid solutions we are also considering which relate to leveraging the distributed approach (i.e., each party running their own Privacy/Vault instances) alongside ephemeral GPU instances for scaling cryptographic IOPS in the cloud. More on that later… but let us know if that’s interesting.