zkSync: An EVM-Compatible zkRollup

Transcript

convenience is here we we want to show something interesting and i just couldn't connect my laptop so we will have to improvise a little uh my name is alex i'm ceo and co-founder of metal labs and then start again okay i see so he will give me a sign he will give me a sign cool hi everyone welcome to the talk about ziki sync the first tvm compatible zika roll-up my name is alex i'm ceo and co-founder of metal apps we are creators of zika sync and um uh i am just going to give you a few highlights

like what what the system is is uh able to provide um first of all uh zk roll up is uh something that can combine the benefits of the uh roll up and side chain worlds so it's possible to to extend it you you can not only have a secure functionality but you can have uh something we call zk porter that gives you uh very cheap accounts so we have two account types in the key system one is the key roll up which is ultra secure it inherits the security properties of ethereum and one is zika porter was which is ultra cheap and they can seamlessly interoperate uh now second thing uh since it's a

evm compatible zika rollup you can deploy any existing solidity contracts without modifications so you don't have to change them you don't have to reorder them you just deploy them and they work and we preserve the full maintenance-like composability so you can one contract can call another you can have atomic transactions spending across multiple contracts uh they can fail they can they succeed just the same way they work in in ethereum uh and uh in zika sync we used to have a different language for programming contracts called zinc so we preserved it as well and you can program zinc and interoperate between zinc and solidity also seamlessly and you can reuse the existing tooling

you can take the existing ethereum wallets with natively support ecdsa signature in zika rollup and uh it works with existing tools because web3 api is fully compatible on the read-only level for sending transactions you need to slightly change the sdk but the your code will remain the same you only need to make a few imports and use different properties there and we actually wanted to show you a live demo and this is why it took a bit longer to to set up these things because i cannot use my laptop we we connect uh someone from our team um hi vlad you should so how do i do this um uh one wait wait wait wait so i need to

go here over here i'll put you on um on the sound can you hear me now yes we can yes we can so we have a couple of contracts here here uh one is uh well i i i i'm gonna put you on mute because otherwise it's echoing exactly sorry i'm just gonna say so we have a couple of contracts uh one is written in zinc one is written in solidity we start with the solidity one it's a very simple one

we're still working on the compiler compiler it does not support hundred percent of cases yet so that's why the test net is not public uh but we are very close like whether we we all we fix the things in the in the llvm backend so the compiler is based on ll vm we reuse all the tooling from there uh and now we're fixing the final things for solidity but zinc works very well so this is as you can see it's a very simple contract it has some storage value it has some some public methods like a public method that can write this value and the immutable public method that can get the value so now we're going to compile it uh using cell c which is a standard solidity compiler uh which produces the u output

and we pass it to the uh to the so uc compiler gets us the the evm byte code for sorry zk avm byte code the the byte code which we use for our virtual machine which is used in the casing so now we can deploy it we have a simple tool to to do do operations on uh with contracts uh it's called z cli and we just take the byte code which just been compiled and we deployed let me see if i can

and by the way i forgot to to mention that this is a very spontaneous demo and expect it not to work something will probably go wrong now we we were we were not uh going to to present it but then last minute like i asked the status and the guy said like it's actually almost ready so like yeah it should work so yeah now we see the the execution result the execution executed was true the the no error here is the actual byte code for zinc vm you have the contact headers here and some other metadata so it's now deployed now let's go over to the zinc code which is uh a bit more expanded so we have two contracts here

one is just the interface because zinc is a subset of frost so we use like same approaches and rust we had to define we have to adhere to strict typing and we have uh uh like essentially an interface for a trade for uh what we're going to call in the other contract so we just define the public methods here and in the actual main zn we have uh the the code of the contract itself so it so it's essentially a proxy contract which just takes some target and we can call methods on that target the same way you would do it in solidity so we we just like want to show you the inter interaction within zinc and solidity so you have some public method to get um the yeah

yeah get the con get so the counter is our target it's the contract called target so we we just just called it this way and u 160 is the type of address um so yeah this is the code we can compile it with the zinc compiler it's going to be optimized we use reuse all the optimization primitives we have from llvm we're going to produce the binary code it worked well you can see it on the debug and we're going to deploy it with the same utility we use for deploying solidity contracts

i think you need target with this ability uh yeah so we we just support two languages now we have front-ends for these two languages to llvm they compile to llvm intermediate representation and then from there we have a single back-end which compiles into the zync vm byte code so we have the byte code we have the exact same result we we deployed the contract to some address and now we can go and uh try to interact with it so maybe uh vlad can you show us the zinc block explorer first so it's our public test net you can you can all go to the zika sync out to alpha zeke scandio and you will see it

and uh yeah can you show us some last transactions we have a deploy contract transaction here so it was it it's it's permissionless to deploy you just send the byte code the bytecode is public since it's a zika rollup all by all contracts that i deployed will have the byte code published through ethereum and now we can go and open we built a very simple demo app yesterday so please apologize the the design uh it's it's actually a beautiful design i think uh uh so uh so we have two contracts here and we have methods to interact with them we support web3 uh this version is done like we're we're

calling native api but uh you you like we we the web 3 will be ready in a few weeks to fully use so you can get the value uh from which is calling the function get value and returns the the value from the storage this is our target contract written in solidity you can click increment value and it will throw a meta mask or like you can connect any wallet it can be like mobile wallet anything that supports web3 you sign the message we use aap 712 for for for signatures and it's uh signed and submitted to the contract it's actually executed it's already uh updated the state of the roller and then we can go

on the proxy contract and get the target value which will invoke the other contract and and get the value there so it's like they're they're already interoperable seamlessly in like if mainnet style composability yeah so that's that's the demo we wanted to show so thank you vlad uh we'll move now to the presentation and okay so this is what's working now we're waiting for the compiler to be fully ready and for the api to be fully tested before we can publish and open the testnet to everyone we we're not going to do black white lists we're just going to open it public

so the question is what are the limitations of this first version so we call it the casing version two but the the release is going to be 0.1 or like whatever alpha so first of all in the contracts we don't support pre-compiles yet we don't support the cryptographic recompiles such as ap 16 uh sorry in 1962 or or like uh the pairing computation uh if you want to do cryptography that that's not ready yet but if you want to do cryptography actually in the future it will be a lot easier because we will support recursive snarks natively and they're going to be super cheap because you don't have to publish the the actual proofs in in the zq roll up or in in dk porter anyway

so no pre compiles for now although we support like all the hashes we support keshak hash we support shuttle 56 and we support algebraic hashes which are much cheaper in snarks so all your normal hashes will be replaced with algebraic hashes automatically but you can fine-tune you will be able to choose which one you actually need i can explain later we don't support cryptographic modular arithmetic so there are a few by uh op codes in evm called add mode sub mode move mode and i don't remember what else x mod i think uh we will support them through the compiler the compiler will will produce the the codes uh we'll expand them into different

codes we don't have these op codes natively in zinc vm but you only need them again if you want to do cryptographic operations if you're just not writing normal d5 contracts nfts whatever no one uses that so like most people are are fine uh what what we don't support what is like with annoying is we don't have ec recover for now because we need the mechanism for our internal pre-compiles to add that and it will take a bit longer and we don't support creating other contracts yet but it will be natively supported so create create two op codes will for now fail like they just won't compile uh but uh they will be supported in the first version so we have all the mechanisms for that as well okay um and the uh so

as i said the read only web free api is list tools which i mentioned like ether scan the graph et cetera et cetera they can all work they can just like go and subscribe for events grab the data feed from uh from our apis uh read like execute the the uh invoke methods uh on smart contracts uh but if you need like it will all works like just with with existing apis if you want to send transactions you will you can use the same signing mechanisms you already have in your apps or in your wallets but you need to format the message slightly differently like we don't support the same format as

ethereum although the api encoding of the transaction is actually the same but unfortunately we we need to like make a hash of it before we submit it to the message and we need to add a few other metadata parameters which ethereum doesn't have because like we support native metadata we support uh natively timestamps like validity timestamps you can say this transaction is only valid for this many blocks so this is all additional information which we need to pass somehow so you need this intermediate step but it's actually very easy to implement in your sdk so we will support like all the usual sdks you can import like ether scan

sorry ethers js for example and just like add a wrapper that will do a different way of signing otherwise you will not need to change your dap in any way uh okay so this is the the overview we can go into different topics in depth i have a lot of slides here but i want to make it a bit more interactive so how much time we have [Music] it's 20 minutes more we can talk about the design of zkvm in depth we can talk about the hybrid zika roll-up ck porter model of data availability and how what impact it has on applications on on the price on the security of your accounts and how they interact

or we can go into other questions uh from you guys if you if you're interested in something else so like who who want to talk about the ziki porter ndk roll up okay who wants to talk about the zkvm design okay so we have more people who want easy kvm so let's start with this and it's actually the next slide uh so okay how it works uh let's recap how roll-ups work in general so you have some off-chain state which is represented by your root hash which is submitted to the smart contract on ethereum and it holds the state and whenever you have an update of the state

we can define a state transition function that takes the previous route hash and produces the neural hash based on the input of like some array of transactions and um what we need to do with zika roll up specifically we need to arithmetize this function to be able to produce proof of it so to take the function and and to produce a succinct proof that we actually computed it and here's the result and the result is valid and we didn't skip any step and this arithmetization process is what made it very difficult for us to implement uh during complete uh like turin complete zero knowledge proof systems in the past because arithmetization means you take your function

and you have to decompose it into a cyclic graph of operations where you have all the inputs of the function as uh you know like on the left side here and then you have gates which represent arithmetic operations and we only support two modular additional modular multiplication and you get the result at the end and this has to be a fixed rigid circuit so we we call it arithmetic circuit which is very similar to hardware circuits how you like just put gadgets on the physical hardware board and connect them with wires and you don't have back loops that's why it's linear it only flows in one direction so the question is how do you represent during complete programs which uh can have loops can have conditionals can

have like different things depending on the data which you input which you you can do it here right so you can have something only a rigid and uh the problem is uh some of the operations are going to be very expensive so like if we need to to implement uh like simple additional multiplication it will take us just one gate because it's a native operation in this circuit but if we need something like a sha two five six hash or cash a cash god forbid it's going to be like thousands and tens of thousands of those those gates here with those operations so it's uh like if you want to combine them and do something flexible like it's gonna just get out of control on on in in terms of costs

so how do we are for that generic computation um and we so i'm gonna like rush through the presentation because we don't have much time but uh the general idea is we used a an approach called tinyram it's actually pretty old it's 10 years or or more of 14 years old where we construct a circuit it's like a single circuit which has um which can prove not just a fixed program but it can prove the execution of arbitrary program because at each step we prove the execution of all the possible op codes which which could have been used at this step

and then we only select the result of the op code which actually corresponds to the input of this operation does this make sense so like we like uh maybe so the the the this spreadsheet i can't open it because it's uh yeah it's a different laptop but imagine a spreadsheet which has this formula on the right like if column d has this formula like if the operation of the uh of at this step is addition then add the operands or like add the operand to the to the previous value to your accumulator uh and and take this value if it's

uh multiplication then multiply it and take this value and so on so you can if you if you read this formula and if you're proficient with excel you will immediately see what i mean like the formula at each step is the same but depending on the operand in the column b we will take different values like we will take different formulas so like if the b 10 is add we will multiply it by one otherwise by zero plus if it's sub uh then we we multiply one with uh the subtraction um and take this value instead and and we assume all of them so we will only take one of the results exactly you still compute all of the

operations but you just like you then then you computed all of them and then you say okay this was addition so let's take the additional the the result of the addition if it was multiplication let's take the result of multiplication so as you can see the we we need to produce like a quadratic complexity so it's like we have the number of steps in our execution trace and we have the the number of operations in our virtual machine and this is going to be your your like uh uh the metrics which which you need to to build the circuit for so it's pretty expensive but it turns out it's only expensive if your operations are expensive um and like if if you only have like 30 operations

in the uh in the in in in your virtual machine then you like the overhead is going to be 30x right if you have some operations which are like a lot more expensive than the others the overhead would be like insane and this is what we actually have with this hashes so we need to solve the problem with hashes somehow and with the way we do it so yeah we have like the the problem is we have different operations which which are like very very variant on the cost and the the way we solve it is with recursive aggregation so we have the basic circuit for the uh for the basic operations in the virtual machine but all the heavy operations are going to be outsourced to different circuits which are way more

efficient which are optimized for this type of operation and then we can combine them all recursively and we use some nice techniques with passing the uh we accumulate the the the cues of operations which we want to prove and then we multiplex them through some hashes like it it's actually very easy but i just don't have time to explain it in detail and we pass them to different circuits and then we we prove them in different circuits and we enforce that actually every single operation is proven that there is not a single hash not a single storage access or signature check which which has not been proven so it has to all converge together and we get the final proof which includes all of them and the problem was with this approach

that we didn't have the pre-compiles on ethereum for uh for curves which would be recursion friendly but it was solved and yeah we proposed this the ap was never adopted but we implemented the first recursive snark with planck so we we took the uh the plonk was invented by guys that's uh from odds tech but we we implemented we ran the first version on ethereum which actually worked last summer and since then it was possible to to do all the rest so we we presented the first at uh the reddit scaling challenge and we brought it to production at zika sync one this january uh and the rest was just engineering effort to build the virtual machine and to to to build the circuits that get connected together

um yeah so it was not during complete but now we combined so the the trick here is that like most of the so the the the tiny ram approach is actually quite expensive it has a very high overhead the overhead is actually a thousand x so if you wrote a circuit for your smart contract natively it would be a thousand times cheaper to compute than the circuit executed through this generic tiny tinyrm approach but it doesn't matter because the logic of the smart contract has like only very very small fraction of the costs of overall contract execution 99.9 percent of the costs go for this heavy operations like storage access where we need to prove merkle

tree inclusions uh we like merkle tree merkel uh accumulators is is um like the the only working approach we have now maybe in the future will there will be better cryptographic accumulators and it will be even more snack friendly but for now it's it's that storage access signatures and access to memory which is also is separate like it's separate circuit and uh yeah uh pretty optimized so uh so we mix that in so i explained that [Music] yeah so yeah the in indication two we have this tiny ram optimize special circuits and we combine them recursively and we actually optimized a lot of

heavy operations such as sketchup hash which naively would cost you like in growth 16 the previous uh proof system which was very efficient up till till planck would cost you something like 300 000 uh gates uh whatever that means like it just translates linearly to the computing complexity uh we managed to bring it down to 25 000 with uh with very interesting tricks in plonk such as lookup tables and custom custom gates and we we did it for for a couple of other operations so it's uh it's very interesting and yeah what we do is we take we we have a compiler based on lvm where we take the inputs in different

languages so we have solidity which produces you we have zinc which just produces goes natively to lvm uh we will add vipre support later which will we which will also probably com compile to llvm not to you because viper is not uh stake based which you expect and then from lvm intermediate representation we compile it to zkb and bytecode and we run a simulation on layer so we took the the execution uh trace of layer one transactions from the different defy use cases some swaps maker cdp execution balancer rv compound transactions

and we we run the simulation to see what the costs are going to be and we came to the um pure proper cost of something like as you can see here hopefully 0.01 usd like two cents for transaction one stand for transaction size it's it's going to be the fixed baseline which you always have to pay everything on top of that is going to data availability so you will have to like if you use zika roll up account you will have to publish data on ethereum to preserve the full security of layer one and by the way zk roll up is the only scaling solution which offers like exact same security as layer one uh assuming bug free implementation of

course but like if you don't have bucks in your implementation in your circuits then it's exactly the same like you you unlike side chains optimistic roll-ups uh plasma anything else it's exactly the same like no one can take your money from you eventually you will always be able to get it back but it has a cost you have to publish data on chain if you don't want to publish data of chain if you just want to stick to this very low fee for like one to five cents you can choose a different account app called ziki porter and here is what it is so what why it matters is we all hope that rollups will bring the cost down uh this this is will certainly gonna be the case in the beginning

uh but they will very quickly be uh eaten up by very aggressive traders who will come and say oh we can do more trading now and do more stuff and they they're just willing to pay a lot like we saw it from the um mev world that they they don't care like as soon as as long as you can make like five percent marginal profit you're going to pay the rest to the fees uh and this is going to affect all the other users so we need a way to scale super linearly and not just like take the existing ethereum throughput and multiply it by 100x and yeah and we are going to have more use cases like we are going to have nfts and all the users coming from different solutions to ethereum because you can have it natively like more users more

use cases and more frequency of transactions will lead the costs the gas costs on ethereum to go up a lot and this is actually what happened the number of users grew uh around like dozenacs over the past year but the gas fees rose a lot more now they're a bit down because of all the uh magic with mev simplification and so on but like it's it's a one-time effort like we we get 10x more users it the same thing is going to happen so uh the solution to this is long-term is sharding like the only proper solution within ethereum you have to you like um the ethereum sharding will bring a linear

boost of scalability but uh um in the future we might have something like even more advanced with erasure codes and so on but it will take years like three five years at least for now what we can do is we can separate our state into do two different subtrees and we we we just say like you as the user can choose which type of account you have is this account residing in the zq roll upset tree or is it residing in the zika portrait subtree and they are all the same for all practical purposes they they have the these like normal addresses they can address each other they don't have to know what the other account is they can you can use a transaction which expensive

and multiple types of accounts uh but for ziki porter accounts we don't publish the state updates which we do for zq roll up accounts that's the only difference so the the practical difference for the users is just the cost is different indeed all up you pay more in zk porter you pay less but the beauty is you can have users who are coming from like you know like binance chain and all the other side chains back to ethereum but they don't care about security because otherwise they would not be there like they just want to achieve transaction costs so they go create the key for their accounts uh they can use the all the zika porter stuff like send money to each other for like one cent for per transaction they don't care but they can still interact with all these services on the zika roll up side

and it's gonna cost them less because we're gonna amortize the final state updates to like uni uh pairs to some data snaps new swap uh across thousands of users who use it on the zika porter site so even though they they they interact with like normal zk like with the canonical unit swapper all the whales have their money with the huge liquidity pools they're going to pay a lot less not one cent maybe 10 cent but it's going to be like pretty pretty fixed so that's what securelap is about i can explain how it works but i think i already did so yeah we just published state updates on the left side we don't do it on the right side but

otherwise the accounts are absolutely the same and the state the data availability of ziki porter accounts is going to be secured by consensus of what we call ezekies and guardians uh like these are token holders that are responsible for securing the data and all they can do like they cannot all the transactions are cryptographically secured so nothing can go wrong they you can they cannot steal they cannot forge state corrupt the state but they could if they collude um with like two-thirds like a super majority of the stake they could freeze the state so it's like it has the similar property to to side chains but it's actually strictly better than a side chain and

there is no incentive like no way to directly exploit it because if they collude and freeze the state uh they're talking is gonna depreciate and uh you know uh uh they they could try to blackmail the users but it's really hard to coordinate with those users so it it's a it's a lot more hurdles for them than for sidechain operators who can just like grab all the all the funds there and exit uh yeah uh yeah and they will like if the stake of the validators is greater than the total amount of value in the ck portal part there is no way for them to make profit they can only do it like as from like a suicidal being evil but they

cannot profit so like there is no crypto economic incentive for them but still it's very important to decentralize the the stake uh properly and we we're putting a lot of thought into this how to do this uh and the users are free to choose like if you if you you like you can you can for example have most of your fonts in a cold wallet on the zika website and have like some some small funds to make daily transactions on the zika port or to like uh spare the costs or maybe traders can go to ziki porter trade a lot uh as opposed to like centralized exchanges and then move all the proceeds back to the secure up where where it's safe at rest uh so yeah with zq roll up we have a cap on on

throughput of around 2 000 3000 tps depending on like how ethereum depending on the transaction type so it's actually a lot cheaper than optimistic roll-ups because we can skip a lot of intermediate steps like we only need to publish the final state for each account on the secure website so like it's in some cases it's going to be a lot cheaper like 10x 100x in some cases is going to be the same price uh but yeah we we all roll ups are going to share the z the ethereum block uh limit for for called for call data so they all compete with the same data on the ziki porter site on the other hand we don't have that limitation we can have like 10 000 20 000 50 000 tps the bottleneck is going to be

the consensus of the validators which will is to be determined like how like what what the other threshold is going to be but like a lot higher than ethereum and fixed cost versus a fraction of l1 costs on the easy curve upside [Music] yeah optimistic rollouts unfortunately cannot offer this extension is a also side chain is going to do this like they cannot have something which is like more secure than than what they have or less secure and cheaper they have to stick to their paradigm so like if you go to like polygon it's cheap for you to transact there with high risk but then you have to actually exit your funds to ethereum move them to some other roll up and then use their whereas in zkro in easy case think it's

going to be all seamless uh yeah thank you uh we have time for questions no i'm not sure but yeah probably [Applause] five minutes okay we have we have time for questions does anyone want to ask a question hello thank you for the nice presentation so years ago you talked about having erc20 tokens on ctasync so are you now going to put them into this paradigm and actually run an erc20 contract or are you still having some

some custom solutions for moving erc20 tokens we will support rc20 so you you will be able to deploy contracts that support different logic and uh you can program them thank you hello sam thank you oh here's this just take it off to ask questions so thank you for the presentation it was very interesting so my question is what do you think of using the mems of hash function for the minimal multiplication complexity uh function instead of sha to 256 which basically

decreases the number of field multiplication of course will decrease um the constraints in the in the hash functions in for example nzk roll up or other zk uh zk snarks or something sure so you when you compile your solidity contract you will be able to to define to say like all the hash functions all the hash functions i used in this contract do i really need to have them as k chuck like real catch up or is it like do i use them because it's a cryptographically secure hash function and if you like you will have like some manifest file for the compilation where you will be able to say like it's just a cryptographic hash function so please replace all of them with invocation of an algebraic hash function what we're

going to use is poseidon probably or like there's going to be some new hash function presented i think in in in fall but for now it's poseidon so we have two different functions in used in our circuits one is poseidon one is uh rescue but rescue we use like rescue is uh proof system specific so like you if you change the proof system like the results will change so you only use it for internal bindings for like this um uh cues and and stacks and so on and for everything which user you like users depend on to have the predictable outputs we use poseidon but it's also very cheap uh if you need to use k chuck hashes as

a k check because here you you take some external inputs from users and you expect the users to produce some k chuck functions you will be able to go on and mark them or either you might your entire contract has like please reuse the k chuck from ethereum or you you mark the specific places where you use the the the real catch up uh but it's actually going to be very cheap even if you use kjack overall everywhere it won't add much to your contact and unless you do like lots of those keycheck invocations you can just do that and not bother and it's still going to be like very cheap okay so it's not no difference basically yeah okay thank you hi yeah so you mentioned that ec recover

isn't supported yet but that it's on the roadmap do you have an idea of like when that will be and how easy or hard it's going to be for you guys to add that we we we need to add like we have a concept of internal pre-compiles like built-in functions which we which are which are going to be passed externally we currently have it for system operations such as like checking verifying the ethereum signatures but we haven't uh provided the interface yet to access them from programmatically from the code once we add that we can add any number of those functions like keychuck and recursive code uh recursive proof verification so that you can verify plonk proofs from your contract which

will allow you to build something like zcash on zk sync with like super cheap transactions so like your shoulder transactions are gonna cost the same as uh like almost the same like maybe slightly more than normal transactions because you don't have to publish those proofs on ethereum even for the key role up so it will i i can't give you an estimate but it's not complicated it's just a matter of engineering it's not something fundamental awesome thanks hi thanks great talk what are some migration option paths between layers one and two and does it even make sense to support layer one uh i think yes because

all the roll-ups are new technologies with uh you know like the the optimistic roll-ups have never been tested before zika roll-ups have been live only for application specific use cases and not with generic programmability it will take time for people to gain confidence in those technologies you need you need like half a year maybe longer for like a lot of money a lot of people willing to experiment uh to use the systems before general audience and and like people with a lot of money with whales get confident and meanwhile use yeah you want to support the layer one and our approach is to make it compatible

so you can build your the same code can be reused between layer one and layer two you can have tests that cover both parts and you can be sure that they will always compile and then you can migrate gradually you can deploy both versions and like layer one layer two and then gradually move some of your users or users will decide to move part of their value uh from layer one to layer two and like gradually this ratio will change favoring the layer 2. awesome thank you uh thanks again for presentation it's very clear but uh

i have maybe a stupid question about zika zika porter accounts uh imagine like defy situation uh units for player and is lp provides some liquidity and like only zka porter account trades on this and as a liquidity provider it depends on validators because while like all this trading uh no proofs has been published and in this situation it's uh it's equal to optimistic roll-up is it or maybe i missed something uh so again you're you're lp's yeah yeah i provide some liquidity to units for payer and forget about it after that

like people that use uh zika porter accounts uh trading heavily and but during this transaction as i understood uh they are not um published proofs on chain validators but you as llp you you you submitted your liquidity from a zika rollup account yeah then you're safe yes so like if something happens to the key porter and the state is frozen all the users with zk porter accounts will get frozen they will not be able to access the funds but all the users with zikr all up and all like all the all the interactions they had with the zika roll-up uh contracts and most contracts are going to reside on ziggurat upside i can't imagine someone deploying

contracts on the keep it probably won't be allowed you you always have to deploy contracts on secure website um you're fine like in uni swap you have your like balance uh mapping which says like you like unisop owns you so and so many tokens like you have this position there right so like as long as your account is on the secure all upside you can always access this mapping and it will work if someone from azeki porter account will try to access it it won't work for them because the the date is not available but you will be fine thank you very much unfortunately we have sure thank you guys [Applause] you