#DappCon22 : Day 3 - zkSNARK-Enabled Bridges On ETH2, Uma Roy, John Guibas

Transcript

so next I'd like to invite Uma Roy and John gibas from succinct labs to talk about the king's mark enable bridges on eth2 so welcome [Applause] is it connected to this oh no no no no hello my name is Uma and this is John and we're presenting on succinct verification of consensus with ZK snarks okay so let's start with an overview of

the multi-chain and cross chain landscape uh over the past few years many different blockchains have come online that lie on different points of the trade-off curve in terms of throughput security decentralization and transaction fees including ethereum and also our friends at gnosis which have gnosis chain so as the number of applications oops as a number of applications have grown across the different chains there's been a lot of user demand for interacting between these chains and in particular users often want to transfer assets from one chain to another and currently Builders are exploring interesting cross-chain use cases that go beyond just asset transfer a large selling point of crypto versus

the previous generation of Internet applications is trustless and permissionless interoperability and in the future if users do want to use multiple different decentralized settlement layers it's important that these blockchains can communicate with each other in a secure decentralized and permissionless Manner and because of this we think bridges are very critical infrastructure in the space so what does the state of bridging look like today currently to meet user demands the solutions for cross-chain communication and transferring assets between chains is through extremely centralized entities the vast majority of L1 bridges are built on top of centralized multisigs where a multi-sig controlled by a set of trusted parties

signs off on deposits and withdrawals on between different chains and we think it's kind of a travesty that cross-trained bridging where a tremendous amount of monetary value flows through is a weak link of decentralization in the entire space and not only is this ideologically bad it has real consequences these centralized Solutions make really strong trust assumptions they're censorable and empirically they've been much less secure in the past there have been a lot of bridge hacks over the past year each in the hundreds of millions of dollars that have resulted in over a billion dollars of lost user funds and not only are these hacks bad for the users it's actually bad for the entire space in general it reduces The

credibility of the entire space and it has Downstream consequences like regulation so I've talked a lot about why the current theater bridging is far less than ideal but let's start talking about Solutions so what if we forgot about the Practical limitations of on-chain computation and thought from first principles about what a maximally secure and Trust minimized bridge between l1s would look like well when we forget about these computational constraints the solution is actually kind of simple and elegant we already have a protocol for a decentralized set of validators to agree on the state of a chain it's called consensus what if we were simply able to verify the consensus of a source chain

in the execution layer of a Target chain then there would be no additional security or trust assumptions placed on the bridge between the source and Target chain of course even if we verify consensus on a Target chain we aren't able to get synchronicity between the different chains and we of course have to rely on the minimum of the security level of both chains but the key here is that we're able to do much better than the current centralized solutions for cross-chain communication so now that Uma has wait oh sorry yeah so now that Uma has painted a picture of what an ideal trust minimized Bridge would look like let's start with a high

level overview of what end to end this system might look like so it starts off with the fact that we have a decentralized blockchain like ethereum and over the course of its lifetime it's going to naturally produce block headers validator signatures attestations and other metadata as part of its consensus process and normally this information gets propagated to other validators on the network to perform consensus but what we can do is we can also propagate this information to a Smart contract running on another blockchain such as gnosis chain and inside the smart contract we can re-implement the logic that an honest validator runs to verify consensus and agree on State and the reason why being able to verify

consents in a smart contract is extremely powerful is because it essentially allows you to run a like client where inside the smart contract we can keep an append only list of finalized block headers and inside these block headers we have access to uh State routes which are essentially Merkle tree commitments to the entire state of ethereum including contract State how much eth I have in my balance all the transactions that I've ever been included in a blockchain and all events that have been ever emitted and we can essentially trustlessly know this information by providing succinct storage proofs which we can query against these Merkle routes so why hasn't this been done before well the problem as Uma mentioned is that

implementing the logic that an honest validator runs to verify consensus is extremely expensive especially with proof-of-stake systems so in particular with ethereum there's two big challenges to implementing this inside a smart contract the first problem is that ethereum has a very large number of validators they're constantly validators entering and leaving the network their stake balances are often changing and to provably know that consensus has been verified you have to keep track of all this information which is a lot to keep track instead of smart contract a second Big Challenge is that currently the execution layer in evm-based Chains don't support the elliptic curve used for signatures by ethereum 2. in particular there's this bls-1231 curve

which is used for the signatures and there's no pre-compiles for it which means that we have to implement this in raw solidity which is extremely gas expensive so the ethereum developer is actually like know about this so they developed essentially a consensus protocol which is meant to be easier to verify and the way they make it easier to verify is essentially by reducing the 400 000 validator signatures you have to check to a random subset of 512 validators which are chosen every 27 hours and these validators do essentially what you think they do they sign over every block header and if enough enough of them sign over the block headers the block headers are valid and you can apply some finalization rules over that

and you know at the cost of it being easier to verify the trade-off is that there are weaker security guarantees right because the economic stake here is only the stake of these 512 validators and the purpose of the sync committee is essentially for like clients such as wallets and potential applications such as Bridges however we explored the feasibility of implementing dislike client uh consensus protocol inside a smart contract and it's still too gas expensive why is it two gas expensive well it's essentially for the same reasons why I outlined before there are at least 512 validator public keys they have to store on chain and prove the valid rotation of every 27 hours for every block header that we want to prove is valid we have to do up to 512

curve additions to aggregate the public key and one pairing to do the final signature check and this is all over the BLS 12381 curve which currently has no pre-compiles on the evm so how do we solve this problem well um we're going to leverage the technology of zero knowledge proofs which have become rapidly more easy to use over the past few years and a very nice property of zero knowledge proofs are that they're succinct and what I mean by this is that you can for any arbitrary amount of computation you can generate proof that proves that this computation was done validly yet the verification of this proof is constant and we can leverage this weird trade-off between the prover and verifier to create essentially what

we're calling a succinct on-chain like client so inside the smart contract what we have is a function that looks like the follows where we basically are validating the new blocks and this sort of function can be split into three parts we have some pre-processing step we have an expensive call to a function which will verify the current validator set and then we have another expensive call to a function we'll verify the collection of signatures that we've collected from the validators and what we can do using ZK snarks is essentially we can move the expensive parts of this Lifeline computation off chain generate a proof and then what we can do instead on chain is just verify this graph 16 proof which only takes 200k gas to verify

and the magical thing about this is that this isn't just specific to ethereum this could theoretically work for any consensus protocol so to recap um you know in the same way that zero knowledge proofs are scaling the execution and throughput of blockchains through the zkevm you can also kind of see how ZK snarks are providing a road map to make blockchains significantly more composable and interoperable in a secure Way by making it easier to verify consensus inside blockchains and we're coining this as a term we're calling proof of consensus which is this idea to use ZK snarks to generate availability proof of the state of the current chain

and yeah basically we believe that succinct like clients and having these succinct lines like clients on every chain essentially the end game for trust minimized interoperability between blockchains okay so John's kind of given an overview of the approach so we can start getting into the details uh what we implemented was a succinct like client for East 2 proof of stake using the sync committee protocol as John highlighted so what does the sync committee actually do there's two parts for the sync committee uh the first thing the sync committee does is every member of the sync committee will sign with a BLS signature a block header they believe is in the canonical chain and then they will

produce together an aggregated BLS signature over this ball cutter and so that's generated every block header that you want to include in your like client smart contract uh the other thing this thing committee will do is it has to every 27 hours it will rotate the set of validators in the sync committee randomly and the current sync committee signs over the next in committee and so in our like client smart contract we also have to uh validate this rotation and keep track of the set of new public Keys as John mentioned uh for the first part uh verifying this aggregate BLS signature and evm is very expensive because there's no pre-compile for the BLS 12 381 curve so we have one snark to basically offload this computation off

chain in a snark and then verify it succinctly on chain so that's our first snark and then the second snark we have is to validate the rotation of the sync committee public keys and there's a little trick we do in there to make it more gas efficient that we'll also talk about so the circuits we built without getting into too much detail are based on a series of Primitives that we had to build out we built these circuits in circom which Jordy the previous speaker helped create uh and so let's just go through a little bit of what The Primitives look like so one primitive we had to build was public key addition to basically create the aggregate public key of all the sync committee validators the other primitive

we had to build was actually verifying this BLS signature which involved Computing a pairing inside a snark and one thing to note here is that the pairing we're Computing is on this curve bls-12381 which is different than the curve uh or like the field that's being used for the snark so we had to implement out of field arithmetic for this and we worked very closely with some friends at Xerox park over the summer to work on implementing this pairing to verify the BLS signature another thing we had to do was basically uh take the sync committee and public keys and then hash them using SSC which is the serialization protocol that East 2 uses to get a commitment to the public keys in the validator set and then we

also had to do a snark friendly commitment using Poseidon and we're going to link the two commitments to have a snark-friendly commitment linked to the snark unfriendly commitment that I'll get into overall our circuits are really large they have over 70 million constraints and these were some of the largest circuits that we've worked with so far which includes a variety of challenges including proving time and memory which was all fun to work through so to go into the trick I mentioned previously with gas optimization so that we don't have to store the public keys on chain um just to go over snarks very briefly snarks of public and private inputs and public inputs are in red and they're bad

because that means we have if we're verifying the snark on chain we have to have the public inputs also available on chain which results in like storage or call data costs private inputs are good because we don't have to have them on chain so naively if you were to implement a signature verification uh you would have the aggregate signature as a private input and a bitmap of who's participated as a private input but you need the header and all the public Keys as public inputs because you have to check the public Keys actually belong to like the sync committee but storing the public keys on chain is really expensive there's 512 of them and then they rotate every 27 hours so instead what we did is we just store a

commitment to the public Keys instead so basically we take all the public Keys We hash them and then we only store like a hash of the public keys on chain which is very cheap and then we can turn make the public Keys a private input but we have to update this commitment when the sync committee rotates so how do we update the commitment when we're signing the rotation of the sync committee the current validators sign and SSD serialization of the public keys so one thing you could do is just use this SSD hash as the commitment but the problem here is that SSD is actually really snark unfriendly because it's basically just a bunch of Shah hashes and it's really expensive to compute and so what we realize is we can map

this snark unfriendly SSD to a snark friendly commitment using a more snork friendly hash function and so what we do when we validate the rotation of the sync committee is we inside our snark we compute the SSD commitment and then we compute a snark friendly commitment and then we just link the two and then we're able to Only Store the snark friendly commitment on chain and at a high level what this does is it saves us around 70 million constraints in the header of verification snark which is really great because it saves us a lot of improving time and just some benchmarks uh overall for our two circuits uh generally both of them are net out to four or five minutes of proving uh proving plus witness

generation time so in ethereum 2 the finality period is on average around like 12 to 14 minutes so on top of that you have to maybe wait an extra three to four minutes for this like client to update uh and we hope with newer generation proving systems that we can take down this proving time quite a bit yeah so as you can tell we have the benchmarks which means that we actually have like an end-to-end prototype of this like client working and in particular we have it working between I think right now Gorly and ghost's chain and we also have like a prototype Bridge demo that you can try out at demo.to sync to XYZ just a wording it's like in

beta and the mobile supports really bad but yeah like you can submit a transaction between these two chains um and basically what happens on the back end is like once you make a deposit on the source chain you have to wait until the like client on the target chain to be updated with a blockhead block header which you can like Merkle include improve your deposit on so basically we have a relayer node which will wait until the block header has been updated and then it'll automatically send a transaction with the appropriate Miracle proof to withdraw your funds on the other end but yeah go feel free to try that out and yeah here's an example of it being uh complete on etherscan but anyways to zoom out a bit as to what

like the pros and cons and trade-offs are between a bridge based on sort of the succinct like client that we built over other Bridges exist today is you know the biggest Pros are like this is much more secure than any other bridge in the long term than what exists today and furthermore if anyone can generate these proofs it's also censorship resistance as we don't mean a multi-sig to update the live client and because anyone can submit these proofs it's also hypothetically much more decentralized if there's a decentralized network of provers the cons in the short term are their their higher gas costs as compared to a multi-sig we have to verify this is EK snark there's also higher latency due to the additional time on top of

finalization where we have to generate the proofs but this can as we must said go down in the future with the use of new proving systems furthermore on the developer side it's a bit tedious as we have to generate hand-designed circuits for each consensus protocol so our future roadmap here is basically we essentially want to be the most like trust minimized interoperative layer for ethereum and other decentralized platforms and our roadmap to doing this essentially is to build a bunch of succinct like clients for a bunch of consensusive protocols um and furthermore one thing we're interested in doing is ZK snarking the full ethereum consensus so like we recognize that the sync committee only has 512 validators but we think that in

the short term it might be possible to scale our snark significantly more to handle all 400 000 validators on ethereum which essentially make this uh much more secure and also we're very interested in exploring other cross-chain communication uh applications Beyond erc20 bridging such as governance identity gaming and more but anyways yeah um this is still a work in progress but this is a lot of this work was funded by gnosis Dao and zurich's park so big props to them and yeah we're also always looking for collaborators if you have any ideas please let us know and yeah feel free to follow us on Twitter as well thank you [Applause] are there any questions we'd love to

answer some if we have time oh yeah oh hello thank you for this presentation and the amazing software you're building I was wondering if you had issues with anchor blocks and rear orgs and whether you're light kayak on one chain has a delay that is some kind of finality period yeah right now for ease 2 we only validate finalized blocks so we kind of sidestep this issue of having to worry about the four Choice Rule and forks and uncles and stuff like that

okay I I guess uh to follow up on that if you if you were to run this on for for other chains that are not non-non ethereum change um our weaknesses in the in the consensus for for those chains or would weaknesses in the consensus on those chains affect um affect this yeah as I mentioned uh you only get the minimum of the if you have a two-way Bridge you only get the minimum of the security Economic Security of both chains so for example if you're bridging from one chain to ethereum and the chain has you know maybe not that much stake or not in that many validators and stuff like that uh of course you're you're exposed to that

yeah I have have you decided your near-term roadmap in terms of which ethereum Networks you're going to focus on next um we're still really actively thinking about what uh protocols to focus on next um so yeah if your ecosystem is interested I think we are still trying to figure that out also I think we don't have time for more questions so uh are we one more okay okay okay that's a very short question so um whoever withdraws from a bridge after bridging will have to provide a Merkel proof right um how does the cost of doing that in

terms of gas compare to current Bridges it's definitely more expensive but I think the inclusion proof is only like 20K gas okay okay thank you all right thank you very much John and Uma