Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Alex Gluchowski: zkSync – The First EVM-Compatible zkRollup Protocol

Episode Date: June 15, 2021

zkSync is a trustless protocol for scalable low-cost transactions on Ethereum. It's also the only zkRollup protocol which supports EVM smart contracts.Alex Gluchowski is co-founder of Matter Labs, and co-creator of zkSync. We spoke with Alex in depth about how the protocol works and the potential for a highly scalable transaction and application layer on Ethereum.Topics covered in this episode:Alex's background and how he got into the crypto spaceAn overview of existing Ethereum scaling solutionsDifference between Optimistic Rollup and zkRollupTransferring funds to the zkSync Layer 2 and gas fees involvedHow the zkSync transaction sequencer worksWithdrawing funds to Layer 1 and timescales involvedHow the procol deals with reorgsHow block formation works on zkSyncThe function of the zkSync tokenEpisode links:zkSyncFor DeveloperszkSync on TwitterAlex on TwitterSponsors:Solana: Solana is the high performance blockchain supporting over 50k transactions per second to power the next generation of decentralized applications. - https://solana.com/epicenterExodus: Exodus the easy-to-use crypto wallet available on all platforms and supporting over 100 different assets. - https://exodus.com/epicenterParaSwap: ParaSwap’s state-of-the-art algorithm beats the market price across all major DEXs and brings you the most optimized swaps with the best prices, and lowest slippage - http://paraswap.io/epicenter This episode is hosted by Friederike Ernst & Sebastien Couture. Show notes and listening options: epicenter.tv/396

This is Epicenter, episode 396 with guest, Alex Klukowski. Hi, welcome to Epicenter, the podcast where we're using for crypto founders, builders, and thought leaders. I'm Sebassiankutio and I'm here with Frike Ernsd. Today, we're speaking with Alex Klukowski. He's the co-founder of Matterlabs 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, 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 1% 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 Solana.com slash epicenter to learn more. We're also sponsored by Exodus. It's an easy-to-use wallet that supports hundreds of assets and 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 Binan Smart Chain. Start trading at Paraswap.io slash epicenter. Alex, hi, thanks for joining us today. Hello, very excited to be here. Thank you, guys. So tell us a bit of your background and how you became involved in the crypto space. Well, I studied computer science in Berlin, and I worked as a team lead and software engineer and CEO in multiple companies, starting with telecommunication space.

And then I moved into startups, was co-founder of two startups in Berlin. and at some point I just felt that crypto is going vertical and it's just like I can't wait anymore I have to jump there because my heart is 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 it really appealed to me as a kind of libertarian person and it was a very exciting technological

thing also from like the beauty of 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 switched only once Ethereum material. I actually, I tried to build a startup in the Bitcoin space, but I felt it was too early. What was the startup? We were trying to do something reputation-based, like,

sovereign reputation thing. I was doing it with Art of Bendican, who is now a CEO at Aurora. But yeah, we couldn't find investors, and we thought like it's maybe a bit too early. So I went back to the classical startups. And the startups you worked on before crypto, they're actually pretty interesting as well.

So maybe let's give those like a minute of airtime. So the ones that I found, one of them was acquired by urban sports, Club and the other one was a Kemper rental startup. Tell us what drew you to these subjects because they're quite, 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, it was essentially a copy of Class Pass, an American startup, where you could purchase a monthly pass to all sports and holistic activities in your city, which I found very appealing, because like this idea of flat rate, it feels like like communism 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. So it felt the same way, but it was not very technological. So then with Paul Camper, the Camper sharing platform, that was very appealing to me because we could build something really interesting with sophisticated search engine and

optimization for this campus in the booking system. And there was a lot of accounting involved. Paul Camper was the company. I'm really, really proud of the team we could build. It was remote first. the IT team, the business team was based in Berlin, but the IT team was completely remote from day one. And it's highly successful. It's the largest camper sharing platform in Europe right now. Paul Kemper is present in Germany, UK, 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'm maxed out. I have done as a CTO, I've done everything I could do there, and the rest does not depend on me. The process and the tech team were working fine, and there were not so many challenges to solve, whereas in the crypto world, Ethereum started to get traction. And actually, when I was in so much more Antpull camper, I tried to integrate Bitcoin. I had this idea of making Bitcoin payments to be accepted. And then I realized I can't justify that. It just didn't make sense.

because there were 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 just doesn't make sense. But with Ethereum, it was entirely different. All of a sudden, this idea of smart contracts, and open financial system and an alternative financial system with stable coins with all sorts of interesting things with potential for improved usability was there

and I figured like I can't 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 to all the different conferences and meeting people and talking and making research and

trying to figure out what are the problems. The crypto space is facing Ethereum space specifically. And I came to conclusion that there are a couple of things that once sold will bring Ethereum to masses and everyone is just going to jump on it. And the problems that had to be solved were the user experience in combination with security. It's kind of like the size of the same coin and scalability. And while the security in UX were kind of clear how to fix. Like we could just apply principles from the Web 2 world, everything we knew from traditional startups, from mobile apps.

It was clear what to do, and they were actually built. We got Metamask, we got Argent, we got Dharma, we got all these wallets with social recovery, with the ease of not having to care about your secret phrases, like Zango and wallets based on some combination of secret sharing and using your email as login and so on. And all the other things were also being built from traditional finance, which we now know is TFI. But scalability really caught my eye because it was very technological. It felt like a fundamental problem which cannot be easily solved 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 just can solve them in, you know, like just tinkering around. So we need something more solid. And then I learned about zero knowledge proofs.

First about the zero knowledge aspect of zero knowledge proofs, so that you can use them for privacy. And later, 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 naively. And my first thought was, when I heard about that, oh, you can apply that to plasma and make plasma a lot, like solve a lot of problems in plasma for that. And if you do that, that's actually like half a roll-up. So like applying zero-knowledge proofs to plasma, gives you the leadium. And then if you put the data on chain, this is the Ziki roll-up.

And I met Barry White Hat who was working, who built the first working group, working on Zika roll-ups. And we met some other guys. We had discussions. Then we, we, we built. published this famous blog post on E3 Research, about Zika Roll-ups. And then I met my co-founder, Alex Flassov, at DefCon in Prague. I think it was Def-Con 4 or 3. He was coming to the same idea from a different angle. He was actually working on plasma.

He was building a plasma implementation. And he learned about zero knowledge proofs. And he was very deep into cryptography, having a PhD in high-energy physics from McGill University in Canada. he was really good. I immediately realized that this guy is genius and we should do something together. And we immediately jumped into discussion

of how things should be built technologically. We built a first prototype presented it. And this is how Ziki Sinket 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 sharded blockchain. It's a single blockchain hyper optimized for performance. So that makes it really easy to maintain compostability 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 slash Epicenter to learn more.

We've done a number of episodes on the topic of scalability and a few episodes where we've talked specifically about ZK. Roll-ups. but let's maybe get a little refresh. How does a ZK roll-up work in a nutshell? What are the main components and what does it try to achieve? So ZK roll-up is a scaling solution that works on top of layer one. So it's a layer two scaling solution,

which is supposed to derive its security 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 plasma, Imagine that you have a single contract on layer one that instead of holding all the balances of the users only holds all the funds together in a single pot. And it holds a root hash of a state which is held off-chain, which contains all the balances. So we only keep one hash.

So this hash being a Merkel route serves as a cryptographic fingerprint of our state. whenever we change something in the state, the root hash will change completely. Now, we want this users to transact. We want these users to send funds to each other, which will modify the state. So whenever we have multiple transactions, maybe a block of like, let's say, 1,000 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 made only one small transaction on layer one, but we enacted many transfers, thousands of transfers, thousands of transactions which happened in layer two. So 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 submit the new route hash and if something goes wrong and this new route hash contains invalid transactions or

some invalid state, you would have to somehow prevent this new route hash from being finalized on layer one. And this is difficult. So with plasma and ZK roll-ups rely on so-called fraud proofs where someone has to monitor it and then provide a proof that the new state is not valid, With Zika roll-ups, we do something very elegant. We provide a zero-knowledge-proof, or like 16-0-know-proof or SNARC, of validity of all the transactions that happened that produced this new root hash.

And the SNARC 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 SNARC is valid, then we change the new route hash on the smart contract. And this way we can guarantee that no invalid transaction is ever included in our rollout block. So just to recap, there's a phrase this differently. In an optimistic roll-up, you have a verification of the different hashes in the Merkel tree and the root hash that has to be verified by some third-party process.

And one of the ways that we've come to do that is to have this front. proof system, but that introduces a whole bunch of complexities. Whereas with a ZK roll-up, you simply have a snark that proves that all of the state in the, all the transactions in the state that's sent to the smart contract is indeed valid. This is correct, yes. So this way we can only prove the validity. However, we also have a problem of data availability. So we need to make sure that everyone knows what the new state is, what the new state is completely. Not. only the root hash. And with roll-ups, what we do is we publish some data on chain that makes everyone 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 multiple ways. You can either publish the inputs of all the transactions. You can do it with Ziki 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 changed in the state? The final state of every account which was touched in this block.

And this is only possible with ZK roll-up. And this is very interesting because it introduces additional succinctness. If you have, 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 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 blog. This place is a flaw at how much a transaction can be reduced by, right?

So basically, if you have an operator and use a, say, optimistic roll-up, you can compress the data much more. Is that correct? Because you don't need to submit it on-chain such that someone can reconstruct the entire thing? So yeah, there are multiple factors that make ZKRO-O-ups cheaper in terms of on-chain data. 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 the Ethereum network, right? So the difference from just putting this data in, 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 the most expensive thing because 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 have to do it sequentially. You have to read one thing, then you have to read the other thing. Because you're working on a global state, right? So that's why you have to do it sequentially. Because you're working on the global state

and you work with Merkel proofs. So you have to retrieve Merkel path for all the accounts. And when you modify them, you have to actually go and modify all the intermediate nodes on the Merkel tree. And this is where you get these delays because this latency is just add up. So what we do with Zikyrily 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 Ziki roll-up. With optimistic roll-up,

you can get the kind of the same scalability factor if you optimize the optimistic roll-up really strongly. What you would need to do is you would have to aggregate the signatures because you still have to publish the signatures through this network in the roll-up, which you don't have to do in a Ziki roll-up because the signatures are verified by the start. And also you would have, there are some other nuances in optimistic roll-ups. say the most compressed version would only work with multi-round fraud proofs, something like arbitram.

And it would be much harder to build with a single round fraud proofs, which optimism is using. But in any case, you only get a linear scalability boost. Let's get to our sponsor, Exodus. Exodus is a fantastic cryptocurrency wallet that strikes a 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 their iOS app and pay just $1 in fee. So go to exodus.com slash Epicenter and check out their wallet.

We want to thank Exodus for their amazing support of Ebcenter. So let's talk about the aggregated block of transaction data. So who actually aggregates that? And basically, if I want a transaction 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 a block and computing the new root hash of this block.

The sequencer can be centralized, 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 peer-to-peer network, and they're just agreeing on what the new block is going to be, and then selecting the leader who will submit it to Ethereum, or maybe anyone from this validators can submit it to Ethereum. With all the roll-ups right now, as far as Zamm aware, everyone is currently using centralized

sequencers, because with roll-ups, you do not rely on the sequence. for security. But they could censor me, right? They could censor you, but only in L2. They cannot censor you in L1. So if you feel censored, you can always go to layer one and retrieve your funds through some additional mechanisms. In our case, it's called Priority Q.

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 are being censored by operators, by the operator by the sequencer in L2, yeah, you're just not going to use this service. It's not as bad. What are the tradeoffs of having a centralized service and perhaps a decentralized service to ensure, like, censorship-resistant aspect? It just allowed us to launch the ZKSync earlier.

And with Zika Sync will follow the philosophy of progressive decentralization. We start with the minimum viable product, which is decentralized, which does not rely on us or anyone for security. So we derive security directly from Ethereum. And it's just much faster to build and to have a full-fledged consensus, which we are building, and this is very important to ZKSing. We don't want ZKSing to rely on any... single party long term or even midterm.

We wanted to be decentralized protocol governed by the community and having multiple value differences that are selected by the community so that we also don't have 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 in Ethereum with multiple miners, there is still a chance. that they will collude. It's not impossible that miners or validators will collude

and 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 roll-up. This has been a controversial topic.

Like, obviously, I am a Ziki roll-up maximalist, and you can say I'm biased because of that. And we had some clashes with people from optimistic roll-up 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 for the ultimate censorship resistance. But I disagree that you can, like, you should not be building protocols that rely on such weak assumptions. This also might be vetted for the time once we transition to proof of stake,

and maybe there will be some clearly written rules, how the community should behave, and we get some signaling from everyone in the community that they're actually going to follow these rules. and we have clear mechanisms how such situation can be cleared up without incurring a lot of masks. Imagine if that happens, and we have a lot of defy transactions going on

that are all intertwined. You put something into uniswap, and then other people put stuff in, and the price moves, and some other oracles rely on this price and so on and so on. 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 would only work once we have proof of stake. With proof of work, there is no mitigation. If the proof of work miners decide to attack an optimistic roll-up, they can do it. This is very real. And they can collude, they can be bribed, there might be some automated bribery mechanisms through some smart contracts that distribute the rewards from this attack. And actually, the closer we come to the moment of transition through proof of work to proof of stake, the less proof of work miners have at stake,

the less they have to lose. In the last days before transition, it's very, very likely that's that can happen. That's why in the long term, we want to rely on something more fundamental for preventing censorship, such

as, for example, time-locked encryption, where the users will be able to put their transactions 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 an address with one ether on layer one. How do I get it onto the ZK sync layer two? As with any layer two, you will have to make a transaction. on layer one to move this funds from layer one to layer two. Alternatively, you could just get this if from someone who already has it 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 Zikisink from there.

We're currently working on down communications. The address that I have on layer 2 is exactly the same that I can also have on layer 1. So there's no confusion possible. Is that right? In ZKSync, 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 have the same address in Lair 2. That sounds super nice because, I mean, as someone who builds decentralized projects and products,

I mean, we have all seen how often it happens that people send funds to the same address on a different network, be it a test network or layer two. Absolutely. So that's super nice. Where there technological challenges inherent to this? I want to also say that indeed, many people do this. Many people would do transfers instead of withdrawals or deposits. they just send funds to the same, like to this address and think, for example, we have a lot of users who would send funds inside ZKSync to some address and expect it to appear on layer one

without knowing that they actually have to do withdrawal. And sometimes they would send it to some address which cannot register in ZKSink because it's a smart contract or it's just some exchange address and 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, where the owner cannot control it in there to. We have a special mechanism just withdraw automatically, and it's fully trustless.

It's enforced by the protocol. It's a part of the SNARC. So it can always be done. So you never are in a risk of losing any funds. No matter what you do, unless you send it to address zero, like any normal mistakes are tolerated. Cool. That's super nice on the usability side.

So now I have, say, slightly less than an ether on layer two. How much would it cost me in gas to actually transfer one ether from layer one to layer two? It would cost us slightly more than a normal ether transfer. Okay. That's not so bad. And then I now have, say, slightly less than an ether on layer two. 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 can control with MetaMask or any wallet-connect-enable wallet, which will derive a signing key for ZCCCC and store it in your browser memory, and then you can use it to send transactions. Although you will always have to co-sign this transaction by Metamask as well.

So we have a two-factor protection. We require the Metamask signature, 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 ZKSink2. Is it dangerous that part of the... the signatures stored in browser, because that sounds like a bad idea? Well, of course, it's not ideal.

That would be the case if you use our web-based wallet. If you use any wallet that natively supports Ziki Sync, such as Argent or Whoopi wallet or I am token, then, of course, you don't have this situation. You can just pick, you will use it inside the wallet. 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 defy swap, just do the same and use pariswap. 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, more liquid thanks to a brand new algorithm. Paraswap is now multi-chain and has expanded a polygon and Binance smart chain. So go and check it out. Give Paraswop a try at pariswop.io slash epicenter. We talked about moving ETH into ZK Sync. Can you move tokens natively into ZKSink or do you have

to first move ETH and then somehow like convert them there or how to Does that work? No, you can natively deposit your Cipended tokens. And we also natively support meta transactions inside ZKSink. So you don't need ETH or anything or like ZKSink token to send transactions. You can deposit die and then pay your fees and die. So the wallet said support ZKSink, 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 can call it the operator. It's a block producer.

It's someone who collects the transactions and just puts them in the blog. Okay. But there are also validators, right? The validators are the general term for when you have a consensus driven by proof of stake. This is what we plan to have. Then they will be called validators. Okay. So basically, currently the sequencer

replaces the validators and who will then be the block producers. Well, the validators will act as a collective sequencer, I would put it this way. How do I withdraw funds to layer one? And what's the timescale for this? Because this is one

of the Achilles seals of optimism, right? So basically there, because you have to, you have the entire thing around fraud proofs and so on, 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 layer one, but this is going to be expensive. With ZK roll-ups, in ZKSync specifically, what you do is you submit a transaction to the sequencer, asking them to withdraw the funds for you on their one. And they will include in

the block, at 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 a 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 one. and you put a record on the queue, which must be processed by the sequencer within some time frame, let's say within one day or something. And if they fail to do this,

then the system will enter emergency exit mode where you will be able to just prove ownership of your funds and withdraw them very clearly on their one. This has never happened before I doubt this will ever happen because the validators or the operator never has an incentive to censor users, since they know this threat is valid and they will just lose credibility. But in normal circumstances, you only have to wait for the block to get filled and for the proof to be generated for this block and submitted to Ethereum,

which with Zikisink 1 takes approximately four hours right now. It depends on the actual usage of the system. 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 to paying 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 start to be generated, 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 a very parallel way recursively. So it will go down to a few minutes. So that means that blocks are, the standard thing for a block is to be full, right? but then the block time can vary. Is that correct?

Yes. We expect the blocks to be full. So if you have, let's say, 1,000 transactions per in 10 minutes, and the block size is 1,000, then your block completeness time will be 10 minutes. I mean, so basically then the sequencer submits this to layer one. And how do you then deal with reorgs?

because this is also often a problem with layer 2s, right? So basically if layer 1 reorgs, 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 reorg happens, then the cash outs will be reverted first, so they will just be erased and never happen. So how we combat reorgs is we require a, I think 10 blocks, 10 confirmations after the deposit to appear in ZK Sync.

Whenever you do a deposit, we wait for 10 blocks before you see this amount on your balance. Before the operator will actually process it and include the next block. So this way we can prevent the casual reorcs, which happen on Ethereum with one or two blocks back because of fluctuations of uncles. And this is only to prevent negative user experience, because 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 you send it to some people, and then they send it to further 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 reorg correspond, where the root hash of the database would correspond to the previous root hash recorded on the smart contract to the point of reorg.

And we would also try to reapply the transactions that were collected. So if reorg 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 two native. 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, 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 it's possible for someone to close the block by paying the entire like the fee basically like it 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 ziki roll-up every transaction must include some fee to pay for the on-chain part of this transaction plus additionally an amortized cost of a proof. So 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 an anti-scaling solution, because you would pay a lot more for a single transaction than you would do on layer one. So the more transactions you include

in the block, the more the higher is a denominator by which the proof cost is divided. It's kind of 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 chart a private plane.

But in this analogy, it would be a rather like you wait. So you have one passenger, two passengers, 10 passengers in this one big Boeing, which has a fixed cost of flying from one place to another. And at some point you say, okay, I don't want to wait for anyone else. Let's fly now. I'm going to pay all the basic cost. And you just close the gate and you fly immediately

without waiting for other people. And they will just catch the next flight. Because the next flight will be immediately available after the first one departs. That's the scenario in which I was thinking is like couldn't someone who wanted to censor the network or to do a denial of service attack, just buy, like, every time there's a new block,

just buy up the entire block. You know, if they had unlimited money. No, because all the transactions that collected by the time he does this, will be just included in this block. So this person will be just subsidizing everyone at low latency. So just to summarize this, 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. This is correct, yes. So the verification costs for Snarks for Planck proof system, which we use is currently around half a million gas 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 NAO1, right? This is correct, yes.

Okay. So do you currently have a token or do you still plan on introducing one? We don't have a token now, but we will require a token for multiple reasons. One is decentralization of the sequencer to have multiple validators who decide on what's going in the blocks. and the other very important reason is introduction of ZK Porter, a off-chain scaling solution which will augment Ziki Roll-Up. It will serve as an extension of ZK.

Tell us about ZK Porter. Ziki Porter is an interesting idea where in ZKSync 2.0, you will have two types of accounts. ZK. roll-up type of account, which will act and cost the same as what you expect from Ziki roll-up. So you will have the ultimate security from Ethereum, and you will have to pay a, like, you will get a linear scalability boost, so you will always pay around 100th of the layer 1 costs. But then you will have an optional ZK Porter account type, which you can choose as a user.

and if you transact within Zika Porter, you only interact with other Ziki Porter accounts, you will pay very small fees that are independent from the gas price on Ethereum because the data will not be published through the Ethereum network. The states of those accounts will be only published to the so-called ZK. Porter Guardians

who will keep the data for you and they will confirm each block with the majority or super majority of their weighted stake to guarantee that the state is available. Sorry, what's the ZK Porter? Ziki Porter is this new architecture I'm describing, which is, so it's an alternative account type in ZKysink 2. You have Ziki Roll-Up accounts and Ziki Porter accounts,

and you can freely choose as a user between the two. And if you opt for Ziki Porter, you will have very, very low fees and also decrease security. You will not get the same security as with Zicke Rolla. That's why we recommend. We encourage all the users to keep most of their funds, most of their fortune in the Zicke Roll-Roll-up accounts. But for some smaller spending for microtransactions, for try-in-out things, maybe for high-frequency trading, you can use Ziki-Porter accounts. And as long as the total value locked in Ziki Porter accounts is lower than the stake of Ziki 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 P.O.A, layer three, on layer two? It's more like a side chain. So it's an extension of Ziki roll-up into a side chain with a very interesting property. From this side chain, you can seamlessly interoperate with any account in the Ziki roll-up. So you can have a single transaction that spans across multiple accounts involving both ZK. Rol-Up and ZK. Porter accounts. So for example, what this means is you can have a lot of users who cannot afford to be on ZK.

Roll-up, because ZK. Roll-up, eventually, Ethereum gas prices will go up a lot because we'll have a lot more users. 100 times, 1,000 times more users. It's inevitable that they will go up, even if we all use layer two solutions. So some users will just not be able to participate. It's just going to be too expensive for them. They can stay on Ziki Porter's side, pay very low fees, but still interact with uniswap,

compound, balancer, curve, all the protocols, defy protocols on the Ziki roll-up site, where all the whales are and all 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 two solutions are also too expensive to use and so we need to move to, you know, other layers. This is what we observe with Ethereum. The number of users over the past year rose approximately 12x, 13x, but the gas prices arose square of them.

that. So we can only, it's only nature of anticipate that the same thing will sooner rather than later happen to where it too, because 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. this, but this also means that ZKSync is also smart contract compatible, right? Yes, a CKSink 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 ZKSink 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. Does that imply any ability for users of, say, like an ERC20 token that was deployed on one of these contracts to interoperate? Can you move assets from one contract to the other? What kind of interesting dynamics that might exist between those two layers? Absolutely. Sure.

So 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 all execute or can revert partially, like everything that will just look and feel exactly the same as an Ethereum layer one.

Okay. So you could have essentially like a transaction where, you know, for example, you were kind of building a complex transaction where you like mint dye on a CDP, and then you take that dye and like, I don't know, trade it on un-swap or something. Like, you know, you do some other action. You could do some sort of like cross-layer transactions where you mint dye on the CDP

and then that die gets sent immediately into, say, like, an AMM or a dex on ZK Relup. 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 transaction. So you can never have layer one, layer two interaction in a single transaction. It's always asynchronous because the blocks are only committed to Ethereum once in a while. And anything can happen in between in those blocks.

So you will have an asynchronous cause between layer one or layer two both ways. You can send some message with some funds from layer one to layer two and it will eventually appear there 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 happen inside one single transaction. But you can extend that to layer one to layer two. Okay.

So you can have atomic transactions just as you do on layer one, but there's no atomic transactions between layer one and there two. 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 personally think that most applications within a year will be on ZK roll-up. Most of Ethereum will migrate to ZKroll-up. I can't imagine any alternative.

I just don't see a plausible alternative to that because ZK. roll-up offers superior properties to any other scaling solution. So don't get wrong, I'm really excited about other scaling solutions launching now. It's really important that Ethereum can scale today, even if we have to take some trade-offs into account, but meet-to-long-term Zika roll-ups are just better in every possible regard. I don't see any other, any reason not to be on the Zika roll-up. So they are cheaper, even if you just compare the Zika roll-ups. the roll-up transactions.

They are cheaper than, let's say, optimistic roll-ups because you need to put less data on chain and you also can have some super-linear scaling if the same accounts do multiple transactions in the same block, which is, for example, the case if you do a lot of frequent Oracle updates. Because the Oracle updates only modify a single variable on the contract.

So you can do it multiple times, and then at the end you will only have one single update of the state. Whereas an optimist to crawl-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 Ziki Porter, still with much improved security compared to side chains, because the validators, the guardians of Ziki Porter, can never corrupt the state. The only thing that can go wrong with the Zicke Porter is that the state is frozen. which is unlikely because then how you're going to exploit this?

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 all the assets and move them to different items. And you have really nice properties with user experience because the finality is fast. You can withdraw funds instantly from the ROAP.

You can withdraw NFTs instantly. For NFTs, there is no mitigation for any fraud proofs. based system, you will have to wait exactly one week for your NFT to go from layer to layer 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 value locked in some protocol, that's probably going to be problematic. It won't work as easily. So all of these problems are sort of.

to Ziki Roll-ups. So as soon as we can support fully VM compatibility and it's been proven and everyone sees that it works on layer one, we expect most protocols to just go to ZiceroL-Up. So what's the blocker with the EVM compatibility? Because that's not live on mainnet yet, right? That's still on test net? So that's currently being built. So we just released our first test net with Zikavim. and there is no blocker anymore. I can explain what was the blocker why it was only possible to build this year, why it was not considered before.

I gave a couple of talks on this. So essentially, the first generation of ZHROPs were application-specific. They could only do some very limited fixed functionality, for example, transfers or AMM or DECS, 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 provide as an input and depending on the function you call and on what contract you call it. and this was very hard to wrap in zero knowledge proofs. Zero knowledge proofs require the programs for which we can construct SMARCs and prove some computational statements to be representable as arithmetic circuits. You can think of it as a physical circuit.

You have some inputs and then it goes through some gates. in like one one wave flow without back loops. And then at the end you get some results. So the other way to think about it is a just a function, a mathematical function. F from X is equal to A plus B times C, blah, 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 conditionally. Like if we wanted to go to the left branch, then take this result. If we wanted to go to the right branch, take this result. But that's some fixed structure which you cannot program. So how you add programmability.

So that was a big challenge. There were multiple approaches that allowed that. one was called Tiny Ram 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 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. There's just one big matrix, n times m, where one side is the number of opcodes,

which you have in your virtual machine, and the other dimension is the number of steps, which you have to go up to the maximum. If you do it naively, that would be very expensive. That would give you 1,000x overhead, over what is possible to prove in Snags, and Snacks are already not cheap. You know, like in our estimates, the transactions on Ziki Sync 2.0

will cost something around one cent per transaction for most TFI protocols. So one cent is okay, but if you did like 1,000 X, it would be $100 for transaction, which would be a no-go. So we needed some way to optimize that, and it came with recursion.

So I won't be able to explain it now, Now, 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 the TestNet of a recursive SNARC was done by Matterlaps for the Redid Skating Challenge, which we deployed last August. and it's now live on Zikisink 1.0 since January this year.

So it took time for the solution to get matured. And now with recursive proofs, the rest is like more an engineering effort. Now we can have all upcodes that the EVM also has plus the pre-compiles? We don't have the same opcodes as EVM. What we have is a separate virtual machine, which is optimized for SNARKS with this separate op-code set, which we take the solidity programs and we transcompile them into this new virtual machine, into the op-codes for this new virtual machine.

Would it have helped you if the BFT signatures 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. if we had support for different elliptic curves on Ethereum, but not BLS 12. 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 BLS and BN 256 curves, which we currently use on Ethereum. And we actually implemented a pre-compile for the.

that, you just never got to accept it. Oh, okay. So one question that 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 almost everyone 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 would be. probably be able to get quite cheaply, no? Absolutely.

So you can actually get privacy out of box with this kind of type of solution, with Ziceroops, because for the transactions 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 as a part of your block proof. So that means that you will be able to implement something like Zcash protocol on top of ZKSync and 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 Matterlabs, 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 talk to a couple of projects who are who are intending to build privacy solutions on top of

ZKSink. You just talked about Matterlabs, just kind of circling back to that. What's the business model here with ZKSink? How do you intend to make money as a company with this? So as a company, 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, ZK Sync is going to be a decentralized protocol, which is owned by the community, not by any given company. And there will be, of course, a token which can be used for staking to become a validator and to become ZKSing Guardian. We were talking about the token earlier.

When would the token be launched? We will have to launch it before ZK or together with ZK Sync 2.0 because we will need it for the ZKPorter. So just kind of zooming out a little bit. I mean, we did talk about this during the show to some extent. And you were pretty confident that most of the usage of Ethereum would move to ZK Sync. That seems like an incredibly huge feat, you know, to move like all of the Ethereum applications and like all of the liquidity and like all of the usage basically from. the main net to a layer two. And I'm sure that's like, it's desirable, right, to have that extra transaction throughput

and we're going to 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 sort of black swan event that happens that makes it such that, you know,

this flow of usage and tokens start moving into layer 2s and specifically into Zika sync. So I just want to correct and say that I believe that the most applications will be on ZKROL-ups. So maybe not necessarily on ZK Sync, but I believe that the very large part will be on ZKSync because we're currently the only ZKRLAP with EVM compatibility. and from what we learned from the market is a lot of projects strongly prefer to have the same code base across layer one and layer two. And this is why they will, I believe they will most like to launch in Ziki Sync rather than other Ziki Rolops. But there might be other projects who do not care about that and can work with different languages. Maybe they will prefer other Ziki Rolups, but it will be all Ziki Rolups.

that's for sure. There is no doubt about that. Long term, it's only Zikao Labs. And why everyone will move from layer one, it's very simple. 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 will just naturally push all the users from layer one to layer two. Even the whales, eventually, what it will take is first and foremost, the lindiness of layer 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 now you should just use the solution.

The solution is sort of the safe. It's never the case. It always has to stand the test of time. And things might happen. There might be bugs. there might be some problematic situations. We're planning for that. We are actually just announced an introduction of Zika Singh Security Council

and a multi-factor approach to security. And it works roughly as we will have the validators who first validate their transactions naively. And only if they believe the transaction is valid, then they will generate zero knowledge. proofs for it so that not everyone can generate zero knowledge proofs and immediately submit them to Ethereum. And if something goes wrong, we will have some people who are trusted by the community to intervene and shorten the upgrade time for introducing some fixes. Because currently

the ZKSync upgrade, ZKSync 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 is the change enacted. But coming back to the question, we believe that there must be some time

for this protocols to mature and get trust. Once this happens, we will see gradual migration. It will be not overnight, but more and more liquidity and more and more users will move from layer one to layer two until eventually it flippens layer one itself and most activity happens on there too. Cool. Where can people go to find out more about Matterlabs and ZKSink 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. with code snippets, with getting started guides, developer documentation, everything. Great. Alex, thanks for joining us today. It's been a pleasure, Alex. Thank you guys, and 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 slash 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.