Stateless Ethereum Meeting 12

Transcript

okay um one thing i'll just let everybody know uh just to head off the meeting to start off the meeting is let me just point out that uh we do record these meetings and uh we do share them so if anybody [Music] uh um to um not be recorded then you know we do you can watch the recording at a later time um but uh just very warning on that we don't share them very publicly um yet but it's always possible it's gonna be posted more publicly as well [Music] and uh you also get the link

for the document if people want to look here is the notes from the last couple of stateless calls that we've had this is a we've been holding them the last couple of months on a monthly basis we decided at the most recent meeting that uh uh i think there's been some kind of good progress especially by putting together um a little bit more of uh structured um thinking around possible um you know uh course to of the work to be done and the kind of team structures and possibly even the kind of funding and we thought it would be helpful to have a

focused discussion on that so um whereas in regular meetings we'll sort of hit a number of different topics um in this one originally i think we set it up and it was a little bit more of uh piper's guided discussion um piper did you put slides together as well uh i don't i think i'm gonna like okay see what using my my previous slides looks like but but it might be really sloppy and i might bail on it halfway through we'll see how it goes all right good set the expectations low now you can over deliver um and then i think also um paul has put in a request for 10 minutes

uh about feedback on some design goals for regenesis specifically i think the order that it's written in the call notes uh you know agenda for this meeting i think that's a good order that we can do the paul discussion at the end because at that point you know all of us we have uh a million things we look at day to day and uh listening to piper's description of his thought process is going to get everybody to context switch in and frame in all of the relevant topics around statelessness um and so that'll be helpful for paul because genesis is a specific portion of it potentially because it's going into my headphone oh do you want to hear what he's saying

what's up jason we can hear you piper if the conversation's good and we're making good progress then we can skip my part piper cool um if uh i'm gonna i'd like to sort of try to time box things but we can kind of play that by ear so robert if you'll like interrupt us at nine or in 24 minutes just to it doesn't mean we have to stop them necessarily but that would check yep cool um grabbing a pdf copy of this thing hold on so that i can show the screen uh here we are

um i don't know how to present with this i'm just gonna go back to the web app all right um let's see if i'm able to share it looks like i can there's a browser tab cool can you guys see this yep looks great cool um i'm not gonna like formally give this talk because generally when i give these things i'm kind of targeting a pretty like very wide range of um knowledge and i think that the knowledge base in this group is adequate that i could i get to skip over a lot of stuff um let's see so so the the core premise behind what i'm kind of talking about here is that we have this

roadmap right now and the roadmap is basically make witnesses small small enough um sorry i'm just going to get us onto a less distracting slide get make witnesses small enough put them into the core protocol in some way distribute them in some way voila we have stateless block execution um what i've come to realize or like that it wasn't just obviously clear to me is that such a client that does this kind of stateless block execution in the totally minimal way that we're looking at doing it is only useful in the context of each two it i do not believe that anybody

else would use one of these clients um and the reason that i say this is that because it will not be you will not be able to broadcast transactions because it won't be able to be part of transaction gossip uh it will not be able to serve any of the json rpc apis or expose any of the like standard user facing functionality it'll literally just be able to verify state routes as the blocks come in there's value in that in eq2 but it isn't a very compelling piece of software in my opinion and if the only value is beneath two it's hard for me to imagine the work actually getting put in to make these things until that is like here um so that's one side

of of just like i'm i don't think the thing is highly useful other than 42 infrastructure typically you mean value in eth2 in that consensus entities consistent participants can run with fewer resources and so maybe you have a more democratized uh consensus player yes and even yeah and and i think even that piece there's a couple of question marks around it in terms of exactly what that needs to look like but yes that um what you said okay um the other piece is that there is protocol work and we are doing that protocol work right now that's

great um the binary tree the merkle uh the code mercalization um there's things coming down the line from each research that might change some of that stuff but ultimately we're doing the work to make witnesses smaller and the extra work for the extra work for uh so the extra work for getting to work and getting an echo back from somebody getting an echo back but can everyone mute nobody let's see still there yep still there all right uh so the extra work beyond the protocol to actually get the clients working is the part that i'm not sure is actually going to happen

at least not until eth2 is right here because there's there's the the piece in the actual consensus protocol that needs to be done but then there's going to be a bunch of extra work that also needs to be done kind of at the networking layer and just at the like client infrastructure layer itself um there's going to be need to be some sort of new gossip network that these kind of eth2 stateless infrastructure clients can get access to new blocks because they can't be part of the eth protocol and somebody's going to have to be producing the witnesses and so like it's really hard for me to imagine this path being highly successful and even if it is successful it's not that interesting it doesn't get

i mean yes it's cool that we get this e2 infrastructure but it isn't really that compelling for the amount of work that's going to go into it um questions so far about that um this is sort of my like this is where i'm gonna go next is kind of talking about slight counter point there like i mean that's like saying oh what's so compelling about youth compared to a centralized database right so decentralization is a feature as well right fair uh totally fair and i'm not trying to like discount the value in eth2 um it just it's hard for me to imagine us

actually getting there until eth2 is actually basically here um so so it's it's interesting but it how about this it's not compelling for me like like that's a statement i can say with without qualifying it um it's cool to have but i'm not um right and i mean i think like we agree that most likely the merge will actually happen before statelessness is all done and dusted right so it we we probably will have these two by the time just implemented sure um and and and if we just deliver that great and the real part of this is that like a lot of the

work that needs to be done there is like completely out of the control of everybody but existing client devs and so it really becomes up to them to decide whether or not they want to prioritize doing that work and i'm not suggesting that we change any of that so i'll lead with that which is that i'm not saying this road map is wrong i'm just pointing out some things i've noticed about it and i'm not suggesting that we shouldn't do the things that we've already set out to do what i want to do is i want to add okay so i wanted to uh to kind of get through this your conclusion through my prism of i

think um i agree with what you said and i want to explain why this actually happens why this why we actually came to this problem for my point of view it's because there was a blind spot in the one on our original discussions about stateless ethereum i think it was my blind spot and i think to everybody else's as well so the hope was that the stateless uh whatever stateless client would be able to participate in basically in that gossip network it will be able to propagate everything but i think we've forgotten about it we'll be able to do everything except

for it will not be able to participate in the transaction pool um so it will be able to propagate blocks uh because the witnesses will allow it to verify it will be able to do blocks headers and stuff like this but it won't be able to participate in the transaction pool fully and that's i think this is the main blindfold are you assuming that transactions don't come with witnesses um yes in the in if we think specifically about the pure stateless client which is not regenesis client which is kind of halfway between uh then yes the in the pure stateless mode the transactions come without witnesses and the the status line might not have

and probably won't always have the stage to be able to to correctly uh pass it through however in the genesis mode it might be the case that it might be able to do so so what i'm saying i think i think that's a mistake so i think the stateless client needs like the transactions need to come with witnesses right okay so then we we're this is actually which is now different from the uh the this what road map that piper was uh was referring to right this would be an added piece to the road map is figuring out stateless transaction gossip it's not nobody here i don't think like neither of us are saying that it can't be done

or that it's like undoable it's just it's a significant thing that's it that has to be added right i mean i agree i that's it's it's difficult but i also think that we i guess like we come we've come to the same conclusion here that you you don't get the really the benefits of statelessness unless you can do stateless transactions as well right and i and this is on the roadmap that i'm that i'm kind of proposing we do right now is stateless transaction gossip uh uh sorry alexi did that um i i agree we had a blind spot in terms of like really looking at what the

end goal produces um did you have more that you wanted to add to that um no it's not like we we had a blind spot in terms of the main goal the end goal i think we had the kind of end goal but actually it was maybe it was probably my fault because i was so convinced that the we could do this without uh witnesses attached to transactions and the reason i thought that because i wish to you know basically yeah i i think it was my kind of mistake to try to push for the for this specific approach when the witnesses are generated by miners because it was very convenient in lots of other ways but the there was this blind spot which

i haven't noticed um for a long time and i think you now picked it up and uh so yeah i think we're that's why we're here cool um so like the stateless client that i want lives in this like upper left corner of my graph that i'm just sitting on the screen this is the part that i'm like that's the thing that i want i mean it's part of like why i started creating a client years ago because i had this like big like bright-eyed pipe dream of like just writing a lightweight client despite that being just fundamentally not reasonable to do on the current protocol and it took me trying and failing to figure that out um so clients are heavy and we like want

lightweight clients and stateless clients are like a cool idea for lightweight clients but the thing is that um well like i pointed out the stateless clients that we can make with our current roadmap aren't that interesting um two end users to the use cases that i'm kind of focused on um so like les hasn't really kind of showed up as the like thing that gives us lightweight clients i think that the client server architecture doesn't really scale well and i think we've seen that in the network i think that there's totally a place for les but les doesn't give us the thing that um we need elias still just means sorry may i uh sorry i i was totally late to the call

and then i'm sorry i just started echoing and everything i stupid zoom started really slowly but um i just want to say that [Music] that yeah i'm i'm totally i totally agree about like alias not being the most i don't know practical solution to our current problems and i'm totally open to your ideas and uh yeah so uh okay go on sorry cool um so like i don't think les is going to get us there the client server architecture doesn't scale well it still just leans heavily on the full nodes there's kind of a tragedy of the commons problem there um so uh the

light ethereum sub protocol um and it and it really depends heavily on just asking full nodes to do the work for you so things like providing proofs for account information uh things like uh looking you know block canonical block indexes and canonical transaction indexes things like that so i want something that lives in this upper left corner this is sort of the idea behind like the stateless client that we wanted um and so i kind of went through a bunch of just thinking about this to see like what does this look like and this is kind of the end goal that i want to build something that runs well on low resource devices that doesn't actually require any syncing and you just turn it on

it works that the networks are designed to scale without a kind of client server imbalance and then it serves the whole json rpc api um i've done a decent bit of work like really looking at this problem like looking at what clients do that is computationally expensive that makes it so that we can't run on the resource devices uh these are things like the canonical indexes um yeah i've got a bunch of slides here but i feel like this is like the raw like i'm i don't know i i i don't want to kind of i'm not sure this is the the right context for me to give this talk but basically i want stuff that runs unknown resource devices like this um we've got history that shows that we can do

things that don't sync with heuristics and jumping straight to the head of the chain and backfilling and there's ways that you can write clients that do this um and making networks that just are fundamentally designed to handle you know whether or not it's the ten thousand notes we have on may next day or a million light nodes like flooding the network um [Music] i can go into details about this but i think now that i'm like in this i'm gonna stop this one and look at this document instead because this really is outlines at this group's level what i'm proposing um

here's our current roadmap which is basically like we need block execution via witnesses some level of witnesses coming around the ability to distribute them this is sort of like part of our existing roadmap this is the part that's um basically what we're already doing um we need the ability for transaction pool include to participate in the transaction pools this is like research that needs to be done into designing a new gossip protocol that is conducive for uh stateless clients about the state to participate in it um and similarly like we need those clients to have access to some of the other gossip

mechanisms as well uh we're going to need just general block gossip and we're going to need to be producing witnesses and gossiping those around in some ways well but the the the i'd say that the majority of the like added work that we're looking at is also just in the on-demand access to all of the different pieces of history and state that are really necessary to be able to serve json rpc api so what i am essentially coming to the table with is my intention is to do these things um not necessarily all myself my team is focusing on some of these problems um i am looking for other people who

want to work full time on this this is something that uh i i have no guarantees that i can provide right now and i'm not gonna like go into details talking about funding on the call on this call but there is funding available for teams who want to work on this um and if you want to do that then come talk to me and i will i will find you the money to work on this if that's the blocker um so i'm not looking to redirect anybody's work that's already working on something i'm looking for people who want to work on this expanded roadmap which includes building out what might be three whole new networks it might be one

it's unclear but essentially we need to fulfill these like pieces of functionality and it and it looks a lot like the actual clients for these networks aren't going to look anything like existing ethereum clients because they're not going to be part of the ethdev p2p network so so we're looking for client teams who are interested not necessarily existing client teams if one of them wants to great but like i think that we're looking at really fundamentally different looking clients and if there's a team out there that wants to be first the table at making one of these um well i'm looking for those teams who are interested in building this out um questions i i i mean at a high level

this is that's it that's what i'm that's what i'm proposing to do that's what i'm intending to do and i wanted to put it in front of everybody to see if there's any blind spots that i'm missing uh questions people have that sort of thing i have one question um it was in my mind that i know it's onscar asked it as well in the chat which is um i just want to make sure that we um disentangle the validation um am i correct in saying you know we need to have uh stateless access to um nonces and account balance state in order to do transaction validation for uh gossiping transactions uh decentralized

uh throughout the you know node network however um full you know kind of uh equivalent uh access like you know les where you can get any state you want as an ultralight client that's really needed by the end user looking to form a new transaction and wants to understand you know the intricacies of will their contract actually execute the way that they want when they submit this transaction uh and so that's so much more i guess the reason i'm distinguishing them is that the second one is a really big heavyweight network i think and the first one is a much smaller undertaking are you looking at doing those two

separately or you know uh i think at this point it's unclear so state network is like gaining some some understanding of what solutions look like they're going to work um transaction like stateless transaction gossip is probably the piece that's been looked at the least you're correct that knots and balance are kind of a key part of validating transactions [Music] transaction like being part of the transaction pool is just inherently heavy like it's a big job that clients have to do um and so i think part of this research is looking at can we actually make that lighter weight as well can we um allow clients to manage a subset of

the pool if they want to limit how much resources they're putting towards it um i think mika should raise your hand yes just to throw a web blanket on the party here um account abstraction and new transaction types are likely to break the assumption that all you need is the nonce and the balance in order to validate a transaction because uh once once account abstraction lands who knows what state you're going to need in order to have all data transactions well no that's not that's not entirely true i mean uh you should be able to validate a transaction using the contracts balance that's kind of the whole point of account abstraction is that you won't need anything other than the abstracted accounts state so

[Music] i thought the account extraction version one uh allowed you to read some examples yeah yeah you're a little bit more than just the balance but the echo is really bad that makes it really hard to talk um but yeah you'll need a little bit more than just the balance but it should be still pretty minimal so sorry sorry just one thought i wanted to add to this is that even if we don't have like uh stateless transactions or whatever it is possible to propagate a proof of the balance and announce with the transaction so that could solve this problem totally

and and that's essentially what i've got written down it's just that it gets a little bit more complicated because you've got things like who's updating these proofs for transactions that sit in the pool for a while and are there dos vectors for right for can you make it you know essentially worse by you know continually like poking a balance that's that's trying to pay for a transaction or one one question here i have is do you actually need to update transaction witnesses if you like forward transactions immediately and later you just keep them in the pool in your local pool but you don't really forward uh so i again this is like

like i'd rather us not get deep into how stateless transaction gossip works it's mostly that it just has to get figured out and done for it for us to be able oh yeah of course to to broadcast transactions so it's just one of these added pieces of work that somebody has to work on and somebody's got to get it done and somebody's got to actually build it so um yeah sorry i'm not trying to like shut down well i am trying to shut down conversation but hopefully not rudely um the problems are totally tractable in my opinion we just need to do them um and they're not currently on the roadmap necessarily so um so this is yeah expanding it to add gossip

state history state availability and chain history there's also another angle to this which i think rick has mentioned in the in the company in the chat um although it's not as trivial is that this um whole notion of minor extractable value and a lot of work now being directed into the like a lot of work and energy being directed in in figuring out the the the like what can we do with the transaction pool because we we're pretty quickly getting to the

point where transaction pool actually becomes the resource then which is most likely going to be abused in in the future like we had these resources uh whatever what is uh this you know the bandwidth the um the the storage now this the transaction pool is likely to become one of those resources and the the reason why it is abused because it's been pro it's been provided for free by the participant of the network and there's going to be more and more sophisticated ways of you kind of using and abusing it almost like you see people firing transactions canceling them and so forth um maybe there is a there is the need for kind of thinking a bit deeper into you

know does this this transaction pool model which we have going to survive a very long time or is it going to force some new stuff that is kind of more reliable i don't know uh maybe the thing that we're hanging on to is actually going to die very soon um that's that's my hope like the things that i've identified here like i you make a list it's the canonical chain index is work that clients are doing for free because you can request blocks by number the canonical track transaction index is mostly a user-facing thing but it's very valuable because everybody wants to look transactions up by their hash and you need 32 gigs of index space to do it uh transaction pool is a is a commons

problem that right like you said the work is being done by all of the nodes and it's really heavy work and it's like prop like you said maybe prime for abuse um but in general it's something that isn't scaling super well and it's just requires nodes to throw more and more resources at it as the transaction pool grows it gets used more in the chain that's used more um because identifying each of these resource intensive things and then looking at the problems to say how can we turn this into something where the work gets spread out across broad sets of participants that can show up with smaller amounts of resources

and handle these problems no what i'm actually getting at is that you know the i have identified with your help that the the transaction pool support was a blind spot for the original kind of pure stateless client design which actually yeah sort of a bit embarrassing but it did happen but now i realize that you know we we actually kind of really like tweaking things to like okay so this is what's the blind spot what if we tweak it in such a way that it doesn't become a problem anymore and so my my point is that what if there is there exists some replacement for transaction pool which kind of makes this idea work again i mean i'm not sure that i want

this to happen but when maybe there is such a thing i mean we're talking about the abstract idea of a scalable transaction pool whether or not it's still the pool as we think about it today or whatever goes forward or whatever but it's um no what i mean is that it's sort of i i just want to be cautious not to throw too much energy behind these kind of re-implement the transaction pool as we know it in the new way because you said that you know these things that we're we you want to create are going to be completely different from what we have now and i'm just worried that these new things might just replicate replicate the some kind of broken design that we

have but uh yeah that's just try not to do that i guess is the um i mean the other thing that i really like about this approach is that right now it's really hard to iterate on the current like eve protocol because it holds the network up and we need it to keep doing that and while it has its problems it's done that well for us for years now um but it's really hard to iterate on because the barrier to entry is incredibly high to even participate in the protocol and so so i i want to break that apart and i haven't seen a way to do it until

now when i just look at it and say okay well maybe we need to just make these separate networks that aren't as utterly mission critical because they don't hold up the core of the network at least not immediately and it gives us the freedom of movement to figure out what works at a um without go ahead sorry all right are we removing them tx gossip or is this um effort wanting to try to keep keep it by building it so we don't like the eth protocol like i'm not talking about changing the eth protocol

at all that lands on like existing client teams because they're the ones that are using it and so this is about figure there's going to be things that have to bridge between the eth protocol and whatever other things get built here for a new version of transaction gossip that that is conducive to stateless client participation i'm not saying that we can't do this by changing the eve protocol it's just that's very much out of my control and so it's not a problem space that i can actively work on at least not easily um so i i i think that over time um i mean i'm pretty involved in mev guth

i'm some level of involved in 1559. um i just don't see the existing transaction pool as surviving both of those things that are happening you know completely disjoint i mean between the two of them the existing transaction pool i just don't see how that will exist um i think that there is a question around just from a game theory perspective there's some basic fundamental issues with how ethereum is designed and this lack of contract between the miner and the transaction submitter the end user and i think that we're running into that problem here and

i'm just going to also point out we're running this problem is related to the global state problem as well so sorry shared global state right so if each transaction could only interact you know established its state and then could only interact with that state you know in like a more sane computing model then um you wouldn't have to recompute the transaction proofs and it would make sense to to only provide uh transactions with proofs in fact because that it would it all sort of be logically consistent i i can completely agree with all of that i i think that that is the direction that we i want to take the protocol that i think that we should be taking

the protocol is towards whatever it is that we can figure out to mitigate some of these just systemic problems that we have like you said global state that any transaction can touch it makes it inherently difficult to do transaction validation and gossip well actually the network is important to bring to be able to bring back the some notion of mempool is that right well the basically the reason why we have this issue about the transaction pool connected to the state why does transaction pool need the state is not actually that very complex is

because you simply want to prevent the um the kind of the the multiplication of useless transactions and you the way you do it is just simply check the balance and nonce so but instead of you don't actually need the entire state you just need the balances and nonsense of the things that are sending transactions which to be honest is not such a huge thing i mean if we separate let's say that theoretically if we separated the state into two parts one of them is these things that were required by transaction pool and the everything else then of course that thing that required by transaction pool is actually pretty small and so the we um i think the problem is that we we have to bring this whole thing only because we just need that little

little small thing for for the transaction pool so but i agree with the rick that perhaps uh you know even with this small adjustment it's still not going to survive for a very long time we probably could uh maybe in order to re you know to make sure that the transaction works for stateless you know stateless clients we can make a state adjustment but then is it going to last for a very long time i don't know does anybody else have questions about specifically what i'm proposing we add to the road now um

yes uh okay also my hair looks stupid so uh what i wanted to ask is i really like so so you said you you just want a gossip network instead of this light client protocol that we currently have and i really like the sound of that so actually i had quite a lot of stuff in mind about uh improving the topology of less and actually the reason the protocol is like still as i designed it as a first idea that sounded like a good idea

so it's because i was lately really focused on problems of incentivization and stuff like that and i think now i'm getting somewhere with that but uh yeah so so so i think the topology also really needs to be improved uh and yeah so this is what i wanted to approach from like the site of incentive incentivization but uh do you have any specific ideas about like how to improve the topology because that's like the key question yes but they're completely unvalidated like i'm working on writing simulations right now for some like different solid like some whether or not the things i'm thinking of actually form the topology that i'm

that i'm hoping that they do and whether or not gossip still works in that but the rough idea is trying to basically build the network out such that the the emergent property is that the the miners are i just think about them being highly interconnected in the center of the network they're the ones that care about seeing everything and are willing to put the resources towards it and then spreading out from there you you get you get fewer connections heading out but lots of connections like essentially of nodes with roughly the same resources that they're putting towards things so the lowest resource nodes end up the

furthest away from the miners their transactions take the longest to get there they're highly interconnected with each other but they're they're less connected with the like people who put more resources in and essentially everything flows kind of in towards that middle part of the network um but it's very abstract and like i'm working yeah so i think i have i have like i think it's like yeah it's easy to come to image imagine like something and and i i so this is basically what i try to like like like build build an incentivization algorithm that

could end up like in a similar topology that you described but maybe if you have like ideas for the other side of it like how how would this thing be formed and everything so i'm really like uh i'll share what i'm interested in so let's not discuss it further in this call but yeah so let's talk later about this okay yeah i should say that we did pass through the half hour point piper um and um yep so if there's any last questions i'm happy to answer them i'm also happy to to talk with people separately whatever um

speak now otherwise i'd like to hand the floor over regardless in the next three minutes to paul for him so it sounds like piper with with your effort um whether there's going to be a you know like these mempools in eath one or e2 right your efforts going to help preserve those i mean right what i think this leads towards is assuming i'm assuming we do these things and we do them well and they work we get ultralight clients that are totally suitable for extremely low resources device low resource devices we build some tools that are useful for existing clients like being able to drop

all of the ancient chain history because we've built a network where you can get it and then we start rather than seeing clients exist on the far ends of these spectrums they slowly start filling in the middle space as well as people peg themselves somewhere not all the way on the heavy end not necessarily all the way on the light end but we have these network tools that clients can use to build out different types of functionality so i don't know if i actually answered your question um but i guess if we think it's it's a problem if um clients are just going to connect directly to miners and validators right and not have a the gossip network anymore no i mean

there's definite i mean i think that there's definitely a gossip network that needs to be built for this to work that we need yeah yeah that's right but my question is the other way that we do want yeah we don't want um clients or nodes to just talk directly to miners and validators we do want a gossip network right so that's why this effort itself is building gossip network so it is helpful to like prevent these um you know the direct minor validator communications um really this is not like there are definitely tie-ins here but this is very the only place in which this is

related to eth2 is in the fact that stateless and eth2 there's some benefit there in the stateless block validation and that there's just some similar needs yeah i guess i'm and bring up e2 because there will be the merge right so even if the eth1 mempool like goes away then you know there will be a merge and then so we have to remember merge the mempool would exist as it currently exists unless it was modified so by default you just kind of get the same mempool um in that validators instead of miners well and in full nodes and whatever that network looks like right okay so i guess i was just wondering then yeah you know general general thoughts

here about yeah you know is the mempool if it does go away right because that's what he gets i don't think we're talking about no no we're we're not but let's say mav geth gets more and more adoption so that you know there's less and less transactions let's say zero goes through the mempool right we have a we have a very big problem if that's the case because we're no longer resistant because you know following where this is going but like i don't think anybody here is talking about getting rid of the men pool um there's shatter in the chat about mev yeah i mean

yeah i'm the person saying that so yeah so so basically um because of minor extractable value and sort of the incentive misalignment that creates um and again because of the way the transactions are constructed and the way that global state is constructed what's happening is uh traders who are our largest users um want to have quote-unquote private transactions and the way that they're achieving this in the immediate term is they're sending the transactions directly to the miners and they're bypassing gossip so uh that's spark pool tai chi which works this way um there's another tool um that is very popular called emif geth that allows a

um it's sort of complicated because it's uh attempting to be altruistic which is very difficult so the the narrative is a little jumbled but basically what you do with mevgeth is you send a bundle of transactions you send an anchor transaction which is the transaction that you want your bundle to be applied before or after and uh you send that directly to miners so this is totally like parallel and orthogonal to what i'm talking about doing like having private transaction pool stuff is absolutely something that people can do but we still need a public some ver some concept of uh of a at least for some time here of a public gossip network so i think the problem things can both

exist and like so so i'm not sure like there's no i'm not sure what so i think that i'm just going to go through the sort of the logic here um my reasoning um expand on it a little bit so if we're just focusing on traders uh transacting directly with miners as opposed to using the pool i mean again remember the vast majority at least 90 of the transactions are done by traders so um our transaction volume is going to drop uh you know significantly and um and i and i think that ultimately um we're just

i agree that what i guess what i'm trying to say is that we never actually really had i guess uh sort of from a philosophical position although we created a permissionless gossip network the incentives were never really there for that network to scale the the the way the system has been designed the existing public gossip it quote-unquote works as long as you know all the transactions are worth the same you know it works as long as there's a certain game theory i don't think that there's like are you like if you're i'm not sure that we have anything that needs to be discussed here because like i'm not saying that we can't have a

private transaction network i get that there's flaws in the public gossip transaction network but we still need it for at least some time here so so yeah i guess what i'm suggesting is that we yes we do need to keep the existing network but i also think that from a to me from a design perspective where we're kind of slicing along the wrong axis right there's some core problems to ethereum and we see those core problems emerge in a whole set of different places and and so if we attack at the you know at the at the bottom of the

tree you know if we're if we're looking at the the consequences and not the roots of the of the problem then um we're kind of it's inefficient right because we're not really going to solve the problem so i don't think that we have any like argument here like this can be part of the research into what transaction gossip looks like um so like uh let's talk about that more um because the idea of how we do transaction gossip for stateless clients is it's a totally open-ended problem right now um yeah i mean and i'm rushing us off of this because i do want to give paul the floor to talk about um his

piece before we run out of time so yeah so let's let's go down that road and explore what alter like fundamentally different transaction gossip models might look like um i'm just proposing we need to have some people working on this so let's do that yeah and i i just want to ground it a little bit more of just being a protocol the the goal here i think piper when we've talked um is that the the protocol design um has implications for the resources that a client has to bring to the network to be a successful participant yes and um somebody you know one of these rules of nature is that a state has to be stored someone has to be

storing it and if you ask a question someone has to answer it and so part of the protocol design is figuring out one that as people come into the network and ask questions and ask for state they also naturally become participants in holding some shards of state and answering some fraction of the questions as well so that the network on its own gets more powerful as more people join it and more requests and more state needs to be added to it so that's really the protocol design is a lot of it is around the protocol that allows a group of successful like clients who just are bringing with them relatively modest cpus and memory footprints and bandwidths

to create a network that has the kind of capability of serving state of some of these centralized ones that are in the bottom left of piper's diagram so i just wanted to ground it in terms of this isn't just an abstract protocol thing it's about a protocol that leads to the right kind of clients that are naturally formed the right kind of network adding more computers should add capacity not the other way around it's basically what you're saying correct yes sorry if i said it the reverse way no no no and uh since uh since uh my name is robert and i'm running robert's rules of order at the moment i will uh uh adhere to piper's request here and even though i spoke last i

apologize i'm gonna cut it there and uh let's move it over to paul so he can talk about regenesis which at this point we've been thinking about this uh quite a bit in our brain so this will be a very natural flow into paul's discussion so paul you've got the floor paul you might be muted or i can't hear you oh there you go yep i can hear you now can people see what i'm showing it says yeah we feed regenesis design goals okay so this is just a libre office it's easier for me like this um so regenesis design goal so this conversation was great and thank you for the introduction uh nice

introduction robert that i think there are these sort of discussions that have to happen but i sort of want to want to maybe steer it towards some written something written but the thing is that i'm realizing that things are changing you know every month or two something else comes up we have some new idea we have new things so this isn't uh final so what i'm trying to present here is in finals just sort of a snapshot of my sort of current understanding of it and maybe other people will give me some some help uh understanding and maybe other people will benefit from this as well so just to get through it quickly i really like this problem statement from the i think maybe alexa wrote it and i hope people can i hope everyone if there's something blocking something

please let me know um the problem statement i'll read it quickly uh preserve resilience of uh ethereum one network uh despite the state growth so we already identified that there's a state growth problem here um and we want and that there's a resilience problem with f1 by making it easier to join the network we're already talking about uh syncing and stay on it um so resources things like this and therefore increasing the number of diversity so we're already talking about security so this is a really nice sentence uh the improvement to user experience is not in the scope of what we're doing so we're doing core protocol stuff not user experience stuff um so this is sort of you know an engineering problem we have a problem statement we sort of have maybe design

you know criteria for success you know things like this but things are changing um design goals have come in over the years this is the major one i think this is a critical one that is often overlooked uh uh that martin said we don't want uh caching in consensus so uh alexa had his moving window uh cash he solved the problem with cashing with his medium posts in 2019 like february and march and april 2019 um but then martin said in early 2020 uh no consent no cashing in consensus this is just so complex then we need extra cashes on top of it extra journals extra all of this

and we're already you know struggling to to have enough cash so we have to design it in a way that we don't have this sort of cash that we have that we and i think this this can be done uh we we have this sort of infrastructure of blocks so maybe they're attached we're like stacking these blocks um uh i think geth calls it stacking sort of diffs um so we have we can maybe put this sort of uh uh regenesis data and this active state in these sort of diffs that we stack and we accumulate them with time so my point is we can't have this sort of pool this sort of cache uh martin's gonna push back we want to keep everyone happy that's that's the thing and if if we have this sort of huge complexity sure it solves

the problem at a high level but you know when it comes time to implement it you have all these extra secondary caches and things like this so this is a big sort of design goal design request no consensus cache and i'll just go through a few more and the thing is you have to sort of follow it as as we go along so we have canonical witnesses were requested a few times i found it requested once here in the regenesis announcement uh we talk about merkel rolls uh we want 32 but bite hashes 30 you know 232 bite hashes to to go to a 32 by hash for merkle trees um but the question of merkel trees is still you know uh we want to be accumulator agnostic um but that's just these rules are sort of coming in as you go along you're sort of a detective and you're

just accumulating these sort of things i proposed an access list witness correspondence now access lists are first class objects and it'll be and now witnesses are going to be first-class objects in the in the whole protocol these are just you know high priority it would be nice if we had a sort of link between them it sort of makes makes a lot of things nicer so i'm just going through these sort of things that you accumulate if you read if you read along another one danny said um this isn't a requirement but uh we would like to have uh stateless black if if we want to leave the we want to leave the option open for stateless black proposal so stateless mining uh we don't want to we let me let me reset it's not a requirement uh but we don't want to make it

to sort of make design decisions that make it impossible so we would like to keep this option open so you go along you collect some sort of design goals and i wrote a few of them i would like to grow this list we don't have much time um but just a few of them i already touched on i'll explain them again no consensus cash clients can use you know internally you know caches journals shadow stacks bloom filters these kinds of things to solve their own problems but we don't want the consensus to have some sort of the sort of comp complexity um but with since we have no consensus cache how are we supposed to store regenesis well maybe you know inside of this sort of black stacking you know we have the

blockchain so inside of these blocks and that's what gen if you read the uh gethsnap snapshots uh blog posts from july of last year on the ethereum blog they explain that this is exactly how they do it so i think we can fit this this is a this is a major thing that we to satisfy no consensus cache but i think we can sort of get around it by by embedding this sort of cache inside of the inside of the blocks and there another one is forward looking to f2 um the regenesis period i i say regenesis what i mean by regenesis is sort of like a generalization of all of these things um uh you know fully stateless uh you know regenesis is sort of like an abstract like a a good abstraction level uh

that we can sort of later on say okay shrink the regeness period to even to zero or to one whatever so we evict every every buck um finality is coming that's gonna that's gonna uh improve things um and danny's post that i just scrolled by uh leave options open for example state execution and charts not a top priority but let's not close the door yet um stateless black proposal um the accumulator uh there's already talk about replacing the accumulator uh so our design should be uh you know swap merkle tree should be swapped in and out you know should be swappable and let's not intertwine the design and leak everything across you know the merkle stuff is leaked into

everything else especially though this is going to be interesting when we design the active and inactive say let's let that be the first class you know the active and inactive state and then the merkel is just some deep some design detail of that but fully contained uh within under the sort of heading this is active state this is an active state um for now but for now we want a binary tree with this merklyzation rule that we just saw witness dependence is minimized so that was my proposals accessless witness correspondence um so so we have a witness i give you an access list you should be able to give me a witness that is independent of the black execution that is independent of you know uh but it's a nexus dependent on you know it's an access list and an

active state and an inactive state you give me these three things and i can give you a witness and we can all agree that it's canonical minimal these kind of things and another design goal that was mentioned a few times i'm just accumulating i'm just sort of picking up things as i go along uh regenesis event is critical so we have to be careful with forks uh there are options with this i want to add to this list i want advice on how i should do it um i know this isn't a fixed list i know things change as we go along you know things become more important but i'm going to open the floor for feedback it's a good looking list um

there's some interplay between figuring out what the cold state mechanism is because right now there's kind of you know unless you just go through and do execution um i think that's one of the areas of research that needs to be figured out is how we actually denote what state is cold and what isn't um active and inactive say by cold do you mean inactive state uh yes it's basically like something's inactive if it's well in the regenesis event it's if it's before the regenesis event um but there's some concept of like knowing which things were active or inactive and um there's a there's an alternate route to

that which is actually having a mechanism that says these things which i guess is really like rolling regenesis is if we can just continually drop things that are colder than a thousand blocks or a million blocks or whatever um then we're effectively enrolling regenesis which is i don't know it's just a different mechanism of it but i like what you call it i wouldn't call it regenesis anymore yeah you're right it's not something else it sounds like a cash um sure yeah it's treating the active state as an lru cash yeah but then that violates the no consensus cash we would have to get

around that somehow and i think with regenesis it's cleaner to do regenesis solves so many problems simultaneously so that's why i'm speaking about it that's why we sort of pivoted away from this moving window uh lru cache uh to this regenesis events um but these regenesis events bring some sort of critical criticality at the forks that we have to discuss things like this um anything else please uh and also meta sort of you know uh how do i accumulate more of these sort of points i know it's a changing list and i want to share it with people i want people to discuss it if this is effective it's possible that what i'm doing is ineffective um and i should stop but maybe i should just keep it to myself but please give

feedback i want to give some feedback so first of all in general i'm i'm really appreciative i really appreciate that you keep looking into this um because it might be um i just wanted to explain a little bit like they there might be an impression that i kind of gave up on those things but i didn't um i don't actively research the genesis at this moment i still think it might be possible to do what i'm trying to do at the moment is actually to create more tools for the further work because i i just realized i can't i mean i'm not the person who can do research without the tools uh and i don't think we we have um them at hand so yeah so i

just wanted to say thank you very much for keep for for doing that and uh you're very meticulous with collecting the you know collecting the history and the you know doing things and i know that you're also quite good at coding because i i saw what you did with the evm 384 but yeah so i'm really glad that you're doing this but and i wanted to let everybody know that i haven't given up on this but i'm just coming back for more tools okay so this is uh we're over time uh uh alexei thanks for for letting us know that's i hope we can sort of get you uh back to thinking about regenesis again

because you're sort of a driver and we need you to drive it um or you know well maybe someone else will have to do it if but thanks for giving a signal um we're over time and uh robert or anyone else okay i ask uh one one thing real quick um for the adjustable regenesis period it'd be nice if someone documented what the pros and cons like there's a contention here where if you get too short or just this period you have one set of problems and if you have too long for this or a period you have different set of problems it'd be nice if those are documented so we can try to think about you know what is figuring out what the ideal genesis period is there's probably a sweet spot somewhere in the middle

so danny ryan said one day is the shuffling in one day look ahead that's what he said last call and that's quoted it's a bit it's a bit in a bigger part of this quote um i agree with you that it's qualitatively different to have a very short one in a very long one and we can design differently for long one and short one and yes i agree with you that it would be good to know what the qualitative differences are and how we can make maybe find a happy middle ground between those and maybe be generic enough so that we can pivot to the problem is we start designing in one direction we you know that these are our fixed parameters these are our fixed constraints and then as the constraints change we have to sort of pivot

and when things are in consensus uh we sort of are left with these design warts uh which which i hope that we can be forward-looking enough of course it's not fully avoidable but i'm hoping that we can sort of identify these things and think things and be forward-looking in the design thank you okay um i think we'll um anybody else want to jump in if they have a question but otherwise i think we'll um wrap up the discussion for today here um hopefully it was uh helpful for people to have a little bit more of uh two targeted kind of

discussions um this time um i think we had kind of agreed that we would have uh some more topical discussions uh um you know that are opt-in between um but otherwise we'll keep the monthly meetings going did anybody want to have a little bit discussion about if there's a topic that somebody wanted to brainstorm a little bit that we wanted to do on another call i have a uh just a minor desire to talk more about a middle ground i've discussed with piper a bit on on this um piper's big fan of kind of a more

homogeneous network where everybody can participate equally whereas i feel like there is an opportunity where we can get a bunch of the stateless benefits or at least some of the tables benefits with a more heterogeneous network where you have nodes like infira and alchemy who exist within the network and they're just doing more work and for whatever reason they're doing it for free but they're free right now and they don't seem to be stopping um and so i think there's so we can leverage that and get some benefits of stateless for cheap or for much less work than trying to do the full everybody's ally client sort of thing uh i would like to at some point talk about that more um

i agree interesting to talk about other other network models too like where not every node is equal like some could be hubs and super hubs like the old nutella networks would be an interesting kind of approach as well so so sam that's exactly what we're doing um i'm you know i'm i've talked about vulcanized db on this call in the past and we're still working towards that end um yeah so we actually are taking that exact approach where we have gateway nodes that gateway that effectively bridge between devp to p and then our own webrtc based uh protocol okay yeah i guess one thing i should say is my

understanding of any of these networks where you have light clients that have a protocol that allows them to both leech as well as seed state and request handling on them they all will end up like what you have rick or what we saw with mustache in the kitsune approach previously which piper is referenced in his you know previous historical kind of work that he's uh you know incorporating ideas from they'll always end up having some aspect of a heavier node that looks like a bridge or a gateway that takes the kind of speed from dead p2p and then refactors in a way that is um you know able to be

sharded and distributed in the distributed hash table of the uh you know like client network um who is sharing the screen right now somebody has okay there's a little card there for github so um so i think there's going to be i think mika i'm glad you raised that point that uh i think today's discussion piper was trying to you know shift and refocus a little bit more on this issue around the transaction gossiping and the kind of ingress side of the statelessness versus a lot of times when people look at statelessness there's this very big value of course on the validation side um

and us having a network a network topology kind of discussion i think that's a good topical discussion as well so we'll put that on the calendar thank you and we generally have channels in the r d discord for each of these things i post a lot of updates with what we're doing um that's a great place for us to continue conversations okay great um yeah like piper's saying you know uh please do if you uh don't actively kind of look at those or if you're not on those please do go on them uh there are good discussions going on there and uh thank you everybody for coming um you know a

very helpful discussion and uh you know have a great rest of the week everybody thanks everyone thank you thanks all right thanks everyone