This is Epicenter episode 507 with guest Alex Glucovsky. Welcome to Epicenter, the show which talks about the technologies, projects, and people driving decentralization
and the blockchain revolution. I'm Brian Crane and I'm here with Federica Ernst and today we're gonna speak of Alex Lukrovsky. He is the Co founder and CEO of Matter Labs. And Matter Labs is the company that's building ZK Sync, which is one of the most exciting and sort of largest ZK roll up technologies that's looking to scale Ethereum by kind of maintaining all the theorems, trust, assumptions and bring freedom to people all over the
world. So thanks so much for joining us, Alex. It's my pleasure. Thank you for having me. So we had your own like three years ago and a lot has happened since then, including the ZK space having gotten lots of traction, lots of interest. It's still an area that's, you know, hard for a lot of people to sort of understand and wrap their head around, even people
working crypto. So I thought maybe we can start with just a very brief recap of what are ZK rollups and why is ZK such a great technology to scale blockchains? Absolutely. Let me try it so with blockchains. You know, like the we really observe the revolution the the cost. Starting with Bitcoin and the theory I'm taking it to the next level smart contacts and all the programmability of money,
interactions value. Like really this is to me, it's the continuation of the Internet revolution but it's a quantum lip. It's a jump from Web 2.0 to web 3.0, like adding value to the Internet on transaction level. The problem is that the very same properties that make things like the coordinate theory and decentralized blockchains valuable, they also lead to the difficulties in making it
available to all of people. There are some key things, in my opinion, that we can distill this value to. Among them are trustlessness, permissionlessness, openness and full absolute inclusivity of this networks. And to achieve that in the blockchain world from the early days, we embraced the maxima of don't trust, verify. So essentially everyone has to verify all the transactions, all of the activity that's happening on chain.
And you can think of blockchains as the social economic systems, but in the essence, what's happening under the hood, those are just computing systems. So Ethereum is really Ethereum started with the narrative of being the world computer. And it's what the theory really is, if you look at it from the
computer science. So that means everyone has to redo all of the computations for everyone else, which leads to quadratic complexity of communication, storage, computational requirements, and it's just infeasible to bring it to the work when you are scaling the Internet and adding a value layer onto the Internet. You can't rerun the computation of all the other servers of all the other, like redo everything
that everyone else is doing. So like this is a fundamental limitation which people have tried to solve with different tradeoffs, always leaving some parts of this value proposition severely damaged. Like either you give up decentralization, or you give up security, or you give up some other important properties. And it was not until zero knowledge proves fear that we found a fundamental solution to this. So we came up earlier.
The community came up with some really ingenious ways to make these trade-offs in a limited way. We we experimented with things like state channels, payment channels, plasma which then transitioned into like optimistic roll ups. All those things were important steps on this journey. But the ultimate destination is 0 Knowledge Proofs to explain why Zero knowledge Proofs are specifically like more more precisely succinct 0 knowledge
proofs or Snarks are in fact. They would be better called proofs of computational integrity. They allow you to verify arbitrary amount of computation very cheaply. It doesn't matter how much original computation you do, how much it would take you to naively recompute. You can let someone do the hard work for you and then only present you with a final proof. Just going to be a short file, like one KB or maybe a few
kilobytes of data. That you can process using very simple arithmetic operations and come to back to result whether it's true or false. And the beauty of it, you can combine various 0 knowledge proofs recursively. So you can do a lot of computation in parallel and then verify them, produce a proof that you verified some proofs and verify these proofs of proofs, and so on. Until we get to this one single proof, which attests to the integrity of all the computation that you manage to back in
there. And then you settle this on something like a theorem, as in global settlement layer, global layer of consensus, where we all agree, okay, this is the last state. And this enables us to scale blockchains basically indefinitely. And just let's say if I'm to verify all of these proofs, then I need to know what is being proved though.
So if there's like a huge chain of all kinds of computation, I still need to know, like you know, all of the things you are computing, even if I don't have to do the computations. You don't have to know all of these things. You only need to commitment like in cryptography. In the work of blockchains we have a really nice primitive
called commitment. Where you can have a single hash that is a fingerprint of multiple things, like usually with packets in a Merkle tree, and you have a lot of the leaves at the bottom of the Merkle tree. And then you have 1 hash, the root hash of the sparkle tree, which will change like which is an unambiguous representation of all of the data that is committed in this tree. If you have to change one of the leaves, this hash will necessarily change, and it's really, really hard.
Computationally infeasible. To find like to fake it, to find some hash that will correspond to the set that you want. So in in this regard, you don't have to know all of the things that's happening computationally there, you only have to know that whatever you're very fine has a subset which is of interest to you. So like I I was recently thinking that the best way to describe zero knowledge proofs
in the blockchain context. Would be to call them not zero knowledge proofs, but like partial knowledge proofs where you can only look at things that are important to you but you still have the full picture and you know that everything else that you currently don't care about is also still correctly
verified. So a good example of this to intuitively understand this and you can calibrate me to let me go deeper into tech or more high level in this interior, but the intuitive understanding for people out there would be. Imagine you're getting you're receiving a payment on PayPal or Venmore or your bank account. You will see that your account balance has increased. You might want to see who is this payment coming from and you don't care about all the other
accounts in the world. You still want to be sure that all the other accounts in your in at least in your bank are correctly managed, that all the other payments are done with high integrity. Because if that's not the case. Maybe your account is increased, but like all the other accounts are increased by $1 million and so the bank is really insolvent and it will be will be able to to pay you this money.
When you go to the shop with your credit card you won't be able to make the payment, so you don't care about those competitions, but you still want them to be to be to be correct. So like 0 knowledge proofs would allow you to verify the integrity of all the other payments without having to care about them. And the way we implement 0 knowledge proofs in the world of blockchains, the way we apply them to blockchains today on Ethereum is by building ZK
rollups. And so we can talk about what ZK ROLLUP actually is. Yes, let's do that. So in a ZK rollup, who produces the ZK proofs and kind of what's the mechanism meant to end? Sure. So ZK Rollup is a layer to scaling solution. So instead of transacting directly on layer one on the theorem on the main net itself, we say, let's create a parallel blockchain that is going to process transactions completely
separately. So we will have someone, some entity or maybe decentralized by of entities that will accept transactions and will sequence them in blocks. We'll call this by. The sequencer can be centralized run by 1 server. Can be decentralized, run by consensus of multiple validators. Doesn't matter. Let's just assume we have this
one blockchain. So the sequencer collects transactions, back them into blocks, verifies that they're valid like tries to. If the blocks are invalid, they won't be able to produce the proofs. And after the blocks are complete, they do two things. One is they compute the zero knowledge proofs for all the transactions in the block, and they produce a final proof that this block is complete. To make it practical, it probably requires still recursive proof generation.
So we will split this block into small, many small multiple chunks. We will produce the proof for each of the chunk. Maybe we will move heavy operations into specialized 0 knowledge proofs that are more efficiently verifiable than generic purpose transactions. We will produce the proof of that. Then we will aggregate all these proofs together in one single proof of the block which contains like all the all the logic that verifies all the logic that we need.
The transactions were done correctly, that the users authorized and with signatures, that smart codec logic executed correctly, and then all the hashes, like, we can basically all the computation, right? We have this one proof, and then this proof is submitted on layer one along with the new root hash for this block. So we don't publish the entire state, We don't publish all the transactions. We just say, here's the new state, here's the new commitment
to the state, the new root hash. And here's a proof that this newer root hash is indeed a valid transition from the previous root hash, the previous commitment to the state which is recorded from layer 1, to this new root hash and layer ones. The smart contract only theorem can actually verify this proof. Come to conclusion objectively, by nature of pure math verification that the proof is correct and make the state transition. And then we need the second thing. We need to make sure.
That even though the state transition is now valid, verified on on on layer one, and the transition is made and we have the new root hash of this state, everyone else knows what actually happened in this block. It was specifically with regard to it what what is the new state of all the accounts in the block. Because if people don't know it, if external observers, the users or the the other violators don't know what what what changed in the state.
They will not be able to do anything with it. Like we will enter a state which is committed on the theory that no one except for the for whoever made this transition can actually process. I cannot prove to you that I have money, I cannot access this money, cannot withdraw, I cannot transact on this chain. So it would be like a frozen state. So in order to solve this, we have to publish something to the users to everyone.
Who wants to observe need to publish some piece of information that will allow them to reconstruct the state or to reconstruct the changes that happen from the state from the previous known state. So there are two ways to do it, like one is you publish all the transaction inputs and you just like make it available to everyone and then people can recompute these transactions and reconstruct the state, which is something the optimistic roll ups do.
And the second approach is that you publish the actual differences. For each storage slot that has been changed in this roll up block, you publish the new state of the storage slot. Either way, the observer now can reconstruct the state and they can work with the new block. But the trick is we have to publish it on some really strong censorship resistant system. And the most censorship resistant we have is Ethereum itself. So we kind of abuse the theory of network to.
Make this data available. We call it the data availability and the ultimate vision for Ethereum to be the settlement and the data availability layer for rollups. Making rollups the center of Ethereum roadmap and really the place where all or most of the activity on Ethereum will happen. Cool. There's a lot to unpack here. Let me maybe recap this. So basically from a technical point of view, what a ZK rollup requires is fall forward. So you need regular checkpoints
on L1 that can't revert. You need a proof of correctness from checkpoint to checkpoint. You need data availability on L1, either directly by call data or kind of in the dank sharding world in the site car blobs. The first thing is you need forced inclusion, and basically that the next checkpoint is only valid if forced inclusions are provably. Part of the next checkpoint, right.
So we were kind of we will go into this in just a little bit and to kind of discuss kind of the recent developments in kind of the Villadium world and so on to kind of look at the entire spectrum of kind of shades of L2. But maybe before that kind of let's quickly talk about the newly launched CK SYNC 2.0, because that kind of that came out. Recently. So now that we kind of know how ZK rollups function theoretically, let's get down to the meaty part.
So what's new with ZK Sync 2.0? Well, ZK SYNC 2.0, which we call ZK Sync ERA, is not such a recent development. We watched it half a year ago, Life in a Minute, and it was the very first ZK ABM, the very first ZK Rollup. With generic programmability that could execute contracts written for solidity insolidity for AVM.
So you could take a contract that works on Ethereum and you just deploy it and it works out-of-the-box in most cases and all the tooling works or like not all the tooling works but like the critical pieces work like the web free API, the testing, the deploying the access to it like logs. And everything follows the EVM programming model.
And yes since then we we experienced a lot of growth on the platform and it's in fact now the the most popular L2 on Ethereum, we had more transactions in the last 30 days than any other. L2 was I think 25,000,000 transactions with arbitrary following with 24 and optimism is 16,000,000 and everyone else way below. And it's currently the 3rd L2 by TVL and it's also growing, fluctuating but the D Phi component is growing very strongly and we have more and more projects launching on ERA.
So era, yeah it's it's a big step for a theory. It's you know, it's what people were waiting for many years and and thought it will take many more years to arrive in in the full form. Let's kind of look at the taxonomy of different CK roll ups, right? So basically it's a space that has grown, you know, leaps and bounds in recent years. And even on this podcast we we recently interviewed Jody and David from ZKEVM at Polygon. We spoke with Ellie from Stark with Zack and Joe from Adstech.
But there's also other people we haven't had on the podcast yet, like the scroll team, the linear team, and so on. Do you have a taxonomy in your head for these different ZK rollups? So basically, what kind of buckets do they fall into? Vitaly came up with this post introducing different types of ZK Avms. I'm not sure it will be irrelevant in the midterm, like it's probably irrelevant. Still relevant now, but we're in a very early experimentational phase.
In that post he broke it down into essentially degrees of closeness to the original theorem specification. Like how how, how far do we deviate from pure native layer one in the M? Different ZK Avms have like some of them embrace the byte code native approach, some of them embrace compiling some, some are somewhere in between. Some of them are trying to be as close to where one is to replicate the full blocks of layer one and let storage be kept in the exactly same format. So look at this.
I think this classification is going to disappear in the short future because the productivity of 0 knowledge proves is accelerating, still at the really high pace.
And so the performance characteristics will allow us to basically verify arbitrary computations we will be able in the very short term, we will be able to run like Ziki ABM, like specialized programs compiled from Solidity to a Ziki VM which is optimal for proving or proof the bytecode native EVM, and like maybe even have storage proofs for. For the exact same format as Ethereum or we will be able to run like native code written in raster C all of that on the same
platform. So you as a builder will have a choice of what type of computational environment you want. For some applications you might want to run bytecode compatible EVM, just there are use cases like you want to deploy the address. The contract which has exactly the same addresses as on all the other AVM chains. So you have no choice but to deploy native native code there. But for some other cases you want 100,000 TPS decks optimized for very specific operation.
You can't really do it in. In India you can't do it because your your sequencer is going to be the bottleneck. So you will probably write a specialized app specific application in Rust that just does that. And you might want to deploy it as a Ziki Roller because you still want all the benefits of interoperability and security that you derive from Ziki Roller. But you will probably not do it in India and you still want a platform that can that enables you to incorporate all of these
designs. And so I think the real taxonomy is going to be the like this architecture of interoperability in the chains. So it's something we recently came up with the publication of the ZK stack that allows you to deploy your own chain and the architecture of hyper chains and hyper bridges that connect them will allow you to have this like different types of infrastructures deployed in the
interconnected way. So I think that's going to be like one major classificator, like how different role ecosystems approach this application specific design and interpretability between them, like whether or not they can make it seamless and native. And the second big classification parameter that I would pick is the treating of data availability. Do you publish the transaction inputs or do you publish the state divs? In what way do we enable volition?
Or is it the single data availability model? You can only be a ZK rollup or only be a validity. This is going to be a big important difference. So those two things I think are much more than the degree of compatibility, because the compatibility is going to be solved and. Let's talk about the first complex of questions 1st and then kind of the validium kind of spectrum later. So we had LE on recently and he was very adamant that Zkevms are not performant enough.
And basically, they don't offer basically in terms of kind of how much computation you can do. He says that Cairo is doing much, much better. But it sounds like you're saying that in principle you can kind of mesh these two approaches. Did I get that right or did I misunderstand? This is absolutely correct, yes. So I agree with earlier that EVM is not the most performant platform, especially for
sequential operations. So you can you could construct an EVM that verifies transactions in parallel, and then even though the performance of these transactions is not at the limit of what the current compute is enabling, you kind of don't care. Because what you care about is the cost per transaction. And if the cost is much, much less than the what the user is willing to pay. And think of like payment applications.
Like if you're or you know like some some important some trading where your margin is like some a few dollars per transaction but you're only paying 0.0001 cent, you probably don't care. Like what you care about is security, you care about interpretability and you care about time to market. And if time to market is important, you probably and you're building smart contracts. You want to tap into a reach
existing ecosystem. You want to be building on Something like Solidity that has a lot of libraries, a lot of frameworks, a lot of tooling, a lot of people who know how to build it. Because it's already hard to hire Solidity developers. How hard would it be to hire people who have to learn some specialized language?
So you want to reach broad ecosystem to be building your stuff on. However, for other applications for like something that like this 100 KTPS exchange, you absolutely need the ultimate compute. You want to like bring it down to you. Probably maybe you don't even want to run it inside a virtual machine like no matter if it's Cairo or VM or EVM or whatever.
Maybe you want like really like a bare metal implementation of your specific roll up that can sell transactions really, really fast running because all of them are sequential because they are trading on the same trading pair. You want to run them as fast as possible what the processor enables you. So you get to this ultra high frequency trading with 10s or hundreds of thousands of TPS. So yes, I believe the future is with this differentiated spectrum of approach. Cool.
That's very helpful. I want to understand this a little bit more. So let's say you have to EVM. Today on Ethereum, right with the EVM, basically there are some performance limitations. For example, one is because of the consensus, you have to like propagate the blocks like it requires certain amount of block time, you can't make them too massive. Another thing is maybe the kind of computation of the state and the EVM.
Now we have the ZKV EVM here. What becomes a bottleneck here, right, because you have a single sequencer that you sent a transaction to. It's basically the bottleneck, the speed at which you're able to create the proofs for for all the transactions. Or I mean first of all how does the the throughput and scalability of, you know one single CKVM compared to ether main net and what what are the bottlenecks there? That's really great question. So we will have a couple of bottlenecks.
The first intermediate bottleneck is going to be the speed of your sequencer, the base at which you can accept and execute transactions and compute the block intermediate, block results and block hashes. This does not depend on the like whatever what's your knowledge proofs or fraud proofs you're using does not depend on data availability. It's just basic computation and networking and it depends on the
architecture of your chain. Some chains will be decentralized and so you will have to tap into consensus and you have to also make sure that your sequencing layer is fast enough and like your latency is good enough for your application. And some other chains might even be completely centralized with a single server that can respond in like 20 milliseconds time. And for some use cases this like for this super high frequency trading this would be the case.
They will likely prefer this, but they might still want the full validity and security derived from Ethereum and open being not an isolated chain but the part of the bigger ecosystem with all this rich liquidity. So that's your first bottleneck and as you can see like the various trade-offs lead to various different solutions. Your second trade off or bottleneck is going to be your the data availability, how you store data availability, how you manage data availability.
If you are a Ziki roll up then you are competing with all the other roll ups on ethereal ziki and optimistic for the block space because the block space of Ethereum is limited. It's kind of a 0 sum game. If some blockchain if some roll ups will get more data, there will be less data data availability bandwidth available to other roll ups so which will lead them just to higher prices for this data bandwidth.
So this is a big problem and the only way to solve it in the short term to make the throughput really unlimited is to use external data availability like off chain data availability. So you will still have Z key roll ups and maybe every chain should have a part of its account in on the ZK roll up where all the data is published on Ethereum and they enjoy high security.
But for the accounts that do not need high security or are willing to take some risks into account you want to publish data availability externally with zero knowledge proofs. It makes a lot of sense. Makes a lot less sense with optimistic approaches which we can discuss why. But for for ZKS it works. So if you can go and you have this kind of elastic extension of data availability bandwidth, then this bottleneck is going to be solved for you.
And the third bottleneck we have is the actual ability to generate 0 knowledge proofs. And this is the least of our problems because the proof generation is they're relatively cheap and we can do it on very broadly available hardware. So the we last week we announced an upgrade called Bujum, a new proof system that is being that's going to be embraced by
Ziggy Singh era. This is a proof system we've been working on and off for a couple of years is based on the construction called Redshift which is just a combination of Plonk and Plonkish arithmetization and Fry polynomial commitment. And the implementation we have today only requires 6 to 16 gigabytes of RAM. Depending on your configuration, you can choose parameters like let's say 1616 gigabytes of RAM only. GPU is basically consumer grade hardware.
You can do it on gaming machines, you can do it like on any cloud provider. They have plenty of GPUs available for machine learning for other purposes that you can utilize. So we will be able to prove all of the world's value transactions with ZK using something like this. So that is not really a bottleneck. So data availability and the sequential throughput or the sequencer throughput are really two bottlenecks and we can talk about the solutions.
The solution to the sequencer throughput is to have many chains. There is no alternative to this. Like we will not be able to handle all of the world's value transactions on a single monolithic chain because it's just physically invisible. Like you cannot imagine all of the world's Internet servers running on a single server or even on a single data center. Like that doesn't scale. You need to be able to add more and more on demand.
It also won't work because different no matter what configuration you take, you're making some trade-offs, latency versus decentralization. Like if you're decentralized consensus then you will nature to be able to handle less throughput and less like. When you say decentralization in this context, like what are you talking about decentration of the sequencer? OK. If you want to decentralize the sequencer as opposed to one, OK,
that makes sense, yeah, yeah. So one validator will be able to handle like really high load with very low latency. If you want to have hundreds of validators, then you naturally have to make the data available to all of them. You have to reach consensus, which requires at least two rounds of communication between all of them. You probably want them to be like broadly geographically spread, not in the same country, not on the same continent.
So like the communication loop becomes larger, like you're not getting anywhere, like you will be in the region of like one second, order of magnitude of one second, maybe half. Then basically you run something like tenement or something like that, or correct tenement of hot stuff like you need. Like even with the newest modification of hot stuff, you need 2 rounds of consensus, 2 rounds of messaging for the
consensus. Which means you have to like just send a message twice between different continents. And you just limited by the speed of light and the speed of communication and those networks which will determine the latency of your consensus which you can eliminate if you're using like a localized data server for centralized sequence. So those trade-offs are impossible to make like once and
for all one-size-fits-all. So you will need multiple chains and so the question is how do we incorporate multiple chains in an architecture where they can still seamlessly, trustlessly and capital efficiently communicate with each other. And this is where the hyper chain architecture comes into play. This is why we've been working so hard on making this architecture available in the ZK sync network and we would love to make it available to other
roll ups as well. But unfortunately the way Ethereum is architected, it's not going to be as seamless between different roll up ecosystems. You will be able to pass messages between say Ziki Sync like one of the Ziki Sync hyper chains and like one of the stock where Starknet itself or one of the old trees. So there will be some degree of trustlessness, but it's not going to be as seamless in terms of assets movement.
To move an asset from one roll up to another you will either need to use external liquidity or you will have to go through layer one and actually pass the this asset from one. Like bridge contract on Ethereum which belongs to Zicky Sing, to the bridge contract on Ethereum which belongs to some other roll up which will make a theory layer one itself. The bottleneck of this bridge which will not really scale for like we're talking about millions or billions of users.
But within the ecosystem will inside the Zicky Sing hyper chain network, it will be possible in to arbitrary degree. So like the way you can imagine, Hyperchange is just like like you have like domains for e-mail you have Brian at Epicenter or Gmail or whatever I have like alex@matterla-bs.com you can send an e-mail from any address on any domain to any other address on any other domain and you don't have to care about it.
You don't like the communication is the same, you just do one click and in a few seconds or minutes the message arrives on the other side and it's end to end encrypted, like you know it's trustless. How does this work technically? Because basically one ZK sync chain would have to know the state of the other chain to actually make this happen, right? So basically it's kind of like the old problem of kind of having smartshots and how they communicate, right? But yes.
So if you want to learn like real technical detail, like deep technical details on how it works, I highly recommend this Slosh paper where the Slosh team has done an extensive research and documented really well how this will work. But like the high level, yes, the two chains that transact between each other and need to share need to have access to
each other's state. So this is already possible with all roll ups on Ethereum. The moment you finalize the state on one rollup, you can use storage proofs to access the state of any other rollup. Because you can go, you can pass. You can imagine that Ethereum kind of unites all of the states of all the rollups in one huge merkle tree, where Ethereum state tree is like the top of this huge merkle tree. So what you do is only one chain. You commit a message with a
destination of some other chain. And in this message you say here I like, I am burning let's say 100 ETH on this chain here like the smart contact takes care of this. And so like I promise I like, I burn it in favor of this destination on some other hyper chain within some period of time. And you make this commitment, you store it in storage. The other chain can then read the storage and say, oh, I see that this amount was burn. And here's a very, very important part.
Because both chains run the exactly same subset of circuits, the exactly same subset of like cryptographic enforcement of the rules, I can trust this other chain with a message that for this commitment that the the this action has actually been performed, that they actually burned this 108th. I can trust it blindly because that chain is is like it's validity is enforced by exactly same circuits as my own chain as as I as myself, as as I myself as a chain, right.
So like for me, I can trust that chain as much as I can trust myself. So I can easily min this 108th on this chain like through some system counter that has access to like minting. And it's probably going to be like a part of the of your bridging. Like your tokens will have to be aware if you either use system conference for tokens or you use specialized tokens that know about this functionality can mint this assets and then you
can use this assets natively. So you need to be part of the same state, you need to have the same circuit so they can trust each other. And then the third key component of this architecture is that all of these chains have to share a single bridge on Ethereum that holds assets for them. Because if you don't share the same bridge that holds the assets, then you can kind of like trust the other chain. You can be sure that they burn some like 100 E and you can mint
it yourself inside your chain. You will never be able to withdraw this hundred you because they don't belong to you then. No blocked in your near bridge on this area. Is is that last one the main reason why you wouldn't be able to get the same kind of convenience when it comes to like vision to start net or some other thing? Precisely, yes.
Like you, you like in order. So like there would be a question if you can trust Stark NET contracts because it's a separate system that is managed by entirely different governance You might like, you know you will have to write your specialized contract, the custom user contract that says I trust Starknet maybe other contracts don't but I do trust them.
So like I can believe that this message is real, but then like, so that's actually the first problem like even if we if we could manage the the ownership of this contract if this contract would not be able to persuade the system contract that we should mint if because the system contract does not know if Starknet is not compromised by their government.
The system contract basically is able to verify the computation that's done using specific circuits and starkness as different circuits, so it like cannot directly verify. That it's just a different system, not not governed by the same like upgradeability pattern by the same code. So like the system the system contract can only trust other system contracts of trusted origin.
It cannot trust users code because if I can deploy arbitrary smart contract which says meant me $1 million trust me bro it's like it's it's honest because it's kind of from the other chain. The system contract will say you know like maybe maybe not so it has to be a message that comes from the other system contract that actually burned this this 100 feet. But yes, but then the second
part is is is you're right. Like even if we if we solve that we like on the system level we make an agreement. We say like the kissing trusts darkness. Darkness trusts the kissing. We still cannot pass the assets because they are locked in different underlying bridge conference. How does the hyper chain know which other chains are in the hyper chain architecture and to trust them right? I mean they kind of need a Hyper chain ID that kind of says I am Hyper chain 72.
You can trust me, but is there any way of kind of faking that or do you need a centralized register? How do you go about that? You will have a smart contact on Ethereum that will hold the Merkle tree of the hyperchange. Let's call it the shared prover or the shared verifier in this Merkle tree. All the state changes will only be authorized if they are coming from a trusted hyper chain. And by trusted I mean like from a hyper chain with the circuits
that the prover contract knows. Because the prover contracts are always verifies the proofs against some verification keys. Like when you verify a proof you need to know what you verify you don't like. You need to have this commitment to the circuits which we call the verification key. It's a small key, but it unambiguously identifies certain cryptographic program. One circuit always produces one
specific verification. So this breach contract will have like one single verification key for all the hyper chains. Any hyper chain that wants to make a state position must support this verification, which means that they are enforcing all the rules the way we all agree that we all enforce. And this is also how you make sure that the the tokens on each hyper chain actually
commensurate, right? Because basically I could be evil hyper chain and could say, look I have 100 ETH, I will burn it, I will reissue it on hyper chain 19 and then basically I burn some sort of fake ether and kind of get really ether on hyper chain 19. Absolutely correct.
So they have to share the circuits, maybe not all the circuits, the hyper chains are actually highly customizable, they are, they are fully sovereign, you can choose your sequence, you can choose your data availability model, you can choose your extensions whatever you want. But there must be a some really small subset of circuits that enforce this integrity, that enforce this the the asset treasury that like really everyone cannot mess with anyone
else's assets. So this part must be common and this is going to be the critical part to verify in the state transitions. I think I think I get get that part. Now let's maybe back up a little kind of to the four requirements of AZK rollup. So as we as we talked about you kind of you need you need regular checkpoints that kind of rebut you need a proof between checkpoint to checkpoint then you need data availability and the reason why you need data availability is so that.
If there is no data availability, there's like some sort of secret transaction that I can kind of include in the block. Other people can no longer calculate the current state of the block and can no longer build on it, and thereby I can effectively break it, right? I can. Kind of. I can't steal ones, yeah, but I can. I can make sure that no one else can do anything because I have the secret transaction. This is why you need the data availability. There are villadiums.
Which are basically ZK rollups without data availability and this is kind of the direction that cello is going as well as Polygon and so on. How do you think about this spectrum of L tuners? And do you think maybe there's even a way of kind of doing data availability optimistically so that basically don't actually because basically if you look at
how much you spend? On the checkpoints versus on the data availability, maybe you can give us the exact numbers for ZK sync, but almost everything actually is is for data availability rather than the checkpoints, right? Absolutely correct. So I'll start with this last question. Indeed the absolute majority of the costs is going towards data availability from like we currently have 3050 sales per transaction depending on fluctuating gas prices Ethereum across all the roll ups.
The bulk of this cost is going to the table ability and it's not going to change even after AP4844 which will hopefully bring the costs down by a factor of 10 X make 20X. But like the even the remaining one cent is going to be the majority of the cost because the zero knowledge proofs
computation part is tiny. It's like 0.0 something like it's hard to calculate exactly because there are many components in the system like it's really like you can benchmark something in vacuum but it's in detachment from the real system. It's not going to be indicative, but like we know for sure it's like a so correct.
The data availability is important, so if you want to lower the cost you have to seek this external data availability solutions like the building something like volidiums or volitions talk about that in a second. The the like let's reason about their L Two's Ness. I think we need a good definition of what an L2 actually is and I've not seen a strict definition adopted by the community like we kind of like know it intuitively but but not
precisely. I think a good definition would be an L2 is a chain that derives its security from underlying layer. One like security in various senses, like it would be liveness, could be security of fonts, retrievability of the fonts eventually and so on. But you need to derive some security from L1 if you don't derive security like for some significant security from L1. So a side chain for example is not an L2 because your security entirely depends on your set of validators.
They can do whatever they want with your money. If they collude, they can still, they can freeze whatever. With ZQ roll up the security is 100% direct from layer one.
You can always guarantee that the users will eventually be able to withdraw all the funds, no matter what the validators, if the contracts are immutable, if they don't have the right to arbitrary change contracts, and of course if there are no box in the implementation, which is a significant risk, which is not negligible, like let's assume those two factors for now. But in this case ZQ Rollup is like ironclad. Security is exactly the same as the theorem in terms of its
properties. The validium is in between. All the transactions in validium are enforced by zero knowledge, proofs and theorem. So it's not possible to make anything invalid. It's not possible to execute something not on behalf of the user. In this sense, it derives a very significant part of its security from Ethereum. And for some use cases you really you don't care that much about data availability, you only care about the correctness of the code.
Like an example of this would be, let's say, online voting. Let's say that you you're voting like, let's ignore salsish resistance for now. Let's let's imagine that we have some like perfect Salish resistance input because maybe like, you know, like what? Like each party collects their own votes and then each party submits their like, you know, like we we have like, you know, blue party and the red party.
Both of them get as many votes as they can from their respective proponents, and then each of them submits a transaction on this chain and all you care about is to calculate the votes correctly. And then you want to publish the result on chain, but you want to make sure that it's actually like correctly available on chain to other contacts, not just to humans. To demonstrate which you could do off changes generating 0 knowledge proofs, you want to
make it available to contacts. So for this, data availability is really not important. All you care about in the end is that the result is correct, right? The same applies to oracles, like when you do Oracle updates, you don't care about the state of the Oracle update because you can discard that. Like if the chain is frozen, who cares? Like you will be able to make new Oracle ticks on the new chain when users migrate, right?
But what you care about is that the Oracle updates have been correctly verified that they're coming from trusted sources, that the way that averages are computed correctly and so on and so on, right? So for those use cases, Validium does not constitute any reduction in security because you only use security for computation, which it's perfectly secure. So from this perspective, I think that Validium is actually like it should deserve to be
called ML2 to some degree. When we talk about the actual, like real life security, like real world security for the user assets, it becomes a lot trickier. It's really hard to reason like we Now we are back to this game, theoretical a plane where we can imagine that the operator, the validators of this Villadium chain that locks a lot of like some billions of dollars of your assets.
They could say, oh you know what, like let's try to blackmail our users, let's freeze the state and then like demand ransom. Or maybe they don't freeze the state. Maybe they are hacked because the servers that operate the validium have to be online, the keys have to be on the whole machines. So maybe there is some like ingenious way to hack the systems and they compromise the majority of the of the validators and then the hackers can demand some like it could
potentially become tricky. So I would of course treat validium accounts always as like significantly less secure than Ethereum accounts. But then you know, like you could like the. I think the ideal solution is the combination of both. When you have something like a volition system where you as a user can decide for each of your accounts, do you want it to be stored on Ethereum?
Like on a ZQ roll up with full Ethereum security guarantees but maybe higher cost of transactions on this account and for some other account you decide that it should be a valid unit. Or is the key partner account where the data availability is secured off chain by some committee with some economic security. But you use it as you would use your savings and your current account. You would keep most of your assets, most of your savings on the savings account.
Maybe you put them in some default protocols from your roll up account and you don't touch it every day, the only transactor rarely on it. So like most of your value is there and then you move some of this value to your current account on the on the validium side of of the volition.
Let's say on like you you on Zicky sink it would be called Zicky Porter. So you put it in Zicky Porter, maybe you have like your millions of dollars and on that side and just a few thousand per month to pay for for your daily
needs on the volition side. And so you kind of like you you you explicitly manage the risks of this exposure and if everyone else is doing the same, then you have a lot less value locked on the Validium side of the evolution, but you will have a lot more transactions, which actually makes a perfect sense from the from this balanced perspective, right?
Like you will have a lot of cheap transactions, a lot of trading going on there, a lot of like computational activity like Oracle updates and arbitrage transactions and so on and so on happening on the evolution side. Sorry, on the Validium side. Can I quickly? Kind of. Question this to a certain extent. Basically, if you kind of look how say Cello is transitioning to being an L2, they're not forgoing their validator set, right? So why a kind of CK sync?
And to be fair, all other L2S have like a centralized sequencer, which is definitely also an attack vector, right? The Validiums that kind of we see emerging, they already have a decentralized validator set. And so basically, there's many entities that in principle are allowed to kind of build the blocks. Where do we see the trade off here? So I mean, obviously if you had a decentralized sequencer on ZK Sync, this point would kind of fall, but currently you don't, right?
You can't really compare the two. So first of all, we are committed to decentralizing the sequencer. We actively work on this. We have a prototype which will unveil very soon. It's running on the hot stuff consensus. It's going to be fully decentralized as a sequencer. And what you want to get from the sequence of decentralization primarily is the resilience and the liveness of your network.
You want to be sure that the network will remain operational, like for everyday transactions, even if one or multiple parties are compromised or going down or unavailable. But the sequencer does not affect the security of your funds. So you could argue that liveness is part of security. I will admit that.
But if you put a lot of value in some default applications, yes, you will be annoyed if it's not available, and you might have some like opportunity costs for not being able to use it for a couple of days. But it's nothing compared to the ability to lose all of your fonts locked in, like in Unis Lock for example. Right, but the validators can't
steer from you, right? I mean so basically if you have the ability to kind of run your own full node, you can't be duped about the state of the chain. You can never steal funds, you can never steal funds. Like all you could try to do is like the validators could try to double, like they can't even do a double span. Like they can only do some short term faking on chain that will
never finalize on the theory. And if you're if you're making high value transactions, you always want to wait for the final find, like for the finality on the theory and for the checkpoint, but it actually guarantees that this transaction is final before accepting it. If you're expecting someone for some of the payment of $1 million, you have to wait for a You cannot trust the sequencer, they just I have a confirmation. Absolutely. But that's the same on
Villadium, right? So on Villadium, the validators or like your guidance of data, the data availability providers can actually freeze. Your state can freeze the entire chain, and so your value will become unavailable to you. You need only a single honest validator, right? Because you're only one person who kind of makes the data available. Great question. This is a big misconception about the data availability
systems. If you have a state transition which has been authorized by a decentralized set of validators, and at least one of them is honest, that will apply. This one honest validator will share the data with you. However, if the majority of your validator set is compromised, let's say like 2/3 of the validator set is malicious, then they will do a state transition without sharing it with any of
the honest validators. So even though you have 1/3 of the honest validators on the chain, they will never get a single bit of this data from the malicious parties. So it's like what matters is like who controls the state transition, not who controls the data for the honest blocks. Because if you control the state transition ability, then you can always make this state transition into this unavailable state and it doesn't matter that you have like a lot of honest
people on the chain. Okay. So you need more than 1/3 honest majorities. The other quorum like the chain can decide is it like one like 50%, two thirds, whatever. But like some quorum this quorum that decides that yes we can accept the state transition because we like the the the smart contract on Ethereum has to make a decision whether this block has data available or not. And it's it's impossible to look for for this block to for this contract to tell it. Subjectively, it cannot talk to
all the validators. It cannot make data availability sampling. Because it's a smart contract, it can only work with limited amount of data that's been passed. So the what the contract can verify is like okay. Do I have enough signatures? Do I have a quorum of signatures, Let's say 2/3? It's a limitation of this verification code. Okay. Yeah, that totally that clears up my question. So if you look at kind of how. DK sync and all other L2S are implemented at the moment.
They're all upgradable, usually from a single multi sync, right? So I totally understand why this is done. So you need to be able to mitigate potential vulnerabilities and and on top of that L1 hasn't really ossified enough, so there might be upgrades on L1 that kind of might actively break things on L2. So how, how do you then mitigate kind of? The risk of compromise key attacks, right?
Because say there's like 20% twenty people on your on your committee and you need like you know 10 signatures for upgrading the contract any allowing you to steal funds and so on like actually ceiling funds not just freezing them. How do you mitigate that risk? This is a great question and this is something like if you if you would ask me like how I feel about this credibility, I would say I feel terrible like we it's
a key sync. The very first version of the protocol we deployed is of Zicky Sync version one, which is now called Zicky Sync right? It was completely immutable. It was immutable with some upgrade period because we could not tolerate that. Like the idea that some multi sync control of credibility or the team can control of credibility and just propose arbitrary changes completely defeats the idea of this trustless scaling, right?
So like the? That was something we were we were finding disgusting and then we had to learn the hard way that, like we are way too early. We have to make the we have to react to all our abilities because the bugs will be found in the short term while the system is in developments.
You have to think you have to take a very paranoid defensive mindset with mechanisms of defense in depth where you have multiple layers of protection and you should be able to react react in a timely manner to threats.
So we came up with the idea of the Security Council and since then it like the the second chain that embraced the Security Council was Arbitron earlier this year and now it's it's a it's a broadly popular idea that like most other chains are embracing and italic and L to be they are making great effort to to push for it to to a set sign high bar of standards of what constitutes a true Security Council. So let's look at how Security Council works.
A-Team should only be able like the core team of any protocol should only be able to propose a change for the upgrade which will execute with some time lock so that the users have time to withdraw from the protocol if they don't like the change or if I'll try the protocol looks malicious. Now if you deal with emergency, if there is a open box on your system and live smart contracts, you want to be able to
accelerate this. And this is where Security Council would kick in and you would get some external people may be appointed by the governance of your protocol like hopefully or ideally a broad set of participants of highly reputable people from the community from a lot of different jurisdictions who use off chain cold wallets to control these keys. So what it gives you is the protection from a regulatory capture.
Like it's a lot harder to compromise people in different jurisdictions because like now it has to be something universal. If if one government goes wrong and and tries to like hijack the protocol, they will not be able to do it. Like if if if if a single company controls the protocol then the government of the company where the company is incorporated would come to them and say like make this upgrade or or you go to jail or
something like this right. But if if if we have a like a broad set of participants, then it's much less likely because it's harder. The second protection it gives you is that compromising a lot of cold wallets in hardware wallets or air gap machines or something like highly secured is a lot harder than compromising the online servers with hot keys in memory that are probably running in some cloud providers that have access to the Internet that are vulnerable to 0 days.
To compromise the cold wallets that are not connected to the Internet someone would have to go and break into like all of the multi participants, which is a little bit harder. But it's still not a perfect solution. And the perfect solution would be to bypass the need to like to withdraw the rights of upgrades from both the team and the
Security Council altogether. So the I can imagine the world where the Security Council appointed by the governance, proudly decentralized, highly secured with gold keys, can only freeze the protocol for a short period of time if they see an emergency, if there is a bug that needs the treatment, they
should go and do this. And then they should bring this question to the protocol governance and the protocol governance should decide and then make appropriate changes and make the emergency upgrades on the product. And then even in this case the question is like what is governance? Is it just the majority of the top and holders? Is it some broader set of participants like I really admire?
I want to make a shout out to the Optimism team for for doing a lot of work on on the on the process of governance like elaborating different schemes like they have the idea of the House of Citizens, the House House of Token Holders.
You offer a consensus between both of them, and even then we might have some better mechanisms such as like eventually bringing up this question to the consensus of where one, you know maybe initiating a an upgrade in a way that can only be accomplished with the soft fork of layer one itself if there is a disagreement between different parties of these governing entities. So this is a big question which requires a lot more research, but I hope I could get something.
Cool. That was very helpful. So one question I think is kind of like very connected to this. You mentioned the risk of bugs. I mean, I've also heard of other people being quite concerned about this with regards to ZK rollups. Can you talk a little bit about where are the risks of bugs and what kind of consequences could we have if there are maybe bugs in different places?
Well, all of the rollups are relatively new systems that need to be bottle tested for a long period of time with a lot of money until we kind of have enough confidence that they are secure. The box can happen in various places. For ZQ rollups, they're really like if you look at the complexity of the systems, the complexities is bounded to different isolated components. So you could have a back in cryptography potentially.
Theoretically that could allow you to fake proofs or you could have a back in circuits that would allow you to if you have like if you are the validator, you can submit any proposal for the new block. You could submit a malicious block and then fake the proof that this block is actually valid, right? If there are box, if you forgot some constraints, if some things are missing in the circuit.
So to mitigate these things it's it's actually a lot easier to do insecure labs and let's say an optimistic collapse, because you can create redundant systems like the way it works in in all mission critical systems today with like live emergencies, aviation, nuclear energy and so on. You never rely on a single component for security or for safety for that matter, like in the aviation you always have like multiple engines and multiple sensors.
The same thing can apply here. You don't want to rely just on the validity proofs, you want to do things like 2 FA where you need two separate mechanisms. In the case of ZQ roll up for example, it would be. First a consensus of the validators has to agree on that the block is valid and only then they produce the zero Knowledge proofs and Ethereum Contact verifies both the signatures of the majority of the validators and the easier knowledge proof and only both match.
Then you make a state transition. So now if there is a buck in cryptography it's you. In addition to to breaking cryptography, you have to compromise the majority of the violators, which is hard because most likely they they were honest to begin with and then it will be hard. You would you would have to buy a lot of stake to be able to get to this critical quorum.
But then in addition to that, if you introduce some things like withdrawal delays as we have in the case sync error for example, the delays are withdrawed. The withdrawals are delayed by a
few hours. In addition to just verifying the proof, you could say that you would also need to compromise the Security Council who would be able to support the problem and freeze the contract before the new malicious state transition is compromised, which will bring you to three FA and then like you can add one more layer of protection.
You can say that in addition to the validators and zero knowledge proofs and this kind of fraud proof monitoring by the Security Council, we would require a trusted execution environment like SJX for example, proof that the state transition is valid. It would give you like 4 layers of protection that you have to bypass and you don't have to rely on Intel or or NVIDIA or NVIDIA or other providers for
this. Like if the SGX proofs become unavailable then the governance can always intervene and just switch them off. This would be something so you would always have kind of a multi stick of several different components with growing degree of complexity of breaking that for security. Okay, cool. Thanks for explaining that. So maybe a final topic we wanted
to touch on, which is that. One thing that's being discussed a lot, which is the sequencer and the decentralization of sequencers, I mean it sounds like if I get sort of the ZK sync path correctly, right, is that you basically want to have the technologies to allow you know, like lots of different people to do lots of CK roll ups and to choose to choose sort of. Whether they want centralized sequencer or decentralized sequencer and maybe different types of parameters.
So as a result, is that correct? And then for the path of, OK, I want to decentralize sequencing solution. Are you guys building decentralized sequencer and you know how, what does that look like? This is a correct statement. We are focused now on the ZK stack, so we are which is based on the source code of the key sync error. This is a modular framework. This is a framework where you can replace different components from the sequencer to the data availability layer to the way
you handle MVV. Like all of this, things are going to be customizable for you and you have the full freedom to choose what components you use in what way. But we have to provide the basic components which some of them we are working on at Matter labs, some will be provided by the community, some will be provided by the grants program that that
we we want to initiate. But sequencer is really fundamental it's it's one of the most important parts of the of the stat and this is something we definitely want for the for for error. We don't want error to remain a chain with centralized sequencer. We want to go to to to decentralize it in all aspects as soon as we possibly can. So we are actively working on a
decentralized consensus. As I said before, we're using hot stuff or modification of hot stuff called hotshot for it, which gives you a very decent throughput at a very decent
latency. So for ZK Sync, we always take the user needs as the like the north star of where we want the Arctic architecture to go like we always architect back from the ideal user experience we envision and the ideal user experience is that every transaction confirms almost instantly like within under one second and it costs like under one cent. So that's kind of the the utopia, the crypto utopia that we want to build.
And from this perspective the the consensus has to be fast decentralized, but fast enough and low latency enough. And HOTSHOT was was meeting this criteria criteria so it became our choose. So, so just to clarify this here, the consensus here, so it's basically.
Like, how does that work? Does it basically mean you have a kind of like improve mistake that let's say there is someone that's kind of like the leader at this point who does the sequencing and then a bunch of data together gets passed around and others kind of using hot stuff. They test the validity or like the correctness of it and and then that's confirmed and then you go to the next leader.
Or is hot stuff just used to basically choose the sequencer and then for some point you just have this one party that's a sequencer? Or like, how does that work? So the blocks are being produced roughly every second and every second the leaders decide that and all of the validators reach consensus on what's the next block and it's in fault tolerance. So like if the leader, if some of the participants go down or become unresponsive it will self repair quickly. But every second we have a
decision. Yeah, yeah, Okay. And then do you feel like all of these things that are like huge topics at the moment on the theory like around the Mev pipeline and the proposed builder separation and those kind of things? Will Will. To what extent will this carry over to like this and the kind of decentralized sequencing seeker sync roll ups? This is a really, really good question. I don't have a definitive answer to it. We are in the research phase. We're looking at all the
different developments there. We're in touch with the Ethereum Foundation with with guys building. There are really amazing teams out there being shared sequencers who think that shared sequencing is is the paradigm. Sorry theorem, I don't have a firm conclusion yet like how it will work. I have some concerns which which I shared with all of them about the centralization of power.
If we come to to a world where proposal builder separation leads to just a few entities essentially building all of the blocks and all the chains, I think that's a bit dystopian because it will give them a lot of soft power. And like you don't want to eventually like to like like some Google or Facebook or something like big corporation like this to be powering all of the blockchains with nominal decentralization through solid-state.
So we want to design systems that actually encourage decentralization in various regards. But there is a popular opinion that that might not be possible and eventually, because of the complexity of entity extraction and the value that you can produce from there, that this inherent specialization in for builders will inevitably lead to this outcome. I don't want to believe this.
I want to believe that we will be able to come up with designs that actually broadly decentralized the system with a lot of individual participants with ways to actually mitigate MV and like it to prevent at least toxic MV from happening,
like targeted MV attacks. I think there are designs out there that largely can accomplish this but I've also heard concerns of schemes like encrypted mantles that they they could lead to other problems leading to like less efficient arbitrage on on on such systems and so on. I don't have a definitive answer but we have a research team focused on this and we will be just trying things out.
I can promise you that ZK Singh that you know to our core various and we we we have not discussed the ZK credo yet but this is like I encourage everyone to read and contribute to the ZK CREDO which is our mission and philosophy and various statement. We will do everything we can and and we want our community to enforce it to go in the direction of the maximum decentralization and
trustlessness. And so we will just pick the designs for era and I think the community will support it that maximize the decentralization and trustlessness and minimize Med. But for hyper chains, I'm sure that we will see a lot of experimentations and people will be trying all the different models with like from going maximum MV and then distributing it to the community to trying to minimize MV and work with like first conference serve
principles or encrypted mantles or some other novel approaches which I'm not aware of and eventually the market will decide what works best. I wish we could go on because lots of these actually sound super interesting, but we are already way overtime. So we'll just have to have you back at some point. Thank you so much for joining us, Alex. It was super insightful. Thank you. It was my pleasure. It was a very interesting conversation. Thank you for great question. Thank you so much.
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 guest 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.