Alex Gluchowski: zkSync – The First EVM-Compatible zkRollup Protocol #396

Transcript

this is epicenter episode 396 with guest alex gluckowski hi welcome to the epicenter of the podcast where are you for crypto founders builders and thought leaders i'm sebastian cuccio and i'm here with felika ernst today we're speaking with alex klukowski he's the co-founder of matter labs and the co-creator of zk sync and it is the first evm compatible zk roll up so before we speak with alex about zk sync and get into all the technical nitty gritties about how that works uh we'd like to tell you about our sponsors for this week solana is the

next generation blockchain with lightning fast blocks and fees less than one cent per transaction scalability is probably the biggest challenge preventing crypto from becoming the backbone of the world's financial system and solana is one of the solutions we have today go to solano.com epicenter to learn more we're also sponsored by exodus it's an easy to use wallet that supports hundreds of assets and uh has native apps for all platforms including ios and android and it's fully non-custodial the team are firm believers in the not your keys not your coins mantra go to exodus.com and give it a try and finally paraswap they just came out with a huge update that's even faster and more liquid it's cheaper than uniswap and it comes with a new gas token that can cut your gas fees by up to 50

it's also multi-chain now and they've expanded to polygon and binance smart chain start trading at paraswap dot io epicenter alex hi thanks for joining us today hello very excited to be here thank you guys uh so tell us a bit about your background and um how you became involved in the crypto space uh well i studied computer science in berlin and i worked as a team lead and a software engineer and cto in in multiple companies starting with telecommunication space and then moved into startups um was co-founder of two startups in berlin

and at some point i just felt that um crypto is uh going vertical and and it's just like i can't wait anymore i have to jump there because my heart is within in crypto so i was very excited about bitcoin actually i think i learned about bitcoin one year after it was invented and back then uh it really appealed to me as a kind of libertarian uh person uh and it was a very exciting technological thing also from from the beauty of uh the architecture of it but back then i thought well if we could only bind it to gold somehow maybe it would work but eventually it actually worked but yeah i i switched only once ethereum

appeared i actually i i tried to to build a startup in the bitcoin space but i felt it was too early uh we were trying to do uh something based like uh sovereign reputation thing i was doing it with uh arthur bendiken who is now uh a cto uh at uh aurora uh but yeah we we couldn't find investors and we thought like it's maybe a bit early so i went back to the classical startups and the startups you you worked on before crypto they're actually pretty interesting as well so maybe let's give give those like a minute of airtime so the ones that i found um one of them

was um acquired by urban sports club and the other one was a camper rental startup tell us what what drew you to these uh these subjects because they're quite um they're quite different from one another no this is true so well as a software engineer i must be honest that initially i was looking into the technical issues and i was not caring so much about the business nature so it looked like a very interesting idea so the first startup was called so much more and the idea was that you can get a pass to uh it was essentially a copy of class pass an american startup where you could purchase a monthly pass to

all sports and and uh holistic activities in your city which i found very appealing because like the this idea of flat rate uh it feels like like germany communism it's some in some sort you know like spotify and netflix you just like pay very small amount per month and you get unlimited access to everything like full abundance the future is here you know like you you uh so it it felt the same way but uh it was not very technological so then with paul kemper the the camera sharing platform that was very appealing to me because we could build something really interesting with with com sophisticated search engine and optimization for scampers in the booking system and there was a lot of accounting involved

paul kemper was the the company i'm really really proud of uh the team we could build it was remote first the it team the the business team was based in berlin but the atv was completely remote from day one and uh it's it's highly successful it's the largest campus sharing platform in europe right now uh polk emperor is present in germany uk um switzerland austria i think even more countries by now but i decided to leave it after only one and a half years because i felt like i maxed out like i i have done as a cto i've done everything i could do there and the rest does not depend on me like the processes and the detecting was

were working fine and there were no no not so many challenges to solve uh whereas in the crypto world like ethereum started to to get traction and actually when i was in so much more ample camper i tried to integrate bitcoin i had this idea of like making bitcoin payments to to be accepted and then i realized i can't justify that it just didn't make sense because no there were no no people using bitcoin and it could be a nice pr move but probably not for this niche startups we had more consumer-oriented in europe and i realized if i think this way and i'm kind of very pro bitcoin i'm very excited about this technology this is how everyone is going to think

about it for now so it's it just doesn't make sense but with ethereum it was entirely different all of a sudden the city of smart contracts an open financial system and an alternative financial system would stable coins with all sorts of uh interesting things with with potential for improved usability was there uh and i figured like i can just my opportunity cost of not going into this is enormous so i have to switch now so what i did is i went to hong kong and i was working as a consultant in a research in an r d startup and we were just going to all the different conferences and meeting people

and talking and making research and trying to figure out what what what are the problems uh the crypto space is facing ethereum space specifically and i came to conclusion that there are a couple of things that once solved will bring ethereum to to masses and everyone is just going to jump on it and the problems that had to be solved for the user experience in combination with security it's kind of like the size of the same coin and scalability and while the security and ux were kind of clear how to fix like we we could just apply principles from the web 2 world or everything we knew from traditional startups from mobile apps was clear what to do and they were

actually built we got metamask we got argent we got dharm we've got all these wallets with social recovery with uh the ease of not uh having to to to care about your secret phrases like it's xengo and wallets based on um uh you know some combination of secret sharing and using your email as login and so on um and all the other things were also being built from traditional finance which we now know as d5 but scalability really caught my eye because it was very technological like it felt like a fundamental problem which cannot be easily solved and unless we have some breakthrough there were a couple of attempts there was this idea of plasma that was introduced around that time

and i remember i met vitalik for the first time in shanghai at a conference where he first spoke about plasma i was very excited but after half a year or a year or so it was clear that plasma is facing a lot of hidden problems and that they appear to be of kind of fundamental nature like we we just we just can can solve them in in you know like just tinkering around so we need something something more solid and then i learned about their knowledge proofs first about the zero knowledge aspect of their knowledge proofs so that you can use them for privacy and later um i learned about the succinctness property that some of them have

specifically snarks that you can prove integrity of very large computations and they are much cheaper to verify than actually doing all these computations and my first thought was when i heard about that oh you can apply that to plasma and make plasma a lot uh like solve a lot of problems in plasma for that and if you do that that that's actually like half a roll up so like applying zero knowledge proofs to plasma gives you a validium and then um if you put the data on chain this is the ziki roll up uh and i met barry whitehead who was working who built built the first working group working on zika roll-ups and we we met some other guys we had

discussions then we published the this famous blog post uh on each research particularly and then i met my co-founder alex flossof in uh at defcon in prague i think it was defcon four or three he was coming to the same idea from a different angle he was actually working on plasma he he was building a plasma implementation and he learned about their knowledge proofs and and he was very deep into cryptography uh having a phd in high energy physics from uh mcgill university in canada uh he was really good i immediately realized that this guy is genius and and we should do something together and we immediately jumped into the discussion of how things should be built technologically we built the first

prototype presented it and this is how aziki was born let's get to our sponsor solana now this is a special ad for me to read because i've been a deep supporter of this project since meeting the solana team back in 2018. i invest personally in the project and my company course one is super deeply involved in the solana ecosystem including running the biggest validator so what's so cool about solana well we all know that scalability is the single most important issue facing the blockchain industry today and the solana blockchain is an amazing solution for it the network supports thousands of transactions per second with 400 millisecond block times and over 500 validators

the special thing about solana is also that it's not a charted blockchain it's a single blockchain hyper optimized for performance so that makes it really easy to maintain composability between all of the apps on solana so that they work together seamlessly now and forever the solano ecosystem is growing at a rapid pace and it's a great place to build your project or just get involved with the community so go to solana.com epicenter to learn more we've done a you know a number of episodes uh on on the topic of scalability and a few episodes where we've talked specifically about zika roll-ups but let's maybe uh get a little refresh you know

how does a zk roll up work in a nutshell what are the main components and like what does it try to achieve so zika roll up is a scaling solution that works on top of layer one so it's a layer to scaling solution which which is supposed to derive and security from uh from layer one and it works the following way maybe we should recap first how plasma works because it's going to be easier to explain so with with plasma imagine that you have a single contract on layer one that uh instead of holding all the balances of the users uh only holds all the funds together in a single pot and it holds a root hash of a of a state which is held off chain which

contains all the balances so we only keep one hash so this this hash being a merkle root uh serves as a cryptographic fingerprint of our state whenever we change something in the state the change the the root hash will change completely now when we we want these users to transact we want this users to send fonts to each other which will modify the state so whenever we have multiple transactions uh maybe a block of like let's say 1000 transactions we would modify the state applying each of them sequentially to the state which will modify all the balances and then we will compute the new root hash

of the state and we'll send this new root hash to the smart contract on layer one and replace it and this way we actually we made only one small transaction on layer one but we enacted uh many transfers thousands of transfers of thousands of transactions which which happened on uh in layer two so the in plasma you would suppose to monitor what's going on in the state and try to catch the so like anyone would be able to to to submit the new root hash and if something goes wrong and the this new root hash contains invalid transactions or some embedded state you would have to somehow prevent this

new root hash from being finalized on layer one uh and this is difficult so with plasma and nzq roll-ups rely on so-called fraud proofs where someone has to monitor it and then provide a proof that the new new state is not valid with zika roll-ups we do something very elegant we provide a zero-knowledge proof or like 1600 knowledge proof or snark of validity of all the transactions that happened that produced this new root hash and the snark is verified by the smart contract itself so what it means is it's been verified on all the full nodes of ethereum and only if the snark is valid uh then we change the the new root hash on

the smart contract and this way we can guarantee that no invalid transaction is ever included in in in our uh roller block so just to recap the the phrases differently in in a in an optimistic roll up you have a verification of the different hashes in the merkle tree and the root hash that has to be uh verified by some like some third-party process and one of the ways that we've come to do that is to have this fraud-proof system but that introduces a whole bunch of complexities whereas with a zika rollup you simply have uh a snark that that proves that all of the state in the uh all the transactions uh in the

state that's sent to the to the smart contract uh is indeed valid this is correct yes so this way we can only improve the validity however we also have a problem of data availability so we need to make sure that everyone knows what the new root state what the new state is completely not only the root hash and with rollups what we do is we publish some data on chain that makes everyone um able to reconstruct the changes in the state to get the final state somehow like if you have the previous state before the block you should be able to get the new state completely in your local database after the block so you can do it in in

multiple ways you can either publish the inputs of all the transactions this is you can do it with zika roll up and you can do it with optimistic roll up or you can publish just the final state like actually like the state delta what would change in the state the final state of every account which was touched in this block and this is only possible with zqraw and this is very interesting because it it introduces additional synthesis if you have uh let's say one account or like two accounts making many transactions between each other at the end we will only need to publish two two updates of the state like the final balance of the first account and the

final balance of the second account and not all the hundreds of transactions with that that took place in this block this place is a floor at how much a transaction can be reduced by right so basically if you if you have an operator and user say optimistic roll up um you you can compress the data much more said correct because you don't need to submit it unchained such that someone can reconstruct the entire thing uh so yeah there are multiple factors that that make zikro ups cheaper in terms of unchained data uh but fundamentally maybe we should first answer the question why does this work as a scaling solution

at all if we still put this data on through on the ethereum network right so the the difference from just using the putting this data in uh you know like using ethereum on layer one normally is that we don't use storage we only use the bandwidth of the network but we do not require the ethereum full nodes to store it in the ethereum active state and we do not require them to verify and like access storage of different contracts to verify transactions and that part random access to the storage is actually the bottleneck right now on ethereum this is this is the most expensive thing because you cannot like we use ssds and we cannot read the data

sequentially from ssds which would be really fast instead we have to go to like jump to random locations in this memory and this introduces the delays and you you have to do it sequentially you have to read one thing then you have to read the other thing and then because you're working on a global state right so that's why that's why you have to do it sequentially because you you're working on the global state and you work with merkel proof uh merkel proofs so you you have to retrieve merkle path for all the accounts and when you modify them you have to actually go and like modify all the intermediate nodes on the merkle tree um and this is where you get these delays because these latencies just add up so what we do with

zikro up we only publish the block as a one big chunk of data we do not use storage it doesn't need to touch storage it just goes through the network interface and the bandwidth is a lot cheaper than storage and a lot faster than storage access so this gives us roughly 100x improvement with zikrolap with optimistic roll-up you can get the kind of the same scalability factor if you optimize the optimistic roll-up uh really strongly for like if what you would need to do is you would have to aggregate the signatures because you still have to

publish the signatures on uh through this network in the roll up which you don't have to do in the z curl up because the signatures are verified by the snark and also you would have uh there are some other nuances and optimistic roll-ups say the most compressed version would only work with multi-round fraud proofs something like our bedroom and it would be much harder to build with a single round throat proofs which optimism is users is using but in any case you still have like you only get the linear scalability boost let's get to our sponsor exodus exodus is a fantastic cryptocurrency wallet that strikes the right balance between

ease of use security and great features you can get exodus on the iphone desktop app web app android whatever platform you use it's a non-custodial wallet and that is so critical because what's the point of crypto if you don't control your own assets with exodus you always do they're old school and they've been around since 2015. over 1.2 million users rely on exodus so you know that they've stood the test of time they have support for over 100 different crypto assets and from within exodus you can easily change one different asset to the other they also allow you to buy crypto with fiat and they even have a great offer where you

can buy up to 500 worth of crypto through the ios app and pages one dollar in fee so go to exodus.com epicenter and check out their wallet we want to thank exodus for their amazing support of app center so let's talk about the aggregated block of transaction data so who who actually aggregates that and who basically if i want a transaction include included in a zk sync block how do i go about that so you normally have someone called sequencer collecting the transactions from the users and packing them in the block and computing the new root hash of this block the sequencer can be centralized it can

be a single party with a server which accepts the transactions through rest api it can also be decentralized some consensus algorithm multiple validators collecting the transactions through a particular network and it's just agreeing on what's the the new block is going to be and then selecting the leader who will submit it to ethereum or maybe anyone from from this violators can submit it to ethereum with all the rollups right now as far as i'm aware everyone is currently using centralized sequencers because with rollups you do not rely for the sequencer on the sequencer for security but they could censor me right they could stand there you

but only in l2 they cannot censor you and l1 so if you feel censored you can always go to layer one and retrieve your fonts through some additional mechanisms in our case it's called priority queue and we have something called exodus mode or emergency exit mode where you can exit without asking anyone for permission and this is very important aspect of the protocol but if you if you are being censored by operators by the operator by by the sequencer in l2 yeah it's you're just not going to use this service it's not as bad what are the trade-offs of of having a centralized service and perhaps a decentralized service to ensure

like censorship resistant aspect it just allowed us to to launch the the zika sync earlier and uh uh we will with zika sync we follow the philosophy of progressive decentralization we start with the minimum viable product which is central which does not rely on us or anyone for security so we we we derive security directly from ethereum and it's just much faster to build and to have a full flash consensus which we we are building and this is very important to zika singh we don't want zika sync to rely on any single party long term or even midterm we wanted to be decentralized protocol governed by

the community and having multiple validators that are selected by the community so that we also don't have uh any censorship potential in l2 long term actually we have some more ideas on how to solve censorship and we will rely on even more advanced cryptography because even if you have even in ethereum with multiple miners uh there is still a chance that they they will collude like it's not impossible that miners or validators will collude and will will prevent users from submitting transactions and this is actually a one big attack vector on optimistic roll-ups or on other protocols that rely on fraud proofs

that the miners willingly or being cursed will just prevent the fraud proofs from being mined on ethereum for a relatively short time of one or two weeks and then the attacker would be able to seize all the funds from the optimistic crawl up this has been a controversial topic like obviously uh i am a zika role of maximalist and you can say i'm biased because of that and we had some clashes with people from who are optimistic proponents and they would argue that the community can always step in and intervene and punish the validators who do such a thing and rely eventually on social consensus for restoring

uh for for the ultimate censorship resistance uh but i disagree that that you can like you should not be building protocols that rely on such weak assumptions this also might be valid for uh for the time one once we transition to proof of stake and it like maybe there will be some like clearly written rules how the community should behave and we get some signaling from everyone in the community that they actually gonna follow these rules and we have clear mechanisms how such situation can be cleared up without incurring a lot of mass because like imagine if that happens and um we have a lot of d5 transactions going on that are all intertwined you know like

you you put something into a uni swap and then other people put stuff in and the price moves and and some other oracles rely on this price and so on and so on like it's going to be very very difficult to sort it out after the fact so you actually need these mechanisms to prevent censorship in place before but that that would only work once we have proof of stake with proof of work there is no mitigation like if if the proof-of-work miners decide to attack an optimistic roll-up they can do it this is very real and they can they can uh collude they can be bribed we there might be some automated bribery mechanisms through uh some smart contracts they distribute the rewards from this attack and actually the closer we come to the

moment of transition from proof-of-work to proof-of-stake the less proof-of-work miners have at stake the less they have to lose like in the last days before transition it it's very very likely that this attack can happen yeah so that's why in the long term we want to rely on something more um fundamental for preventing censorship such as for example time locked encryption where the users will be able to put uh their transactions uh in in some encrypted envelopes and submit them to validators to include in the block before the validators can learn what's inside cool yeah that makes total sense so maybe let's do

a walkthrough of how it works step by step because so far it's been pretty abstract so let's say i have i have an address with one ether on layer one how do i get it onto the zk sync layer too as with any layer 2 you will have to make a transaction on layer 1 to move this fonts from layer 1 to layer 2. alternatively you could just get the this if from someone who already has it in in layer two so for example if you're a normal user and you just want to move your fiat to layer two you will probably just go to an exchange and withdraw directly to zika sync from there we're currently

working on number indications the address that i have on layer 2 is exactly the one the same that i can also have on layer 1. so there's no confusion possible is that right in the case sync this is how we designed it so it was very important to us to keep a very very high degree of usability and yes you you have the same address in flair that sounds super nice because i mean as someone who builds decentralized projects uh and products i mean we have all seen um how often it happens that people send funds to the same address on a different network be it a test network or lay to uh absolutely so that's super nice um were there were there um technological

um challenges inherent to this i wanna also say that indeed many people do this many people would do transfers instead of withdrawals or deposits they just send funds to to the same like to the service and think for example we have a lot of users who would send funds inside the key sync to some address and expect it to appear on where one without knowing that they actually have to do withdrawal and sometimes they would send it to some address which cannot register in zk sync because it's a smart contract or it's just some exchange address and they the funds would get stuck there so we had to develop a special mechanism to

force the funds out for new addresses that have not been used yet which where the owner cannot control it in there too so we have a special mechanism just like withdraw automatically and it's fully trustless it's enforced by the protocol it's it's a part of the snark so it can always be done so you like you you never are in a risk of losing any funds like no matter what you do you know like unless you send it to address zero like any any normal mistakes are tolerated cool that that's uh super nice on the usability side um so now i have say slightly less than an ether on layer two how much how much

would it cost me in gas to actually transfer one ether from layer one to layer two it would cost you slightly more than a normal ether transfer okay that's that's not so bad and then um i i now have say slightly less than an ether on there too um how do i send it to someone else do i need a special wallet or can i do it from metamask or how do i go about it currently you need a special wallet what you can use is our web-based wallet which you you can control with metamask or any wallet connect enable wallet which will derive a signing key for the keysync and store it in your browser

memory and then you can use it to to send transactions although you will always have to co-sign this transaction by meta mask as well so we have a kind of two-factor protection we require the metamask signature which which is verified by our servers this is in version one in version two you will be able to just sign it with metamask directly we will support ethereum signatures natively in zika sector is it dangerous that uh part of the signature is uh stored in browser because that sounds like a bad idea well that that of course it's not a it's not ideal uh that would be the case if you use our web-based wallet

if you use any wallet that natively supports the key sync such as argent or hobby wallet or uh i am uh then of course you don't have this the the the situation you can just you you will use it the inside the wallet and the private key will never leave the wallet so when you're looking for a flight you go to a flight aggregator to see all the different places where you can buy the flight to get all the options and make sure you get the best price for your travel plans and when you're making a d5 swap just do the same and use paraswap it beats the market prices across all the major dexes because it aggregates them

and thanks to their network of professional market makers you get zero slippage on your trades so they just pushed a huge update that's even faster and more liquid thanks to a brand new algorithm pair swap is now multi-chain and has expanded polygon and binance smart chain so go and check it out give paraswap a try at paraswap.io epicenter we talked about moving eth into zk sync uh can you move tokens natively into zk sync or do you have to first move and then somehow like convert them there or how does that work you know you can natively deposit irresistibility tokens and uh we also natively support meta

transactions in inside the kissing so you don't need eth or anything or like zika token to send transactions you can deposit die and then pay your fees and die so the wallets that support zk sync they natively send the transactions to the sequencer then this is correct the sequencer this is currently one centralized party which i assume is somehow affiliated with you guys but will be sequentially decentralized yes this is correct is the sequencer the operator in a sense or is there a separate operator you you can call it the operator so it's it's a block producer it's someone who collects the transactions and just puts them in the block

okay but there's there are also validators right the validators are the general term for when you have a consensus uh driven by proof of stake this is what we we plan to have so then they will be called validators okay so basically currently the sequencer replaces the validators and who will then be the the block producers well the validators will act as a collective sequencer i would put it this way how how do i withdraw funds to layer one and what's what's the time scale for this because this is one of the the achilles heels of of optimism right so basically there because you have to you have the entire thing around pro

fraud proofs and so on and you actually have super long withdrawal periods this is true to withdraw from optimistic roll-ups you natively need one week which can be mitigated if you have liquidity providers who will borrow you some funds on player one but this is going to be expensive with ck roll ups in zika sync specifically what you do is you submit a transaction to the sequencer asking them to withdraw the funds for you uh on their one and they will include in the block and the moment the block is completed and verified on ethereum you will automatically get the funds on ethereum to the address which you wished so this is one way this is the normal way in this scenario your transaction could

be censored and then you can also go and you have a second option which is the priority queue i mentioned before where you make a transaction on layer 1 and you put a record on the queue which must be processed by the sequencer in within some some time frame let's say within one day or something and uh if they fail to do this then the system will enter emergency exit mode where you will be able to just proof ownership of your funds and withdraw them directly on their own this has never happened before i doubt this will ever happen uh because the the the validators or the the operator

never has an incentive to to send the users since they they know this threat is is valid and they will just like lose credibility but in normal circumstances you only have to wait for the block to to get filled and for the proof to be generated for this block and submitted to ethereum which with ziki sync one takes approximately four four hours right now like it it depends on the through on on the actual usage of the system like the more blocks we have the faster they get generated and you also have an option of fast exit if you need some funds immediately you can opt in into paying the

the block verification overhead yourself and then the block will be immediately closed and immediately submitted for verification and yeah you also have to wait for the proof to be generated for the stock to be generated which uh which is not long it only takes something like 20 minutes right now and it will be even lower with version 2 because we are building it in in a very parallel way recursively so it will go down to a few minutes so that means that blocks are the standard thing for block is to be full right but then the the block time can vary is that correct yeah so we expect the blocks to be full

so if you have let's say 1 000 transactions per uh in in 10 minutes then like and the block size is 1000 then your block completeness time will be 10 minutes i mean so basically then the sequencer submits this to to layer one and how do you then deal with re-aux because this is also often a problem with layer twos right so basically if layer one re-walks how do you make sure that and people have already cashed out based on i mean how does this work there is absolutely no problem with reorgs fundamentally because if a york happens then the cash outs will be reverted first

so they will will just be erased and never happen so what we how we combat reorgs is we require a um i think 10 blocks uh confirm 10 confirmations after the deposit to to appear in the kissing whenever you do a deposit we wait for 10 blocks before you see this this amount on your balance before like before the the the operator will actually process it and include in the next block so this way we can prevent the casual reworks which happen on ethereum with one or two blocks back because of fluctuations of uncles uh and this is only to prevent uh negative user

experience because if if the reorg happened on a deposit then we would have to roll back all the transactions that depend on this deposit and it can be a lot because they you send it to some people and then they send it to other people and it spreads but if a big reorg happens which would go back more than 10 blocks then we will just roll back the database to the point where the rework correspond where the the root hash of the database would correspond to the previous root hash recorded on the smart contract to the point of york and we would also try to reapply the transactions that were collected so if we work was non-essential

if it didn't actually modify a lot of balances and did not affect deposits then we will be able to reconstruct all the transactions in layer 2 natively and users will not notice anything if it affected deposits then some of these transactions will fail because there is not enough funds and then they will cause other transactions to fail potentially because users would send funds further but as i said uh it does not affect the zika roll-up in any way from the security perspective we just bound to ethereum for finality you mentioned a while ago that um it's possible for for someone to close the block by paying

the entire like the fee basically like does that introduce any denial of service attacks where one could just continuously just be like paying to close blocks before anybody can get transactions in is that something that is possible no no no it's more so for you to understand the cost structure of a zika rollup every transaction must include some fee to pay for the unchained part of this transaction plus additionally an amortized cost of approve so you can you could theoretically include a proof for every block even if the blocks are small even if blocks contain just one transaction but that would be super expensive that

would be a an anti-scaling solution because you would pay a lot more for a single transaction than than you would do on layer one so the more transactions you include in the block the the the more the the higher the denominator by which the proof cost is divided it's kind of like like going from flying commercial to flying private and saying i just can't wait the three hours for the next commercial plane to go from berlin to say moscow and i'll charge a a private plane uh but in this analogy it would be a rather like you you you wait so you have one passenger two passengers ten passengers uh

in this one big boeing which has a fixed cost of flying from from one place to another and and at some point you say like okay i don't want to wait for anyone else let's fly now i'm going to pay like the all the basic cost and you just close the gate and you fly immediately without waiting for other people and then you will just catch the next next flight because the next flight will be immediately available after the first one departs that sort of the scenario in which i was thinking is like couldn't someone who wanted to to censor the network or to do a denial of service attack just buy like every time there's a new block just like buy up the entire block you know if they had if have unlimited money no because all the transactions that

collected by the time uh he he does this will be just included in in this block so this person will be just subsidizing everyone at lower low latency so just to summarize this um so when i do a transaction on zk sync i pay a small fee that is associated with the overhead of my transaction being included and a part of the overhead cost of the zk sync proof of the verification of the verification cost of the proof that this is correct yes so the verification cost for snarks for plonk proof system which we use is currently around half a million guests on ethereum

but that means because you're still dependent on the gas price on layer one the fees on layer two will actually fluctuate with the fees on layer one right this is correct yes okay so you currently do you currently have a token or do you still plan on introducing one we don't have a talk now but we will require a token for multiple reasons one is decentralization of this sequencer to have multiple validators who decide what's going in in the blocks uh and the other very important reason is introduction of zk porter a uh off chain scaling solution which will augment zika roll up

it will serve as a is a is an extension of the law tell us about zk porter ziki porter is is a is an interesting idea where in zk sync 2.0 you will have two types of accounts zq roll up type of account which will act and cost the same as what you expect from zika roll up so you will have the ultimate security from ethereum uh and you will have to pay a like you you will get a linear scalability boost so you will always pay around 100 of the layer one costs but then you will have an optional ziki porter account type

which you can choose as a user and if you transact within zk porter with you you only interact with other zika portrait accounts you will pay very small uh fees uh that are independent from the gas price and ethereum because the data will not be published through the ethereum network the the states of those accounts will be only published to the so-called uh zk porter guardians who will keep the the data for you and they will confirm each block with the majority or super majority of the weighted stake to guarantee that this data is available

sorry what's the ck porter part has this new architecture i'm describing uh which is so we it's it's an alternative account type in the kissing 2. you have ziggy all up accounts and ziggy porter accounts and you can freely choose as a user between the two and if you if you opt for ziki porter you will have very very low fees uh and also decrease security you will not get the same security as with zikirola that's why we recommend we will encourage all the users uh to keep most of their funds most of their fortune in the geeky roll up accounts but for some some smaller spendings for microtransactions for trying out things maybe for high like frequent high frequency trading

uh you can use ziki porter accounts and as long as the total value locked in zk porter accounts is lower than the stake of zk porter it's actually economically secure it doesn't make sense for the validator to try to attack the system so is it kind of like a poa layer 3 on layer 2 it's more like a side chain so it's an extension of zika roll up into a side chain with a very interesting property from this side chain you can seamlessly inter-operate with any account in zika roll-up so you can have a single transaction that spans across multiple accounts

involving both zikr olaf and ziki porter accounts so for example what this means is you can have a lot of users who are who cannot afford to be on zika roll up because they curl up eventually ethereum gas prices will go up a lot because we'll have a lot more users a hundred times thousand times more users uh and it's inevitable that they will will go up even if we all use layer 2 solutions so some users will will just not be able to participate it's just gonna be too expensive for them so they can stay on ziki porter's side pay very low fees but still interact with uni swap compound balancer curve all the protocols d5 protocols on the zika rollup site

where all the whales are and all the the the other users everyone but they will still pay very small fees for that it's crazy that we're already anticipating a time in a world in which layer 2 solutions are also too expensive to use and so we need to move to you know other layers this is what we observed with ethereum the number of users over the past year rose approximately 12x 13x but the the gas prices rose a square of that so we can only it's only an issue to anticipate that the same thing will sooner rather than later happen to wear too because

the this is called induced demand once you have a lot more opportunities to trade and you and do nfts and do a lot of interesting things in there too more people will do it a lot more frequently and this will drive the prices up again so alex you kind of already alluded to this but this also means that zk sync is also smart contract compatible right yes cksync 2 will have not just smart contracts but full evm compatibility or like evm portability you will be able to take existing smart contracts that are live on layer 1 and easily port them to the keysync and just deploy

out of box most of them will just work so that means you redeploy essentially a smart contract that was deployed to ethereum uh does that does that imply any ability for users of say like an erc20 token that was deployed on one of these contracts to interoperate with can you move assets from one contract to the other are they what what kind of interesting dynamics that might exist between like those two layers uh absolutely sure so you you you will have our design of zk evm was to keep all the properties from ethereum including composability if you deploy multiple contracts they will be able to interact with each other just the same way it's currently possible in ethereum in

atomic transactions that can uh can all execute or or can revert partially like everything that will just look and feel exactly the same as an ethereum layer one okay so so you could have essentially like a transaction where you know for example like you're kind of building a complex transaction where you like mint die on a cdp and then you take that die and like i don't know trade it on uniswapper or something like you know you do some other action uh you could do some sort of like cross-layer transactions where you might die on the cdp and then that die gets sent uh immediately into say like an amm or a dex on um on zk roll up is that is that possible or is there like some extra

complexity there you mean like moving funds between layer one and layer two yeah like in sort of like a single in a single transaction so the you can never have layer one layer two interaction in the single transaction it's always asynchronous because the blocks are only committed to ethereum uh once in a while uh and anything can happen in between in those blocks so you will have an asynchronous calls between layer 1 and layer 2 both ways you can use you can send some message with some fonts from layer 1 to layer 2 and it will eventually appear there and and will interact with the contract and you can do it the other way around

or you can have atomic transactions within layer two that that that happen inside one single transaction uh but you you can you can extend that to where you want to learn okay so you can have atomic transactions just as you do on on layer one but there's no atomic transactions like between layer one and there too correct yes so what are the applications that you would say zk sync is particularly well suited to or do you think it's equally well suited to all applications i i personally think that most applications within a year will be on decay roll-up most of ethereum will migrate to z curl up i i i can't imagine

any alternative like i just don't see a plausible alternative to that because zika roll up offers uh superior properties to any other scaling solution so i i don't get wrong i'm i'm really excited about our skating solutions launching now it's really important that ethereum can scale today uh even if we have to take some some uh trade-offs into account but mid to long term zika rollups are just better in every possible regard i don't see any other any reason not to be on ezekiel so they are cheaper even if you just compare the the zika the role of transactions they're cheaper than let's say optimistic roll-ups because you you need to put less data on chain and you also

can have some super linear scaling if multiple accounts if the same accounts do multiple transactions in the same block which is for example the case if you if you do a lot of frequent oracle updates because the oracle updates only modify a single variable on the contract right so you can do it like multiple times and then at the end you will only have one single update of the state whereas an optimistic roll up you would have to post every single oracle update separately so they're cheaper on the roll up side they have the option of this super cheap side chain like zk porter still with much improved security compared to side chains

because the the validators the guardians of zika porter can never corrupt the state the only thing that can go wrong with the zika portrait is that the state is frozen which is unlikely because then how you're going to exploit this you can you would you would have to blackmail the user somehow it's complicated it's a lot more complicated than in the side chain where you can just grab uh all the assets and move them to different edits and you have really nice properties with user experience because the finality is fast you can withdraw funds instantly from from the roll up you can withdraw nfts instantly you don't for nfts there is no mitigation for for any fraud proof based system you will have to wait exactly one week

for your nft to to go from there to where one but even for fungible tokens if you want to move some small amount of funds then the interchange solutions some state payment channels will help you but if you want to move half of the of the value locked in some protocol that's probably going to be problematic it won't work as easily so all of these problems are sold to zika roll-ups so as soon as we can support fully vm compatibility and and it's have it's been proven and everyone sees that it works on layer one we expect most protocols to just go to ezekiel so what's the blocker with um the evm

compatibility because that's not live on mainnet yet right that's still on test net so that's that that's currently being built so we we just released our first test net with zkvm and there is no blocker anymore i can i can explain what was the blocker why it was only possible to build this here why it was not uh not considered before i gave a couple of talks on this so essentially the first generation of zika roll-ups were application specific they could only do some very limited fixed functionality for example transfers or or amm or dex but it was limited to one function which could be repeated

multiple times with smart contracts the challenge was that users want to define smart contracts themselves and each smart contract can be different in terms of code and in terms of the execution length of this code so execution trace can vary depending on the data you you provide as an input and depending on the function you call and what on what contract you call it and this was very hard to wrap in zero knowledge proofs like the zero knowledge proofs require the programs for which we can construct snarks and prove some computational statements to be con representable as arithmetic circuits

you can think of it as a as a like as a physical circuit you have some inputs and then it goes goes through some gates in like one one-way flow without uh without back loops and then at the end you get some results so the other way to think about it is a is a just a function a mathematical function f from x is equal to a plus b times c blah blah blah you know like some very complex expression but it's a single expression there is no way to encode loops in this expression there is no way to encode conditionals except for just like build two branches of this conditional statement separately

and then combine them uh conditionally like if we wanted to go to the left branch then take this result if we wanted to go to the to the right branch take this result but that that's some fixed structure which you cannot program so how you add programmability so that that was a big challenge there were multiple approaches that that allowed that one was called tinyram where you build a snark which does not prove any particular program but can prove any program by executing the op codes of this program at every execution step it's a bit hard to

explain in on the podcast without the visuals without going like making some pictures but you can imagine just like a mathematical function that executes every possible op code at every possible step just one big matrix n times m where one side is the number of op codes which you have in your virtual machine and the other dimension is the number of steps which you have to go to up to the very the maximum if you do it naively that would be very expensive that would give you a 1000x overhead over what is possible to prove in in snacks and snarks are already not cheap

you know like we in in our estimates the transactions on ziki sync 2.0 will cost something around one cent per transaction for most d5 protocols so one cent is okay but if you if you did like thousand x it would be hundred dollars for transaction which would be a no-go so we needed some way to optimize that and it came with recursion so i i i won't be able to explain it now why like what what what how recursion gives us the ability to combine multiple contracts together but i would just say that recursion is one of the necessary components and we just did not have efficient recursion on ethereum before last year the first implementation that was

live on testnet uh of a recursive snark was done by metalabs uh for the reddit skating challenge which we deployed last august and it's now live on zika sync 1.0 since january this year so it took time for for the solution to get mature and now with recursive uh proofs the rest is is like more an engineering effort now you can have all op codes that the evm also has plus the pre-compiled we don't have the same op codes as evm what we what we have is a separate virtual machine which is optimized for snarks

with this separate op code set which uh we take these solidity programs and we transcompile them uh into this new virtual machine in into the op codes for this new virtual machine would it have helped you if the bft signatures um had had already been shipped it would help us if we had support like we could have implemented recursion earlier maybe two years ago if we had support for different elliptic curves on ethereum but not bls not bls12 rather we would need something like b t curves which are much larger they have something like 700 bits length as opposed to 256 54

that we have for for bls and bm 256 curves which we currently use on ethereum but and we actually implemented a pre-compile for that it just never got accepted oh okay so one question that i've i've wanted to ask for a while now so we've talked about scalability for a long time now but basically as you said in the very beginning zero knowledge is obviously lends itself really well to privacy as well and this is how how almost everyone um initially approached this in 2017 when it kind of entered the scene so do you plan on using this for privacy as well because it seems like something that you you would probably be able to get quite cheaply you know

uh absolutely so you can actually get privacy out of box with with this kind of type of solution with easy hero ups because for the transactions uh that contain some snarks for privacy you don't have to publish the proofs on chain it's sufficient to have them as a witness or as input of the transaction which you just omit in the final block but you verify them in as a part of of your blocked proof so that means that you will be able to implement something like zcash protocol on top of zika sync and the transactions uh the shielded transactions in this protocol will cost almost the same as normal transfers just slightly more expensive

that's really cool so we don't intend to do it in matter labs but we because we want to remain a neutral platform where everyone can build stuff and we don't want to intervene and build our own applications but we we talk to a couple of projects who are who have interested who are intending to build privacy solutions on top of the keysync you just talked about matter labs uh just kind of circling back to that uh what's the what's the business model here with zk sync how do you intend to make money as a company with this uh so as a company we will there are multiple ways to approach this from the company perspective

so there will be token involved and there might be some ways to monetize the token there might be some services we will be building but in general zika sync is going to be decentralized protocol which is owned by the community not by any given company and the there will be of course a token which which can be used for staking to become a validator and to become the case in guardian we were talking about the token uh earlier when when would the token be launched uh we will have to launch it before zika or together with zika sing 2.0 because we will need it for the zk porter so just kind of zooming out a little bit i mean we did talk about this during the show to some extent and you know you

were pretty uh confident that uh most of the usage of ethereum would would move to um to zk sync that seems like an incredibly huge feat you know to move like all the ethereum applications and like all the liquidity and like all of the usage basically from you know the mainnet to a layer two and you know i'm sure that's like it's desirable right to have that extra transaction throughput and we're gonna need it and like i think like zk sync is one of many solutions that can offer that but what's necessary for that to happen because it seems like a very chicken and egg type problem i mean if we have congestion on the ethereum network today it's because most of the apps are being built there that's because most people are using it what is the uh the sort of blocks one event that

happens that makes it such that you know this uh flow of usage and and tokens uh start moving into um layer twos and specifically like into z guessing um so uh i i just want to correct and say that i believe that the most applications will be on the hero ups so maybe not necessarily on decay sync but i believe that the the very large part will be on zika sync because we're currently the only zika roll up with evm compatibility and from from what we learned from the market is a lot of projects strongly prefer to have the same code base across layer one and there two and this is why they will i i believe they they will most

likely launch in zika sync rather than other ezekiel but there might be um other projects who do not care about that and can can can work with different languages and maybe they will prefer other zika roll-ups but it will be all the hero ups that that's for sure there is no doubt about that long term it's it's only easy curl ups and why everyone will move from layer one uh it's very simple if the gas prices will just go up back to where they were at the worst stance and ether price will likely to go up so the transaction costs will be just enormous it it like it will just naturally push all the users from layer one to where to even the whales eventually what it will take

is first and foremost the lindiness of where two solutions so they must remain operational for a pretty long time for everyone to get confidence it's never enough to just publish something and say oh we audited it and and now you're you should just use the the solution is totally safe it's never the case it always have to stand the test of time and uh the things might happen there might be bugs there might be some some problematic situations we're planning for that uh we are actually just announced a an introduction of zika sync security council and the multi-factor approach to security and uh we like it works uh roughly as

we will have the validators who first validate their transactions natively and only if they they believe the transaction is valid then they will generate the zero-knowledge proofs for it so that not everyone can generate their knowledge proofs and and immediately submit them to ethereum and if something goes wrong we we will have some people who are trusted by the community to intervene and re shorten the upgrades uh upgrade time for uh for introducing some fixes because currently the zika sync upgraded zika sync is an upgradable protocol but we have a long notice period any

change has to be announced in advance for the community and only after a couple of weeks passed and everyone who didn't like it had a chance to opt out uh is the change enacted but like kind of coming back to the question um we believe that there must be some time for these protocols to mature and get trust once this happens we will see a great job migration it will be not like overnight but more and more liquidity and more and more users will move from layer one to where two until eventually it flippings layer one itself and like most activity happens on there too cool where can people go to find out more about

matter labs and zk sync and all the great research that you guys are doing zksync.io has a pretty comprehensive documentation but for the end users we have some faq which are very structured and for the developers uh with with code snippets with with getting started guides uh developer documentation everything great alex thanks for joining us today it's been a pleasure alex thank you guys and thank thanks to all the listeners thank you for joining us on this week's episode we release new episodes every week you can find and subscribe to the show on itunes spotify youtube soundcloud or wherever you listen to podcasts and if you have a google home

or alexa device you can tell it to listen to the latest episode of the epicenter podcast go to epicenter tv subscribe for a full list of places where you can watch and listen and while you're there be sure to sign up for the newsletter so you get new episodes in your inbox as they're released if you want to interact with us guests or other podcast listeners you can follow us on twitter and please leave us a review on itunes it helps people find the show and we're always happy to read them so thanks so much and we look forward to being back next week [Music]