zkSync 🛠 zkSync 2.0 for Builders

[Music] [Applause] [Music] okay let's begin fantastic uh guys welcome uh to the workshop uh my name is alex kmco co-founder of metalabs which is the company behind zika sink and we're going to talk about what zika singh is we're going to talk about zika sync version two so we have zika sync as a zika roll up for payments uh and swaps basic specialized operations on mainnet since two years with some 200 million dollar value locked but that's not what we're excited about we uh really are uh looking forward to launching the kissing v2 which is gonna be uh a lot more interesting so we will touch on that what it is why it's important and then we will discover user experience like how it will feel to your end users if you're going to build on zika sync then we'll deep dive into the actual developer perspective like how what it means to build on it what nuances you have to observe and then we're going to talk about security aspects because security is the paramount concern of the ksync like this is why we're building the uh zq roll up specifically and then we will also touch on the ecosystem and some support programs which we can offer from from our site now okay so what is zika sync ziggy sync is an l2 powered by zk evm so it has the benefits of evm it's fully evm compatible you can take anything that is written for evm in solidity or viper or you and just plug and play and it should work out of the box in in most cases uh it has full web3 api supports your front end your your apis your packet services will also work and the the most important thing is that it inherits security from layer one what this means is your logic of the contracts and your authorizations by the users are verified not by zika sync validators but by ethereum itself every single transaction that happens on zika sync is checked by all of the ethereum validators through very fine z zero knowledge proof so you can think of zero knowledge proofs how many of you are familiar with zero knowledge okay so like the zero knowledge proofs are or snarks more specifically are protocols cryptographic protocols that enable compression of computation into a very small piece of data that you can check with simple arithmetic operations which take something like 30 milliseconds on any smartphone and you can be sure that the result of the computation we've done on arbitrarily large array of data with arbitrary many steps is valid you don't have to redo all this computation you can just check the results get your for example your commitment to state my merkle root hash and you will be no you will be sure that this new root hash is actually in the new state of the blockchain by applying one billion of transactions like all of the world's financial transactions that happened over the last hour or day or whatever uh like this is this is actually like a little magic uh but it's just pure math and it's quite easy to understand if you go step by step and see what happens there uh but i can give you an intuition for it right now like just trust me like you only rely on math and smart contracts in the code to verify all of these transactions so that gives you perfect security from l1 uh censorship resistance is a different property that ex says that if a user has funds in layer 2 how likely are they to be able to withdraw it even if the validators are malicious are not aligned with you like they're trying to censor you specifically so censorship resistance is enforced through layer one and we actually why i called it l2 and node zq roller because zika sync v2 is a combination of zika roll up and zk porter protocols it's a fusion we call it volition a hybrid system where users can decide whether their accounts are residing in the zika roller part or in the ziki portal part and they by by making this choice they will uh both enjoy the full security of ethereum so all transactions are validators cannot do anything wrong cannot freeze state so it cannot corrupt the state cannot execute anything other than the user ask them to execute but with the roll up you have full censorship resistance exactly as on layer one so the protocol guarantees that you will always be able to access your funds in any contract you will be able to just push them out uh on the zika portal side it's more like or all or none approach to censorship resistance the validators won't be able to send their individual users but they theoretically could freeze all of the state and this will stop everyone prevent everyone from exiting which will by the way also freeze their own stake in zk porter and zq porter is going to be stake based um tokenized systems so they like it's going to be a suicidal move for them but it's very very important now like side chains they cannot steal funds they cannot say okay we're going to lose our stake and we're just going to take all of that and sell somewhere else they can't do that they can only like kill themselves with like let the boat sink with all the passengers uh so with zika roll up since you have like full 100 censorship resistance from ethereum you only enjoy linear throughput boost so all the transactions in other words are going to be n times cheaper where n is some something like 50 or 100 x uh with ziki porter on the other hand your throughput is completely unlimited so we can this is important you can go to 1 million 500 million one billion active daily fusers and it will work because ck porter can work in parallel you will have many instances the all of them will derive security from ethereum itself like zk-based systems is the only way blockchains can reach the actual world scale of mass adoption like with to do like anyone in the world with trustless connection between all of them um but yeah you will have your trade-off in security because uh you you still have to trust validators of specific shards or that we call them to be non-suicidal but that's a different assumption uh but what's really is really important uh ziggy porter and sdk roll up accounts will be synchronously interoperable uh or at least like seamlessly interoperable if there are many shards but if you only have one zika roll-up chart and one's a key port or chart you can make calls from one to another and have cheaper transactions if you're a portal user but still access all the protocols on the zika roll up side which is like just in different way to say like all the protocols on ethereum you can have uni swap with liquidity providers that have a lot of capital there that who care about security first and foremost and you have users like if long tail retail users who just want to access funds and they can do it in the same atomic transactions they can can have um instant loans and so on and so on like flash loans and whatever it will work this way okay and and what's the philosophy of zika sync is the philosophy of ethereum we don't want to build a proprietary technology bound constrained by artificial means it's going to be all open source with permissive software license and uh the network itself is going to be owned and governed by the community and if your community finds that the current validator said is malicious they can always away because they like we will also provide the means of mass size we'll talk about that uh cool now user experience uh it's really important for user developers to see to to like imagine how the users will think about uh or perceive your system uh so we'll start with how they begin using zk sync they start by having fun somewhere else right they have an empty account so they can either receive funds indicating from from someone else who is already on zika sync or they can just bridge them natively from layer one or from exchanges from one ramps it's going to be directly on uh on dk sync uh native it takes ten confirmations so like one one minute uh two minutes to for funds to arrive like any message from layer 1 to layer 2 passes within 10 confirmations and you have native withdrawals to layer 1 and correspondingly to other roll-ups if you need and this is important on optimistic roll-ups it will take one week at least on zikr allaps it will take your next block which uh which realistically right now it's hours on zika sync one we think it will go down even two minutes uh because we with with higher uh throughput we will have shorter blocks uh with a lot more transactions which will still make cost economically to verify and ethereum and the latency will reduce and you also will have normal bridges custodial to other chains but those are like much less interesting than the native trustless withdrawals to l1 which affect nfts you cannot do it with like really with trusted with custodial bridges for nfts you you just have to wait like an optimistic roll-ups you have to wait one week to throw it anywhere else on zk it's not an issue um now okay so that's bridging interacting with the keysync will work from any wallet even though it's a zika roll up we fully support we're fully compatible with ethereum so you use ecdsa signatures you can use anything from metamask to coinbase to argent to trust wallet whatever you like they will natively support ac20 and token transfers so you just use native interface of your wallet to send funds and uh for normal contract interaction you can also use ethereum message format uh but for some more flexibility we'll also support eap 712 for signing transactions which will look like this i think you're all familiar uh wallets can support it natively to better display it and we'll have also external tools to better display what you're actually signing there and this is a big problem for ethereum because sometimes you need to sign it with a uh smart contract wallet or so sorry with uh with the hardware wallet so you only see the hash so you still need some external mechanism to show you what you're saying but then transactions are going to be instantly confirmed even with decentralized sequencer we are aiming at sub-second confirmation times four blocks and you can pay gas in any token at least at any liquid token which our validators are willing to accept which is very important for mass adoption as well because if you have users who are joining ethereum player twos because they just want to to have the savings not in like local pesos rubles lyras or whatever currency they have in their corrupt country uh they can just use usdc usdt of stable coins like stablecoin version of uh or like you know like whatever they want and they can pay fees in those so for them they perceive it just like a new bank they have their dollars there and they they they don't think if they don't need to learn about the ether gas it's too complicated you want to reach masses with this approach you want you make you have to make it simple so that that's why like ux is at the core of will with like everything every design decision we're making at dk sync we're thinking about end user experience like how to affect them so that's why uh paint isn't it uh okay so this is ap 712 and another thing for mass adoption is we're going to support account abstraction natively which is hugely important for smart contact wallets like argent and in other wallets that are building this experience without having to work with seed phrases which again would be a massive hurdle for for big adoption with a lot of people uh so with argent you you don't you don't have that you just log in with your email but you still have full custody of the funds even if google compromised your like had your secret they would not be able to take over your account maliciously like you still have in full control and there are other approaches to this as well so this is very important for us to to uh support uh then another uh thing is some protocols might want to subsidize the gas like this happens on dydx for example you don't want to pay any gas at all you're just like you your all transactions are just one click and the and you pay maybe some percentage or maybe you don't have you see anything you know when you're paying with a credit card you you don't have fees on the credit card at least you don't see them right because the merchants are paying it so similarly protocols might choose to to abstract it away from users and uh increase the ux even further this way and this is for this account abstraction is necessary and finally there are some special use cases like tornado cache or other protocols where you just need it for normal functioning so right now on ethereum itself with external real layers which would be a lot more convenient if you had the kind of abstraction so that's why we decided indicating by default every account has code and can be upgraded and can be replaced you know like with uh customizable signature verification so cool [Music] developers perspective so like what it means for you if you want to start building if you you want to try this casing out at uh current hackathon uh you can just take whatever you wrote for ethereum at and most apps should compile and just work out of box without no any modifications so that that's essentially just our approach like make everything plug and play there are a few yeah so there are um some differences in the way you might want to interact with contracts we have our own zika sync sdk written in typescript javascript uh going python we support multiple right now on the js but we will support the plethora of stacks for for you to to use and if you just uh want to use it out of box like to migrate to to to start using the casing sdk all you need is just to change your imports as you can see the code on the left and the right is exactly the same but then you can extend it and for example this is how pain in a different token will look like you just specify the token you want to pay and there are some other extensions that you can take with zika sync sdk you will need it for certain cases that are working like inherently different than ethereum which we'll discuss later most important one is deploying contracts contract deployment works slightly different on zika sync compared to ethereum and app you first deploy the contract itself like the contact code and then you deploy an instance of the contract so we have native what's it called like account proxy so let me speak here because it's recorded and uh in the microphone so uh the uh on ethereum factories contain the code of the contract and they output the code as a result of their execution which is a slightly weird approach but this is how ethereum works today in zika sync the code must be deployed separately before you around the factory and the factory only points to a an account where the code implementation resides and then it's copied or like rather referenced by the account where you instantiate the contract so that's that's why you need to approach it separately uh questions it's still the same you you will still deploy your proxy uh which will contain the logic of upgrades and logic of delegation of your code and it works the same way okay so but but let's uh so yeah most things work out of books but let's see at some differences some of which are dictated by uh a different design approach some of them are necessary because we have we have a different architecture with zika sync we we don't implement bytecode compatible zkvm but rather our own version of zkvm which is optimized for being provable in zero knowledge proofs and so we compile your code through from solidity with native solidity compiler into you which is native ethereum intermediate representation of byte codes then we compile it from there into using llvm framework how many of you are familiar with llvm uh well it's it's a it's a very mature very well-known compiler framework which is used by almost all modern languages from c plus plus to go layering to python to rust to everything so you just compile it into this intermediate representation of llvm and from there we compile it to zkvm which will allow us in the future to also integrate languages like rust and golang and whatever like all of them will just work immediately but okay so let's look what it means in like what design differences we are going to make permanent in zika sync which will be always diverging from mainnet number one is create and create two address deviation uh errors derivation will differ because we have a different byte code so if you just do it natively it will be different by code so like you you just have to be aware of that although we we are also thinking like if if if there are use cases where you want to have the same contract address on different chains we are considering making this possible so if if you are having these considerations or if anyone watching this wants this please reach out to us and we will we can introduce this feature um we we're going to deprecate payable and message failure message value will always be zero just like so it's perfectly compatible with ethereum just you have all accounts with zero if balances no no no account will have ether balance so all the calls will happen uh like his little account didn't have like or spent all of eth on on gas uh everything is going to be represented is erc20 including eth itself and the the fees are going to be paid in erc20 um tokens right so like this should not affect anything because most applications are supposed to work with both native eth and erc20 cell destruct is deprecated just the same way as ethereum explaining this there are multiple aps for this so we it creates so many problems that like it's kind of consensus that it's a bad thing it should be removed and gas metering will be slightly different obviously just as it's the case with all roll-ups because we have in layer two um operations have different impact on the pricing than in layer one storage is for example very much cheaper uh certain uh uh operations will be computationally more heavy so we'll label slightly more expensive and so on but that that's that's like you you can't just rely on having the exact same metering scheme there are some things that we don't currently support uh so solidity uh is not supported in the very early versions that did not have proper yield support although on the current test net solidity is only supported starting with version 0.8 i think uh but earlier versions coming like in the next days or weeks like they already implemented some openly zeppelins leaps won't work mostly because of the different way we work with deployment of contracts and we are currently working on making them compatible so like all of that will be rewritten with some special cases so that most things should work out the box some tooling like hard hat plugins need adaptation for the same reasons and we're also working on that and some crypto uh and specific like all crypto pre-compiles uh modular arithmetics add mode moon mode [Music] and [Music] pairings currently do not work but they will be supported in in the next month okay hashes will hashes are supported today shot of f6 catch up perfectly work and are cheap unlike many other zk based systems everything else will work and even wipers will be supported on the front-end side or access side we will support legacy transaction formats so your front-end applications should just work without modifications unless they deploy contracts if they deploy contracts you will need to to adjust and you will need to use sdk um web3 api is fully compatible for queries so it you just make the same binary calls you don't need to change anything and we have this custom sdk for more flexibility and here's how you can get started just go to v2 docs dot z and you will have the uh um nice tooling a nice portal where you can try out things with your metamask just go to faucet get some test tokens and you will have full documentation with samples tutorials how you can start it fast okay security the security model of zika sync is as i said before exactly the same as in ethereum so the protocol guarantees the full security of player one uh full security derived from a layer one and by insecurity i mean specifically like not violating the rules of the protocol not executing transactions on the user behalf without their authorization and not executing like changing the logic violating the logic of contracts um we discussed easy gear roll up and ziki porter with uh censorship resistance but what's what's really important all these properties are preserved without requiring modifications in your smart contracts without having like without forcing you to think differently about the security of smart contracts which is not the case for many other platforms so for example currently on startnet you cannot have the same security properties you will need to think specifically of how you're going to change your contracts to to make them enforceable and like what other contracts are you gonna access are they still gonna be available in the case of data unavailability event and so on none of that applies in zika sync like if you have if you deploy something on dka roll up you have exactly same properties as layer 1 period of course if we don't have box in implementation or in cryptography but that's the case for all platforms like i would not trust all of my fortune like a significant fraction of my own money on any of the current l2s for you know longer period of time they need some time to to get mature to get stress tests uh you know just to to make sure that there are no bugs but from the protocol perspective you don't have to think about it and if you have code which is running on layer 1 which is currently audited you most likely don't have to uh do to make any changes if it compiles it will just work if the compiler doesn't uh curse with any uh uh warnings that there are some things that you like you're using self-destruct or you're trying to use message value in some specific ways that that are requiring you to use it everything should work like the most audience should be preserved and finally we are putting efforts into designing mass exit mechanisms so that the uh that goes back to the philosophy which i mentioned earlier if you have a malicious takeover of the protocol by group of validators for whatever reasons that might even act against their own self interest financially just to grieve users or maybe they have some political pressure to censor a certain group of users or a certain type of transactions they can say we're not going to support this type of business and a large fraction of the users won't agree with it they should have an ability to exit safely to maybe to a fork of zika sync or maybe to a different role up if if like the zika sync it doesn't fit them for whatever purpose so we're going to provide that we're going to make sure that the mass exits are as cheap as individual exits for those users we can just discuss the mechanism specifically and yeah all the usual l1 security practices will apply and pre-existing audits are at least we are putting out for redesigning the security aspects in such a way that they should preserve current audits unless we explicitly provide a warning in our compiler and we're also going to partner with major security firms if you have a project uh and uh you need like you're close to launch and it's really exciting we might be able to help you with getting earlier slot toilet to wield our best ecosystem obviously sync is growing we have lots and lots of projects coming but uh you can um [Music] have the like all the projects that are coming from ethereum are thinking about like the migratability of existing use cases existing applications uh that might not necessarily take this massive scale into account so there is a big opportunity to like reimagine things with the new features that we have with account abstraction with with uh meta transactions with like just just taking something and saying like how it will work at scale in the early there um and finally we will we're going to support projects we have a big uh zikidaw ecosystem grant program with grants and with investment programs uh where we're going to support the the projects and we'll share more details later but specifically we are going to offer grants for making things compatible like for finding gaps in the current developer ecosystem for something that works on layer one or on other l2s and does not yet work for zika sync like the aforementioned hard hat plugins some open zipping in leaps etc uh so those things will need adaptation and we want this adaptation to be plug and play so it's just like the the the environment will just see oh you're trying to use this library so you need to to download the zika sync version of that library uh from the same repository from from the same vendor and we're gonna specifically offer support for that so this is the perfect opportunity to do something in this hackathon uh yeah to uh to participate in this call and that's it please follow us for news on ziki sync on twitter happy to answer any questions deep dive into any topic you want discuss we have uh our technical product manager here we have uh head of marketing here anything you want to know sure please go ahead like um user exit uh so in comparison maybe with uh like more lightweight roll-ups like optimistic products it doesn't require a lot of computation so a user can commit like in your state to an uh like you need to generate the proof which is like with huge scary means like a data center user doesn't have a data center so user can't exit can you please expand like one sure sure i'm going to repeat every question so that it's on the recording uh so the question is about uh exits forced exits for users and in comparison to other more lightweight roll-ups like optimistic roll-ups that do not require heavy computation of their knowledge proofs how can we make sure that the users can always exit without requiring them to have like data center computation level requirements the way it will work is we will have a priority queue on layer one where users can submit transactions with full inputs like transaction signature like all the witnesses they have in this transaction and the priority queue is something that obliges the validators to execute it in the next possible the next possible convenience like within a certain time frame within a very short time frame days or maybe maybe hours so if there is something in priority queue it must go through priority like you the validators must do priority transactions first and then process all the rest that they get from the users if they don't do this if they fail to process priority queue requests within a this short time frame then the roll up will enter what we call emergency exit mode which is which means that it will still accept blocks the blocks will be accepted from anyone not just from the set of validators that are whitelisted by by their token stake uh and um anyone must like or the the blocks that that will be accepted will have to contain only transactions from the priority queue in predetermined order that means we can all work together like if you just have your own one transaction there you can generate a block you as a user can generate the block with just this one transaction and that will not require huge computational resources from you you like you can do it on a laptop it might take you you will need to sync full ethereum node on this laptop uh and then you you you will get all the state from zk sync you can reconstruct the roll up state in your local database requirements are like essentially the same as for ethereum full node just just the laptop will work and then having the state you can execute this block and on the laptop it might take maybe longer maybe like one hour a few hours depending on like what you're doing transaction but you will not need external hardware then you can always submit this transaction and the only reason you might not be able to submit this transaction is because someone else produces this blog before you but that's better for you because then you can just abort operation and continue and this is designed in a way where transactions can also be submitted in batches and then the assumption is that if there is a censorship it's probably not going to be individual censorship it's going to be mass censorship by some criteria so then users can coordinate and withdraw uh just deploy their own version of the casing fork and withdraw in masses because if you're just one person the priority will likely be sufficient because otherwise you will just stop the roll up no one else will be able to do anything on the roll up and this is going to mean huge economic loss for the validators so they will they will have to process your transaction more questions do they just by themselves select new or just left tokens like who sets the rules which stories are accepted how do they do this the validators will so we will start out with so the question is like how the tokens for paying fees are selected and initially all roll-ups currently are having centralized sequencers so they just there's one system and then for centralized sequencers uh it's up to the sequencer as long as we will be running the sequencer it will be just the major liquid tokens which we can sell instantly to uh to cover our our costs because we we're going to be running zika sync on like at roughly the breaking costs just the same way we do for version one we're not making any profits which is covering the costs um so for us what's important is just like uh market liquidity that you can sell it's not some coin that that you're going to be stuck with at some arbitrary price and i think that once you have a consensus of validators the same logic will apply they will be willing to take any token they can instantly liquidate in this block or in this subsequent blocks because why not [Music] so you're asking about removing the payable functionality so by payable i mean native like uh special token in the system like ether is a special token right it has its own like special api which no other token can replicate everyone else has to use erc20 but ether has this special first class citizen status so we just like we're removing that we're making all token tokens equal we're like this this is a design flow essentially in the original ethereum esc-20 is somewhat clunky has huge security risks because you either have to like authorize unlimited access for a certain contract and then have one click transactions or you have to make two confirmations for a transaction if you just want to to spend certain time a certain amount of your c20 tokens but uh but that's just how it evolved and we're thinking like with account abstraction you will be able to mitigate that you will be able to also pack together transactions for your c20 but but back to your question um it will not affect most protocols that are supposed to work with erc with tokens in fact there are many protocols that only accept eth as weth wrapped eth because they want to treat all tokens in a uniform way or maybe i'm is does this answer yeah you can but you just like imagine a system where no one has heather balances so you can use it but it will never be used because no one can send you any money right because you don't have native eth you only have like tokens and but you don't need this e to pay a guess because you can pay guests with your tokens all right so like the functionality can be there but it will just sit idle and no one is going to use it you wanted to add something just come over here to michael yeah i just wanted to like clarify that if you have a payable function you can still call it it's just that the behavior will be the same as calling a non-payable one because there is no native eth maybe you can stay here for more questions sure tokens is there something like how does it know what the value of die or whatever token would be so the question is how is guest how are guests these calculated for non-heath tokens and the answer is the validators know what the transaction will cost them they know it in terms of like when they uh prepare a block they know what uh amount of gas they will have to spend and what amount of computational resources they will have to spend on this block those are two attracts separately gas is like what you what what you will have to pay for verification of your knowledge proofs on ethereum which is amortized across all transactions in the block and then transaction specific costs like paying for storage paying for events paying for this and that um computation is with what it takes to like actually like the part of the producing zero knowledge proofs specifically this transaction this part is largely negligible it will be like fractional offices of ascent we have really really efficient provers now we have hardware accelerated provers of fpga gpus uh so those things are all done in parallel and and like small but guest price is important so the value just know okay we're gonna have to pay for this amount of gas at the at the end of the block which they still have to project like what's the gas price will be in like 10 minutes from now in one hour from now so they have to to get some margin there and then they see okay so we like we assume we'll have to spend like five dollars for this transaction like one dollar or whatever like 50 cents and then they look at the price of the token which you're offering them and they look at the depth of the market for that token and they ask themselves for how much like how much of this token do we need to have a guarantee to get 50 cents when we're gonna sell it right and and this is what the the threshold which are there they will be willing to accept and which their apis will also render as uh acceptable price yes and you were basically mentioning something very much like meta transactions like people paying for their for their clients like basically um you are supporting uh and maybe this is like because i i don't understand account of other structures like at all as well but if you're supporting uh seven one two uh you should like our method transactions support the automatic um so let's so the question is if i can repeat i'm sure i can repeat the question but i will just answer and uh so the uh uh maybe let's begin with uh clarifying what is exactly account abstraction so on ethereum account like on ethereum you every every transaction can only be initiated from the um what's it called externally owned accounts eoas accounts that are controlled by ecdsa signatures a smart contract cannot initiate a transaction so like you cannot initiate a transaction if you don't have eth on something that is other than eoa right the idea of account abstraction is to allow contracts to implement their own logic of initiating transactions so the users can send some data to the contract like make a call on the function and let the contract pay guess for this call if the contract believes that this is a legit call right so like the contracts will accept transact like the contracts will accept calls without the user having any funds and the contracts will say oh this call looks good to me i'm gonna pay for it so and then the evaluators will will see that and we'll accept this transaction so that's the idea of account abstraction so oh so the question was like does it imply that you have meta transactions by default it depends on your implementation of the contract the contract might say yeah like i'm i'm gonna i'm willing to accept like certain tokens and do certain manipulations with them and do it and like or you can implement it differently or you can just say like we're gonna pay it from the protocol treasury to subsidize initial usage of the protocol say even if it's not we're not making profits but we're just gonna let users use the protocol for free for a while up to the implementation we have like milestone based roadmap so the next milestone for us is to launch mainnet as soon as possible so we we're like the team is completely focused on mainnet uh testnet is running really stable you can try it out but everything works really well we have dozens of teams building already on on testnet and preparing to launch and for us it's just pushing out the main at first s z key roll up the second step after we launch zikrollap in maynet will be adding zk porter we have implementation we have a like a local test net already running internally but then we're going to add this like enable the integration so ziggy porter and zq roll up are not two different protocols they are two different account types but they are the same protocol it's just the same state divided into subtrees and the like launching ziki porter will simply mean that we will enable this functionality because we will need a token for that we need to distribution of the token we need the uh the validators with nodes for this validators but the protocol itself will will remain the one we're launching so the question is how do you choose accounts on dql up in z porter and the the answer is first of all you choose account um and uh like you know it doesn't apply on transaction basis it applies an account basis right you you can have two different accounts your accounts on zika roll up and dk portal site will have the same address so what you decide essentially is what you use most likely from the user perspective it will look like just having different networks so you can connect to zika roll up network and then you use this account and then you you use it from the zqirl upside or you connect your metamask to a z keyport porter network and then the same account with the same address will control a different set of balances right but they they have a an interesting logic of interconnection which we like we i can't cover now because they need slides or just to show explanation uh but for user it will look like this so you decide where you go and most likely it will be protocol or like wallet uh assisted so wallets like argent will just tell you okay you're creating it on ziki porter are you going to use it there or with universal wallets like metamask we'll just control it by that i think we we should actually cover more things in in the presentation and like more benefits of zk-based systems which we currently don't have uh just one thing that came to my mind while i was talking was that um on zika roll up your you can have transaction input that is essentially free that is very cheap because it's not going to be propagated to ethereum so you can have transactions that accept a very long call data do a lot of computations this is going to be all cheap sans fractions and then they only save uh like mix a few storage rights at the end and you will only pay for those storage rights so like you can think like the the applications can be structured differently because of this guest pricing so we need to cover this in future versions any more questions [Music] because of the way how their knowledge proofs work so um the bot so the the question was why is that the case what i just explained and and the the the the reason is we have two we have to track two different metrics for of of pricing one is uh call data that we use on ethereum this call data is used by all roll-ups equally all roll-ups essentially compete for this call data like there is it's fixed and it's limited if we use 50 of that all other roll ups will only have 50 left right so like get like in in the increased demand from any of the roll-up will affect everyone else because the gas prices will go up and guess uh spent on data availability is going to be the main bottleneck for all roll-ups that's going to be the most important the most expensive part but for us we only use data availability gas data availability space in the roll-up to publish the changes in the state of the roll-up don't use it for anything else everything else is just computation of zero knowledge proofs and we only use ethereum like we use a fixed amount of gas roughly one million gas or six hundred thousand gas to verify proof of arbitrarily many transactions if we use starks uh it would be like five million gas like ten times roughly more but um the cost to produce this proof is is cheap per transaction on a per transaction basis it's going to be just a fraction of this you had a question um because for exactly so the question is like why roll up offers linear boost and ziki porter uh we are claiming unlimited throughput uh the the reason for this is that ezekiel roll up is limited by the data availability of ethereum so we only have this 12 ha twelve and a half million guess which means like how many bytes per second i don't know you need to calculate right but um linear amount of this data availability for the linear like if you have n transactions you will need n pieces of data to put on this chain and this is going to be remain remaining limited even with ethereum going towards dunk sharding um it will remain limited it will be larger by in by some factor n but it will be still limited you cannot go and add more and more and more charts in in infinite way that will all be uh uh committed to in the same ethereum blog does this answer the question or not it has zero to do with your knowledge because it's it's all data availability it's a different or source metric zk itself allows you to like we could have like if data availability was cheap and and limitless we would not need the keyboard at all we would have ziggy roll up that is infinitely scalable but that's not the case so we'll need to parallelize data availability at some point and this is what porter is for more questions cool i think then we're done thank you guys is [Music] [Applause] [Music] you