ZK Whiteboard Sessions – Module Nine: Introduction to zkRollups with Barry Whitehat

Transcript

[Music] hello everyone my name is bobin i'm from polygon and we're here today recording another episode of the zk white board sessions and here with me today is barry whitehead from the ethereum foundation and we will be talking about gk roll-ups so i guess the first question barry in general what is a roll-up and why do we need it right so a rollup is a way to scale blockchain okay and we need it because we need to because blockchains are really the the like amount of transactions they include is quite low so like the way that blockchains work is that there's there's always this commitment there's

always this state and the state is basically like how much money everybody has so this is this is like one person this is another person this person has like 10 and this person has like nine yep and then every time we make a new block we have a state transition right and we move from from this state to a new state so let's see what the new state looks like okay so this is the new state and we updated these two leaves so what's the what's the balance of these two leaves okay so this leaf let's call this one nine and let's call this other one ten okay so basically what's happening here is like this user is sending one something to this other user and this is called the state transition and like the

way that blockchains work is that this state transition is validated by all the all of the nodes so there's many many observers and they all observe this state transition and when you see the state transition you say oh this is a correct state transition and when you say observe they actually i think re-execute the transactions to get the same exact state transition exactly okay yeah so so so the way that a blockchain works is that we have this state transition everybody is observing and confirming that it's correct if if someone presents an invalid state transition all the users will ignore it all the users would be like oh that's not correct i don't want to be part of that i want to be part of the correct one and this is how blockchains work and this is why they're they're secure so they're secure because everyone is

checking but like the problem is that like when we have money when we have a state transition and we have many users to check we want to make the same transition as simple as possible so that we maximize the number of users that can check like the way that we do that is that we just reduce the number of transactions that we have here we have just one transaction and this makes it easy for us to validate yeah so so if we wanted to put a million transactions into a block some participants in the network would just not be able to keep up to validate all of them exactly yeah but like what we do with rollup is we want to put a million transactions into a block so let's talk about how we do that yeah so with a rollup we we have the same

situation but instead of having everybody check we have we have something that guarantees the validity this can be a ckp or it can be a fraud proof okay and basically what happens is that the zkp makes sure that all of these transactions were done correctly and this gives us our validity guarantee but we also need to have a data availability guarantee because if okay so because if you if users don't know the new state of the system they won't be able to make more transactions they won't be able to withdraw and like these are two important issues so in order to guarantee that our data is available we make sure that our proof also comes with a representation of all

the transactions that happen so let's take an example here we have a transaction where this person sent one dollar to this person so what's the the simplest representation of that the simplest representation of that is the 2 is a two the from and the amount that was transferred right so we say okay so from user zero from user zero to user one we transferred one okay and with that information and the previous state you're able to calculate the new state makes sense yeah so now um usually when you sign from like when you send transactions you sign them right there is also a signature involved um and this is when we are talking about l1

on l2 is very signature as well like when you're when we're talking about roll-ups yes so in the context of rollups it's really important that that user's consent to this transaction because on layer one everyone signs to say oh i want to send this much money from from me to this other person so it's it's important to do that on on layer two as well so and we do that exactly the same way we have signatures and like yeah we have signatures and we use those signatures for users to consent to say that oh i want to send one i want to send one token from me to this other person makes sense makes sense um okay so to kind of like make sure i understood

everything um in the zk roll up there is a separate state so we still have the l1 state which is separate and then there is an l2 state which is uh now this represents it and then the validity aspect it proves that the l2 state was transitioned correctly yes so um i'm just trying to understand a bit more about like interaction with an l1 and o2 so like let's say we have an l1 a smart contract or something like what do we what do we actually push to l1 uh when we have a transition on l2 okay so let's take this example and let's let's let's draw the smart contract that's used to execute this example so we end up with two layers so we have layer one this is the this is the blockchain that

already exists this is the one that we talked about earlier where everyone is validating every single state transition this is the one that we talked about that's very few transactions per second and inside of this we make a second layer this is that we make a smart contract this smart contract it makes our our layer two and basically what this smart contract does is it accepts accepts as ekp or a fraud proof or fraud proof yeah it accepts and and some call data and and like maybe call data is not the best word so like there's different words that are used to describe the minimal representation of the state transition so like some people use diff some people use call data what do you think is a good term for

this how about state right state transition representation yeah let's go with state transition station it's a bit of a mouthful but let's go for it okay so so they put the ckp and they also put the the state transition representation t or yeah uh they put both of those things into this into the smart contract and the smart contract then basically does the following things number one it verifies the dkp is correct this is our validity guarantee make sure that oh yeah this this this this transition is correct all of the users consented to this list

of transactions secondly it checks that this list of transactions is is included in the zkp it checks that like the state transition representation is part of the zkp that's the second thing that it checks and the third thing that it does is it remembers the new state so it used to remember the whole state root and after we do the state transition we go to root prime yep and the smart contract just says okay root prime is our new latest state and so we have this is our layer two this is our layer two and our layer two is basically like a contract that tracks root the root

every time we update the root we give it a zkp and we give it a state transition representation and this guarantees validity and the state transition representation guarantees data availability makes sense so just to clarify a few things so the route is the commitment to the state right uh so by kind of like knowing what the route is we know kind of that there is a state that is a specific state and it cannot be changed very easily and that when we execute the smart contract and verify this the root actually you know changes right um why uh can we just you know simplify this and just have a root in there as well uh like what would happen if we don't have the state transition

representation you just have a zkp and a root okay so let's talk about that so in that context what would happen is that we remove the state transition representation and our users who are observing the system would not know this information if they don't know this information if they don't know this information they wouldn't be able to withdraw or they wouldn't be able to do another state transition right just say transition because this is one state transition but we're going to do many many more like the point is that like each of these state transition functions is like a new block we're processing transactions but we have more transactions coming we need to process them and if we don't know the data we're

not able to do we're not able to do another state transition and we're not able to withdraw so that's why the state transition representation is a very important part of the the guarantees of of rollups so while you know zkp guarantees that you cannot do invalid transition there is still you know somebody who doesn't reveal the state they can do uh like valid transitions but hide the actual state and then it's kind of like you're you're stuck in that situation where you don't know exactly what the state is exactly so like it's kind of like a ransom attack yep makes sense and then uh is if we don't put the state transition representation that is technically not a roll-up anymore right yes okay that is correct okay

so roll up you have to be able to reconstruct the state and i guess that brings me to a question like what are the properties of a roll-up like what do we want to say like this is a roll-up and this is not a roll-up like one of the key properties that we want our guarantees that we want to ensure so what we want to ensure is that like the roll up inherits is security from layer one this is the key property of rollup because let's look at the the situation that we have we have a layer one that's very secure because many many people are checking it many people are being careful about is this correct and we want to include more transactions but we want to have the same security guarantees so basically what a roll-up does is it says okay i want to inherit

those security guarantees the two security guarantees are validity and data availability so we we use the the fraud proof or the problem for the ckp to verify the state transition function and then we use the the layer one to guarantee the the from proof that the zkp is correct and also to make sure that the data is available so the key thing about rollups is that we want to inherit our security from layer one that's the key property they're trying to achieve and i guess by security we mean maybe a couple of things that one our funds cannot be stolen uh from a roll-up uh and the same kind of applies and the second one is our transactions cannot get censored right yes um i guess

we didn't talk about this yet but i'm curious so who is actually generating the zkp's and uh putting this on l1 like is there an entity is it one entity is it many entities like how does it usually work and what are the trade-offs of different approaches so there are different approaches here so like as you said there's always that there's always an entity that needs to create the zkp yeah so they have like some powerful computer or maybe not so powerful depending on the ck roll up and inside this this powerful computer they can compute the zkp right they they they get transactions from from the users our users are here let me draw some users yeah

they get transactions from our users and then they use those transactions to make the ckp finally they send the zkp to the layer on the layer one the layer one then puts the zkp into the smart contract and and produces a layer two block so the entity that makes these these proofs it seems like they're quite powerful because they're getting transactions from users and they're they're putting them on chain and like we said before that like one of the things we want to guarantee is that there's censorship resistance here we want to make sure that like this party isn't able to censor other users and my son should produce and basically if i want to get my transaction if i have the funds in the roll up i wouldn't be able

to make sure my transactions get executed yeah so this party could theoretically just say ah i don't like this user i'm not going to include their transactions right so so right how can we decide who to be the coordinator it seems like it's such a powerful position so there's two approaches to to limiting the power of the of the of the block producer and like i recommend that like we all we take both approaches but let's talk about them and and see so the first one is to basically say that okay let's just make other people who are also able to make ckps who also have a computer they make their zkps they make those ekps two to two and they

send them on chain and we have this kind of like competition and the users are then able to decide oh i want to send my transactions to this one instead basically whoever will be willing to process my transaction yeah exactly so this is the first step in kind of like preventing this censorship issue and this somewhat replicates like a l1 dynamic right you have uh kind of some form of consensus that these guys need to come to before they can send something to unless maybe there is a race condition if they i'm guessing there are many ways to like coordinate these guys between themselves right yes yes yeah there's many ways for them to be coordinated one of them is is is proof of stake

proof of stake is is basically where everyone puts down a deposit and like you trust people you you assign people a right to make a block based upon how big their deposit is and the reason why this is secure is is that basically if this person puts down a deposit they're they're losing something they have like an opportunity cost with that money yeah and when they receive transactions from users and they don't include them they're missing out you know they could make more by receiving transactions from other users so that's how proof of stake works and proof-of-stake is very secure on layer one because on layer one if there's some very rich person who is getting the opportunity to make money blocks

and decide i don't wanna make blocks for this user i i'm going to censor this user i don't care that i'm losing a little bit of money because the amount of money i'm using is so tiny compared to the size of my stake it's not i don't like that user i'm not going to do it and if that happens on layer 1 we can have what's called a hired fork to recover basically on layer one we the other participants say ah that's not that's not the rules of the system that's not like that's not the the properties of blockchain we're going to change the system so you don't have that state anymore so you bring like a social aspect to this and be able to kind of recover through through social means yes so on layer one you can recover from this type of censorship attack by a

social recovery hard fork unfortunately this doesn't work on there too because if we were doing the same thing on layer two and like a certain user and the same attack happened and we wanted to do a social recovery hard fork we couldn't do a social recovery hard fork of the layer two we would have to do one of the layer one and like historically it's like historically it's been very rare for there to be hired forks to recover broken smart contracts and i think that in the future it's going to be very very difficult to do it's very hard to justify that because it basically means that like everyone has to change their philosophy or everyone has to accept this might slight change in order to to help this broken

thing so because of that i think that leader election via proof of stake is is is not a good mechanism on layer two yeah because if somebody as like controls the significant portion of the stake they can still censor transactions yeah exactly so instead of doing this we can we we can have some other mechanisms so like we talked earlier about like how on layer one we want to inherit the security guarantees of layer one and layer one has very good censorship resistance so how can we inherit this guarantee well one thing that we could do is we could let me let me make a little bit of

space here is that we could add something to our to our to our l1 to our to our rollup and we could basically make this kind of like forced transaction right okay so do you explain what it is yes again so let's talk about the context first okay let's say that we're in this situation this user is being censored not just by one coordinator but by all of them they're running the kind of like the same attack that we discussed earlier and the layer to the the and this user is just not able to get their transactions included so the idea of a forced transaction is that this user could instead of sending their

transactions to the to the block producers could send the transaction to the layer one and because layer one has better censorship resistance guarantees the transaction can be included by the transaction will appear here because because like layer ones censorship resistance guarantees are very very strong so the logic in the smart contract will actually say you cannot execute the state transition unless you execute this transaction is that right yes oh that's right so so the next part is that like once a transaction appears here if this if any coordinator wants to make a new block they must include the transactions here that's the that's the rules of the system

so i guess the only downside of this approach is that you do have to pay the l1 costs for the transaction to be able to do this right so the the the l1 cost is going to be higher right because like we built this whole system we built all of the roll up in order to be like oh we're not able to do a lot of transactions on layer one so if a user has to put a transaction on layer one in order to get it processed that's that's that's kind of defeats the whole purpose right so what we can do but there's ways first to mitigate this and basically what we do to mitigate this is instead of putting a transaction here the user can produce a zkp the user says okay i'm done i'm going to make a zkp

and they can put the zkp on jane and this would be like a representation of many other transactions they can get this transaction from this user or from other users and it's possible for them to to sort of compress these like many transactions together just like we do with a rollup so it's possible for the cost of the forced transaction to approach the cost of like a regular roll-up block okay so there is some coordination effort this guy needs to do but hopefully he will not need to pay the l1 cost if he is able to get enough other people to include into his zkp right yes okay and this this is like some important nuance here is that because transactions are super

cheap on layer two and they're really expensive on layer one if there's like a censorship attack against like a user or a group of users it can be really difficult for them to withdraw their money because the transactions are just so expensive like if i have like ten cents on a layer two and the ethereum transaction fee is 12 cents i can never do a forced transaction yeah so it's important that we have these mechanisms to force transactions that are as cheap as the as the layer one gas cost or as the as the layer two gas does although otherwise users can be kind of like trapped inside a roll of biome by a malicious malicious user a malicious coordinator block producer okay

so basically and just to summarize there are a couple of approaches one approach is you know you kind of have many uh block producers or it's a decentralized blog production to some extent and that helps you in in some ways but it doesn't prevent the worst-case scenario uh and the worst case scenario can be prevented by doing this forced transactions when you know if all all else fails and then uh you can go through l1 and do it and hopefully you know the mechanism that you described can make it actually not super costly to do yes okay yeah make sense now um i think one of the things that is frequently talked about is like do we actually need to have many like if we have forced transaction like mechanism is there any value to having many block producers can we just have one

block producer and say that's enough so yeah so this is an interesting trade-off because like if you have a single block producer you get some other benefits right you're able to have different features like you're able to have that that coordinator kind of like give you like a weak promise that they're going to include a transaction and they can give that to you very quickly like that's just really nice ux people who are used to web 2 just click a button and it says yes and like we want to have that same user experience for layer 2 and like one way we can do that is if we can have like a single block producer and like the good news is that like it's possible for us to have to use a force transaction and a single

coordinator to get approximately the same guarantees like we're inheriting the censorship resistance from the forced transaction uh and like we're getting some of the like nice benefits of like a centralized processor by just having a single coordinator so it's also possible to have a system where where we can transition between the two systems we can have a single coordinator where we have these nice properties and we can also have like another coordinator who appears and says oh i want to be a coordinator too and we can have a system where like they're able like one coordinator is able to provide the instant finality guarantees and the other coordinator is like there's all these different ways that we can build a system that's that's that's able to have this kind of like censorship resistance and inherited from

layer one and i guess you may still want to have like as you said maybe like a backup coordinator or something like that or maybe people being able to come in because in case this guy's goes down for whatever reason you don't want to sacrifice the liveness of the system right exactly okay make sense so we talked about how do we enforce validity but one of the things that i'm kind of still curious about is this uh state transition representation so you do need to put data on chain and i guess the question and i think you uh kind of explained it but i wouldn't dig deeper into it like is this actually cheaper than like regular transactions like what is like why is this uh data smaller than what you would go with like regular l1 transactions like how we're

able to make this more efficient uh from data from data perspective okay so let me talk about like the difference between the costs of like layer one and there two okay so let's take a look at like what's included in layer one transaction so there one transaction has a bunch of data data associated with it it's like two from amount and signature and the layer two transaction uh basically can we can do a couple of things the first so so we have to basically have the same representation

but we can reduce the cost a little bit and this is like just this is a simple transaction we're not talking about smart contracts yet this is like a very basic like payment transaction yeah exactly this is very simple so on there when we have these costs uh for the next section i'm going to talk about okay let's do optimistic role of antique roll up so let's see what uh optimistic roll-ups will do so optimistic rolls have the same have the same thing they have two from amount and amount and signature so the one thing that optimistic roll-ups can do is they can reduce the size of two from an amount because on layer one two from an amount are like uh

i think it's like how much is it how much is the 256 bits okay let's say it's 256 bits yeah 256 bits i promise 256 amount is 256. like although it's like not it's exactly amounted to fifty three for this purposes i think that's fine we can we can round up or estimate it okay and signature is much bigger let's say it's like 512. yeah okay so this is the the size of those so so on on layer two we're able to reduce this a lot uh we can we can probably put this down to like 32 bits 32 bits uh 32 bits and signature is still has to

stay the same as by 12. so 12. okay so we're already getting some gains we're reducing their outskirts by having this like compression algorithm that we're using um right so could the layer one apply these same optimizations could the layer one reduce the the size of the two address the from address and it it could it could but it wouldn't give any benefit because on layer one everyone is executing the computation and if you reduce the size they'll need to check that the size reduction was done correctly so we'll just add more computation so layer one has bigger data

footprints because execution is expensive but in optimistic roll-ups and in dk roll-ups we have we have cheaper computation the computation is is very cheap so we're able to reduce the data size the next thing to look okay so let's look at zk roll up so zk roll up is very similar to optimistic it's the same to from amount but it doesn't need a signature the signature gets removed because the zkp verifies the signature in an optimistic role the fraud proof verifies the signature so because we're able to put the zkp we're able to replace the dkp with the

signature we're able to replace the signatures with the ckp so we do need to put a zkp here right but although zkp gets amortized across all the transactions in a given block right yeah we put the zkp here which is bigger than one signature but because the block contains many signatures it ends up being cheaper so let me just write up the cost here so it's 32 bits 32 bits and 32 bits for the amount and then different proving systems have different sizes for jkp some are very small right like 16 i think is just cost of a few signatures probably yeah yeah and and like starts are quite big yeah yeah and so there's different trade-offs there like you can have a start can

include more transactions though so like maybe stark is going to be better because it's going to have a thousand transactions like there's trade-offs here we need to need to think about one other thing to mention is that like it's possible for optimistic roll-ups to to replace this signature scheme they can use something like bls signatures instead of the current signature that bls is a compressible signature scheme you can aggregate together many signatures so it's also often possible for optimistic roll up to to sort of remove the signature requirement would that require like l1 to be able to process these signatures efficiently um or yeah it would require that but it's actually possible to do that right now like

you can do bls signature verification and actually theoretically optimistic roles would be cheaper than dk rolls because they wouldn't have to include the zkp or the signature uh but it would be cheaper but it's very small difference because it turns out we can make zkps that include many many transactions one other thing i wanted to ask so uh in the tree that you draw previously like where you had a state um in the context of zkp and my understanding is that you only need to like put the final state of the let's say um let's see if i if there are three people involved and i send tokens to you and you send tokens to another person what needs to go on chain is only that i like

i sent one token to someone and someone else got token but the intermediate transaction doesn't need to be recorded ah so this is a tricky this is a tricky situation because okay so what you're saying is technically correct but like what one thing we want to do with with blockchain done with ethereum is to make sure that transactions work once and only once okay and there's there's two ways to do this one of them is that like every time someone makes a transaction you use a new leaf in the tree and that means that the old leaf is just kind of discarded and thrown away the other thing you can do is you're going to use something called the nonce and the nonce is just like this number that every time it's the count of the number of transactions you make every time you do another transaction you

increase the nouns by one so in the case where you where you discuss oh so let me add this here so like ethereum uses the notes because that's that makes the tree space that that makes the tree space like it allows for the tree space to be used more efficiently yep so then like you could remove the nonce but then you would have to make this number bigger so in general people use the dots but why didn't i put the nonsense in the data availability before well we have the nonsense data available in layer one but on there too we can remove it right because we already have this implicit idea of nuts because we have this from if there's a problem you know you have to increase that nuance by one so we're

able to remove the able to remove the nonsense so like the optimization that you're talking about it's possible but it might not work out as being the most efficient thing because although you get rid of the nonce and you don't have to put it on chain you end up like using your state tree less efficiently makes sense i guess it depends on like what representation and that's actually maybe a good point a rollup doesn't need to follow the same state model as the l1 you can experiment with different state models so yeah and some people have done that using like um making like a zk roll that's a a kind of automatic what is it amm stand

for automated market maker automated market maker exchange yeah yeah this state is completely different yeah so you can have like an account based system you can have a utxob system or anything in between or something new exactly yeah there's a lot of space to innovate but like there's a lot of things that people are optimizing for that like you might want to optimize for uh call data sites maybe you don't care about that maybe you want to optimize for like uh simplicity or something else there's always there's a big trade-off space with many things to to worry about or to care about okay so basic takeaway we can compress things and that's why so the in the previous kind of uh

discussion about validity we simplify the computation burden right because you don't need to do the computation all the computational one here we're also simplifying the data burden so to say because you can represent things succinctly but it does seem to me that you only get a constant improvement here right it doesn't uh like if you need to put some data you can only shrink it so much you can't shrink it exponentially am i thinking about it right yes i think that that's correct so there's there's more advanced compression algorithms we are only scratching the surface of like what is possible that you can have ah so there is some interesting thinking here that like theoretically when you

make when you put data on chain you need to put data on chain for new blocks not for old blocks so if you wanted to make transactions for like if i wanted to send 10 transactions every month to the same people with the same amount i wouldn't have to put a call date on chain for that i could just refer to a previous block i could just say that oh i made this block last week it's the same block just process just this is the same data so like once data is available it's possible but like that's this kind of like nuanced kind of edge case and i feel like that's like what you're asking is like is different than that i mean that's one thing to to be aware of but in general there is

oh so in general we're moving from a world where computation costs one layer one computation is expensive on layer two computation is like effectively free because we don't have to do we don't we hardly ever execute our fraud proof and we and our zkp is is constant time verification because of that like data becomes expensive and data is a new thing to worry about and it's impossible to compress data infinitely you can never just get rid of data yeah um there isn't the other reasons like you can give up some of the security guarantees to like the validium model or whatever else like it's not a roll up anymore right but you can say i'm not gonna put all the data uh on chain i'm just gonna put truth over the state and

the actual data is somewhere else like there is something else but then you don't inherit quite the same security guarantees anymore yeah you don't inherit like a validium doesn't inherit the security guarantees of ethereum yep it like it affects the it affects the state it affects the data availability guarantees which like also ends up affecting the validity guarantee oh no it doesn't doesn't affect the people yeah it is not really but like yeah so it affects the data availability guarantees so it means that like users can be used users can lose access to their funds and like a malicious coordinator could use that in order to extract a ransom or extract high fees from their users yep yep so

like you mentioned that like okay there's this problem of data availability like how can we scale past that yeah so like the the kind of like after the merge and ethereum the next major feature to add is is ap4844 and ap4844 basically adds a lot more call data an ethereum block right now i think includes order of of of kilobytes per second of data and ap4844 will be like one megabyte per second or one to 16 megabytes per second so it's going to be this major scalability upgrade okay yeah and in the long term like sharding and things like that will give a look even more is that yeah so like yeah that's true but like

the sharing has changed so much from when it was originally defined because charity used to be like oh we'll just have like many people executing different things but now sharing is just like oh we're just data availability for many different people makes sense it's kind of like data sharding not execution charting anymore right it's definitely okay make sense okay so we talked about fairly simple models for the roll-ups where this is just moving you know some amounts of tokens or whatever coins from one account to another what other types of roll-ups are there assuming we say we want to do something as sophisticated so we can do an l1

ah so we can have a we can have a zk roll up that supports the ethereum virtual machine yeah so it's more kind of like a general purpose roll up not just a specialized roll-up that does only transactions yeah okay yeah so let's let's talk about how that works so in order to talk about that work how that works first we need to talk about like how ethereum works so let me clear this and we can we can talk about it all right so we talked about fairly simple roll-ups where you just transfer tokens from one account to another but obviously we get a lot like with l1 we get the ability to write smart contracts and like little custom logic and all of the cool stuff can we do something similar in a roll-up context yes we can um

so it's possible to do that with optimistic roll-ups and i think optimism membership both have like optimistic roll-ups that are that are like evm compatible and it's also possible to do that with zk robs but it's a little bit more difficult why is it more difficult that's a good question um why is it more difficult well okay let's look at the roles we talked about before that like when we were talking about the robes before we had like a merkle tree and like we did a very simple state transition where we just like like this sleeve and this leaf we updated them so basically we just like changed two

things and we did the search transition and it was easy to make a ckp for that the computation involved here is very easy and it's fairly simple to put a gkp together that can prove that computation the key is that the the the the change is not dynamic it's constant like okay we did one state transition here i'm going to do another one where we change another two leaves and like what we're doing is the same all the time we're just changing two leaves we're just updating two leaves and like because we're doing a constant thing all the time it's easy and like we can make application specific roles that you mentioned

earlier like we can make an automatic automated automatic market maker roll up where like we're doing like what uniswap does but we managed to encode that in a way that's like just updating several leaps just changing several things the logic is fixed basically logic is fixed yeah and the problem with the evm is that the logic is dynamic i can deploy a smart contract that does anything i want and like if we want to make a zkp for that we can if we want to make a proof about that we need to like dynamically adjust so there's all these different kind of approaches and mitigations that people have taken to try to allow you to have smart contracts like the simplest thing to do is that like to say that okay

every time i deploy a smart contract i'm going to make a new zkp right i have one zkp for this so i'm going to make a new one for amm and i'm gonna make another one for something else uh for for e and s then but this is this is this is hard to do it means you have to do like a whole bunch of different setup phases it means that like you have to update your smart contracts with the new proving keys it just becomes really difficult to do and i would say also a person who deploys it actually needs to be able to write zkp's right right they need to have the special expertise which is slightly more complicated right than

writing celebrity smart contracts i would say bobbin is being very humble yeah yeah yeah it's it's a lot more complicated than i think than the density contracts because solidity contracts are like a paradigm that people already understand uh with these smart contracts you're just doing like oh check signature and add this money to this yeah and subtract this money but with zkp's you're not able to do these things you're all you're able to do is just like a plus b equal equals c you're just able to check that like different numbers are that that like there's this constraint they have to do these numbers and like you eventually use this to compose like

a signature check or like other things but like it's really hard to do and it's not a good developer experience especially for like the i don't know is it millions or tens of thousands or thousands of people writing smart contracts like for the people writing smart contracts is really hard and like one thing that we think about when we think about like oh how can we scale ethereum it's like developer experience but like this was this is like a mistake that a bunch of people made originally people thought that like oh i'm just going to build my thing and people are going to just come and come and use it but they didn't really take into account that like it takes a long time to teach people how to use a new a new thing so yeah and then learning curve here is probably super high and yeah yeah yeah

so this is one approach let's talk about some other approaches because i don't want to spend too much time on this so this is this is one approach to just make like special ckps another approach let's talk about the compiler approach oh i'm going to leave that there actually because this is yes so like we have a system where we have a smart contract for amm this is a smart contract and we have one for ens this is a smart contract too and like basically we say that okay well let's just make a compiler that compiles them across yeah let's make a compiler that converts

this into this and like this works too but there's some concerns here some of the concerns are the compiler security is very difficult to be sure about that like we have this compiler here that's converting one thing to another how do we know that it converts exactly the same yep the other thing is that like this smart contract is written with like a certain set of security assumptions in mind but moving to a different a different a different execution environment like as ekp those security assumptions can change that's the second concern here that like people are very worried about like compiler based approaches because like this could be an issue

uh there's another approach that just says let's make a special dkp and compiler and like let's not use solidity like in this example i was talking about this was this was like solidity contracts uh but yeah this is in this example but but i also think making a compiler that compiles arbitrary solidity is probably a challenging task in itself yeah it's not easy yeah yeah i mean i think the complexity approaches the complexity of the ckvm uh well yeah it's not easy so those are two types uh let's talk about like the third type where you're really starting to get close and like basically the third type is where you figure out a whole bunch of the problems related to

the zika vm and you say that like okay well what's in ethereum so there's stack there's by code memory yeah memory storage or something yeah storage yeah and you say that okay i'm gonna figure out some of these things but not all of them so stacked let's do it by code good memory good storage no storage is more difficult so like there's some approaches that kind of basically take storage and like they take the the storage tree that ethereum currently uses and they move to another one they have a different kind of storage stream yeah yeah maybe it's different like

i should yeah let me draw the way that you draw it i like the way i like the way that you draw them right yeah okay like this yeah so we we used to we moved to a different like storage storage structure and so to be clear in this approach we have a zkp that will actually prove the execution of the evm uh and with them making compromises on different parts of the evm of how we want to represent them yeah exactly yeah i guess one of the curious things why why is storage for example difficult like why would we want to change from ethereum storage to something else right so storage is different for two reasons the first reason is that the hash function that the storage sword uses is very it's very difficult to implement it in zerk

it's not well it's not that it's difficult it's that it's just and it's not that it's expensive either it's that it's just used so much that the the hash function in storage is just used all the time so like people use i think it's prohibitively expensive i don't think that anymore yeah yeah so there's some really interesting work about optimizing cat jack and things like that that's really exciting stuff uh so so that's one of the reasons the other major reason is that like this representation of state is very complicated like this is called the merkel patricia tree and it's really it's really hard it's really hard to implement and it's especially really hard to implement inside out inside yeah inside zkp is generally like the simpler the computation the easier it is to handle in the zkp something that doesn't

has a lot of edge cases and complexes difficult to handle yeah yeah exactly yeah there's a lot of educated systems yeah yeah so this is uh this is another approach and the final approach is basically to just be like okay we're gonna do it anyway is to just be like okay we're gonna figure out a story so like why would people go to this length well like one of the problems with not having storage is that like the philosophy here is basically that if you change anything in ethereum it has like these huge implications for other parts of the stack for example if you change storage yeah your deposit and withdrawals are broken also there's a whole bunch of smart contracts that that use storage to look up other things and like if you do that you'll you'll break those contracts too so the idea is that like okay well

we want to have storage as well so like let's make a zkpp for storage as well and like we're working on this a whole bunch of different people are working on this and we're thinking it's possible it's just going to take a little bit longer i think that like the key realization here was to just be like prover time doesn't matter that much that like developer experience is more important than prover time and i think this ties back to like i think there was a blog post by vitalik about different types of zkdm compatibility right so like when you handle everything this is a bit like type one you basically don't change anything about how uh evm or ethereum work and then there's like type two and type three and which are kind of different levels of kind of pick and choose like what you

keep the same and what you change right yeah and then type four is like a different one where you just like a compatibility solidity level am i yeah yeah yeah that's right okay so like the another point of doing the the the highest level of compatibility is it will let us make a proof of validity for ethereum so far today we've talked about like using zkp's for state transitions and like we talked about how layer one everyone was checking and like the idea is that we can have a ckp so everyone doesn't need to check and especially people who have like uh uh not powerful devices don't need to check or don't need to download so much data so that's another like really interesting really interesting possibility if we if we end up with like

a single decay roll-up or a single a single uh evm compatible rollup then we're able to make this proof of validity but if we manage to get multiple then we're able to have like multiple client diversity of different different proofs of ability for it here makes sense yeah no this is like the type one zke the like equivalent so uh that basically you can improve the state transition of the main chain of ethereum yeah okay awesome um i think one other thing i want to kind of uh get a bit more detail about like we mentioned that it's difficult to build ck evms and zkvm in general like what are the difficulties like we mentioned like hash functions being different or like the three strategies being

different like are there any other like challenges that uh you know you faced or others are facing in in building this yeah so like there's a whole bunch of challenges and there's a lot of really fun stuff let me let me talk about one really fun thing and let me talk also about like the actual difficult challenges okay so so the actual difficult challenges is like the issue is that everything is dynamic that like we have the by code circuit here and like we're we're going through our by code circuit we're executing things and every time we execute something we don't know where we're gonna go next like once we're here we could go here but we also could go like to here like we don't know where we're gonna go yeah

and because of that it's just really hard to get a zkp to represent that within the ckp because like a zkp is like just ordered it just goes like one step at a time like here just update this leaf update this leaf update update this leaf but here you can't do that because you don't know what leaf you're going to do and you don't know like where you're going to go it's that's that's the that's one of the indications of it the the other difficult thing is that like each time like not only do you not know where you're going to go you don't know not only do you not know where you're going to go you don't know what you're going to do like if you come here you're going to do one thing you're going to do like cat jack and if you come here

you're going to you're going to check the storage like because you don't know what you're going to do it it ends up that like that like it's just really difficult to to to to have a list of everything that you need to do because ethereum has a whole bunch of different op codes that are like really expensive or really difficult to implement at snack so yeah it's a really fun challenge and i think this like difference by the way you mentioned like some things are more expensive but like also in the gas model right like something is a fairly cheap like ketchup could be cheap in ethereum more or less and it's an expensive thing in the zkp context so like you need to somehow uh you know account for the differences because like if you want to execute a thousand of catch ups maybe

it's fine in the zqp context but here it's going to be much more costly so there's a close discrepancy between zkp and the gas model of ethereum as well yeah so like that's an interesting question and it's an interesting topic to think about like my opinion here is that like compatibility is so important that like you shouldn't even change the gas prices you just you should just be like prover you just have to do a hundred times more work and we have to spend a hundred times more money on aws and like i think that that's okay because like we're good at scaling compute like compute is like we've been making we've been we have super computers we've been doing computation for hundreds of years that like being able to being able to

i think that it's easier for us to solve that problem than it is to solve the problem of like teaching ten thousand people that this doesn't cost one anymore this doesn't cost 10 anymore it costs 100 now yep yep but this is like an example of a challenges like which yeah are not obvious but still like you need to deal and figure out how you make sure that you know your execution trace doesn't run out or something like that while doing something expensive while it was cheaper on the in a kind of original smart contract yeah yeah let me let me tell you about the phone one yeah so there's one special code that's called x code size and basically xcode size you you give it an ethereum address it will go and get you the size of that ethereum address and it will give it

back to you and like this this originally was like oh i thought that was easy right because we just go to storage we just look up the contract we get the size but like it turns out that like in stores they don't store the size they don't store the size of the contract so when you go there you can't get the size so what you end up having to do you have to go there you have to get the code hash and then you have to like get all of the all of the code hash it together make sure to use the code make sure it matches the code hatch and then you get the then you get the size of the of the code that you put there so it's this huge amount of hashing it's like one of the most expensive things in the evm yeah

but there's a bunch of approaches to solve it like one approach is to put it into the merkle patricia tree to just add the size here but like that changes ethereum like what else can we like the actual solution to this is we're going to have a hard fork to include that we're going to update the state tree to include the code size because zkvm is is a really important thing to do yeah the other thing we could do is we could just reduce the cost of cat jacks so much that it's it's okay to have that because the xcode size is like 100 and like the biggest contract i think is order of kilobytes so it's a lot it's a lot of patching yeah yeah yeah but that's that's fun yeah awesome you know it's it's a lot of interesting challenges and but uh a lot of people

are working on it all the smart people yeah yeah but yeah i'm really excited to see like there's a whole community of different people working on the zkvm there's there's there's polygon hermes there's you're working on it too and like there there's there's other groups there's scroll there's there's aztec oh no that's like or not but there's starkwear and there's there's uh uh matter labs yep yeah and yeah there's a whole bunch of automatic roll-ups too and they're they're all working on this stuff together and like i i think that like at the end the most efficient solution will be combining the the implementations of different groups like i think that like i want to work i want to be part of a roll-up where there's a ckp but there's also a fraud proof and there's a zkp

from polygon hermits but there's also a zkp from scroll tank and there's also zkp from starkware and all of these things need to be all of these things are checking the same thing and like this will give you the security guarantees that we that we really need because like with ethereum we have this velocity we want to have multiple different client implementations yeah and when you have multiple different implementations you it basically says that well if one of the clients is broken i'll just contin like the other client will recognize it and we'll no one will be able to be tricked we'll be able to fix the other client yeah so like we need to have that too for roll-ups yeah we need to have client diversity and we need to have fraud proofs and and zkp's and we need to have like all different groups working

together yeah no agreed all right well this has been awesome but just to summarize like what are the zk roll ups and what are the benefits like why do we care of them sure so roll ups are a way to scale ethereum basically it's basically we use fraud proofs or ckps to to remove the computation burden that allows us to worry more about the call data burden which we're which we're currently compressing and in the future we'll have 15 15 or 4844 will will allow us to have like many many orders of magnitude more transactions per second that's like that's what roll-ups are and that's like the plan to get to the roll-up-centric

roadmap where ethereum is just roll-ups and everything else is just about data availability i think the roll-up model also allows you to experiment more and like have faster transaction confirmation and all of that stuff yeah because there are different models that you can deploy where you know you still have the same security but you can let's say for short term you trust in optimistic way to for you know a centralized uh validator or something like that right yeah yeah i found i found a group working on zk wasn't we could have a zk wasn't roll up in the future yeah that could be fun yeah awesome well thank you so much barry yeah thank you bobbin yeah happy to be happy to help yeah thank you everyone [Music] you