Stateless Ethereum & Verkle Tries with Dankrad Feist

Transcript

[Music] welcome to xero knowledge i'm your host anna rose in this podcast we will be exploring the latest in zero knowledge research and the decentralized web as well as new paradigms that promise to change the way we interact and transact online this week i chat with dankrad feist a researcher at the ethereum foundation we talk all about the future of the eth client infrastructure the merge vertical tries or trees and more we also explore how concepts that originated in the zk research space have

made their way into the eth client stack but before we start in i want to let you know about zk hack a multi-round online event with workshops and puzzle solving competitions it's put together by this podcast and the zk validator and it's supported by a group of fantastic sponsors it will kick off a weekly cadence starting october 26th so every tuesday we'll be hosting a workshop and a puzzle think hackathon meet ctf meets round-based competition there will be a leaderboard and there will be prizes as well as deep dive learning sessions with the best teams in the space do head over to the website now and sign up to join i've added the link in the show notes

i also want to thank this week's sponsor elio who as an aside is also one of our partners on zk hack alio is a new layer 1 blockchain that uses cutting-edge cryptography to achieve the programmability of ethereum the privacy of zcash and the scalability of a rollup it's gas free and gives developers the tools they need to build programs to protect privacy while allowing applications to be regulatory compliant the same team has also built a new open source smart contract language called leo this will enable non-cryptographers to harness the power of zero-knowledge proofs to build next-generation private applications applications like front-running resistant decentralized exchanges hidden information games regulated stable coins

and more go to elio.org to learn more about the protocol or roll up your sleeves and visit leominuslang.org to start building and last but not least the aelio team is inviting the community to participate in their ongoing setup ceremony for trustlessly generating the system parameters you can find out more at setup.alio.org so thank you again elio now here is my episode with dankrad [Music] so today i'm here with dank red feist who's a researcher at the ethereum foundation this is the first time dank red's on the show i want to say welcome to the xero knowledge podcast hello and thanks for having me you are not however the first ethereum research person that

we've had on the show we've spoken to justin we've spoken to vitalik i feel like we've spoken to a few other of your colleagues um but i'm very curious to hear what exactly are you working on in ethereum research yeah i'm i'm working on fundamental protocol research things so i'm working a bit more on the theory sides so i do a lot of things that have to do with cryptography like i look for new cryptographic constructions that we need and some in our protocol and i work with the cryptography team at the ethereum foundation and yeah i mean basically the interface between the protocol and the cryptography finding new constructions and putting them into our specification would you say or is your

primary focus eth2 then i know that there's been some debate as to whether or not it should even be called eth2 but like at the eth2 world as we've understood it is that where you are focused um so this is this is how i originally came into research um we are actually now giving up this distinction because it doesn't really make sense anymore like the murders coming up and from then on like it will all be one so it will all just be ethereum research yeah and um i have actually now started doing work that's like i mean i guess the distinction is now between consensus and uh execution like the consensus part is what used to be is two and execution is

what used to be is one but i'm also working on uh on execution things so for example statelessness is all about execution and i've started working on that earlier this year so i'm i'm doing both i would say got it i had an episode with ben edgington i think a few months ago and in that like we explored this evolved version of eth2 and the merge and the two different kinds of nodes or two different kinds of agents in the ethereum construction i would love to at least briefly cover that again for this episode because i know that we're going to be talking about like these different roles and i want to explore kind of both of them with you if that's possible so yeah can you explain to me or can you explain

to the audience like how does future ethereum look like right so um currently in ethium one as it is now we have clients like for example go ethereum or open ethereum and they um actually have several different roles and they they verify the consensus so they verify that they are on the chain with the majority hash power but they also verify the correctness of the execution so they execute every single block and confirm oh yes like all the transactions were valid and this is the new state rule that resulted from that compared to that so in east 2 currently we are already running the beacon chain

but we aren't actually doing any execution on it so right now that's more or less just a way to test out the consensus um and this of course the new proof of stake consensus which to be fair is a lot more complex than proof of work to verify so like um it's it's very reasonable to test it for an extended period but it does nothing else at the moment and once we merge the two we are actually planning to keep the separation between these two kinds of clients but the what is currently the eth1 clients which are going to be execution clients will not uh care about consensus anymore they will then their only role will be to verify um correct execution and they will

leave the verifying the consensus the proof of stake to a different piece of software which is what is currently the eth2 client you just mentioned beacon chain though is the beacon chain the eth2 client yes so that's basically what these two clients do right now they just follow the beacon chain so you just said the beacon chain has no execution currently but it sounds like will it ever have execution well basically the what is currently ethereum one will just become part of the beacon chain so we'll put the eth1 blocks which currently come with proof of workers consensus we'll put these onto the beacon chain blocks and that will be the execution but then whenever an eth2 client what's currently in history client let's call it like consensus client

receives the beacon chain block they will immediately send this execution part to the execution client let it verify then they get a message back yes this was correct or like no you shouldn't follow this block it's not it's not a correct block so as i understand here though is it there's two different client types but there's only one chain it's not that there's two chains running parallel and you sort of said that there's this verification like what is actually going to be written then onto the chain is it you sort of said this execution would be written on but like what does that mean like what does it look like is it just a proof or something it looks the same as a current uh eth1

block so currently one block consists of transactions and uh it also has a state route so like basically at the end when you've executed all those transactions you commit to like this is the new state and uh basically like the execution is verifying that these transactions lead to the new state route what are you calling the what was the eth2 client now is that just the consensus client um yes so that's that's how it what it's going to be in the future yeah okay and this is going to be proof of stake so this is where the validators are going to live i guess this is where the current validators already live it's just going to be evolved a little bit why the separation uh why we're keeping two kinds of

clients so i mean in practice we've already seen like with ethereum in the past that the monolithic design like having one big client leads to like a lot of problems basically like teams don't scale very well like typically like developer teams work best when they're like small teams five to ten people or so it's really efficient but once you have like a big monolithic piece of software that requires a larger team like things become very problematic and like basically generally like the erp process was slowed down a lot because of this because it's just like i mean actually we currently only have like one team that was able to really keep up with it and that's like a huge problem like we we're looking toward this multi-client

feature where we don't future where we don't have to rely on one single client that ensures consensus like we want to have a fail safe if one client has a bug then there's a different one that we can rely on that will correct it and this can only work when you have like smaller building blocks where like you can put different pieces of software together and they can live independently maintained by independent teams that only have like a limited interface where they need to work with each other and that team you were mentioning though the one that's running right now is geth i guess exactly yeah okay and i know i mean we did talk about all these clients that are building the consensus client but will you are you also expecting more teams to start building the execution clients i mean

that is happening like we do have other clients which are currently in the process of catching up so i mean i believe that this will happen one major feature that we're working on that will enable this more is actually statelessness because that will enable different sort of sets of features that execution clients can target and some of them will be much easier than others that's a topic that i want to jump into like kind of in depth but i first still like i kind of want to understand or i want to make sure that we're super clear on these like two clients and i think i want to know a little bit about the consensus side first specifically like you were saying you used to work there or you used to work more on that like focused on that piece of the stack

is there zk stuff in the consensus in eth2 the reason i ask is i like having seen some of your talks and like obviously having followed each research for quite a while like zero knowledge concepts keep getting like put in but in this final version of the client the consensus client is there anything zero knowledge in there so the answer is not at the moment okay it's something like i mean it's really when when you're working on something as fundamental as like the consensus for the future of ethereum then you have to be quite conservative and so uh we would we we don't want to use it unless we're really certain that we both need it and that uh we are really sure

that it's that it's safe and everything so there's a very high bar and we really want to keep things simple there are pieces however where this might happen in relatively near future like one is a so-called single secret leader election where we want to to make it so that only the blog proposal of a block knows when it's their turn like currently everyone knows who is going to be the next block proposal which which causes some problems so basically the problem is that you can you can then dos that specific validator even if it's not currently known like which ipe is behind which validator there are probably ways to find out if you're really like determined and so think a secret leader election

avoids that because you won't know who is going to be the proposer so you can't dos them is that an idea or is that something that's already built in no so that's not built in we currently have a we have a protocol that uh i think marie muller was working on and that's now i think like i mean we know it works and everything um as far as i know there's currently a team uh working on that and specking that out and building that out but it's gonna be at least a year or so i would i would reckon until it would be actually implemented are you then going live with the consensus client as it is where that could happen where like a validator

could actually be doxxed well i mean it's already live uh to be fair um but yes like it the immediate version after the merge will have that but i mean like as i said it's not that trivial like like we don't we don't have a public list like uh which validator is like which peer-to-peer nodes so you would have to be quite elaborate and like set up like a huge dragnet in the peer-to-peer network to find out who you have to dos okay and it's possible and then there would still be ways to react to this like you could then put notes behind tor and stuff like that yeah we want to fix it but it's also not like something where i immediately see that there will be huge attacks got it um what kind of consensus is it so we

talked about it being proof of stake but what is it based on is it different from like tendermint or from the polka dot model like is it is it very unique um yes so it is um it is different uh from what many other consensus protocol protocols do so it's uh the casper ffg protocol um so of course one thing we want from proof proof-of-stake which is something that proof-of-work can't give us is finality like this property that you can have a checkpoint that can never be reverted unless at least one-third of the validators collaborate to do that and then they would also get slashed so they they would lose a huge amount of money but we we do want more than that so like

basically we're not happy with the property like that traditional consensus protocols have that like once you have less than two-thirds of the validators online that you can't build a chain at all so we we want in addition we want what we call this available ledger so even when more than one-thirds is offline we can't have this finalization property anymore we know that but uh but what we can still have we can just build like an optimistic ledger and uh and keep building a chain and like some people might be happy to work with that and some others not so that's your own decision as a user but like basically uh you're not just stuck with like nothing and uh that that's something we really

want to do and uh and so like that's that's why we have a different protocol that's um quite specific to ethereum got it so now let's let's move into this execution client side of things because i know you had mentioned statelessness and i know i wanted to explore this a little bit the execution client this is the current it's like the ethereum client as it's known today this merge as i understood it it's like it will be somewhat seamless for the client runners they download like an update tell me a little bit about how from the client side like the eth1 clients as they are run today what changes so it will not be completely no change at all it's not just you you are because of the separation that we're doing

between execution and consensus clients it's not enough to just update your client so basically you will you will have to run an eth2 client as well because you need to verify the consensus size of things as well which currently these one client does but in the future i won't be able to do any more because that depends on the beacon chain and nobody's well people aren't going to implement that in geth for example so basically for someone who currently runs beneath onenote they will need to pick one of the eth2 clients and run that in addition to their currently one client and connect the two so that they can keep running each one well an ethereum node can someone just run the consensus like once this is all live if they just want to run the

consensus node um no you can't and that's because the consensus is only valid if it's uh it's based on valid eth1 blocks basically it's always like this always the property that we want with blockchains that you both verify that a majority is is voting for your current chain but also that it's a correct chain and it's only a consensus if both of these properties are true and you can only verify the second part if you also run this execution client so you always need an execution client on the actual merge what happens to the previous ledger like kind of that that big chunk of data that everybody needs to have on their

computer will that just stay somewhere and then a new no no it just becomes part of like it just becomes part of the beacon chain okay so the whole the whole chain just the two chains just come come together like the opposite of a fork in a way yeah the merge got it yeah exactly okay okay so in this execution client so this is this is maybe where i sometimes get a bit confused because i thought like you know i knew that there was these two clients i thought of it as like maybe something you could run separately but it sounds like no matter what you're going to be running both all the time yes and it's pretty much so it's kind of like running one but it's in under the hood there's gonna be two right um and you can you can pick and

choose so yeah like we're we're planning to make this all compatible so you can run all the different combinations of execution clients and consensus clients okay all the different teams who've built their unique clients do you think i mean will these clients have very unique properties like between teams i mean like will they be able to actually have different qualities will like mev still be like only in some of them not mev but rather like a flashbots-like project in only some of them like that that's sort of what i'm curious is like how heterogeneous is an execution client i mean i i think it's it's similar to how it is now like different teams can focus on different specific use cases

like i mean some teams might decide that they want to build a really lightweight client that you can run on very like low hardware some teams might decide to run on mobile phones which i really encourage which is great like if we can do that and others are maybe focusing on enterprise whether like we can integrate with everything and maybe focus less on resource consumption because that's less of an issue um so i expect these different kind of strategies to exist but i think that's more or less the case now except that like at some point um i guess like in eth one many client teams dropped out unfortunately you just said that you could potentially run it on a mobile phone but you still need to have this heavy chain don't you

so like how would you how would that work which do you have to break it up somehow okay i mean there are different things you know so right now the for example the consensus the beacon chain you could easily run that on the mobile phone i don't think like most mobile phones would be capable of doing that but that's current beacon chain before the merge yes exactly exactly so after the merge um i don't know i actually know if it's possible now it would be interesting thing if anyone has tried uh porting i am not aware but i would say like a good mobile phone could probably run currently an execution client because like they mostly do use ssds anyway and the main the main restrictions like you can you can run execution on raspberry pi but you need an ssd you need to add

an ssd to it and this is actually the big thing that's going to change with statelessness so after statelessness it's gonna be easy like because you don't need that ssd anymore i would suspect it's possible to run it on a mobile phone now i think it's a bit challenging okay what is statelessness and just as a caveat i'm pretty sure i've talked about this on the show before but it's been a while so i don't remember so maybe you can like help me to just like yeah tell me what statelessness means and maybe what is statefulness right what's the opposite yes so i mean they're different different degrees of stagelessness i wrote a blog post going into details about these but basically what we're aiming for is so called

weak statelessness and that what that means is that you can verify the execution of everything so like these um execution blocks that we talked about earlier which consists of like basically transactions and then like a new state route and you can verify that all that was correct without having any additional information so basically um in terms of like pure i guess computer science speak and we would call it like the this it becomes a pure function so like verifying that a block is correct is just like you just take that block and it's like true false you don't need any other inputs there's no like nothing that changes with it or anything that's it right

what we're aiming for is weak statelesses which means only the verification can be done without the state not creation of blocks in order to make create new blocks you still need the state and there are reasons why we think that's fine and that's that's the best way of doing it in terms of ux there's a stronger notion where you say like well even even creating blocks it should be possible without the state which would be like yeah the strong statelessness but current currently it's and i don't think you call it state fullness but it's not it's not like transparent you're still verifying state in the current thing right it's not just like so right now right now it's stateful like right now in order like if i send you an eth one block and like ask you can you tell me if it's valid or not

you would need to have this whole tens of gigabytes um if your ethereum state otherwise you can't see it got it and basically with statelessness what happens is we add these witnesses these proofs that everything in this block had a certain state and this was applied correctly and we add that to the blocks and then i can send you this block and without knowing anything else just by like putting it in a piece of software um you can say this is the correct block or this is not even if you don't even know the previous blocks you might never have heard of them it might just be one isolated block and i don't even tell you what's happened in the past what is this witness is a witness of proof is witness an agent is witness a client a witness is uh is a certain kind

of proof okay it's a proof of correct state access basically so basically what will happen is with statelessness so for example like one operation that i could do is like i transfer one ether to anna and right as part of verifying that transaction you need to do certain things you need to verify dunk right had one ether you to verify after executing this transaction he has one ether less and ana has one ether more so and there are a couple of more things you also need to check that the signature is correct so you also need to know what is my public key and you need to know that this transaction was set in the right order so you need to know my nuns so these are basically the different

things and all of these things all of these this information we will add to the block so each of these pieces of information instead of getting it from your memory when you verify the block i i just provide them to you as part of the block but in addition to that now i have to prove to you that i provided the correct information and so that is the witnesses that's the witness so the the proof that this these five pieces of information that i just mentioned that will be part of one such transaction that all of these were provided correctly that's the witness then a nice property of these witnesses at least in in the scheme that we are using which is vertical tries is that using this this witness you can always also update this information so now we

have the state route and now we need to compute an update to the state proof so there's a pre-state route that's like the commitment to the complete all state all accounts everything that ethereum has and then then we have an update state route and that says these are this is all the new like this is how it's after applying this block and we need to verify that's correct and the nice thing is the witness gives you all the information to update it so now like from this witness i can also compute okay these are all the changes that this transaction enacts and then like we verify that these were correctly applied to the state route what kind of proof is a witness um well i mean it's for example if if your state commitment scheme is a would

be a merkel route then it's a mobile proof okay um so it can be different it depends on your commitment scheme but in this in this case then it's like it's not because i i guess when you said it's a proof i thought i started to think it says you're not proof or a fraud proof or so like i started to think like validity proof like is it well and it could be a zero for example like there's the notion of witness compression where you say i wanted this witness to be as small as possible and then you can simply have a zero knowledge proof that shows that your witness is correct and then you don't need all the other all the witness anymore and like in a way like when you look at how vocal proofs work it employs a lot of the technique of

like general zero knowledge proof so yeah in a way it does as a knowledge proof is this any in any way and i don't know if you're as familiar with like the mena system but like the idea of recursive snarks being used as validity like it does it in any way relate to that or would you see this as quite different no i mean we're not trying basically we're not trying to compress the execution so we haven't touched execution at all like to verify the block in a state stateless system you still need to actually execute all the transactions basically the elegance of statelessness is like realizing that executing is actually not a big deal it's not the main problem and also like

also downloading all the blocks is not the biggest problem the biggest problem with execution like with smart contract execution as we have it right now is accessing all the state if you look at what the big problem of running ethereum notice it's all about every transaction touches like different parts of your so you can't you can't just it's too big to just keep it all in ram but once you put it on a hard disk it just becomes very very slow and that's that's the big deal and that's why statelessness goes such a long way of course like basically proving the complete execution is strictly more powerful like it's it's it's much better but there's also a much much harder problem so we we see that definitely coming in a few years but statelessness

is like a great step in between that gets us many of the advantages already does this impact data availability itself or would you put that in a different place like when you talk about having to prove and trace back like that's at least what comes into my mind but i know it might be a different part of part of the thing yeah so so data availability is is quite different it might sound like the two are related um but when we're talking about data availability we are like the main thing we're trying to solve is um is this data withholding problem where someone tries to hide some data and that's not really like a concern with with the state so it's they're quite two quite separate problems i see

and the statefulness when we like here we're still talking about i mean and i know that the question of data availability comes up a lot because of like the l2s and the roll-ups which i believe would intersect with the execution client right not with the consensus client they can intersect with both because like oh well once we add charting well i guess that's that's a debatable thing but yeah maybe so shouting will probably be part of what is currently the consensus line yes i'm almost wondering if we should hold because i have more questions on on the l2 side of things but let's keep going into this so you mentioned you had just mentioned vertical tries or vertical trees i know tries and trees get and verkle is a take on merkel and vectors yes you mean merkel i can't okay let's

take the world completely apart so okay basically like vocal tri there's like a lot in these two words and basically vocal stands for vector merkel so it's basically a combination it's a merkle tree but with a vector commitment instead of a hash at the nodes and uh try simply means it is it's a kind of tree and it's just a kind of tree that's uh used for key value storage where you use just use a key to determine the path you use your key to determine the path you go through your tree so that that that's what the word is about and vector commitment so vector commitments what we're looking for is sufficient vector commitments basically where you where you can

prove membership with less than linear work so for example if you hash like 16 children right um are they called leave leaves sometimes so the leaves are at the very bottom of the tree okay and then then nodes are anywhere in the tree and nodes have children and they can be leaves or they can be other inner nodes right so both are possible um yes and then each node has children and in the merkle tree you just hash all the children and in mercury you usually have exactly two children per node and the reason is that this is how merkle trees are most efficient in this way

because in order to prove membership in a hash you have to give all the siblings right and so if if you make it wider then you have to give a lot of siblings that's the problem with the merkle tree so there's no there's no point in making it wider it becomes less efficient but if you we use efficient vector commitments they are inefficient like a hash is technically a vector commitment as well it's just a bad one because you have to give all these siblings so we're looking for more efficient vector commitments which luckily exist and then we don't have to give all the siblings we just have to give a constant size proof and suddenly it makes sense to make them wider because suddenly that doesn't increase the proof size anymore

it just decreases the depth which decreases the total proof size so that's why we want vertical trees one side note i mean you did a talk quite recently on this with graphics which i will link to in the show notes because i i did watch that so i'm following what you're saying but i'm also realizing that if people are just hearing it it might be a little bit it might be good to just see the map um to see these trees kind of mapped out but anyway sorry continue with the explanation yeah and so like basically now you could ask the question like why don't we just go to like with infinity why don't we just put it all into one vector commitment if we have them because that's great and the problem with that is that um this would be amazing for the verifier like whoever just wants to like

verify that the witnesses are correct but it's very bad for the proverb because all these vector commitments basically once the width becomes very wide you need all the siblings for the proof you don't need them to verify it but you need them to generate the proof so basically the the vertical tree is actually an interpolation between these two extremes where you kind of make a trade-off between okay like we give the verifier a bit more work but in return now the prover becomes actually like practical crazy who makes the blocks in in this entire setup right so i'm i'm assuming you're talking about the execution blocks that they would be completely remain the responsibility of execution clients okay

um and post statelessness you could have you can have different goals with an execution client for example you might say like i only want to verify consent is i don't actually care what the actual state is and then you will run a stateless execution client just verify that just verify okay it will never generate a proof and like you could ask the question well what's that good for like as a user like don't i need the state somehow or at least need my account or something or the contracts i interact with but the nice thing is actually i think it's extremely useful because suddenly you can just get the actual state from a service but you don't have to trust that service anymore because you can very very easily just verify that everything is correct just by by doing this much

much less expensive thing so suddenly like infura doesn't become this oh horrible centralized thing that everything in ethereum depends on that's like well you just run this tiny extra piece of software and infuria becomes powerless like they just they're just a service provider and like you don't have to worry about them cheating or anything anymore yeah you might have to worry about them going offline but once we have a couple of these services that shouldn't be a problem either okay now the other question is who makes the proof yeah um so basically in order to create those proofs like when you create a block you have to create the proof so as i said we're going for this weak statelessness notion where you don't um transactions don't come with their full

witnesses there are several reasons for this it makes a bit less to do the sense to do this in a smart contact chain in general so basically we're doing this weak statelessness the block producer in order to combine the transactions they have to have the full state and they generate the proof this is not like it's not horribly expensive like i mean i've done some estimates and like this this should be like a few seconds of work or so at most so it's actually really easy um but it needs the state so it's it's not it's not much more much worse than running a normal eth1 node now so things aren't actually getting worse for block producers you just made me think though like i always equate validators as block

producers and in this case is the block producer living only on the execution side right um yes so so there's the beacon chain yeah and the validators are the block producers for that beacon chain okay and it doesn't make much sense to like do that any differently there's a difference for the execution chain so the execution chain when you run your own execution client you can make that produce your blocks for the execution chain what we're seeing in practice though is that because of mav like a lot of people very likely will outsource this functionality and um this is this probably is the most efficient construction and so like we're not gonna stand in the way of that so very likely like the actual proposing

of blocks um is going to be a much more specialized role that like people who extract maybe are probably going to do so wait this i got a little lost here because you just said like there's block production on the execution chain i know right now there is but like is there actually block production on the execution side so it's it's just this this part of the block so like the the beacon chain block the full block will be everything that is now just the consensus part and will contain basically one field that is like execution block and uh and i'm talking about this field so that's what i mean by block production on the execution side so it's not a full block if you just send that on the peer-to-peer network it would be

ignored because that's that's not anything that's it's not fully locked into the to the beacon chain yeah exactly and now going kind of back to what we were talking about before the proof generation this witness proof would be made on the execution side into the execution block that would eventually be included in the chain exactly full and would be written into that chain by the validators yeah yeah okay cool that's helpful you said weak statelessness and the word weak and i know you've already said how it's weak but i want to kind of highlight what's weak about it yeah yeah so weak just means block producers still need the full state that's what it means

that's how we defined it okay it's stateless but you still need the state it's uh i mean in the end some okay let's say it like this someone always need the state right yeah and i guess like the strongest notion of stateless is like uh nobody needs the state well no the strongest would be only the user the users maintain their own state like you have an account and you will always just remember how much you have in this account and you remember your witness for your account as well i think that's terrible for ux because like it means you always have to be online otherwise you always have to be worried what if i go offline like yeah i will someone sends me something and now the problem is

you have more eth but you have no way to access it anymore because you always need a witness to access your account uh so that sounds pretty bad to me i don't see how the ux of that is attractive does this mean that block production is maybe a bit more centralized and like not as decentralized as the validators and um i think this is likely true and but this is forced by will be forced by mav anyway so that's very likely the case uh and the reason that i'm not that worried about this is that we only need one honest block producer in order for this to be fine like we only need someone to still be online and not to be censoring uh for the system to work

whereas if we look at the valid data set the full value data set if a majority of them is compromised then we have a problem right like basically everything breaks we don't get our nice guarantees anymore um but this is not true for block producers like we we just we just need one of them and like if if we notice oh like they've all gone to then someone can just make a new one and they don't need to like replace everyone else or so they just go online and say here here here are the new blocks i'm here now uh just take mine so it's a much much weaker um security assumption and and i think that that's amazing and that that means that i'm

much less worried that there's some reduced uh decentralization in that part of the system so what you're saying here though is it has a weak security model does that kind of almost mean like you well the security model is actually stronger because it has a weaker assumption the assumption is weaker so the security becomes stronger yeah okay so but like if the assumption is weaker then what you're saying is do you need less in order to be secure you need like less good actors is it like i'm kind of going back to the validator idea like is it is it now saying like you only need is it like an npc you only need one honest participant in order to like actually have an honest system yeah exactly yeah that's okay that's basically what i'm

saying yeah so like um it's just n minus one security assumption like as long as there's one honest party everything's fine everything works yeah i don't know if i fully understand how that works though like why can one honest proposer actually like beat out the others right i mean the assumption would be like so for example in in what we call like this buildup proposal separation we say like we basically have two different roles like one where you build blocks and a different one where the validators they they pick one of those and propose it and then you need a third system to protect the builders from just taking their blocks and taking them apart and

posing them in a different way but we have systems to do that so the the idea is basically the builder will bid for that block to be included they will just bid for the whole whole block and so like they can they can make this bid based on the transaction fees that they're receiving and on any mav that they can extract from it and then the proposal just needs to take the highest bidder oh wait the proposer like the builder oh see i think i confused them i thought the proposer fed into the builder but what you're saying is it's built and then the proposer is the one who assembles the blocks like ah okay connections and say like adds new ones to extract mev and stuff like that um and the proposer

is just the one who like says i propose that we choose the specific block from the builders i see and they don't earn any fees necessarily do they they basically well so the builder will pay the fees to the proposal so basically the in in the end actually in uh if it's competitive then the proposer should uh should actually receive most of the fees and the mov because like if there's two different builders and uh they're both quite good at extracting maybe then they will constantly outbid each other like bit a bit more because like they basically they're their limit as however much they are gaining from the block right so it's this competitive market and all the all the profits should in the end uh go to the

proposal oh i misunderstood that then because you i the builder itself like putting this together if they're doing the mev like they're incentivized by fees as far as i understand like there are i guess fees and arbitrage i don't know fees and flash bots payouts but like exactly so is that what you're saying though then like the the builder will be more incentivized probably by the mev side of things and less by the fees both i mean both fees are a type of mav right so all the fees that go to the block producer builder proposer they they are also mav right okay because they go currently what we called to the miner but i'm still confused though like so

you what i just understood those fees kind of go through the builder to the proposers like the proposer ah yeah but they but the mechanism is not direct so like basically i as a builder build the best possible block that kind of like the the one that gives me the most possible amount of fees mvv call it all maybe basically mav because these are actually part of maybe right okay now i have this block now i need to bid for a proposal to include this block right how much am i going to bid well the maximum i can bet is however much maybe i'm getting right i'm not gonna bid more because then i lose money yeah okay the minimum is i have to bid more than anyone else otherwise i won't get it

included yeah right and so as long as they are too reasonably good builders they will raise the price to almost the mav right they won't pay as much they will pay a little bit less but if it's competitive then they would pay like only a little bit less like and that however much less that's basically their their profits and like um but most of it would actually go to the proposal and the proposer is the kind of agent that you imagined being more professionalized and potentially more centralized no no the builder the builders okay okay yes exactly yeah so the proposal is the validator the proposal is just a normal validator yeah so but the the point of this is that we don't want uh validators to we don't want them

to have to become very sophisticated because that will lead to centralization if they have to be good at extracting mav then they will end up like being only like big pools who are competitive like otherwise you're like well i don't make as much money i should rather just join the pool yeah is the builder happening on the execution side and then the proposer's like is it is that sort of the crossover moment where it like goes from this execution block to the beacon chain um so the builder is clearly on the execution side um yeah the proposal um is both like the proposer is a full consensus client but that means it has to be connected to an execution client of their own yeah yeah but the point is for example in the post statelessness

world that could be a stateless client which is really really light it could be like you you almost don't notice that you're running it it's that light um because you don't need the state because you're getting the blocks from a builder anyway so you don't need to run a full stateful execution client anymore because you never need to build blocks yourself but since since both clients exist often on the same machine at the same time is there any way to connect your builder to your to your proposer yeah of course there's this i so if you are both good at extracting mev um or some people might just say like well i don't want this i just want to make sure that everyone's transaction get included

and i don't care about maybe then absolutely you can do that and yeah it's possible yeah okay now i want to take another step back to the vertical tries because you had sort of mentioned or you touched on the fact that you're using some sort of zero knowledge techniques in there right what are you using this will be interesting for the zero knowledge podcast audience potentially i mean it's it's nothing super fancy like it's essentially the way we're building uh the vocal trees i said earlier that they're basically merkle trees but with vector commitments but we are we're actually using um something even stronger than that we're using um commitment schemes

and basically i mentioned earlier so basically the way the way a vocal proof works is this you like um so you need to give a proof at like for every bit of the state for every leaf that you're accessing which is basically represents a key value pair um you need to get go through all the layers of the vocal tree until the root and you always need to give this vector commitment proof in addition you have to give the parent vector commitment so like basically the here's a slight difference like with merkel trees like you mentioned it earlier you only have to give the siblings right which is really elegant this is not true for most vector commitments like for most vector commitments the proof itself will not let you generate the parent node which

is the tree for merkle trees so you also have to give the the nodes themselves like the nodes on the path you have to add them to the vocal proof um and now the the the bit i mentioned which is a bit like based on things that you use in zero noise proofs is like um to compress this whole proof what we do is we just uh use tricks to like when you have many polynomial commitments evaluated many different points then there's basically a technique to compress all of that in one single proof and that's a trick that we're using to make this proof uh smaller where did you get that from like what was what were you studying that like led to that finding uh i don't know i mean that that's a good question i think like um

justin and i have been thinking about like um polynomial evaluation proofs for quite a while last year it basically came out of these discussions but uh i think justin basically says it's kind of like a pretty standard technique so i i don't think it's it's nothing fancy it's uh yeah we did uh for the ck study club we actually did a three-parter with justin on polynomial commitments that i'll try to link to as well in the show notes here if people want to find out more about it one thing we didn't talk about yet was sharding but i also did talk about it many times on many episodes in the past i think that our audience should have us understand what sharding is but i guess the question i actually have for you and this i understand would have

been happening on the consensus side is this on the consensus speaking uh i guess so i mean you could actually technically consider the third part but i mean oh practical reasons it will just be part of the consensus client i expect yeah okay and i guess the question is mostly is that in the road map or is that sort of been pushed back because i just i know in the conversation with ben it sounded like the client developers aren't like thinking that much about sharding right now um i wouldn't call it pushback i think it was always like an upgrade um i think we decided uh some time ago that we're gonna do the merge first which i'm strongly in favor of i think it's a very important part and like we basically need to have that um finished before we

can uh implement data charts so i mean we in the spec research team we're definitely thinking about charting now so like it's it's not like it's been pushed far away um but like right now client teams wouldn't have the bandwidth because they are all working on the merge full time what do you need sharding for in this case is this how you scale so this is how we scale data bandwidth so basically it would add to ethereum to the functionality to say this data is available like it was made available um and that's useful because it scales rollups so basically roll-ups need exactly this functionality right now basically how roll-ups work they just put this large chunk of data as call

data on the ethereum blockchain and the reason they put this is to make it available to be sure that it's available and now in the future they can do this on the charts set and on the execution chain they only have to do like a much smaller piece of work where they say okay this was executed this was executed okay here's a fraud proof yeah and this actually so that going back to that question that i had earlier about data availability this is the data availability part so it's not the state data it's this data yes yeah yeah got it i think i was just using like the word data could be yeah yeah this actually leads really nicely into kind of my last question of this interview which is about the roll-ups

and you're thinking from where you're sitting about them i think we now live in a i want to say post but not quite and we live currently in a in a roll-up world where we have live roll-ups coming on we we have different kinds we have optimistic roll-ups we have zk roll ups we have validium kind of roll-ups like the starquer stuff so like this is really altered i feel like the the way of thinking about the future of ethereum if you compare it to like two years ago or three years ago yeah are you actively working on almost designing this out or is this like the ecosystem build stuff and then you're kind of trying to find ways to help i just want to know like

where where is the research face for you on this yeah i mean it's a bit of both i'm not i'm not doing concrete research on rollups uh although some some people from from the uh research team are are doing that i think like we're we're more focused on the long-term perspective like for example like how do we get to a full evm execution for example that's an interesting or like full full zk evm execution like executing the evm and zero knowledge like that's still a very difficult problem uh that i think is a few years away from being practical but that's definitely one of the big questions i guess like the nice thing is that i mean

roll ups have basically solved a lot of problems for us like i mean in the past i think like a few years back we were still thinking about uh about execution charts so like this is basically like the big news that we like completely got got rid of them and i think uh almost aren't thinking about them anymore like they might come back in the far future when we have zk evm but in a way then they are actually roll ups um wow but yeah so like it has made the design space for us much simpler like the consensus just needs to ensure that we can prove that some part of data is available and everything else will be done by the rollups

that's so interesting so that's that's the change then it was that the execution side of things was going to be sharded but now with rollups those are the shards and they're header genius because originally the shards were supposed to be all the same right and now you have very different teams even working on these different roll-ups so so it's a bit dangerous so some people have made that mistake of just thinking of rollups as charts but you have to be careful because the one thing that people where we're super worried about is um composability in charts right like that you can't do that anymore you can can't just like call one contract and then another contract and get a complete log like getting this atomicity of the transactions and that's indeed not possible with

execution charts it's even less possible with roll ups i guess say yes so it's well it's possible within one roll up yes it's not possible across roll ups well it might be possible of course ck roll ups i doubt anyone will implement it but the the interesting thing is one rollup doesn't have to live on one chart so if you have many data charts one rollup can't can simply live across 10 of them at the same time um so that's the danger in thinking about oh like roll ups are just a replacement for shots well they are not because they can they can fill up like there's no fundamental thing that restricts one roll up from simply filling up all the shards and giving you full composability across all of them wow

that's interesting so they are so you you really do make a distinction here that these are not like shards i do wonder what do you actually see the execution layer looking like as these rollups gain momentum track like as more actually funds and movement goes over to these roll-ups like if if more of the action is happening on the roll-ups what is the execution like the main etherium beacon chain in this case but like on the execution side what's it for like what would it be it's the settlement layer it's like it's just behind because like either for for optimistic uh roll-ups like you need somewhere to post the fraud proofs yeah

and so you need someone who can do execution or for uh for zika roll-ups you need somewhere to to post your proofs and someone to verify this you you could do all of this which is like basically this uh this ledger or what is now celestia idea you could you can do many of these things without any um execution layer behind what then becomes very hard in my opinion is light clients and settlement between the different layers like so i do think that this execution layer between them brings really advantages why like client why does it help with like clients um because otherwise the light client still has to the execution layer kind of you could

almost say like finalize those things in char in there so in the rollups and light clients can just take that as their source of truth and otherwise they they can be like clients on the consensus but you can't really have light climbs on the roll-ups yeah you just mentioned zk evm too a couple times and how that could change something like zk evm we did an episode with jordy by linda and david from um hermes polygon i guess that's what you call it now and i know they have a version i heard after that episode that ethereum foundation has a version of zkevm and i think there's a third one that's being built out or developed these are still very theoretical it's the idea that you would have like full evm

like with the op codes all exactly as it is but in a zk roll up that would that would be the ideal result because then you could just take the the execution chain as it is now and put that cks yes oh wow um i didn't think about it that way whoa okay um so you can you can't do that if you have any version that requires recompiling or changing the hash funds or stuff like that if you have to do any of these then uh clearly you can like you can potentially redeploy smart contracts to a new chain and do it on that but you can never do the whole thing on the currently existing chain um so it depends on what exactly your goal is how far you have to

go yzk evm because you can also have full evm compatibility and what's the word it's not even compatibility is not the right word it's like the the actual evm running as it does in an optimistic roll-up but you didn't highlight that all right um so basically what you're suggesting is like take the evm as it as it is now like the execution chain and instead make it an optimistic roll up itself i'm just wondering if there's any just like disadvantage to doing it that way um i mean main it's mainly it's mainly about uh finality um ultimately right yeah i mean i think there are some disadvantages um it's also not easy to be honest like first we can't do it

until we have statelessness so statelessness is an as a prerequisite for that okay um then then we could in principle do that i haven't thought it through to be honest okay fair but on the zk side you have and so that would be possible i mean theoretically it's possible right now it's just completely impractical like i mean the question is like i mean you need to be able to generate a proof for a block in seconds right and so yeah that's difficult i do wonder from where you're sitting do you have a preference for any of the kinds of roll-ups and maybe here it sounds more like you've researched maybe zk more but like do you think that it's actually better i mean ck is better like for sure i mean the optimistic is a practical trade-off

i mean like okay like if i have a roll-up with the same throughput cost blah blah and at zk is clearly better okay but that's very hard to achieve so basically that that's we have optimistic roll ups because there are many things we can't do in zk yet and what do you think about like the porter zk porter or the um the starkware versions which or even actually the i guess the zk evm uses that even it's like using a stark like thing that creates a huge proof and then using a snark that makes like compresses that into a small proof but i mean i think what you're referring to like with ck porter or like star quest validium is like having uh this zero-knowledge boost for validity but not posting the data on

chain like basically not ensuring data availability i mean there's definitely something in it for uh zika roll-ups like going to this validium construction definitely works like it has some advantages that like you you can't do that with optimistic roll-ups um i still think that's much much better to just get the data availability and i think like with sharding it will become cheap enough that nobody would make that trade-off and i think valedium's will just not be very attractive anymore i think like is it i think zk porter is doing this interesting thing where basically who's doing this where you basically they they they give you as a user they give the you the option to just be online and if you're online you just sign that you have received the update

oh i don't know and then they don't need to post it online and i think that's a pretty cool construction because basically nothing bad happens if you go offline you just pay a bit more and your state is guaranteed to be online and if you're online then you just get it directly and you don't have to pay for the cost of putting it on change so i think that's pretty cool yeah i don't know i i don't remember that from the zkpoder interview although it might be there maybe it was another one might be another one i can't remember well we'll try to find it okay in this world with a lot of roll-ups and you're saying like the execution layer becomes sort of just the settlement layer do you actually imagine dapps actually still living there or do you think they'll all just like migrate off

dabs are living there now right i don't know like i mean it's it seems unlikely that they will all immediately make the jump um it feels like we're likely going to see um a trade-off where some will just say well yeah i mean it's expensive but for me it's all right so i'll just stay on the execution chain i don't see like an immediate transition of everything what about like how mev is treated though going back to that question mev in a roll-up world where like roll the roll-up written to chain i don't know if there's like advantages for certain things to go faster or slower if there's like a possibility of a sandwich attack between i don't think you'd call it that but between like a zk roll up and an optimistic roll up fraud

proof like being written at a certain moment like is this even a space to worth thinking about or is that like completely not i mean i would think that most mev would be internal like they because like the communication between these different systems is asynchronous like it tends to be very slow so i i don't know i haven't yeah i i feel like there isn't directly maybe that can be extracted from those i think the mev is mostly within one rollup but i think within a rollup it's exactly the same as it is now so like each of them will get their own yeah yeah i think that's kind of what we're all understanding now is it's not just an ethereum or like it doesn't have to just be the

main chain if there is any other sort of like place to do sandwich attacks people are going to try to do it right yeah cool well thank red i want to say thank you so much for coming on the show and walking through all of this with me um thank you for patiently listening to my kind of ethereum merge questions things that maybe i should have known before but forgot thanks a lot for going over all of this with us yeah thanks a lot anna for having me and it was a lot of fun and i thought you you had really good questions so thank you cool so i want to say thank you to the podcast producer tanya to our podcast editor henrik and to our listeners thanks for

listening [Music]