Alex Gluchowski: zkSync - A New Era for EVM-compatible ZK Rollups. 507

Transcript

welcome to Epson and 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 Frederica earns and today we're going to speak of Alex lucrovsky he is the co-founder and CEO of matter labs and matalabs is the the company that's building ZK Singh which is one of the most exciting and sort of largest ZK roll-up Technologies uh that's you know looking to scale ethereum by kind of maintaining all the ethereum's trust assumptions and you know 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 uh we had you on like two years ago and uh you know a lot has happened since then including the CK space having gotten you know 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 work in crypto so I feel like maybe we can start with you know just a very brief recap of you know what are ZK Roll-Ups and you know why is DK such a great technology to scale blockchains absolutely let me try it so with blockchains uh uh you know like the yeah we really observe the revolution the the

cost starting with Bitcoin and ethereum taking it to the next level with smart contracts 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 lid it's it's a jump from Web 2.0 to web 3.0 like adding value to the internet on transaction level uh the problem is that the very same properties that make things like Bitcoin ethereum decentralized the blockchain is valuable uh they also lead to to the difficulties in making it available to a lot of people there are some key things uh in my opinion that we can distill

this value to among them are trustlessness permissionlessness openness and full episodes inclusivity of these networks and to achieve that um in the blockchain world from the early days we embraced the Maxima of Don 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 a world computer and it's what ethereum really is if you look at it from the computer science

so uh that means everyone has to redo all of the computations for everyone else which leads to quadratic complexity of our communication storage computation requirements and it's just infeasible to bring it to the work you know like you you when you are scaling the internet and adding a value layer onto the internet you can't re-run the computation of all the other servers of all the other like like redo everything that everyone else is to it so like the the this is a fundamental limitation which people have tried to solve them with different Traders 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 some other important properties uh and it was not until zero knowledge proofs appeared that we found a fundamental solution to this so like we we came up earlier the community came up with some really ingenious ways to uh to make this trade-offs in a um in the limited way you know we experimented with things like State channels payment channels uh plasma which then transitioned into like optimistic Roll-Ups all those things were important steps on this journey but the ultimate destination is zero

knowledge groups to explain why is your knowledge processor specifically like more more precisely succinct zero knowledge proofs or snarks um are in fact they would be better called like proofs of computational Integrity so they allow you to verify arbitrary amount of uh 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 which is going to be a short file like one kilobyte or maybe a few kilobytes of data that you can process using very simple arithmetic operations

uh and come to back to result whether it's true or or false and the beauty of it you can combine it various your knowledge probes recursively so you can do a lot of computation in parallel and then verify them uh produce a proof that you verified some proofs then verify this 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 managed to um to back in there and then you settle this on something like ethereum as a 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 um let's say if I'm to verify all of these proofs then I need to know what is being proved though now 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 in uh in cryptography in Oracle blockchains we have a really nice primitive called commitment where you can have a single hash that f is a fingerprint of of multiple things like usually we pack it in a miracle

tree and you have a lot of leaves at the bottom of the Merkel tree and then you have one 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 the Stream if you have to change one of the leaves this hash will necessarily change and it's really really hard computationally in feasible to find like to fake it to find some hash that will correspond to the set that you want uh so in in this regard uh you don't have to know all of the things that's happening computationally there you only have to know that whatever you verifying has a subset which is of interest to you so like I uh 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 that are important to you but you 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 um and you can you can calibrate me to let me go deeper into Tech or or more high level in this interior but the an intuitive understanding uh for people out there would be imagine you're getting you're receiving a payment on PayPal or venmor 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 one million dollars and so the bank is really insolvent and it will be will be able to pay you this money when you go to the shop with your credit card you won't be able to make a payment see you don't care about those computations but you still want them to be to be uh to be correct so like zero 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 zero knowledge Pros in the world of blockchains the way we apply them to blockchains today on ethereum is by building ZK rollups and so we can we can talk about what ZK roll-up actually is yes let's do that so in a CK uh roll up um who produces um the CK proofs and um kind of what's what's the mechanism end to end sure so Ezekiel rollup is a layer to scaling solution so instead of transacting directly on layer 1 on ethereum on the magnet itself we say let's create a parallel blockchain

that uh that it is going to process transactions completely separately so like we will have uh someone some entity or maybe decentralized by your entities that will accept transactions and will sequence them in blocks we'll call this body sequencer can be centralized Run by One server can be decentralized run by consensus of multiple validators doesn't matter like let's just assume we have this one blockchain so the sequencer collects transactions pack them into blocks verifies that they're they're very effectively if the blocks are invalid they won't be able to produce those 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 checks will produce the proof for each of the chart maybe we'll we'll move heavier operations into specialized zero knowledge proofs that are more efficiently verifiable than generic purpose transactions will produce the proof of that then we will aggregate all these proofs together in one single proof of the block which 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 contract logic executed uh correctly and then all the hashes like

we can like basically all the computation right we have this one pro and then this proof is submitted on where one uh 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 is the new state here's the new commitment to the state the new root hash and here's the proof that the this newer root hash is indeed a valid transition from the previous root hash previous commitment to the state which is recorded on layer 1 to this new root hash and layer 1 the smart contract of ethereum can actually verify this proof come to conclusion objectively by nature of pure math certification 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 the state everyone else knows what actually happened in this block it was specifically with regard to like what what is the new state of all their cards in the block because if people don't know it if external observers the users or the um the other validators don't know what what changed in the state they will not be able to do anything with it like we will enter a a state which is committed on ethereum

but 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 I cannot withdraw I cannot transact on this chain so it would be like a frozen stick so uh in order to to solve this we have to publish something to the users to everyone who is 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 happened in 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 uh 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 either way the Observer now can reconstruct the state and they can work with with the uh with the new block but the trick is we have to publish it on some really strong sellership resistant system and the most Central resistance we have uh is ethereum itself so we kind of abuse ethereum Network to to make this 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 Roll-Ups making Roll-Ups the center of ethereum roadmap and really the place where all where most of the activity on on ethereum will happen cool um there's a lot to unpack here let me maybe recap this so basically from a technical point of view um what a ZK roll up um requires is full 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 um on L1 either directly by call data or kind of in in the Dank shorting word in the in the site curb Labs the first thing is you kind of you need first

inclusion um and basically that the next checkpoint is only valid it forced inclusions uh probably 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 um developments and kind of the validium world and so on to kind of look at the entire spectrum of kind of um shades of L2 um but maybe before that kind of let's let's quickly talk about um the newly launched CK sync 2.0 because that kind of that came out recently so now that we kind of know um how a CK Road apps function

um theoretically Let's uh get down to the meaty part so what's new with with ZK sync 2.0 well the guessing 2.0 which we call zika sync era is not such a recent development we launched it half a year ago live in Maine and it was the very first ZK AVM the very first the Ezekiel roll up with uh generic programmability that could execute contracts written for solidity in solidity 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 uh or like not all the tooling works like like the critical

pieces work like the uh uh web free API the uh the the testing the deploying the access to it like logs everything follows the evm programming model and yeah since then we we experienced a lot of uh growth on the platform and it's in fact now the the most popular l21 ethereum we had more transactions in the last 30 days than any any other L2 was I think 25 million transactions with arbitrary involving with 24 and optimism is 16 million and everyone else way below uh and it's currently the third um

L2 by tvl and it's also growing fluctuating but the D5 component is growing very strongly and we have more and more projects launching on on era so um uh era yeah it's um uh it's a big step for ethereum it's you know because it's 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 Road UPS right so basically it's a space that has grown you know Leaps and Bounds in recent years um and even on this podcast we we recently interviewed

um Jody and David from zika ebm at um polygon we spoke with um Ellie from Stark um with um Second Joe from Aztec um but there's also other people we haven't had on the podcast yet like uh the scroll team the linear team and so on do you have a taxonomy in your head for these different DK Roll-Ups so basically what kind of buckets do they fall into vitalik came up with this post introducing different types of of ZK VMS I'm not sure it will be a relevant uh in this in in the midterm like it probably relevant still relevant now but we're in a very early experimentational phase so in in that post he broke it down into um essentially degrees of closeness to

the original ethereum specification like how how um how far do we deviate from like pure native layer 1 EDM different zkavms have like some of them embrace the bytecode native approach some of them Embrace uh compiling some some are somewhere in between uh some of them are trying to be as close to where one as to replicate the full blocks of layer 1 and and let uh storage uh be kept in exactly the same format so uh looking at this I think this classification is is going to disappear in the short future because the productivity of zero

knowledge proves is accelerating still at the at the really high pace and so the performance characteristics will uh allow us to basically verify arbitrary computations we will be able in in a very short term we'll be able to run like zkbm like you know specialized programs compiled from solidity to to a zkvm which is optimal for proving or proof the bytecode native uh EDM and like maybe even have storage proofs for uh for the exact same format as ethereum uh or we will be able to ride at around like native code written in rust or C

plus plus all of that on the same platform so you as a builder will have a choice of what type of uh of computational environment you want for some applications you might want to run bytecode compatible evm just you know there are use cases like you want to deploy the address the contract which has exactly the same address as as on all the other AVM chains right so you have no choice but to deploy native uh native code there but for some other use cases you want a hundred thousand TPS uh decks optimized for like very specific operation

you can't really do it in in India you can do it because yours 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 may might want to deploy it as a Suzuki roller because you still want all the benefits of interoperability and security that you derive from zikirola but you will probably not do it in Libya 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 gonna be the like this architecture of interoperability between the chains so it's it's something we recently came up with uh the uh publication of the ZK

stack that that allows you to to deploy your own chain and the architecture of hyper genes and Hyper bridges that connect them it will will allow you to have this like different types of infrastructures deployed in the interconnected way so I think that that's that's going to be like one major classificator like how different raw ecosystems approach this application specific design and interoperability between them like whether or not they can make it seamless 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 publish the state divs in what way do we enable volition or is it a single

data availability model that you can only be azq roll up or only be a validium this is going to be a big important difference so those two things I think are much more than the degree of compatibility because that the compatibility is going to be solved in reversary let's talk about um the first complex of questions first and then kind of the the validium kind of spectrum nature so we had early on recently and he was very adamant um that um ZK EVMS are not performant enough and basically they don't offer basically in terms of kind of how much computation you can do and he says that that Cairo is 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 yeah 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 uh the uh like the performance of these transactions is not at the limit of what 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 uh what the user is willing to pay

think of like payment applications like if you're or you know some some import some trading uh where your margin is like some a few dollars per transaction but you're only paying 0.0001 you probably don't care like what you care about is security uh you care about interoperability and you care about time to Market and this 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 yeah so like you want this reach broad ecosystem to to be building your stuff on however for other applications for like well some something that like this 100 ktps uh uh exchange you absolutely need the the uh the ultimate compute you want you want to like bring it down to you you probably maybe you don't even want to run it inside a virtual machine like no matter if it's Cairo VM or evm or whatever maybe you want like really like a bare metal implementation of your specific roll-up that can sell with transactions really really fast running like because all of them are sequential

because they are trading on the same trading player you want to run them like as as fast as possible what the processor enables you so you get to this ultra high frequency trading with thousands of DPS so yes I believe the the future is with with this differentiated spectrum of approaches cool that's that's very helpful I I want to like understand this like a little bit more so let's say you have the the evm today on ethereum and right with the evm basically uh you know there are some performance limitations you know I mean for example one is because okay because of the consensus you have to like propagate the blocks like you know it requires certain

amount of block time you're kind of making too massive uh another thing is maybe the the kind of computation of the state in the evm now we have the ZK the evm here what becomes a bottleneck here right because you have a single sequencer that you send to transaction to it's basically the bottleneck the speed at which you're able to create the proofs for for all the transactions or how I mean first of all how does the this the throughput and scalability of you know one single CK evm compared to ethereum mainnet and what are the bottlenecks there

uh that's really great question so we will have a couple of bottlenecks the first in the media bottleneck is going to be the speed of your sequencer the the base at which you can accept and execute transactions and and compute the block intermediate block results and blog hashes this does not depend on uh the your like whatever what's your knowledge proofs or fraud proofs you're using does not depend on data availability it just basic computation and networking and it depends on the architecture of your chain some genes will be decentralized and so you will have to tap into consensus and you have to like also make sure that your sequencing layer is fast enough and like your latency is is good enough for your

application um 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 uh trading this will be the case they will lightly prefer this but they might still want the full validity and security derived from ethereum and open you know being not an isolated chain but the part of the bigger ecosystem both are always Rich liquidity so that so that's your first uh bottleneck and as you can see like the various trade-offs lead to various different solutions your second trade-off uh or bottleneck is going to be your the data availability how you store

datability how you manage data available if you are a ziki roll up then you are competing with all the other Roll-Ups on ethereum ZK and optimistic for the block space because the block space of ethereum is limited it's kind of a zero-sum game if some blockchain is if some Roll-Ups will get more data there will be less data data availability bandwidth available to other rollers uh so which will lead them just to higher prices for for this data bandwidth so this is a big problem and the only way to solve it in the short term to make the the throughput really unlimited is to use external data

availability like off-chain data availability see you will still have Zeke 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 external with zero knowledge proofs it makes a lot of sense makes a lot less sense with optimistic approaches which we can discuss why uh but for uh physique error or Ops 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 solve for you and the third bottleneck we have is the actual ability to generate zero knowledge proofs and this is the least of our problems because the proof generation is today relatively cheap and we can do it on um on very broadly available Hardware so they uh we uh last week we announced an upgrade called boo jump a new proof system that has been that's going to be embraced by uh ziki sync era uh this is a proof system we've kind of been working on and off for uh for a couple of years is based on the construction called redshift which is just a combination of plan uh and uh plankish armentization and try

polynomial commitment and the implementation we have today only requires 6 to 16 gigabytes of RAM depending on your configuration you can you can choose the parameters like let's say 16. 16 gigabytes of RAM on a GPU is basically consumer grade Hardware you can do it on gaming machines you can do it in like on any cloud provider 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 with ZK using like something like this so that that is not really a bottleneck so data availability and the uh the the sequential throughput or the

sequencer throughput are really to 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 on even on a single data center like that that that that doesn't scale you need to be able to add more and more on demand it 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 if you're decentralized uh consensus then you will naturally be able to handle less throughput and and less like when you say decentralization in this context like what are you talking about uh decent generation of the sequencer oh okay if you want if you want to decentralize the sequencer as opposed to on okay it 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 you're not getting anywhere like you will be in the in the region of like one second the order of magnitude of one second maybe half percent basically you run something like tenement or something like that or perhaps tell them in the hot stuff uh like you need like even with the newest modification of hot stuff you need two rounds of consensus uh two rounds of messaging uh for for the consensus which means you have to like this send the message twice between different continents and you're just limited by the speed of light and the speed of communication those networks too like which will determine the the latency of

your consensus which you can eliminate if you're using like a localized uh data server for uh for a centralized sequence right so those tradeoffs 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 to 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 we've been working so hard on on making this architecture available in our in the CK sync Network and like 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 it's like you will be able to pass messages between say zikinsync like one of the easy guessing chain hyper chains and like one of the stock where uh stock net itself or one of the LPS 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 row up to another you will either need to use external liquidity or you will have to go through layer 1 and actually pass the uh this asset from one like Bridge

contract on ethereum which belongs to the kissing through the bridge contract of ethereum which belongs to some other roll up which will make ethereum layer one itself the bottleneck of this bridging which will not really scale for like if we're talking about millions or billions of users but within the ecosystem will inside the zika Singh hyper chain Network it will be possible in to arbitrary degree so like the way you can imagine hyper chances just like um like you have like domains for email you have Brian at epicenter or Gmail or whatever I have like Alex at matalabs.com you can send an email from any address

on any domain to any other address on any other domain you don't have to care about it you don't you know you like the communication is the same you just do one click and in a few seconds or minutes the uh 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 um one um uh 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 smart shards and how they communicate right yeah so if you want to learn like real technical detail like in deep technical

details on how it works I highly recommend this slosh paper where the the slash team has done an extensive research and documented really well how obvious will work but like the high level yes the two chains that transact between each other need to share need to have access to each other's state so this is already possible with all the Roll-Ups on ethereum the moment you finalize the state on one row up you can use storage proofs to to access the state of any other rollout because you can go you can pass like you can imagine that ethereum kind of Unites all of the states of all the Roll-Ups in one huge Merkle tree

where ethereum state tree is is like the the top of our of this huge Oracle tree uh 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 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 I burn it in favor of this destination on on some other hyper chain uh 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 burnt and here's a very very important part because both chains around 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 100 if I can trust it blindly because that chain is is like its validity is enforced by exactly the same circuits as my own chain as as myself as as I myself as a chain right so like for

me like I I can trust that chain as much as I can trust myself so I can easily mean this 100it on this chain like through some system counter that that has access to like minting and it's probably gonna be like a part of the of your bridging like you know your talkers will have to be aware if you either use system contracts for tokens or you use specialized tokens that know that about this functionality candle in this uh this asset and then you can use this assets natively so like the you need to be part of the Sim stay 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

passes for them because if you don't share the the same bridge that holds the assets then you can kind of like trust the other chain you can know you can be sure that they burnt some like 100 and you can mint it yourself inside your chain but you will never be able to withdraw this 100 because they don't belong to you they're not locked in your in your 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 bridging 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 ecosystem that is managed by entirely different governance you might like you know what you will have to write your specialized contract the custom user contract that says I trust stocknet 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 that's actually the first problem like even if we if we could manage the the um the ownership of this 100 if this contract would not be able to persuade this system contract that we should mint 100 if because the system counter does not know if starknet is not compromised by their government because 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 it's just a different system not not governed by the same like upgradability platform by the same code so like the system the system contract can only trust other system contracts of trusted origin it cannot trust user's code because if I can deploy arbitrary smart contract which says mint me one million dollars trust me bro it's like it's it's honest because it's kind of from the other chain the system conflict will say you know like maybe maybe not so it has to be a message that comes from the other system counter that actually burned this this community

but yes but then the second part is is we 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 trust Darkness Darkness we still cannot pass the uh the assets because they they are locked in different underlying Bridge 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 uh you can trust me but is there any way of kind of Faking that or do you need a centralized register how how do you go about that you will have a smart contract on ethereum

that will hold the Merkel tree of the uh um of the hyper chains let's call it the shared prover this or the shared verifier in this miracle tree all the state changes will only be authorized if they are coming from a trusted hyper chain and by by trust that I mean like from a hyper chain with the uh circuits that the prover contract knows because the Brewer contracts are always verifies the proofs against some verification keys yeah like so 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 it it it it's uh unambiguously identifies certain cryptographic program one circuit always produces one specific verification key so the so this bridge contract will have like one single verification key for all the hyper chains any hyper chain that wants to make a state transition must support this verification which means that they are enforcing all the rules the way we all agreed the 12 will enforce and this is also that the um the tokens on each hyper chainer actually commensurate right because basically I could be a evil hyper chain could say look I have a hundred eight I

will burn it I will reissue it on hyper chain 19 and then basically I when uh some sort of fake ether and kind of get really ether on hyper chain 19. absolutely correct so they have to to share the circuits maybe not all the circuits the hyper chains are actually highly customizable they are fully server you can choose your sequence you can choose your data availability model you can choose your extensions whatever you want but there must be some really small subset of circuits that enforce this Integrity that enforce this uh on the the acid 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 the 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 roll up so um as we as we talked about that yeah you kind of you need you need uh regular checkpoints at currently but you need a proof between checkpoint 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 um other people can no longer calculate the current state of the block and can no longer build on it and thereby I can effectively uh break it right I can kind

of I can't steal yeah but I 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 validiums which are basically ZK roll ups without data availability and this is kind of uh the direction that cello is going as well as polygon and so on how do you think about this spectrum of L trueness 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 if you look at how much you spend on the checkpoints versus on

the data availability um maybe you can give us the exact numbers for Z casing but almost everything actually is is for data availability rather than the the checkpoints right uh absolutely correct so I'll start with this last question indeed like uh absolute majority of the uh costs is going towards safety availability from like we currently have 30 50 cents per transaction depending on for trading uh gas price in ethereum across all robots the the bulk of this course is going to the table ability and it's not going to change even after EAP 4844 which will hopefully bring the costs down by a factor of 10x 20x but like the even the remaining one cent is going to be the

majority of the cost because the zero knowledge Pros computation part is Tiny it's like 0.0 something I you mean like it's hard to calculate exactly because there are many components in the system like it's really like you can Benchmark something uh in it's vacuum but it's getting detection from a real system it's not going to be indicative but like we know for sure it's like 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 the building something like validiums uh or Evolutions talk about that in a second um the the like let's reason about their l2000s I think we need a good definition

of what nl2 actually is uh and I I've not seen a strict definition adopted by the community like we kind of like knowledge uh intuitively but but not precisely I think a good definition would be nl2 is a chain that derives its security from uh underline layer one like Security in various senses like it would be alignments the security of funds the retrievability of the funds eventually and so on but like you need to derive some security from a lot if if you don't derive security like like four four like some significant security from from a one so as 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 they can freeze the whatever with Zeke here all up the security is 100 direct from layer 1. 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 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 in this case zq rollup is like Ironclad security is exactly the same as ethereum in in terms of its properties the validium is in between

all the transactions in validium are enforced by uh by zero knowledge proofs and ethereum so it's not possible to make anything invalid it's not possible to execute something not on behalf of the user so in this sense it derives a very significant part of its security from ethereal and for some use cases you really you don't care that much about data availability you only care about the um the correctness of the code like an example of this would be let's say online voting let's say that like you're voting like Let's ignore salvation persistence for

now let's let's imagine that we have some like perfect censorship resistant input because maybe like you know like what like each party collects their own votes and then each party submits there like you know like we have like you know blue party and the red party both of them get as many votes as they can from their respective uh uh 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 contracts not not just to humans to demonstrate which you could do off changes during generating zero

knowledge proofs you want to make make it available to conference 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 the oracles like if when you do Oracle updates you don't care about the state of the Oracle update because you can discard that like if this if the if the chain is Frozen who cares like you will be able to make new Oracle ticks on the neural chain when users migrate right like so 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 Valyrian does not constitute any reduction in security

because the 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 nl2 to some degree when we talk about the actual like real life secure like real world security for the user assets it becomes a lot trickier it's really hard to reason like we now we're back to this game theoretical a plane where we can imagine that the operator the validators of this validium chain that locks a lot of like you know some billions of dollars a few other 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 uh freeze the state maybe they are hacked because the the servers that operate the validium have to be on chat or online they the keys have to be on the hot machines so maybe there is some like ingenious way to harp the systems and they compromise the majority of the of the validators and then the hackers can demand around some you know like it 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 the I think the the ideal solution is the combination of both when you have something like Evolution

system where you as a user can decide for each of your accounts do you want it to be stored on ethereum like one uh you know on the zq roll up with full ethereum security guarantees but maybe higher cost of transactions on this account and for some other account you you you decide that it should be a validium or you know is it important 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 D5 protocols from your roll-up account and you don't

touch it every day at the only transactor early on it so like most of your value is there and then you move some of this value to your current account only on the validium side of of the evolution let's say on like you you on the key sync it will be called ZK Porter so you put it in the city border maybe you have like your millions of dollars on on that side and just a few thousand per month to pay for for your uh daily needs on the evolution side and so you kind of like 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 uh validium side of the evolution but you will have a lot more

transactions which actually makes the perfect sense from the from this balance perspective right like you will have a lot of cheap transactions a lot of trading going on there a lot of like a computational activity like uh orc updates uh and uh Arbitrage transactions and so on and so on happening on on Evolution side sorry can I quickly kind of question this to a certain extent basically if you kind of look how they Sello is transitioning to uh being in L2 they are not foregoing their validator set right so while kind of um CK sync and to be fair all other l2s have like a centralized sequencer which is definitely also an attack Vector

right um the the validiums that kind of we see emerging they already have a decentralized validator set um 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 could if you had a decentralized sequencer on ZK sync this this point would kind of fall but currently you don't right uh you can't really compare the two so first of all we we are committed to decentralizing the sequencer we are actively working on this we have a prototype uh which will unveil very soon it's it's running on the Hot Stuff uh consensus it's going to be fully decentralized as a sequencer uh and what you want to get from the

sequence of decentralization primarily is the uh the resilience and the aliveness of your network you want to be sure that the network will remain operational like for everyday transactions even if one or multiple part is a compromised or going down or unavailable of that reasons but the sequencer does not affect the security of your funds so you could you could argue that liveness is part of security I will admit that but if you put a lot of value in some D5 applications yes you will be annoyed if it's if it's not available and you might have some like opportunity costs uh for for not being able to use it for a couple of days but it's nothing compared to the uh to the to the ability to lose all of your fonts locked there like in for example right

but the validators can't steal from you right I mean so basically if if you have the ability to kind of run your own flow node you can't be duped about the state of of the chain you you can never steal funds yeah you can never steal funds like all you could try to do is like the validators could could try to double like they can can't even do a double spam like they they can only do some short-term uh faking on chain that will never finalize on ethereum and if you're if you you're you're making high value transactions you always want to wait for the final find like for the finality on ethereum for the checkpoint it actually guarantees that this transaction is final before accepting it if you're expecting someone

like for someone a payment of one million dollars you have to wait for ethereum file you cannot trust the sequencer to just oh I have a confirmation absolutely but that's the same on validium right so on the radium the validators or like your your guardians 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 kind of makes the data available great question like this is a big misconception about the data availability systems the like 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 two-thirds of the validated set is malicious then they will do a state transition without sharing it with any of the honest validators so even though you have one third 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 uh for 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 on the chain okay so you need more than one that honest majorities can decide is it like one like fifty percent uh two-thirds whatever but like some quorum the the this Quorum that decides that yes we can accept the state transition because we like the the um 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 author for this contract to tell it subjectively it cannot talk to all the validators it cannot like make data availability assembly because it's a smart contract it can only work with a limited amount of data that has been passed so the uh what what the contract can verify is like okay do I have enough signatures do I have a quorum of signatures let's say two-thirds it's a limitation of this verification code okay yeah that that totally that clears up my question um so if you look at kind of how Z casing and all other air tools are implemented at the moment they're all upgradable usually from a single multi-sig right so I 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 there too um so how how do you then mitigate kind of the risk of compromised key attacks right because say there's like 20 or 20 people on your on your committee and you need like you know 10 signatures for upgrading the contract in if allowing you to steal funds and so on like act actually ceiling fine the funds not just freezing them how do you mitigate that risk this is a great question uh and this is something like if you if you you would

ask me like how I feel about this upgradability I would say I feel terrible like I I uh we the atziki sync the very first version of the protocol we deployed is of executing version one which is now called the kissing white it was completely immutable it was immutable with some upgrade period because we could not tolerate that like the the idea that some multi can control upgradability or the team can control applicability and just propose arbitrary changes completely defeats the idea of this trustless Scalia right so like that that was something we were uh we were finding disgusting and then we had to learn the hard way that like we're way too early we have to make the um we have to react to

vulnerabilities because the Box will be found in the short term uh 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 uh react in a timely manner to threats so we came up with the idea of the security Council and since then at like the the second chain that embraced the security Council was arbitrary earlier this year and now it's it's a uh it's a broadly popular idea that like all most other genes are embracing and italic and l2b they are making great effort to to okay push for it to a set time high bar of standards

of what constitutes a true security console 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 uh upgrade which will execute with some time log so that the users have time to withdraw from the protocol if they don't like the change or if alt right the protocol looks malicious now if you deal with an emergency if there is a open box on your system on live smart contracts you want to be able to accelerate this and this is where Security Council will kick in and you will 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 called 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 one government goes wrong and tries to like hijack the protocol they will not be able to do it like 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 it's not like this right but 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 maybe Hardware wallets or air gap machines or something like highly secured is a lot harder than compromising the uh online servers with hotkeys in memory that are probably running in some Cloud providers that have access to the internet that are vulnerable to zero days to compromise the the the the cold wallets that are not connected to the internet

someone would have to go and break into like all of the multistic participants which is a little harder but it's still not if not a perfect solution and uh the perfect solution would be to bypass the need to like to to withdraw the rights of upgrades from both the team and the security console all together so the I can imagine the world where the security Council appointed by the governance broadly 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 a treatment

they should go and do this and then they should bring this question to the protocol governance and the protocol Governors 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 in the majority of the token holders is it some broader set of participants like you know 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 often 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 layer one uh you know maybe initiating a an upgrade in a way that can only be accomplished with a soft Fork of layer 1 itself if there is a disagreement between different parties of our of these governing entities so this is a big question which requires a lot more research but I hope I could add some flat cool no that was very helpful so one question I think is kind of like very connected to this uh you mentioned you know the risk of bugs I mean I've also heard of other people being quite concerned about this with regards to ZK Roll-Ups can you talk a little bit about you know where are

the risks of you know bugs and and what kind of consequences could we have if there are maybe bugs at different places well all of the Roll-Ups 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 that they are secure the Box can happen in various places uh for Zeke Roll-Ups they're really like if you look at the complexity of the systems the complexities um is bounded to different isolated components so you could have a bug in cryptography

potentially theoretically that could allow you to fake proofs or you could have a buck in circuits that would allow you to if you have like if you are the validator you can submit any proposal for the new blog you could submit a malicious block and then fake the proof that this block is uh is actually valid right you throw a box if you forgot some constraints if some things are are missing in the circuit so to mitigate these things it's it's actually a lot easier to do in zikiro apps than saying optimistic collapse because you can create redundant systems like the way it works in in all Mission critical systems today with like live uh 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 Pros you want to do things like to fa where you need two separate mechanisms in in in in the case of Ezekiel roll up for example it would be first a consensus of the validators has to agree on on that the block is valid and only then they produces your knowledge proofs and ethereum contract verifies both the signatures of the majority of the validators and the easier knowledge proof and only both

match the new to make a state transition so now if there is a bug in cryptography it's you in addition to to Breaking cryptography you have to compromise the majority of the validators 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 ziki sync era for example like the the laser withdrawal the the withdrawals are delayed by a few hours in addition to just verifying the the proof you could say that like you would also need to compromise the security Council who would be able

to spot the problem and freeze the contract before the new malicious State transition is compromised which will bring you to 3fa and then in 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 console we would require a trusted execution environment like sjx for example proof that the state transition is valid it would give you like four layers of protection that you have to bypass and you don't have to rely on Intel or uh or nvida and video or other providers for this like if the sgx become a proofs become unavailable then the governance can always intervene and

just switch them off this would be something so like you you would always have kind of a multi-stick of several different components with uh 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 that 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 uh to choose sort of whether they want centralized sequencer or decentralized sequencer and maybe different types of parameters so are you is a result is that correct and then for the path of okay I want to decentralize sequencing solution are you guys building decentralized sequencer and you know how what's that what does that look like uh this is a correct statement we are focused now on the ZK stack so we're which is based on the source code of the kissing era and this is a modular framework this is a framework where you can

replace different components from the sequencer to the uh um data availability layer to to the way you handle MVD like all these things are going to be customizable for you and you have the full freedom to choose what components you use in what way but but we have to provide the basic components uh which some of them we are working uh on at meta Labs some will be provided by the communities some will be provided by the grants program that that we we want to initiate but sequencer is really fundamental it's one of the most important parts of the uh of the stat and this is something we definitely want for the for for error we don't want error to remain in a chain with a

simplified sequencer we want to go 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 uh we're using Hot Stuff uh or modification upload stuff called Hotshot for it which gives you a very decent throughput at a very decent latency so for for ZK sync we always take the user needs as the you know as as the like the the north star of where we want

uh the architecture to go like we always architect back from the ideal user experience we'll 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 that's kind of the the um the Utopia the crypto topic 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 uh Hotshot was was meeting these criteria's a great area so it became virtues so is there just to clarify this here the

consensus here so it's basically like how does that work does it basically mean you have it kind of like improved 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 odd stuff just used to basically choose the sequencer and then for some point you know you just have this one party that's

a sequencer or like how does that work uh so the the blocks are being produced roughly every second and it every second the the the the the leaders decide that and and they all of the validators reach consensus on what's the next block if some of the participants go down or become a responsive it will uh self-repair quickly but every second we have an insert yeah yeah okay everything and then you feel like all of these things that are like huge topics at the moment on ethereum you know like around the me Pipeline and you know the proposal Builder separation

those kind of things to what extent will this carry over to uh like this and the kind of decentralized sequencing secret sync Roll-Ups uh this is a really really good question I don't have a definitive answer to it we are in the research phase we are looking at all the different developments there we're in touch with the ethereum foundation with uh with guys building uh there are really amazing teams out there being shared sequencers uh who think that share sequencing is is the Paradigm for ethereum 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 uh to a world where proposal Builder separation leads to just a few entities essentially building all of the blocks on 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 eventually like to like like a some Google or Facebook or in your something like big corporation like this to be powering all of the blockchains with nominal decentralization through uh through Solace taking so we want to design systems that actually encourage decentralization in various regards but there is a popular opinion uh that that

might not be possible and eventually because of the complexity of MVD extraction and the value that you can produce from there that the the this inherent specialization in 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 decentralize the systems with a lot of individual uh participants with uh with uh with ways to actually mitigate Mev and like it it to prevent at least toxic MAV from happening like targeted immediate attacks I think there

are designs out there that that largely can accomplish this but I've also heard concerns of of schemes like encrypted mantles that they they could lead to other problems leading to like less efficient uh Arbitrage 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 DK Singh the you know to our core values and we we have not discussed the ZK credit yet but this is like I encourage everyone to read and contribute to the ZK credit which is our mission and philosophy and values statement we will do everything we can 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 error and I think the community will support it that maximize the decentralization and trustlessness and minimize Med uh 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 of Maximum mov and then Distributing it to the community to Trying to minimize Mev and work with like first conference serve principles or encrypted mempools 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 uh lots of these actually sound super interesting but we are already way over time 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