Burning Bridges and Strengthening Relationships | Pavel Sinelnikov - ZKM

[Music] use that for I don't know what whatever it is that you choose to I work with many types of different applications as well as many different types of bridging protocols interoperability thing essentially a lot of things uh and then I also have my own startup built it using smart contracts connecting it with with things essentially it's like a influencer marketing platform uh programmatic influencer marketing platform so work with smart contracts as well so have I would say pretty General overview of the different things oh so we're going to be exploring the different types of bridging situations the simplest one is that I want to transfer or in this case Alice wants to transfer 100 usdt to Bob from ethereum to Avalanche ideally Alice wants to work with a trustless system where it doesn't depend on external third party validation she also wants it to be extendable so that it can work with other different blockchains without too many changes and number three which is important and uh should always be considered when creating any type of bridge is that the liquidity that is created can be actually used what is a bridge essentially a bridge is transferring assets from one chain to a different chain it can be from a layer one to a layer two it can be from Layer Two to layer two layer one to layer one any type of asset transfer between different types of uh blockchains they all have let's say different design decisions different things that make them usable and fit for specific use cases and we'll explore some first let's explore how an externally verified Bridge works so I send tokens to a bridge deposit contract on a source chain this can be ethereum this can be Avalanche this can be an L2 uh essentially we receive that request and then we achieve a set of consensus like we agree that this transfer did happen as a result of this agreement we then Mint or unlock a bit of tokens on the destination chain so if it's minted there's a wrapped version and if it's unlocked that is typically the native version and we'll we'll see what the difference is between those things uh but if you if you've ever used multi-chain they have a token called you know any usdt any usdc so they have like their version of a rra token here are some externally verified Bridges so they basically have an external type of consensus where it's verified by a set of validators and then as a result the bridge operation occurs these are typically trusted right I have to trust that they do the operation correctly and then as a result they do whatever type of uh results but essentially trust is one of the main regards is that I have to trust that everything is verified correctly now externally verified Bridges have a high security assumption because I have to trust that they are uh essentially that that the transaction has executed I have to rely on an external set set of validators so essentially I have to trust the protocol that they do the actual Bridge operation correctly and or I have to trust the multisig that's controlled by the protocol so whether that be through different types of signature schemes like BLS wallets whether that be through um let's say like the validator scheme of like I have an another blockchain that verifies other blockchains either way I have a lower security or sorry higher security assumption to enable this bridging in addition externally verified Bridges typically need to have a high amount of liquidity deposited within their contracts so they need to attract a lot of VCS a lot of people to put money into the application can we use a layer two let's talk about natively verified Bridges so what is a layer two a solution built on top of a layer one's consensus for the purpose of scaling privacy or similar use cases so this is what we mean by natively verified we are depending on the security of the Native base chain so that can be a layer one or if I'm creating a layer three solution that can be from a layer one to a layer two so I'm inheriting the security of the layer 2 so on and so forth so there could be multi multi-layered applications but essentially might by natively verified I mean that the L1 itself or whatever contract itself we're depending on their consensus mechanism for validating different types of operations that occur so for example here are some of the natively verified Bridges so we have like arbitrum op Mana Bas mettis mantel Etc so these are verified essentially by the L1 so a lot of these are are layer to scaling Solutions and they're built on top of ethereum so we're depending on ethereum's consensus in order to bridge to these ecosystems how does it work well first we send tokens to a bridge dep deposit or withdrawal contract this can be on layer one or layer two depending on the operation but typically if it's from Layer Two then you want to withdraw if it's from layer one you want to deposit into the layer two the natively verified Bridge receives the request sends it to the destination chain using uh the native security so this can be from optimistic Solutions this can be from ZK Solutions depending on how it's implemented but typically I need to have layer one to verify and guarantee security for the chain so essentially I rely on layer one's consensus mechanism to make this withdrawal that's the important part the destination chain mints or unlocks a corresponding amount of tokens if you are bridging to L2 they're typically minted or burned so if I'm bridging let's say from like uh one one eth from ethereum to metis I am locking that eth on L1 and then I am and then the the L2 side mints the corresponding amount of eth on that side and so I have that one eth on that side and then for L1 that's when I said that the tokens are locked and then minted on L2 if I want to withdraw then they're burned and unlocked on L1 following the different types of you know schemes optimistic ZK can we make this type of scheme better we have a natively verified bridge that can only communicate with the base L1 so it doesn't work if I want to communicate from ethereum to Avalanche so in that side I can't really you know I can't inherit the security of ethereum while bridging to Avalanche because there's nothing that really connects the two because Avalanche is isn't built on top of ethereum it's its own independent L1 but I can transfer assets and have native security if I interact with an L2 on the same let's say base chain so for example if I'm bridging from metas to optimism I can inherit the security of ethereum because that's the common ground so essentially how this structure would work is that if Avalanche is separate ethereum is also separate but optim ISM and metas are both inheriting ethereum security I can basically transfer assets from either one while still retaining the security of ethereum but I can't do that when uh communicating with Avalanche so this is what we mean by multi-chain that example of connecting Avalanche to ethereum that's cross chain that example when connecting optimism to medic that is multi-chain so I'm inheriting the security of the L1 to process the bridge transaction now question is this is like the billion dollar question jillion dollar even can we get native security and cross-chain communication and this is where we have locally verified Bridges typically the IBC inter blockchain communication is like a protocol it's a messaging layer we all hear that it's compared to tcpip so how we do messaging in in let's say the web 2 world or even the web 3 world we communicate via HTTP and then I need to send data from one place to the other in order to do that I have the the everyone agrees on a set standard to base that communication off of IBC is that standard for cross-chain communication now this relies on like clients basically sitting in between the two two different chains so I have one line clients on uh Avalanche and the other line client on ethereum I use the native L1 consensus to achieve the bridge so I have that common messaging layer and then I'm able to basically say that when I deposit something on ethereum I want to withdraw something on Avalanche and as a result the line client would verify the transactions that take place on each layer one and be able to send a corresponding amount of tokens or or like unlock a corresponding amount of tokens on the other chain and then uh Cosmos is is uh implements IBC so that Cosmos is like a sort of like layer zero Network where like it connects the different blockchains together kind of like polka dot as well so can we make it better so locally verified Bridges can connect with let's say any different chains that exist we don't really need any additional trust assumption since we're basing this verification off of the layer one so because I'm basing my security off of the L1 I don't have to depend on any other external network or external set of validators in order to make sure that this transaction occurs I don't have to trust anyone essentially though one big issue liquidity is not guaranteed to be present or can be used now what do I mean by that so as an example IBC fund is uh like the let's say the the interface towards all of this like cross chain communication and in my example remember how I said Alice wants to send 100 usdt to Bob on Avalanche so as you can see I'm trying to send 100 usdt from ethereum to Avalanche but it says down here that the route was not found so this means that liquidity wasn't provided for that to be unlocked on Avalanche so there no route can be found so therefore no assets can be transferred so it's super secure but nobody can use it that's basically the uh the uh unless someone provides that route provides that liquidity implements that protocol etc etc so a lot of things need to be done before that can happen we let no let's sum it up we've reviewed the different types of bridges externally verified natively verified and locally verified we want ideally a bridge that is trustless so again we thirdparty validation so externally verified out of the question at least in in what we're look what we're looking for we don't want to depend and trust someone else to facilitate the bridge transaction extensible it can work with to any other blockchain without needing a ton amount of change or implementation and finally liquidity optimized we can actually use the network because people have you know we're we're not depending on a lot of people putting a lot of money before it's actually being adopted now let's talk about zero knowledge and where let's say the idea of Burning Bridges comes from current zero knowledge proofs can be built for multiple use cases but there's two main use cases that have been adopted by a lot of solutions from uh from like identity solutions to scalability solutions to privacy Solutions right but two main use cases for ZK proofs are first privacy I don't have to reveal the information of whatever that I'm trying to do and the other is verifiable computation that I can verify that I did execute this transaction or this batch of transactions and therefore can unlock some amount of funds that's how you know ZK rollups work so how does the scalability rollup work we take a bat of transactions generate a proof and then send the proof of the computation to L1 to have it natively verified and that way we can basically be sure use complicated math to facilitate brid ing between a layer one to a layer two ZK rollup and back now can we make a ZK proof Bridge it has been done right there has been different solutions that exist for example ZK Bridge utilizes layer zero for liquidity and message passing so they essentially went in and focused on I want people to be able to use our Network and I want people to be able to reliably bridge between it and I want people to also have a great user experience because there's actually money in the system where I can bridge to different networks so in their solution they focused on extensibility because layer zero is a is uh implemented across different types of solutions as well as liquidity optimization unfortunately for the security part we can take a look at the you know layer zeros like Omni chain model and we have a lot of red things scary ah but essentially I am putting my trust in layer zero how layer zero implements things in order to facilitate the transfer so they make it really easy to get the liquidity they make it really easy to do all these message passing but you have to trust layer zero now another solution ZK link say they use native ZK proof verification but they need need to depend on external liquidity providers so what do we mean by this it's like uh so the way that they do it is that they have multiple different um proofs synced across the different networks but in order to let's say facilitate a transfer from one network to the other I need to deposit money into that bridge or deposit liquidity into that bridge so it runs into the same problem as IBC does where I need a lot of people to adopt liquidity across a lot of different types of bridges in order for me to actually reliably withdraw to that specific Network so it's trustless right we we depend on the ZK proofs how the ZK proof is generated and we just use the the ZK proofs and it's extensible right it works with the different types of blockchains that they've connected unfortunately it does depend on different types of external uh so external factors like VC's putting money in so so you need to have people to deposit a set amount of usdt on one network in order to be able to withdraw on that Network so can we make this process better how can we use the liquidity of one chain and use it in another and in this case the problem that we're solving is primarily the liquidity we need a network of usable pooled resources and a trustless extensible system that combines them together so this leads to a solution potential solution to the problem where we can take a ZK Bridge plus an L2 and combine it together with ZK proofs as that messaging layer so any deposit to the layer Layer Two would then increase the total amount of liquidity of the entire network of l2s so the example here is 100 usdt deposited on ethereum and 100 usdt deposit on an Avalanche would net $200 of total liquidity across all the l2s now let me explain this in a little bit of of like this overview we have a layer 1 ethereum right we deposit 100 usdt on that layer one ethereum now we have a layer 2 ZK rollup right and ZK I'm implemented and I'll explain that like how all of this you know would connect to each other but essentially we have it so that the layer two acts as an interoperability protocol same way that layer Zero Solutions uh like Cosmos as well as the the uh as well as polka dot would work except this is deployed on a layer two so in this way we have it so that the layer 2 can communicate with other layer 2s that Implement that same protocol in this way we can actually burn 100 usdt on one of these layer twos and then essentially generate a proof that I burned this layer this amount of usdt on that layer two and then be able to redeem it on a separate Layer Two within the same network so what this means is that I'm depending on Native ethereum or L1 security and then I'm able to essentially generate a proof that I have essentially do not no longer have access to that 100 usdt as a result I'm able to Mint it on the other layer to in this case the the the one that's built on top of avalanche and then finally the end result is that I would be able to withdraw it on Avalanche itself now the one big question is oh well what if there's nobody that deposited on Avalanche well in that case you wouldn't be able to withdraw an avalanche but you would still be able to Mint it on the layer two that's built on top of avalanche so in this case you can deposit to the ethereum blockchain and then navigate it and put it into the zkm blockchain OR sorry sorry into the uh Avalanche uh Layer Two so in this way you can transport liquidity very easily you might not be able to withdraw to the layer one but you're still able to let's say if you're a a VC you're you're always looking at different narratives you're looking at like oh what what does this chain do what does this chain do what does like these different types of narratives and so you're able to essentially transport liquidity very securely and still be able to use all of the liquidity that you've deposited that liquidity isn't locked and you're just waiting for someone to bridge to ethereum to get the fees from it now you're actually utilizing that liquidity within the layer 2 ecosystems and then navigating it across the different blockchains so pros of this method one is that it's trustless it doesn't depend on third party validation there's nowhere that I need to depend on another blockchain in order to facilitate this transfer I depend on the ZK proofs that then uh inherit the security of layer one so I'm able to basically guarantee that that amount was burned based on the layer one's uh verification method interoperable so I can within this system assuming that we have ZK proof validation or verification on other systems so let's say on salana orve right if I have the ability to verify ZK proofs on those blockchains I can technically connect this within the uh the current infrastructure so I can essentially expand this to other chains that are not at all related in terms of that same VM next is that it's liquidity optimized right I don't have to depend on a bunch of VCS with a large liquidity pool to provide liquidity for every single chain that we're going to integrate instead I'm using the liquidity from the people that have already deposited to the L2 or or to the L1 in this case you know there's there's whatever amount of millions of dollars that are even billions of dollars bridged to layer twos that are just sitting there in this case we're depending on the people to fund all of these other you know layer two structures so we're not depending on big liquidity providers to then you know hopefully someone Bridges my Protocol no I'm depending on just regular people to come in and uh any bridged funds that enter the network can be used across all networks so remember how you know that example for Avalanche well that can be used for the L2 that's uh on Phantom it can be on the L2 that's that's used in on Harmony or any other Layer Two that that that is essentially connected to a layer one we we also have the benefits of L2 so right now the the benefit of of L2 is either privacy or scalability we can inherent that type of let's say positive relationships so people are putting you know billions of dollars into l2s because they provide that scalability benefit or that privacy benefit we can have have natively native bridging benefits as well in combination with the scalability so this is essentially the the you know we don't have to sacrifice the scalability and the interoperability we can have it all in this case you can have your cake and eat it to essentially now there are cons right remember the the three things that I that I mentioned trustless extens extensible and liquidity optimized unfortunately this model in order to be let's say adopted it needs to be implemented by the L2 that essentially would allow the minting of assets on their L2 through this ZK proof protocol so for example in order for me to use this in let's say optimism I'd have to convince the Dao to essentially uh open up their uh L2 mint to be able to facilitate native ethereum so that's how it's done right now and the ZK proof bridging so in this case they need to make sure that everything you know it's all audited secured and everything but in this case we can we can do this by creating you know separate l2s that facilitate within this this entire network and then the idea is that since all of the liquidity can be used within this entire L2 Network you can easily transport it using the native L1 security so it might take a matter you know depending on how it's all implemented depending how it's all audited depending on like different factors it can be a big consideration especially if there's a large amount of liquidity sitting in this network and all you have to do is just uh implement it within yours so it does have to be implemented so again it does have to be implemented within the native bridge on the L2 and it has to be you know adopted and and and you have to make sure that the ZK proofs are working correctly on every single implementation one mistake potentially can lead to like uh Mass withdrawals of like oh no in addition that example that I mentioned in terms of the Avalanche uh where let's say nobody just deposits on Avalanche so everyone deposits on ethereum and let's say I bridge to the Avalanche based L2 that's connected in this case I can't withdraw to Avalanche because there's no liquidity on there but I can withdraw to let's say another chain I can bridge to another chain on the L2 Network that has liquidity on L1 to withdraw it there so in this case I'm able to I I could still access my funds but on a different chain that's implemented so maybe not Avalanche but maybe back to ethereum in this case what we're basically it's it's like a it's like a bridge without a bridge I know I know it's like the um like the the main the main problem that we're solving is that we want to bridge these assets across the different types of l1s and so in this case and I'm saying like oh well you can't do that if there's no liquidity but in this case as a person that wants to operate within this entire network if I'm just integrating a chain I have liquidity within the entire L2 space that implements this type of solution so I'm able to basically utilize different networks liquidity and then be able to move it around seamlessly Within These different l2s and then if I want to eventually withdraw I can do that as well but it can be on a different network so this is like a collective Layer Two that works across different types of ecosystems and we can use it for bridging we can use it for scal ability we can use it for these different types of applications that really bring benefits right now we only have you know l2s that work on either privacy or on scalability and so in this case it works with bridging as well uh yeah that that's that's everything and we have like uh different types of resources uh we're giving different talks as well based on these types of mechanics and Designs at our hacker house if you're interested in exploring the space of bridging and how this entire mechanism Works how ZK proofs work how this can all be used together you know definitely come by speak to me and uh and uh I can I can get you in um but yeah I guess any questions from uh from people like how this all works what the uh what I don't know what the benefits of this it sounds like there's too many downsides oh yeah sorry I ju just uh shout got it okay so the question was how did the different l2s talk to each other the primary communication for this is that they talk to each other through the layer two acts as both escap a ability layer as well as that interoperability so they communicate with each other through these proofs that are generated so in this case we burn the usdt and then we generate a let's say a receipt this receipt can then be used to let's say mint an amount of assets on that native uh on that native L2 so in this way the communication is done via this uh this burn address uh model via ZK proofs entirely so we don't need to depend on external verification uh like it's done with with other bridging Solutions so I don't need to depend on an external multisig or validators to to be able to facilitate this yeah so so yeah that's that's an important concept since we're inheriting the security of L1 essentially if there is a reorg on L1 that it's like like there needs to be some amount of finality present on on on that that that L1 so I can basically within within this L2 I can basically uh I can use this this uh this proof that was generated but I am yes depending on the security of L1 depending on that that aspect of finality that that that is achieved on the layer one side but essentially I can use that proof that I you know did this action on L2 and then eventually like it it did get processed it did get resolved there might be that uh delay right where we where we want to reach that L1 finality and there might be like you know built in uh A system that that you know waits for a specific amount of time but in this case I do depend on the L1 security I do depend on the L1 finality to be to be achieved to facilitate this this uh this uh let's let's say Bridge request sorry yeah the there might be a bit of a delay I you know in in this case like when uh when I generate the proof I could basically say that I have uh I have uh essentially verified this on the on the L2 side and uh and as a result it will eventually be uh finalized on L1 so like like eventual finality will occur on the L1 side because uh because I post this transaction on L2 and then uh unless there's like some amount of massive sensorship going from from from there but uh but essentially the the idea is that eventually there there will be some form of finality on the L2 and that's what we're you know doing with the with uh with the different like uh L2 L2 L1 to L2 bridging and L2 to L1 is that we're essentially saying posting a proof saying that this did in fact happen and then we're we're essentially trusting that the sequencer would eventually post that proof to L1 and to be able to withdraw from the network so in this case again we're we're still depending on layer One Security layer one finality to achieve that you know like like the the the the the bridging essentially hopefully that makes sense if anything we can uh we can talk about it uh when presentation's over yeah anyone else okay awesome well thank you everyone uh really enjoyed giving this presentation I'm going to give something similar like this and then maybe uh go into more of the Privacy use case and the the implementation from something that like based on like uh not Wormhole itself like the bridge Wormhole but Wormhole style bridging and we'll talk a little bit more at the hacker house so if you want to find more about that let me know