ZK8: Cross-chain Zero-Knowledge Messaging - Drew Stone - Webb

Transcript

foreign welcome everyone I'm Drew I'm the founder of web we build we're building a zero knowledge messaging layer to enable things such as private Bridges and the applications you can build on private Bridges and we focus a lot on the application space so hopefully we'll get to that by the end of this talk and we'll talk a bit mostly about some of the infrastructure that we're building and the ideas that underpin it so the title of the talk is cross-chain zero knowledge messaging um and we're gonna just jump in

um so cross chain zero knowledge messages are quite similar to just cross chain zero knowledge proofs so what what are they and why are we interested in them we want to prove or have the ability to prove statements from one blockchain to another so here we have like a toy example there's four blockchains and Alice wants to interact with a smart contract on ethereum and maybe later she wants to prove knowledge of some state of ethereum but on polka dot or on polygon or Cosmos there's a there's a a yellow box around Alice because Alice can do this ideally in zero knowledge she doesn't have to disclose her Identity or sort of any any information about the state on ethereum and she

doesn't want to disclose said in a slightly different light Alice inserts a message into ethereum or a bridge on ethereum and she proves knowledge of this message somewhere else and if she does this in zero knowledge an observer Eve will only learn whatever Alice wants to disclose so that's sort of the the idea that we're playing with here is we want to send messages and we want to be able to prove properties about these messages across chain from anywhere from anywhere that a bridge is connected why are we interested in doing this well we can do cross-chain proofs of identity

we can transfer assets across chain we can do primarily all of this with privacy so you don't need to disclose what you don't want to if you build zero knowledge circuits the way to support that functionality and something really nice about this architecture is that since you don't prove since you don't disclose information about your messages specifically you don't need to disclose where those messages were inserted you also get scalable privacy set so people can participate in this messaging system from potentially many many different blockchains and when they prove

properties about their messages they all they all sort of contribute to a shared privacy set um some more complicated examples and generally speaking that we're interested in are doing even just scalable proofs of arbitrarily many statements about things happening on different blockchains so maybe you want to prove about a batch of messages where those batches can grow arbitrarily large um how do we do this the main way we do this is by connecting a cryptographic accumulators across chains so there's two sort of paradigms that that we are interested in at web

primarily the easy approach we've we've started on which is by actually inserting messages into our own custom Merkle trees and connecting these Merkle trees across chains but there's also the generic approach where you can just use the underlying blockchains try and prove properties about you know multiple different tries the reason the first approach is easy because you get to roll your own Merkle trees you can keep them all consistently structured and the reason the generic approach is hard is because you might have to deal with different tries different hash functions inside of a single circuit it might get difficult to reason or not reason but to build a

system that deals with you know a try with Shaw and a try with Blake too and and so on from 8 or 16 blockchains at once so here's a diagram or a little toy diagram of what this kind of looks like we have Merkle trees that we put on all of these chains um and the standard zero knowledge proof that we're we're interested in is a one of many membership proof so kind of motivating it with that original example if Alice were to insert a message on ethereum she would insert an element into the Merkel Tree on ethereum and assuming we had some way of updating

the root set everywhere Alice would be able to go anywhere and prove knowledge of that message using a proof that proves she knows a message in one of many Merkle trees so that's sort of the basic primitive we're dealing with here I'm focusing on Merkle trees because it's well known but you can use any type of cryptographic accumulator or commitment scheme but that's a general idea um and here's sort of how the paradigms are different so in the message driven method we Define a message we hash that message with a zero knowledge friendly

hash function we insert it into a Merkle tree where where we want to at least deposit that message to we have some Oracle that will update the state across chain where we have some bridge and eventually we'll prove knowledge of that message in the in the set of roots um in the generic method users are interacting with smart contracts and that state is being updated across chain similarly as in the previous method and in this one we have to prove knowledge of state or receipts against the like the tribe so the state try or the transaction try and whatnot and this is very general it doesn't necessarily provide developers flexibility to

customize applications as easily but it is some it's an open research area that we're investigating awesome so hopefully that gives us the grounds for what we're mostly focusing on at web which are the applications so the first application that we've been interested in is an interoperable shielded pool or an interoperable private Bridge so you can think of this as a private transaction system that spans many different blockchains um right now we're we're test we're in we're testing basically Bridges between eight different evm chains um between substrate chains potentially

even Cosmos chains soon in the future um yeah and what is what is this an application like this afford US um what allows us to build a single anonymity set across chain for shielded assets so users can contribute to Shared privacy for their eth for their stable coins without even needing to bridge to other chains they all sort of collaborate and create more privacy by participating in an interoperable shielded pool some examples of this would be like taking zcash or tornado cash and making it also bridged so we've built this on

top of web um as like you know one of the motivating examples for all of this research and infrastructure how does it look it looks quite similar to tornado cash if people have or really tornado Nova if people have interacted with that this interoperable shielded pool is like a bridged utxo system so you generate utxos on the chain that you want to deposit to those are your messages in this messaging system and you can generate proofs pretty similarly we use circom for a lot of this stuff and Arc works for the rust based chains you generate proofs pretty quickly the

circuits aren't extensively large um and this is just a simplified API you know our apis are still in in you know work in progress and we're improving them but ultimately you get a nice API where you can transact from one chain to another in a shielded pool um yeah so in this example we are both registering and transacting similar to what you might have seen or known on tornado Nova before it was removed from GitHub cool yeah a second application or set of applications that we're also now building are interoperable semaphore

sets so these are membership sets or identity systems that span multiple blockchains what this enables similar to semaphore if people aren't familiar is the ability to do Anonymous signaling now we can do Anonymous signaling with members from any blockchain that are in this set and we can run the polls on any of the connected blockchains so we've taken the standard semaphore system and sort of created it as a as a cross chain system it's nice because the the anonymity set scales now across chains you can sort of customize what you would you know what you want your users of these semi

semaphore sets to you know what properties you want them to have whether it's they have to have like at least one token of a native Native balance or to hold a specific nft or hold nfts from different communities and this will allow them to sort of group together without needing to be on the same chain they can be in the same group so some example applications we get from this are ultimately voting we get social forums and we get identity based D5 which is sort of the next thing that will will talk about But first you know to show you what the what examples of what the API looks like it's exactly

more or less the same as what semaphore provides today it's just that we now get to create polls and people can generate proofs potentially being members of the semaphore set on some other chain in order to vote on those polls so I could be a member on ethereum and run a poll on polygon and then everyone in this group sent this bridge semaphore system can go vote on polygon because it's cheaper there to to generate or to submit these transactions um yeah so it's a you know give a few seconds just to look through it we're identifying a group adding a member

crafting a vote and generating a proof and submitting it and this is all sort of a bridged system you can see in the generate proof function we're passing in a root set we're passing in Roots so these are roots of the many Merkle trees that Define our Bridge semaphore system the nice part about all of these tools is that they compose quite nicely with one another you at the moment just have to write a new circuit so something we're doing is taking those those two example applications that we

described the shielded pool and the semaphore system and combining them so we can build shielded pools that are bridged between chains where in order to transact on them you have to continue to prove every time you transact that you're also still a member of the semaphore system so people can create identity systems where they also allow those those users to transact in a shielded pool um and this is fairly customizable you just change something in your circuits so if you want to you know restrict users from who they create output commitments to like uh Tran transfers to

you can also restrict that those outputs are in the semaphore set and so on there's a lot of flexibility here and we're we're investigating this a lot how we can compose these different systems so here's an example of the API similarly to before of the shielded pool we're going to create our inputs our outputs which are all all destined for some chain to be spent on you know some chain there's some Nuance to it we create some external data that we want our smart contract to deal with and eventually we'll just generate our proof but in this proof for example you

also have to provide a proof that your identity is in the semaphore set cool so what are the future Explorations that we're interested in um yeah we're at the moment trying to unify a system like this so right now every time we deploy one of these applications it also comes with its own set of Merkle trees which is a bit clunky you know you have to basically roll a new tree for all the different message types that you have so something we're investigating is whether we can use one set of trees for all of our messages for all the users

who want to deploy applications to a system like this it'd be nice if they can use a single uh deployed set of Merkle trees so we're investigating what what would take into what would what you would need to take into account to support an application like this it might be that you need application identifiers or it might be that you also commit to the Circuit that you want your message to correspond to it similar to how sexy works and so we're sort of exploring that too that's the second point one one nice part of that line of work is that we can also start to unify our setups for our our Bridge systems so we can Venture more

into like a ZK VM landscape where maybe it's possible to deploy multiple different programs to this type of bridged system where each message commits to the program that they're interested in that's part of like the message itself this would allow us to do user Deployable applications and run one consistent set of infrastructure that doesn't you know blow up as as the number of applications grow and then finally there's a nice and new interesting line of work by e-sun it's a GitHub project called ZKA tester where we can start to do General State proofs

in zero knowledge so these are just proving State about let's say the ethereum Merkel try um and if we can sort of compose lots of these proofs then we can do quite expressive and interesting things like prove that you made a transaction with some property without disclosing whatever properties you don't want to disclose um so this goes back to the general messaging Paradigm but it's it's certainly of interest to us um but yeah that's the talk I hope there might be questions but if not thank you all for listening um this is some of our community links

we have a Twitter it's at web protocol our doc site is docs.web.tools and our GitHub is GitHub at web slash web Dash tools my emails there if anyone wants to email me we are hiring so if you are a zero knowledge engineer would be super interested to chat with you and even if you aren't an engineer I'd still be interested to chat with you so thank you thank you for listening thank you in the back this one yeah

uh at the moment they're Kinda Yeah I would say some form of actually governance right now so we are we have built a layer one that runs an on-chain governance process for connecting these smart contracts um so how to how to participate in those votes is effectively by bonding tokens um but yeah each of these right now it's it's sort of like an ad hoc setup you propose to link this system a priority to to people using it yeah right now we are investigating

doing basically one-way trustless like clients but we do use a threshold signature Network to sign these updates primarily because it's extremely expensive to build bi-directional like clients and prove this state so we wanted a cheap solution yeah once you set a system like this up you connect these smart contracts together you know we can play around with the different truss models we want um

um so this the this system effectively becomes a bridge is if that answers your question and that's sort of what our chain is is providing this is message signing in order to bridge these systems together it's sort of the missing piece the missing like Oracle that tells you know one end what the state of the other ends are is sort of the part that wasn't described in this talk but yeah that we you know we've built the infrastructure for doing the bridging um and we're exploring like how we can continue to decentralize that more and more that answer your question

let me go for it just curious about like what forms of privacy leakage are possible for example can we see assets flowing from one chain to another in general like in aggregate toward yes so at least for the interoperable shielded pool in order to get assets into a system like this you have to deposit them so it could be that we have a 16-sided shielded pool on 16 different chains but most of the liquidity was deposited on three and most of the withdrawals are happening on those same three so there's certainly you know some metadata that you can infer from the usage of the system

um and it would be it'd be interesting we explored Us in the past how we might incentivize like Distributing liquidity evenly across a system like this because that might provide the most privacy um but you're right what what other sorts of privacy might be exposed they're certainly like traditional you know as is traditional with tornado cash and and Etc like how quickly you transact through a system like this will will kind of dictate your privacy um and certainly at the RPC level like how you're making your proofs so if you ask an RPC node for you know your witness data you know you'll tell

that that node what your what transactions you're spending yeah yeah that's a good question I don't know we don't have yeah so this is all

customizable you can totally run your own smart contract on top right now we have like deposit and withdrawal limits per account um other types of limits uh mentioned like we're certainly exploring these identity based systems so like proving that you might you you still have to be in say an identity set in order to transact um but yeah nothing beyond that right now cool thanks again for your time and thanks for the good questions [Applause]