ZK8: Succinct Verification of Consensus with zkSNARKs - Uma Roy & John Guibas - Succinct Labs

Transcript

Here, let's welcome Uma and John who will be presenting about ZK-SNARK enabled light client and bridge for ETH 2 clients. Anyways, give them a quick round of applause. Hello, I'm Uma and this is John. And today we're going to be presenting on succinct verification of consensus with ZK-SNARKs.

How do we Maybe it's not on. Okay. Yeah, so let's start with a 10,000 foot overview of the multi-chain and cross-chain landscape. In the past few years, there's been a ton of different blockchains that have come online and they lie on very different points of the trade-off curve in terms of decentralization security throughput transaction fees, etc. And as the number of applications has grown across all these different chains, users generally want to interact between these chains. So, some of the things they want to do include transfer assets from one chain to another and currently a lot of builders are also exploring other applications of cross-chain interoperability that go beyond asset

transfer. And the current space of crypto, like one of its main promises is that it really delivers on permissionless interoperability. And so, if users do want to use multiple chains and multiple different ecosystems, then we should allow these ecosystems to operate in a permissionless, decentralized, and secure fashion. And because of this, we believe that bridges are actually very critical infrastructure in the whole space. So, what's the state of bridging today?

There's a lot of user demand for bridging, and what does it look like? Right now, all the bridges or most of the bridges go through very centralized entities. In particular, most L1 bridges today are built on top of a multi-sig architecture where you have a centralized entity controlled by a set of trusted parties that's responsible for watching deposits on one chain and then signing off on deposits on another. And this is really bad because a lot of assets flow through these bridges, and it's kind of this centralized choke point of, you know, the blockchain ecosystem. And not only is this ideologically bad, it has real consequences.

Uh it the multi-sig design is very censorable, and also practically speaking, there have been a lot of hacks of these bridges. So, in particular, there have been many bridge hacks over the past year or so that have resulted in over a billion dollars of user funds being lost. And I would argue that this is not only bad for the users, it's actually bad for the whole space in general because it lessens the credibility of the entire space, and then it leads to downstream consequences like regulation. Okay, so I've talked a lot about the current problems with the bridging landscape. And so, let's start talking about solutions. So, what does a maximally secure and trust minimized bridge look like between L1s?

So, if we were in a world in which on-chain computation was not expensive and we didn't have to worry about those practical limitations, then a really simple and elegant solution comes to mind. We already have a method for a decentralized group of validators to agree on the state of a chain. It's called a consensus protocol. And so, we think that if we were able to verify the consensus of one chain in the execution layer of another chain, then we can use the same mechanism that's already being used to agree on the state of the chain for bridging. We call this verification of consensus, and we think that if we're able to do this, then it provides a really great solution uh for more secure, decentralized, and permissionless bridging.

Yeah, so before we get into how to actually verify consensus in a practical manner, um let's zoom out a bit and try to understand like the high-level overview of how you might be able to build a bridge or cross-chain communication protocol over this idea of verifying consensus. So, in practice, you're going to have some blockchain like Ethereum, and over the course of its lifetime, um it's obviously generating block headers, validator signatures, attestations, and other metadata and as part of its consensus process. And this information is normally gossiped over the network to other validators. But, what we can also do is we can propagate this information to a smart contract running on another

blockchain such as Gnosis Chain, and inside the smart contract, we could theoretically re-implement all the logic we would normally run to verify consensus. And the reason why this is super powerful is because um if you can verify consensus, you can sort of keep like an append-only list of finalized block headers on this like target chain such as Gnosis Chain. And if you have access to the block headers, um as you probably know, we have access to all of these Merkle tree commitments to the entire state of Ethereum, all the transactions that have ever been submitted, all the events that have ever been emitted, and basically we can trustlessly read any of this data as long as you provide a valid Merkle inclusion proof um against these commitments.

So, why hasn't this been done yet? Well, it's because in proof-of-stake systems, verifying consensus is just a generally very hard problem on consumer hardware with not that much resources. Um in general, for Ethereum, there's two big challenges. So, the first challenge is that there is a lot of validators, and the number of validators is something that you have to keep track in your client which is trying to verify consensus, because you have to know like the validators' public keys and how much ETH they have staked to like accurately calculate um how much their signature is worth.

The second problem, in particular with um the EVM, is that there are no precompiles for the elliptic curve operations um which the Ethereum 2 signature scheme is based off of, which is this curve known as BLS12 uh 381. So, um the developers of the Ethereum ecosystem actually recognized that um like verifying consensus cheaply is a sort of an important primitive to have for your blockchain to run light clients. So, they sort of introduced um this easier to verify consensus algorithm on Ethereum, um and it's known as this uh protocol called the sync committee.

And it's basically the way to think about this is that instead of having 400,000 validators um running consensus on the chain, you select a subset of 512 validators, which are chosen randomly every 27 hours. And basically these validators will just sign um each block header, and if enough of them vote on it, it's considered valid. Now, the tradeoff here obviously is that at the cost of it being easier to verify, um you obviously have much weaker security guarantees as you're assuming that, you know, 2/3 of these validators are acting honestly.

So, we explored this method at first um to see whether we could basically build a light client on chain um with just like these 512 validators, but we found basically in practice is that even verifying this consensus mechanism on chain is uh too gas expensive. Now, the practical reasons for this are that um you have to store these 512 validator public keys and prove that they validly rotate every 27 hours. Um there's also this problem again, which I mentioned previously, where we don't support the elliptic curve operations currently on the EVM needed for these signature schemes. So, for every header you want to finalize, you might have to do up to 512 curve additions and one final pairing check on chain.

So, what's our solution? Well, well our solution is basically to use the technology that ZK Summit is all about and to leverage the power of succinct zero-knowledge proofs. So, what I mean by that is that like in your smart contract, you're going to have some function that's validating new blocks. And in practice, what we're doing in there is some preprocessing step, some check that the current validator set is valid, and then finally we check like the aggregation and the final signature check. And as I mentioned multiple times before, the big two challenges are these two bottom functions that I highlighted in the red.

And essentially, what we can do is that we can move all of this expensive compute off chain. Just wrap it up into a ZK-SNARK, and what we can do instead on chain is just verify this, you know, super easy to verify Groth16 proof on chain. And that basically makes it super gas efficient to run these light clients on chain. And I think like more broadly speaking, while we did this design originally for the ETH 2 sync committee, you can essentially think of this as a roadmap to basically creating light clients for wide variety of consensus protocols, including full Ethereum consensus.

And I think this is really exciting because we're obviously seeing how ZK-SNARKs are being used to scale the execution and throughput of blockchains. We're also now seeing how ZK-SNARKs can scale like the interoperability and composability of blockchains by making it easier to verify the consensus protocols that these blockchains run. So, we're calling this basically like proof of consensus cross-chain communication or proof of consensus bridging. And essentially, the idea again is to use these ZK-SNARKs to generate a validity proof of the state of the chain.

And we basically believe that this sort of bridge design, where you're running light clients on the target chain that like can trustlessly prove the state of the source chain is sort of like the end game design for trust minimize interoperability. Okay, so John talked about the high-level approach and now I'm going to dive into some more technical details in particular to the implementation we did for the Ethereum sync committee. So as John previously mentioned the sync committee does two things. Members of the sync committee for each header they generate a signature they generate a BLS signature for each header they believe to be in the canonical chain and then that signature gets aggregated and so for each header there's an aggregate BLS signature from validators in the sync

committee and a proof that we generate of that signature being valid. The other thing the sync committee does is every 27 hours it rotates its members. It's important it does that for security reasons and so the current sync committee basically signs off on the next sync committee public keys and we have another snark that basically validates this rotation and we have a trick we use in there to reduce gas cost so that we never have to actually post the sync committee public keys on chain cuz that's expensive. So yeah, we have two snarks one snark that verifies this BLS signature is valid over the header and the other snark that validates this rotation.

And without going into too too much detail of the snarks basically we have these two snarks and we have to develop a suite of primitives that we built in Circom to actually generate these proofs. So I'm going to just go over some of the primitives we have to develop and we hope that it's like generically useful for you know future work. So the first primitive is BLS public key addition to get the aggregate public key of all the sync committee members that are signing and generating a proof of aggregate verification. The other primitive we worked really closely with our collaborators at Zcash Perk over the summer um for implementing pairing inside of SNARK uh and we use that primitive to verify the BLS

signature. Um and so one thing to note here is all the field all the arithmetic we do for the pairing and elliptic curve stuff is done in the BLS12-381 field, which is different than the field that we're doing the arithmetic in the SNARK. So we have to do this out-of-field arithmetic. Um other primitives we have to implement were um the commitments to the SNARK public keys or commitments to the sync committee public keys. Uh so we had to implement simple serialization as which is what Ethereum 2 uses for serialization, SSZ for short. Um and we also implemented a SNARK-friendly commitment to the public keys um called with a Poseidon commitment.

So I have previously mentioned this trick uh we did for reducing gas costs of storing public keys on chain. So just at a very high level, SNARKs have public keys and pri- SNARKs have public and private inputs. Um and the public input is in red because it's bad because that means if we're verifying a SNARK proof on chain, we have to store the public inputs on chain. And a private input is in green and it's good because it's invisible on chain. So we never have to put it on chain. So naively if we were to implement ver- verification inside of SNARK, we would have to have the public keys as public inputs cuz we have to check that the signature is from a known set of validators, right? Um unfortunately,

as I mentioned, storing public keys on chain is expensive also because the set of public keys in the sync committee rotates every 27 hours. Uh so we decided, what if we just store a commitment to the public keys? So you basically hash all the public keys together and store this commitment on chain. And then inside your SNARK, you prove that the public keys, which are now a private input, belong to this commitment. Uh Uh, but because the sync committee rotates, we have to update this commitment. And it's not super clear how to do that. So, one idea is when the current sync committee signs uh the next sync committee, they actually sign a SSZ serialization of the public keys. So, one idea is we just use the SSZ of the public keys as the

commitment, um which is pretty simple. But the problem is that the SSZ is very SNARK-unfriendly, uh and so it's super expensive to compute in every header verification SNARK, uh because SSZ is just a bunch of SHAs, which is very SNARK-unfriendly hash function. Uh, so our idea was when updating the sync committee, we would verify a proof that would take in the new public keys, uh assert inside the SNARK that it corresponds to the SSZ uh serialization, and then also compute a Poseidon serialization of the public keys, which is very SNARK-friendly.

And with that, we're able to map the SNARK-unfriendly commitment to a SNARK-friendly commitment, and what we store on chain is just a SNARK-friendly commitment. And what this gets for us is it saves us 70 million constraints, which is quite a lot, in every header verification SNARK. Um, so yeah, hopefully this trick uh can be useful in like other contexts as well. And just some benchmarks. Uh, so as I mentioned, we have two different circuits. Um, the sync committee rotation circuit has way more constraints because of this SSZ thing I had to I mentioned, uh but for both circuits, uh the total witness generation plus proving time is on the order of 4 to 5 minutes. Uh, so our methods are actually really practical.

Um, in Ethereum, you have to wait for finality anyways, which is two epochs, which generally is maybe around the 12 minutes. So, on top of that, you have to wait an additional like 4 minutes for proof generation. Uh, and we think that more modern proving systems uh can reduce this time quite significantly, and so hopefully the delay is quite minimal. Yeah, so we've been working on this for the past few months and everything we describe in the presentation we've actually implemented. We implemented the light client and we've also gotten like a prototype bridge working on top of it.

You can go play around with it at I think now it's at just a sync.xyz. Fair warning, it's in beta and the mobile support's bad. But yeah, here's just like a few Yeah, here's just a few screenshots of it working. It's just like a normal token bridge demo. You just choose your network, you choose your token, you say how much you want to send over, and then you'll basically just submit a transaction. And then basically behind the hood, what's happening is you'll make a deposit on like Ethereum. And basically what you have to do is you have to wait until the light client on the target chain gets updated with a block header which can Merkel prove your deposit. So that'll happen after like 12 minutes plus like the three minutes for proving.

And then we'll submit a transaction to update the light client. And basically to withdraw your assets, you'll just basically provide a Merkel proof proving that your deposit is like validly represented in the ETH state root. And after that you'll have your assets. And yeah, you can go play around with it. It's all online. But anyways, yeah, to zoom out a bit about like what the pros and cons are of like these like proof-based bridges. Our first like obviously because we're able to borrow the security of the consensus protocol in theory, like in in theory you could borrow like the entire security of Ethereum here.

Your your bridge is going to have much higher security guarantees especially when compared to existing bridges such as multi-sig bridges or bridges based on like smaller decentralized networks. Another pro is like in a world where there's like a operator implementation where anyone can generate proofs. Theoretically, you for example, you could incentivize people to submit proofs on chain and maybe they get like a small percentage of like the fees that the light client's making or something like that. And like for these reasons it's just much more decentralized and I think aligned with a lot of the values we care about in blockchains.

And like at this trade off there's obviously some cons. Verifying like a snark proof is obviously more expensive than just checking that like five out of seven signatures a five out of seven validators have signed. There's also some latency that you're incurring because of the proof generation time but maybe that can be reduced to like a by an order of magnitude. And also in terms of like scalability one challenge here is that for every change you make to a consensus protocol or for every difference in consensus protocols for different blockchains you have to kind of like go ahead and like hand design your snarks and maybe you have to get them audited and stuff. So that can be a huge developer bottleneck for building these type of bridges.

In terms of like our future road map we kind of want to become like a like a trust minimize and decentralized interoperability layer for Ethereum and other decentralized blockchains. And in the short term we're actively working on building what we're calling these like succinct light clients for other consensus protocols. And we also want to start working on moving away from the sync committee which only has a security of 512 validators and work towards a world where we can verify all 400,000. Furthermore we sort of want to also explore applications such as governance and identity outside of token bridging. But yeah that's what we're thinking for now.

Before we end I just want to give a big thanks to No Sis Dow who was generously very funded us a lot for this work and also Zerk's Park where we worked out this summer and we brought a lot of ideas from the people there. And yeah that about wraps it up. If you want to collaborate or if you have any comments or thoughts I'd love to hear them and come find us afterwards. But also if you have time we can take questions now. So we have about uh a little bit over 5 minutes if anyone has any questions for Uman John.

Yep. All right. Um first of all, congratulations and thanks a lot for doing this. This was way overdue. This like should have um yeah, awesome you guys are pushing this. Um just maybe if you could So you use this uh sync committee from E2, can you elaborate a little bit more how you prove that this next set of signatures is constrained to be the correct one? Um just to get questions started.

Uh yeah, so the current sync committee signs the public keys in the next sync committee. Um or they do something like something very equivalent to this. Uh so you just have to verify that they that the signature of this header that includes these next sync committee public keys is valid. Um and then as I mentioned with the trick where we map this like commitment to the public keys from being a SNARK friendly commitment or SNARK unfriendly commitment to a SNARK friendly commitment, that's just to reduce the gas costs of not having to store these public keys on chain.

I have a question. Are there any more questions? In fact, there there should be more questions. If you have a if there's like nobody who has any questions, I'm shocked. I guess you you did such a good job that we have Oh, all right, there we go. Haha. I think I saw Henry. Oh, okay. No, no, I think it's uh sorry. Uh just quickly I might maybe mention that but I could have missed it. So how do you handle the equivocation if the current um sync committee signs multiple succeeding ones?

Sorry, Sorry, you repeat the question? Yeah, but if they sign multiple disjoint subsequent sync committees to follow them. Oh, like this is what he's saying like if they basically double sign. Oh, yeah. Yeah. Yeah. Yeah. Yeah, so currently the sync committee there's a honesty assumption on the sync committee where if they double sign, they're not penalized for this. So you have to assume the members of the sync committee are honest.

Of course, if you validate full Ethereum consensus or like validate like some subset of Ethereum consensus using like the duties the validators normally do, then you don't have to worry about this problem. So the assumptions of a sync committee are definitely a lot stronger than the assumptions on full Ethereum consensus. Hey. So this is kind of a philosophical question but do you think that it's better for decentralization overall to have a consensus protocol that has many many validators but no real practical light client or one that has fewer number of

validators but where the light client is very easy to run on any device? Yeah, I think like I think this is one point Uma made like a few times to me, but I think basically having a lot of these I think in principle like having one big network decentralized network is probably better. Like I think the Ethereum and roll up future is actually like pretty secure and pretty nice. But I think one thing is like basically having multiple of these L1s is a point of like meta decentralization where maybe you don't have so much lock in into for example the EVM or for example like you're too much relying on

like the ETH consensus protocol like operating correctly. And by having like many of these other L1 chains, you can sort of hedge against um sort of bugs being introduced into a piece of software that's so important. I don't know if you have any other comments. Yeah, I think also your point about um it's you know, in other consensus protocols maybe you have like less validators or something and it's easier to have a light client. Um I think if we accomplish one of our goals, which is to put verify all 400,000 or you know, someday maybe it's more Ethereum validators and verify all of their signatures and verify the consensus in a SNARK, then you can have a light client with a lot of validators. So, I think this is kind of like working towards that future as well. Um obviously it's you know, technically very very complex,

but I think it's possible if we're able to do it, yeah. Cool. I guess I'm all the way back here, but are there any any last burning questions? No, all right. Hello guys. Uh do you still uh use Groth16 as the your ZK proving system? Yeah, we use Circom. We mean we used Circom uh to make these circuits, so that uses Groth16 or I guess it also has Plonk, but we used the Groth16 version.

Uh but one of the main benefits of Circom and Groth16 right now is that it has a really stable, really trusted used on-chain verifier like for example in Tornado Cash, so it actually makes it practical right now. Um but as like these newer generation of proving systems get more proven out, especially with ZK-EVM and stuff, we definitely want to like reimplement this stuff and get all the efficiency advantages. Thank you. Is that a We've got a question from the chat, the live stream chat all the way back here. All right, go for it.

Jeremy asks, if I make a malicious ERC-20 token, for example, only transfer to my address on one L1 and bridge it to another, does it emerge as a quote normal ERC-20 on the second L1? Does it does sync committee check code? Yeah, I I think this is this is like a problem any bridge has or something. So, I think most bridges like deal with The sync committee does not check code. Um yeah. Like we're mostly making this like cross-chain communication protocol for getting one chain state on another chain state and then what you do with that if you choose to make a token bridge. Like you

have to figure out like what cases you're going to handle. All right. Well, let's give it up one more time for Uma and John.