Privacy bridges & Ethereum compatibility

Transcript

cool all right um hi i'm drew i'm going to be talking about privacy bridges and ethereum compatibility i'm the founder of a protocol called web here's my email if anyone wants to reach out to me after the talk or follow me on twitter at zknark um and so this this talks about privacy and bridges and so and obviously ethereum so why not start with the state of bridges on ethereum there's a lot of bridges being built some of them are live some of them less so but overall there's a tremendous amount of bridges um and currently there's no privacy layer for it for any

of them there's bridges to that are being built out in cosmos polkadot you know between bitcoin with wrapped tokens near and so on um but something that's really interesting to me is whether we can add privacy to these bridges and the answer is yes we can with zero knowledge proofs and we can do so in quite a novel way we can benefit from something like shared privacy in the same sense that some chains talk about shared security we can come up with a notion of shared privacy where anyone who uses any bridge as long as it's sort of the same consistent private bridge

will benefit from a shared privacy so how do we use or at least what is zero knowledge used for in privacy well zero knowledge proofs allow us to make privacy preserving escrow mechanisms something like tornado cache the amount of privacy we get depends on the total number of funds in the pool and the more funds we have in the pool the more privacy we get so when we talk about increasing privacy in this world we talk about increasing the anonymity sets for these pools next we can discuss how we can use zero knowledge for interoperability so zero knowledge allows us to prove

complex statements about potentially large data sets like what are the merkle roots or at least the sorry uh what are the leaves in a bunch of merkle roots prove membership about these sets and so at least for interoperability we are interested in proving statements of the following sort like a one of many merkel membership proof or one of many merkel membership proofs over a set of like client header hashes and the benefit we get when we make these types of proofs is we get an interoperable anonymity set and what that means is basically i can

have funds locked in one side of the bridge and it can contribute to privacy anywhere else that this pool is connected to and so that's something that we're building out at web across the entire space so what is web web is meant to be the privacy layer for bridges and the goal is to deploy web everywhere so definitely on ethereum definitely on any smart contract chain that can support our zero knowledge primitives and the goal over time is to decentralize this protocol and make it as trustless as possible so we've been building in the ethereum ecosystem and in the

polka dot ecosystem and will continue to expand and so what does this bridge look like or at least the first version of this bridge we're really interested in bringing bitcoin and stable coins to or at least building anonymity sets for um these types of tokens so the first version of the protocol looks very simple you know you wrap bitcoin into a new representation and you lock this into an interoperable mixer and then you can transfer this wrapped bitcoin across the ecosystem to wherever their deployments are and withdraw it potentially

if the liquidity permits so at least in this example there's no there's no end liquidity in on the right side or at least on the polka dot side so there's nothing you can unwrap it into but we can think of um yeah so how does it how does it work um basically each side maintains a mixer or merkle tree you're going to deposit things into it we're depositing these web wrapped assets we have a set of incentivized relayers who move the merkle roots of these merkle trees around the users will generate withdrawal proofs with that more complex zero-knowledge proof statement and finally they will withdraw so that's

like the first basic flow and we'll use that flow you know for all in instantiations of this bridge um but the more interesting incarnations of this bridge are when we add complexity to it so obviously there's a lot of different types of assets that exist in all different types of ecosystems and we're interested in growing the amount of privacy that exists for all of these assets at the same time so one of the most at least for me interesting instantiations of the protocol is for doing something similar to a stable swap where we're going to wrap multiple types of bitcoins all around the ecosystem

into a consistent representation and there were there were some talks yesterday by james who was talking about optics and you know the main discussion around bridges is the representation of assets that exist and this is sort of the main thing when you talk about bridging assets in my opinion because assets across a bridge are new they're not really the same types of assets but with a protocol like this we can continue to add new representations to each side to wrap into our newly private wrapped assets

and then contribute or at least grow privacy for everyone that uses it everywhere so in this example you can take a variety of bitcoin tokens on ethereum wrap them into a web btc set token and potentially unwrap it for inter btc on polka dot and finally in our roadmap the third and final um thing that we're working on is to sort of add risky and yield delegation primitives to this bridge as well so people will be locking liquidity into these bridges and we can do things with the underlying liquidity we can lend them

out while people are at the same time moving their private assets so in some sense the private assets always provide a an iou to the underlying liquidity and we can add different risk levels to that iou in this case you know there is risk putting these assets in these protocols and the users who use the risky set bridge might accept that risk because they might earn yield in in doing so and the interesting thing is when you build this across chains you can start to take advantage of potentially different interest rates and it provides for interesting potentially bad behavior but nonetheless a really

useful piece of infrastructure for for privacy and so while building this out you know you obviously want to connect to ethereum so ethereum becomes sort of the main constraint when building a private bridge or at least a privacy an interoperable privacy project why is that so um basically ethereum only supports one pairing curve and so this is a fairly weak pairing curve compared to what currently exists in the research literature in the crypto cryptography space and something we need at least i think

like the this ecosystem needs to embrace is faster deployment of new curves so the bn254 curve a lot of people are critics of it and ultimately it's not a super secure curve compared to what else exists like bls381 when building on a private bridge it becomes extremely extremely important to make all the primitives that you're using on this bridge consistent so along with the curve it becomes really important to make sure you have consistent implementations of your hash functions and your elliptic curves in different languages so that you can build at least these primitives

everywhere in golang and rust for different ecosystems and so on um and we basically use these curves not only to do zero knowledge but eventually as as many other projects are doing to aggregate signatures for relayers um to make the system work a lot more efficiently um so yeah we are targeting at least to deploy this with both curves at least because our system is general in that way but we do want to support bls 381 in the long term so at least getting that on ethereum is quite important i was recently chatting with some people

at the conference who mentioned that this pre-compile or at least the inclusion of this precompile will like won't be prioritized for ev2 which seems kind of odd considering i mean from my perspective adding features like this only improves the types of applications that developers can build and so i would support it and so yeah with bls support there's already a tremendous amount of implementations of this curve out there there are precompiles that are sort of standardized and compatible with one another and so you know the tech is ready now to integrate

and so yeah as i said you know when we talk about ethereum compatibility we are talking about compatible implementations in many languages as well as compatible implementations in our zero knowledge circuits and for pretty much all the evms in this ecosystem to also adopt those pre-compiles and so using bls as the bedrock we just really need compatible hash functions we're using poseidon right now we use it in the evm and we also use it in webassembly we need some consensus process for agreeing upon parameters because these hash functions

require parameters and finally we need to run trusted setups for these bridges and yeah so i mean this is really cool to me it's really interesting because private bridges allow us to scale anonymity sets in many different dimensions we can scale them across similar assets so that you know all the stable coins on ethereum contribute to the same anonymity sets as well as all the stable coins that eventually exist everywhere they can all wrap into a consistent representation and we can even govern this representation to add new uh

stable assets into and remove from this set so it becomes a quite a flexible system for growing privacy of a specific asset class and then the the next benefit is ultimately these private bridges become platforms for developers so once you have a private bridge where you can move assets you know between chains privately you can also start to build different types of defy applications on top of it as i showed in the third version or the second version of the protocol you can build stable swapping mechanisms yield aggregators and eventually you can start to

generalize this system to support not only assets but different types of data so right now most privacy projects on ethereum have and in the ecosystem have focused primarily on asset privacy um you know in the first case we have something like tornado cache which does pretty atomic asset privacy here we're trying to build at least interoperable asset privacy and third once we accomplish this goal once we build out our protocol we're going to generalize this so that we can do interoperable data privacy so you can prove statements about data that exists in different chains on whatever chain

you might be interested in and yeah we've ultimately been focused on the evm and with rust in substrate actively hiring so if you know of anyone or interested please reach out or you know send me send me an email this is our website webwith2bs.tools and that's our github definitely check it out we've got some cool we're building out some cool stuff but thank you that that's the end i'll take questions if anyone has questions it's i'm curious about uh like since you

want to have the largest possible and enemies anonymity set you want to introduce these stable swaps uh i mean that kind of puts you in the same position as curve you're taking on like weird counterparty risks because like well wbdc is custodial spdc is synthetic they can fail in different ways and if one of them fails you end up in your stable swap with like one just now you have 99 of the really bad asset that kind of thing uh i'm just wondering what you're thinking about that because it seems like it's sort of a problem you need to tackle but it's also orthogonal to the already complex problem you're solving so yeah what's your thought on that no good question

um so it's it's worth noting that every instantiation of the bridge is really a separate bridge um and then to go to to answer your point of like who who's going to take on the risk or why would they accept the counterparty risk something we're thinking about is if people join say a very simple bridge like this they wrap their wbtc in and this is all it provides it's in in my opinion like a low risk system because there's always only one asset to take out we can give the governance power to these holders these web btc holders to vote in whether they would want to accept something like sbtc

into the set so that's one way we can handle this type of risk situation is by giving the voting power to the people already in the pools they vote to accept the risk secondly we can just create a separate bridge entirely and let users sort of choose whether they want to in the first place at all so we can just create an instantiation of a bridge like this where at the onset three types of bitcoin tokens are able to be wrapped into this new wrapped asset um we haven't yet looked at the you know whether we want to include

a type of curve-like functionality when you're wrapping and unwrapping just because it does complicate certainly when you go across chains we're trying to i got i'm playing with where you might take a fee within the system perhaps when you rap to prevent at least too much you know behavior that wants to arbitrage in and out of these tokens but yeah good question anyone else um i was wondering if you could speak a

little bit about the relay infrastructure that you have that supports the bridge i know i know you mentioned i missed the first part but um yeah maybe if you could go into a bit more detail about how that works and who's running the relays and how much they can introspect into the transactions another good question um yeah right now the relayer section so the relayers they agree on the merkle roots of all the deployments or all of where the bridge deployments are they're basically oracles over the merkle roots and right now we're using a modified version of chambridge to at least update these merkle roots um this is like the first most primitive

way that we're handling it but the goal is to aggregate you know do off chain signature aggregation to update the roots and try to do some batching techniques to improve the efficiency um right now with how chainbridge works you're stuck with a fixed relayer set but the goal is to do some proof of stake election somewhere ideally it's going to live on one chain and use that to um yeah we want to do proof-of-stake election to run a dkg and people who at least are

what's the word registering to participate as a relayer they would have to provide like key shares to participate in this dkg and if people aren't familiar with dkgs they're distributed key generation protocols so we want to generate effectively a shared public and private key under a threshold system and use this to update the routes so we'll run like a pretty hopefully large npc um in the in the end that answer your question yeah so part of at least how we're

thinking about it is that wherever the fees are generated they will go to a portion of them would go to these relayers um thank you you