Watch Me Prove Anything | Pavel Sinelnikov - ZKM

on watching me prove everything what does this even mean okay let's walk through just the entire steps of using ZK proofs to prove everything I've been working in the metas ecosystem for over 3 years I do mostly governance now but I did work as the Integrations lead so I know a lot about the ecosystem the different projects how everything can be built unified and together I developed three articles related to different types of bridging techniques so from nft bridging to L2 bridging to well we're going to find out what the third version of that is I also built smart contract based applications using uh my own like uh essentially model of Distributing rewards for influencers based on specific let's say requirements so I knew I know basically the Practical the theoretical as well as the BD aspects so what a way to unify the entire ecosystem using bridgeless bridging so what we have here is a scenario Alice wants to transfer 100 usdt from B to Bob from ethereum to Avalanche Alis wants her bridge to be trustless extensible and liquidity optimized ZK proofs have been built for two main use cases privacy and verifiable computation we are using zkm for verifiable computation but it can be used potentially for privacy as well right now in this example we're focused on the verifiable computation how a ZK rollup Works step one take a batch of transactions step two generate a proof that you've executed this batch correctly step three you send the proof to the specific layer one for finalization that's how you ensure the security of the that the actual transactions happened the first bridge I want to talk about the ZK based bridge that I want to talk about is ZK Bridge it uses layer zero for liquidity and message passing remember are three things that we want we want trustless we want extensible and we want liquidity optimized well if we take a look under the hood layer zero is not trustless I have to trust them a lot I have to trust them for different things they have many different types of trust assumptions built into the protocol so even if I use ZK proofs I'm still not g I am essentially trusting that layer zero provides me my assets that I've transferred I have to trust them the next one is ZK link we're using native liquidity for Z we're using native ZK proof verification but there are liquidity assumptions it's not liquidity optimized what what do I mean by liquidity optimized it means that if I deposit my 100 usdt I will will get 100 usdt on the other chain guaranteed so an implementation using ZK link ZK jump essentially says that a quote is made and essentially whoever fulfills this quote would then have their assets bridged if no one fulfills the quote if I want to transfer $100 million and there's no one to offer me that counterparty to transfer that $100 million I can't transfer it there's no agreement so how can we make this better how can we use the liquidity of one chain and use it in a completely different chain in a completely different ecosystem unrelated to each other well we need a network of usable pooled resources and a trustless extensible system that combines them all together we have the entangled rollup infrastructure now it's a bit hard to see and it's a bit complex but I have a implementation utilizing this initial entangled rollup structure and essentially through a universal Layer Two I'll you can read about how this all works by the way we have a white paper out but I want to explain it in simple understandable terms but it's using this version of infrastructure let's say to do it so the entangled rollup can actually Implement and adopt other l2s optimistic rollups ZK rollups and hybrid Roll-Ups as well now hybrid Roll-Ups is the combination between optimistic and ZK but essentially I can adopt any other layer 2 that's already implemented arbitrum optimism mettis we have different types of layer twos that already exist in the ecosystem and they can all be included within this type of structure so what what am I proposing what is this bridgeless bridging well it's combining native verification with shared liquidity essentially any deposit that would go into a layer 2 would increase the liquidity for the entire ecosystem that adopts this Universal L2 structure so for example 100 usdt deposited on the ethereum L2 yeah L2 and 100 usdt deposited on the Avalanche L2 would would have an increase of 200 total total usdt total amount of usable liquidity that I can then transfer from any other layer 2 connected within this network here is how it works I have a layer one I deposit 100 usdt I then have my ethereum Universal L2 Universal integrated L2 again this could be optimism arbitra metas any of these l2s I would then have the assets minted to my address I would burn that exact amount of usdt I would then do a public burn address and potentially can be private and I'll go into that a little bit more but we burn it to a publicly known burn address we then generate a proof based on that burn we're not generating it off of the L2 data we're generating it off of the L1 data this ensures that this transaction is secured by native L1 secured and finalized so that means that nobody can say that they burnt something but in fact not have burnt it so this liquidity this 100 usdt is provably removed D from the ecosystem but now I can burn it I I can generate a proof of that burn and I have a receipt a receipt that basically says that I can redeem this 100 usdt on any other connected Universal L2 L yeah so this means I can take this and I can send it to the Avalanche L2 and it's using the native Min function on that L2 so what this means is that I am getting Nate I I am burning native liquidity on the L2 on ethereum and I'm minting a corresponding amount of native liquidity on this other L2 this L2 is built on top of avalanche in this case Avalanche would resolve this transaction and finalize it on its own L1 I do not require an external consensus mechanism I do not require external validators to verify that this in fact occurred I am using ZK proofs as as the means of communication in order to facilitate this transfer what does this mean overall and what do I mean by watch me prove everything within zkm ZK VM we are able to prove General computation that occurs what does this mean well I can run VMS inside of my VM inside of the zkm VM I can prove that some level of computation has occurred on each and every single L1 even if they are incompatible with one another as long as they have some type of way to have a smart contract function or some type of way to allow me to verify a proof on their chain I can integrate so this means that I can verify ethereum transaction evm transactions MVM move VM transactions Salon VM transactions near VM as well as algr VM like I can introduce this to any other incompatible L1 and still have the same trust assumptions of each and every single L1 each L1 secures its corresponding L2 which is then using proofs to pass messages across all of these layer 2s this also allows me to Mint any amount of liquidity native liquidity on each and every single one of these l2s what this means is that if I burn $100 million on the universal L2 on on uh ethereum I can bridge this to any other Universal L2 connected within this ecosystem using the native mint function on on this L on these corresponding l2s this means that I'm using native liquidity Within These entire ecosystems I do not need to go and Pitch to VCS and say hey store your $100 million on this chain here and I'll promise I'll facilitate some transfers no I am essentially utilizing the liquidity that's provably burned and I can mint it across entirely different incompatible ecosystems essentially being able to prove anything so what's the pros of this type of model one it does not depend on any external third-party validators to facilitate this I am relying on the proof generation system the proofs that are generated for enacting the mint so the finality of this type of interaction I essentially use utilize the native L1 consensus mechanic for all of these individual l1s I'm not using an external consensus mechanic I'm not using an external set of validators like potentially Cosmos or poad do the other big part is that it can work between other incompatible ecosystems it doesn't just work with evm it doesn't just work with tenderman it doesn't just work with this one thing it can work with all evm and nonm chains essentially securing it through these verified ZK proofs the next point and the most important point I think is that it's liquidity optimized the one thing that I have to convince people is well to convince any anyone to adopt a solution is is there enough liquidity do I have enough liquidity to facilitate this do I have enough demand do I have enough people and in defi liquidity is the most important thing that's talked about across everywhere how can I how can I get enough people to use this product that's why a lot of things are being built on ethereum because there's a lot of liquidity there there's now migrations to other layer 2 ecosystems but again liquidity liquidity liquidity this uses the native L2 mint function this gives me native or in this case proxy usdt but it's used as the official usdt of the network so this means that this usdt I don't have to swap it for another usdt I don't have to you know transact or or or maneuver it I essentially use this as native assets on the L2 this also we see a lot of funds locked in l2s currently there's 122 billion locked in arbitrum there's a few multi-billion dollars locked in other l2s as well like mettis and and and optimism so we have billions of dollars of locked liquidity in these ecosystems essentially just stuck on one ecosystem we can have multi- let's say the liquidity locked on one ecosystem it's still locked on ethereum it can be used anywhere across any blockchain ecosystem again utilizing the the native mint function there are two major cons to this type of model the one the biggest one is that access to the native mint function in order to have this solution be adopted we have to get everything uh we in order for the native mint function to be used essentially the chain has to give the Privileges of that to this proof system to this proof generation system what this means is that we're using the ZK proofs as a means to Mint it the only way to traditionally mint the uh the assets is by a deposit to L1 the other way in this model is to Mint it using a verified proof that you've burned the asset on some other chain as a result of this in order to convince any other chain to adopt this we need the mint function of that chain but every single time any chain adopts this it increases the entire liquidity of the entire network so we're seeing a lot of l2s pop up a lot of implementations pop up some privacy focused l2s some compatibility based l2s what we can see is that they all have that same problem they need liquidity they need to be onboarded and how else are you going to transfer hundreds of millions of dollars from one to the other so it's beneficial for the user standpoint it's beneficial for new starters to come in to use the already existing liquidity in the entire ecosystem the other downside is that there might be dry spots remember that scenario where I deposit usdt on eth if I want to withdraw this on Avalanche I must have a corresponding amount of usdt on Avalanche if I don't let's say I bridge that 100 million to Avalanche but Avalanche only has 1 million well I can't utilize the entire let's say let's say all of my assets on that L2 to L1 I would have to then bridge to another ecosystem that contains that liquidity but in this case that is a very minimal issue since you will always be guaranteed to have liquidity somewhere it might not be on the native chain that you use to deposit instead it might be on another L1 which then you'd have to bridge to but then at that point it's still the equivalent let's say value that usdt on on uh Avalanche is equivalent to the ethereum we also have a potential extension to this and this is actually the EIP that inspired this entire aspect of essentially using proofs to verify that you've taken the asset out of circulation this EIP essentially says that we can burn e on ethereum and then privately mint it to another address in this case we're using this similar model to do it across different L2 ecosystems instead of burning directly on eth or privately burning on eth we are now burning on the L2 which then resolves to the L1 we can also extend this and as I said to the Privacy aspects so we can technically implement this potential EIP as well for this uh cross chain native bridgeless bridging mechanic so this is what we're doing here at zkm is creating the proof system for the interoperability of incompatible blockchain ecosystems since we are a general purpose purp ZK VM we are able to prove computations across different types of other VMS and as a result the bridgeless bridging the universal L2 model can be adopted within this this system using this type of ZK proofs generalizable and efficient thank you all right thank you very much pav that was there was a