ZK13: Towards a Standard for Programmable ZK Proofs - Ying Tong (Ethereum Foundation)

Transcript

[Music] Thank you everyone for coming to a talk about standards at 4 p.m. Um so for context um I've been involved in the ZK proof standards for a few years now. Um, and as with many standards efforts, the failure mode is that it tends to lose momentum because nobody's full-time job is standards. Um, but recently, uh, the EU Commission has been pushing for a digital identity wallet for roll out in 2026. And the solution that they chose

uh was woefully inadequate for their own privacy regulations. And so essentially they're scrambling now um for an actual zero knowledge privacy preserving solution and they are considering generic zk snarks such as those that we work on. Now the problem is that when you're engaging with um actors at the level of nation states they're going to ask you like what the standard and we don't have one.

So that's the first motivation to work on a standard for generic zk snarks is to even make adoption possible at these scales. Um so you may have seen the announcement from the Google team that they'll be deploying um a GKR licero snark in the Google wallet. uh and they are targeting the EU digital identity wallet use case as well. So um yeah if you were looking for the deployment of ZK snarks at scale it is happening now

um and we need the standard to match we need a standard also to put in safeguards um so that instantiations of these protocols are secure. So uh for example, yeah, there's been any number of um insecure fiat shamir instantiations. There was one very recently with Salana, I think. Um and then yeah, like there's certain arguments that uh you need to be careful about what field you choose. Um, and so basically it's kind of like specifying a

cipher suite. Uh, you need to specify uh what combinations of primitives within the cipher suite are secure. And lastly, a standard is important for upgradability. So this is the Google uh Google published an IETFformational draft. They called it lib zk. Um it is not as generic as it sounds. Uh libzk is just describing their specific GKR plus liarero scheme. But um yeah even today we saw like leharto came out and it

shrinks liara proof size for very little overhead and this field is developing very fast. It is too early to enshrine to oify a specific instantiation. So and furthermore um in different deployment contexts we need different parameters. We we can relax uh security requirements in certain context. We can have bigger proofs in certain context and so on. Um so yeah standards uh at a sufficiently high level allow for this upgradability. Also, I invite any questions and comments at any point in

this talk. Um, yeah, this is another example of a a much older standard um for a much simpler protocol BBS signature that allows for blind signatures. It allows for selective disclosure. Uh, it allows pretty much for the instantiation of anonymous credentials. um is way easier than way simpler than a generic zk snard for it exists as well. Um but maybe worth noting that it relies on pairings and there's also no standard for pairing friendly

curves. Uh and also there's no support for pairing friendly curves in most secure hardware in in insecure hardware elements. So that's why um the EUDI wallet is looking for another solution, a generic ZK solution like what Google has. So um yeah, I guess this talk really is putting forth um a different vision for the standards process. So um instead of standardizing each instantiation of a protocol, we should aim for a higher level of abstraction.

And this is something like like what Ana Leman said in her real world talk. Um that basically we're the current standards process is duplicating a lot of work and it's ending up with multiple uh inconsistent standards uh for the same primitive. Whereas um how we could approach it is to rigorously standardize some core primitive and then for subsequent uh application specific variants um have a standards light process for that. So this is very much a balancing act because as she mentions here uh if your standard is too specific no one else uh it it will not be useful

for anyone else. If it's too powerful and too general, it will give no information. Um, yeah. So and especi I I think all of us are familiar here with the modular structure of modern proof systems that for example you can swap out a PCS um depending on uh like which like if you're optimizing for a fast prover if you're optimizing for a small proof and so on. So it would be really painful if every time you had to swap out a component, you had to go through the whole standardization process again. So that's the intuition behind this meta

standard approach is that um we do not so like lots of us like mix and match um multiple elements here and multiple stacks and we do not want the situation where each combination has to map to a new standard. Yeah. Are there any questions? Okay. I think um the standards world we haven't been engaging with it that much.

Um but the time is now um basically. So I I do think the standards effort is closely related to the benchmarking effort because benchmarking very much involves trying to find common points of comparison across different protocols and you need to do it in a granular enough way that no one complains it's unfair. Um yeah but um so I'm now going to go through some existing efforts um that are already ongoing to standardize generic ZK snarks. Um so the ZK proof standards has been working on standardizing the

plunkish arithmetization for a few years now. Uh so this is very much a specific arithmetization and I think it's um yeah I think the arithmetization layer is probably the trickiest to standardize because like yeah for instance GKR just looks completely different from uh longage and R1Cs air for example like is must be completely structured cannot have pre-process asing cannot have randomness from the verifier and so on.

So um it I think yeah part of this talk is also sort of a call to action for people who are knowledgeable about let's say intermediate representations like ACIR or um like PIL the polomial identity language or um symbolic repres representations to suggest like just suitable levels of abstraction that we can target um with our standards. So at the IOP level um this is an example of a protocol that sort of

composes IOPS in parallel and in series and reduces them to a zero check. Um many of our protocols do look like this. Um and so yeah a standard for IOPS should be flexible enough to allow composition like this and it's I think here it's very related to formal verification efforts. So um if you express um your relation as a series of reductions uh this is very natural for like lean for example to understand um and I think this is very close to what we actually want for an IOP standard. So this is actually called interactive oracle reductions.

Um so the next layer is polomial commitment schemes. I think this is one of the most natural layers to standardize because PCS interfaces have arisen in many projects such as artworks. Uh people I think this is the component that people most commonly swap out. Um and the PCS like interface is um relatively simple just for methods. Um but of course the devil is in the detail as well. Like maybe one thing you notice is uh artworks it does not allow you to use a different field for your witness and your challenge cuz I don't think they support small field uh PCS's. So

there's subtleties like that that arise. Um maybe like your PCS needs more parameters, more degrees of freedom. Um and so yeah very much so I'm working on a draft specification of PCS's. I presented this to the W3C um for initial feedback and this is part of my call to action for comments from you guys about what has been left out of this spec. uh whether or not it's useful, whether it sufficiently describes your protocol. Yeah, I'll put links and whatever.

Um so, and the last step, um so now we're at an interactive argument with polomic commitments and the last step is the fear shamir heristic. So again um Mck Kelly from the ZK proof standards working group has been pushing for an IETF draft for FID shamir and also this library sponge fish for fameir with duplex sponge. uh and I think this is very crucial to standardize just because of like frozen herd vulnerabilities all the common uh insecure instantiations of phmir that we do see in the

wild. Um so uh at the Ethereum Foundation ZK ID project we've been engaging with the open EU digital identity wallet discussions. We've also been engaging with standards bodies. So yeah, we've attended a bunch of the working group calls um and have been familiarizing with self ourselves with their existing specs. So they have this spec called um data integrity that seems very much compatible with the spirit of using generic zks um as sort of a layer for um

integrity assurance. Um so the idea here is if you replace base proof with say an ECDSA signature um the idea here is that you can verify that ECDSA signature within your ZK snarker um and present a derived proof um to the verifier. So um I think how they're using this right now is in the context of BBS proofs whereby the base proof is a BBS signature and the derived proof is a BBS proof that selectively discloses a few

of the messages. But yeah, um this is like very much this is very much um the meta spec structure I was talking about because they do have a generic VC data integrity verifiable credential data integrity spec and then allow for separate sort of standards light instantiations using uh different uh cipher suites. So I I think there is precedence for this.

Um so this is at the W3C but uh I believe the IETF is not too fond of meta standards. Um but in any case it's essential that we have reference implementations, benchmarks and test vectors. it. Yeah, this is just an example of how we've been trying to engage with existing standards uh outside the blockchain world. Um so yeah, I think I'm going to end with my call to action. So yeah, I've been mostly I've been mostly engaging with people outside the ZK world. Um so

people who are very much looking for like an approachable interface um for developers who are unfamiliar with cryptographic primitives. So this crowd today is very different from that. You are experts um in these cryptographic primitives and what would be really helpful for us is if you could comment on our drafts. So we like success for us looks like um a standard that is adopted and we are aware that if people need to modify their libraries to fit the standard then

it's not going to happen. So if um our standard does not um sort of allow you to specify your library, your optimizations, the degrees of freedom that you need. Um it would help us a lot to know about this early. Um and yeah, I invite you to try your hand at writing a few standard slight uh application specific variants of the meta standard.

So yeah, I think KZG is be the easiest by far. Um Liheru is used everywhere now. Google uses Liharu. Um, Leher is like and and liatron also uses liar. So that's a really good one to standardize as well. I think Google also did a lot of the work already in their libzy case spec. So yeah, like submitting sort of standards light um drafts and then as I mentioned um to just call to our attention um protocols and instantiations that you know of that don't fit into the

standard. So like counter examples, edge cases um and like requirements that you have that we don't meet. Um yeah, that's all I had. Thank you. So um it seems that we need actually like un either universal setup or like just no trusted setup, right? Um is there actually a need for something like Gross 16 to be standardized because right like we have maybe two or three implementations of that and and it's much more widely deployed uh still in systems. Yeah, I wrote this to be general over trusted setups and

transparent setups. Um, I think the growth 16 is an is an interesting one that you bring up. Growth 16 does not fit into this neat um modularized sort of view of the modern snark. So yeah, it doesn't use an IOP for example. So yeah, graph 16 is definitely a tricky one. Uh and it's so wide. Yeah, I don't have a good answer to that. That's one of the main edge cases. But but would you say that's it would be useful to standardize it because right it does have a per circuit choice to set up like I'm just wondering what they cover actually cover use cases because that would be an easier point to attack right because already widely deployed

and you know and want to have implementations right that maybe they can be more unified but I'm curious if doing so will be useful because Okay. Yeah. Would like a standalone spec just for Goth 16 be useful? I think absolutely. Um as you said the trusted setup and also like pairings. Yeah. If we had a we look there was a standard for pairing friendly curves and it expired like two years ago or something. We have a problem with momentum and losing it in the standards um working groups. So yeah, I think standardizing GR 16 would be greatly helpful. Yeah, thanks.

Um, so this question is like kind of t um um tangent tangential. So I was curious like um if you feel like any like ZKDSL's like nor or arc works um R1CS um should be or circom should be um like standardized and like what do you think of those like personally your opinion like of these DSLs which one should be um standardized for like common developers to use? A really good question. Yeah. Um, so I think arithmetization is the trickiest part to standardize just because of how much variance there is and how sort of mutually incompatible they seem. Like on

the high level, you could say something general about all arithmetizations. You can say like they all need to take in some relation and witness and they all need to output some zero check. Uh but that that's to me that's an example of like being too high level to be useful. Um so yeah so the there is a working group or that has been standardizing plunkish uh for a few years now. Um and then yeah I think another thought I had was to standardize it at the intermediate representation level. So for example ACIR used by NAR uh it can compile to

both plankish and R1Cs for example but not air um and there's like uh yeah there's there's many sort of attempts to generalize like this CCS um what does it mean customizable constraint system I think also generalizes over plunkish and r1s Um yeah so I don't know arithmetizations is I I think the trickiest um yeah my best sort of approach would be to target the one level lower like at the intermediate representation.

Thank you. [Applause]