Stateless Ethereum Meeting 11

Transcript

okay so uh i am uh gonna kick this off a little bit um let me see did somebody already post the uh yeah brian's agenda item should we let him go first uh yeah let me post the link here for everybody if you want to jump into it this is the uh call document that we put together for um the continuation of the meetings uh it has notes at least since call number eight in it um and uh you know this was uh you know an open document we keep this open uh between meetings

so um um [Music] so anybody who wants to put on agenda items between meetings you're feel free um you know you have edit rights please be responsible and don't trash the document although we have backups of it um and uh so we've had uh two down here i think joseph ciao you wrote the second one right about piper piper's behind yeah that's right wanted to lead a discussion on one topic and then we had piper on the second and uh honestly uh you know talking about

piper's work is uh really pretty uh exciting progress um so i'm hoping we can do that as well um piper doesn't look so sure but i think it's quite quite exciting uh to see and see everybody working around some of the cool questions he's raising um but how about we just jump into it in the interest of time we got started on time this time which is great um so brian are you here and uh let me see hi srm great um i guess uh uh anybody who's having any thoughts that they want to discuss anything you can feel free to kind of

jump in but also feel free the document link is there if you just write into that there then we can address stuff as we go as well um i see alexi is on this call and i don't know alexi if you had some thoughts about anything stateless i know we've mentioned in a couple of like one-on-one or one-on-two calls recently um and how much you've been following so maybe this is a little more catch-up of what piper's been doing yes i'm just probably going to listen and try to you know if anybody says questions i will answer but i don't have the the active proposals to put in yeah i mean not surprisingly um when people are looking at pulling state and other things that work is happening in turbo gas

because you know you've done a great job on making a tool that uh allows performant uh access and so forth so that's been great um but uh okay let's uh let's get going so brian i'm gonna hand over um uh the microphone to you and uh please uh proceed sounds great so there were two things i wanted to talk about one of them is gas cost accounting trying to figure out how we're going to charge for witnesses and the other one is a proposal called alaska which i posted in youth research a while ago and also in a discordant telegram um that sounds great one thing i just

realized is just in case some people on the call may not know other people around if you could maybe just say a few things about your background i'll i should say for anybody who doesn't know anything about my background um i've been heading up some r d work at consensus labs um which is uh not the part of consensus that's doing the enterprise stuff but it's the one that's more future worky and more r d focused uh and there are a couple people who work with me on the call like joseph chao and uh light client who's matt garnett is on this call and um onsgaar dietrich's is on this call as well um and so forth so brian for sure uh yeah my background i've been

working with the foundation for i think almost two years now which is exciting um largely on piper's team working on python projects the snake charmers team we call ourselves and recently i was in the within the last year i've been working on more eth1 focused projects uh just trying to figure out like where i can contribute to eth1 1x so that's a brief background i yeah so i wanted to drop into gas cost accounting i thought it would be useful to sync and see like where we are there had been a lot of progress earlier in this year um and it seems like we kind of stopped trying to figure out like how we're going to charge our witnesses um if i'm reading the tea leaves right i haven't talked with alexi about this that could be misunderstanding but it seems that he had to in extent

given up and started to focus more on like just attaching witnesses and transactions because we know how to charge for witnesses that we do it that way um but it seems like in the regime where witnesses are not attached to transactions where they are attached by minors we still really don't have any good ideas and i wanted to ask about where everyone's current thoughts are on that we had some proposals alexi had talked about oil which we had i think liked but thought was quite complicated and patella had some kind of proposals which i'm not gonna lie i didn't entirely understand and i wonder how we all feel about them um does anyone feel like we solve this problem does anyone feel like we have good solutions on the pipeline or we could talk about the solutions we have what we don't like about them

does it sound helpful to cover like what we've looked at and didn't seem like it was going to work um oil was won so oil introduced a second unit of accounting and the idea was that we make oil non-introspectible and gas remains in inspectable um the problem was that it didn't actually sidestep the problem because if there um the if there are any costs in oil that exceed the costs for gas effectively then you still end up with the same

problem of effectively making a backwards incompatible gas change so that one felt like a dead end um there's been a very like the on the far other end of the spectrum maybe was at least one proposal by vitalik that just bumps gas prices and it's super simple and it just doesn't aim to actually account for witnesses in gas as much as just hike up the gas prices for the things that generate witness data that doesn't give us gas accounting but it does

attempt to capture the cost of witnesses in gas um that one runs into the problem of all gas changes in the upwards direction are backwards incompatible and so um and so we're stuck with a backwards incompatible change and we've seen in the past that that is ambiguously problematic it's basically one of these things where we've been you know mike is probably shaking in the seat right now in terms of how much we've like tried to educate people on don't assume that the gas schedule will stay the same but there's probably things out there that will break fiber yeah if i may interject so

there is a more uh elaborate scheme which also vitalik is the autobahn 2930. so imagine that we raise the gas costs for store or whatever s load towards infinity but we still maintain these access lists uh whereby you can if you pay for something in an access list you don't have to pay infinity amount you pay some reasonable amount instead and that way we essentially prevent

people from um from not having accesses so access this becomes in practice mandatory because you don't have an infinite gas there is no breaking backwards compatibility because anyone can send an access list and thus you have a way to charge for gas uh interesting i had missed this and that subtle script yeah exactly yeah vitalik pointed out quite early that this is like it's a stepping stone towards witness cool one exorcists are great and we should have

them but mandatory uh access lists the problem is they're not decidable you can't decide a priori what the black cash will be for example and who the dice winner game winner is i think texas has solved a lot of problems but not ever no that's that's if you if you are under the impression that this access list must cover everything then yes how can we check that the exercise is valid but these aren't um mandatory access they're optional accesses and if it happens that you touch a piece of data which you had not declared in your access list then oops this costs 10 million gas yeah sorry you can't afford that

that sounds like something that we can play with too where that pricing scheme for when you miss on the access list like that's a knob that can get turned right where yeah maybe there is a dsa problem that isn't in track like it's not tractable to solve with an access list but it's only going to touch three pieces of state outside the list or something that's why also yeah i think that's like a really good point that's why like i'm i think it's this is like a really elegant solution for um for just these these um edge cases they can break by if we increase uh upgrade pricing and someone relied on that even though that kind of is against best practices

um i yeah i would feel less comfortable like um about a solution that would require access list as like the default at least where as martin was just saying right there where the the non outside of the access list access costs 10 million gas now which of course it would work right from a consensus point so you don't have the issues of decidability and everything but but it might just um break use cases again with the dsa and everything so i i think i i like the sweet spot for for this exercise solution really is in we change gas price like we could change guest prices as like vitalik was proposing to a reasonable just higher amount that just accounts for in some i don't know relative relatively

connected way to the increased witness um effort that that that comes with them and then you just use access list as like a basically a um solution of last resort for these um use cases that would break and potentially also for for like general use but but more like let's see if if it's useful for more so it's like more like we we can kind of unbreak these these breaking um use cases and then yeah i would be hesitant to rely for on the x list for more than that but for those for that i think they're great i want to zoom us back out and run through the tail of the things that we've tried before we go

deeper into this one but thank you for that because i think it's like it's a good perspective to look at them there's options there but the general idea looks promising um we looked at briefly at just actually accounting for the bytes as the witness gets generated and things like that but that runs into similar problems with oil as well as just being really complicated because it means that we're locking essentially the witness format into the protocol and that didn't seem very um it didn't seem ideal um and then we've looked at just

you know the trying to shove witnesses into the transactions themselves and that's where you run into the dsa problem with dynamic state access and not always being able to know what a transaction is going to touch as well as not knowing when the transaction will be mined and if the witness will still be valid um did i miss anything there in terms of main like approaches that we've looked at how about um gas uh ungas yes is definitely the other route that we've looked at which is can we just completely make gas non-introspectible make it invisible at the evm level

um and that one also was just looked hard like uh how to it's a backwards and compatible change um it's got some you know it's maybe the last backwards and compatible change we have to make with respect to like gas pricing stuff um but it ruins uh meta transactions which is where 2718 came from uh to try to sort of set in another mechanism for us to be able to do meta transactions and still put on gas in but it's a bit of a tangled web there there's probably a solution down that line that we could find but it's going

to have a bit of complicated interplay between a couple of different changes that we have to make yeah i think that sounds right i'd love to dive more into that it sounds like the biggest problem with on gas was meta transactions um but if we have a alternative mechanism running transactions it sounds like it's actually going to be okay i'd love to hear what more of the problems were maybe before that i wonder if there any other major approaches to this problem oh and it's worth pointing out that ungass doesn't just suddenly give us good gas gas accounting but it lets us muck with the gas schedule to do with this gas accounting so it's so like we still do have to do

the thing after that which is yeah accounting for gas and transactions but it gets a lot easier i think if you have on gas and you can just muck with the gas schedule yeah i think it's the mindset change where you have similar problems where right now if you move to oil or just if you increase gas prices you might break some contracts and like you will have the exact same breakage under um ungas where like sub-calls can fail but because we moved to on gas we're now okay with that because clients should know better than to depend on gas yeah well it still breaks oh i was just gonna say i mean it still breaks meta transactions which is really the only use that we found of these protected sub

calls that we care about yeah absolutely so i think we'd have to combine it with something to provide many transactions like a new transaction type so you would have on gas and also a way of saying okay let's do this call with this much gas um but you were saying i think you wanted to talk about other solutions first right before the the discussions around and guess okay because i also have an opinion on that yeah one other yeah one other comment i just wanted to make uh just on the record here is that um i think one other interesting point with the witnesses is that i think it's very easy to think about them only in terms of um having the right witness so that when a transaction is being included on a

minted block it's valid but the problem with witnesses is a lot more nefarious than that because in order for a transaction to propagate on the wire among nodes the nodes have to have some idea about its validity and so it kind of requires in the mempool distribution level that each of the nodes that's making a decision about propagating it has the information necessary meaning that they have enough state that they can tell whether the transaction is a good one or not um so it's going to appear um you know pretty quickly once a transaction uh starts wanting to propagate around totally i believe if i remember right i think this one

was actually a solid problem where we looked through to see what you need to be able to propagate a witness or propagate a transaction i think all we wanted was a proof that the account had the enough balance and that was a pretty easy thing to be able to prove or maybe a misunderstanding what you would what you said i think it's that the witness can change out from under you and so if you were stateless then the handling of the mempool gets a bit more complicated because you effectively have to probably throw away transactions that come in like you can't participate with a transaction that doesn't have a witness

and if the witness is old you also can't propagate it and so i think that there's some issues that could show up like they're maybe not catastrophic but it means that like the clients might need to continually like re-broadcast their transactions with updated witnesses to keep them in the mempool because otherwise they're going to fall out of it or or a benevolent actor does this or something but like it i think that the mempool management it's a whole separate thing that's going to show up when we if we end up with transactions that have witnesses paired with them

yeah totally this sounds right i think there's another approach and i'm not sure if people have looked into it but has anyone done any work on on how it might be possible to refund like the delta of gas that's spent like say during the execution you pay the maximum that you would expect if your transaction was the only transaction to use that witness and then you add a new processing point at the end of the block where you actually refund some of the gas that the witness has touched multiple times potentially my go for it go ahead brian uh i was going to say my operating assumption has been that we're not going to

touch that whereas it will be nice we can ask our witnesses by combining witnesses but it'll be allowed to perfectly charge transactions for like i will say that you touch and then i don't think the refund will be very large in most cases and so it's probably not worth um trying to deal with refunds but uh matt are you talking about like uh say two transactions from the same account like sending information or two transactions that like touch the same erc20 balance or something like that and sort of how they yeah i was i thought that we were talking about um you know miners or block producers constructing these witnesses and i

thought these witnesses would be you know the exact witness not a per transactional witness because i thought per transaction witnesses mostly a solved thing we just charge whatever it costs to include the witness and that's that that i think that's kind of what we're talking about here is that okay on one side we'd love it it'd be cool there's like some nice properties of miners are generating witnesses and then there's a bunch of check marks that we have to check for that to be okay like making sure that they're bounded and that they can do it and things like that on the other side it's a lot easier in certain respects if transactions have witnesses attached to them because it means that miners

don't have to do anything else and that you're sort of shouldering the burden on the people who have the most motivation to make the witness in the first place the center of the transaction it's sort of like and and and we might there could be a world of where we end up doing both somehow but um but one way or another we want a witness to show up and we're i think we're essentially just trying to figure out how do we do that okay while still accounting for it i think that uh redundancy uh regenesis sort of addressed this problem because the redundant chunks not just the leaf but you know the the path up to the leaf

it might be there might be overlap with pure statelessness yes every time but with regenesis it's often the case that you have you know the bottom whatever or however you look at the tree the near the root you have everything but then once you get a little bit further from the regenesis point say 10 100 blocks a lot of the witnesses are going to be unique and there's going to be less redundancy unless well there are some whatever special cases and things but maybe a contract gets hot or something and or something like this but um i think that this problem is partially solved that's why i think regenesis was so popular because it solved like 10 problems at once and including this partial witness thing yeah i was going to say from the

perspective of the miners um generating the witnesses uh my correct piper with the perspective that for each one mentality um it you know we feel like having minors generate it um is very helpful but then in eth2 it's mitigated some of the regenerasis but uh we want validators to not have to be holding state as they jump among shards um so there's you know difficulty there when once we finally get to actual execution on the shards um you know obviously this won't be an issue if the shards are just data availability because you don't have to go back and read data for data availability shards

um i think that's right which suggests that minor generator witnesses are actually sub-optimal like in the longer tale and that we do want transaction level witnesses because we want block producers to be able to be stateless right and if they're responsible for generating the witness we're kind of going against that ethos um so i think we're getting a little bit off topic here although i think this is actually important to talk about um we he seems to keep running into this wall where we would prefer to do um minor attachments we prefer to decision type witnesses and i think at the very beginning we kind of knew that doing minor attached was not

um the ultimate end goal like we were gonna it was going to be kind of a we're going the wrong way a little bit make this easier um but i don't think we've solved like even though eventually we do want to get transaction attached witnesses um this runs in the dsa problem doesn't it like i think we still haven't like it's a thing we would love to be able to do but we just haven't figured out how to be able to do it yet is my understanding wrong here or does this easier change things no i think you're right um i think minor uh generated witnesses are are not what we want in the e2 game and that we're wanting them attached to the transaction level yeah go for it matt sorry to be fair i think that you know

in terms of like the optimal case the minor witnesses are going to be smaller because you're not going to have any duplicates and yes it's harder to generate um and it's requiring more resources on the minor but it could be possible to kind of combine the two where you as a transaction submitter submit a transaction with the witness and the miner is kind of incentivized to create this block that has the smallest block witness based on what it receives and you know this is like a really complicated problem definitely but i don't think it's fair to say that minor witnesses are completely sub-optimal uh totally and i think it's worth pointing out that these two things are not necessarily mutually exclusive we it may make a lot of sense for us to figure it out at the transaction level

so that the miner can block mine the blocks statelessly but part of their responsibility might be aggregating all of the witnesses that the transactions included into a single block level witness which is then what everybody else in the protocol uses to to do stateless block verification that's what i think i'm guessing here but that's the shape that might look right yeah also i think like an adjacent idea um seems to be right that that you could also have like a mixed system where um you have different transaction types for transactions with and without witnesses and then some miners might be stateless and they only accept and process and include those

that they bring their own witnesses but some might hold all or some of the state and then they could just um basically also process these other transactions still so that yeah there could at least be like some transition period or something yeah and scar i i think this too and martin i think this could be done with a binding uh access list so you can announce i i promise with this transaction i will touch these only these leaves and here are the witnesses with them yeah i think that's what this is exactly i still it still sounds like we're stuck between a rock and a hard place here where so i agree that for some transactions you could have binding witnesses and that would allow you to um like have transaction attached witnesses

um but i still think in the general case like it's only possible we can only move to a regime where the only ever witness is attached to transactions if we have a massive trade-off where some some contracts simply just aren't possible anymore so i think maybe there's so i think this is where why you and i brian got excited about the concept or like some of the things that were in alaska it's not necessarily that it is the solution um the gist of that proposal at the highest level is that you decouple transaction execution from transaction ordering and

that you've got some short window so what miners do instead of these are the transactions execute them this is the block what miners do instead is they say these are the transactions i could find that make sense to tag onto the tail there are some transactions that other miners already put into this ordered list i will process as many of those off the front of the list as i possibly can fit into a block and that is the block that i mine so they they process stuff off the front of the list and they stick stuff onto the tail end of the list and the idea there is that there's this middle time in which the execution of the future evm

has become completely deterministic we know it a minute in advance 30 seconds in advance five minutes whatever like that window you can turn the knob and in that time you get an opportunity to solve the dsa problem like you get a window of opportunity where that that that that corner edge case that we're always stuck on where there are some kind of contract that has dynamic state access and that cannot predict what it's going to access up front they could submit a certain transaction of a certain type with a certain budget that says minor please fill in my witness for me

this is how much money you have to do that and they do and and the details of this are something we have to suss out but the idea here is to give a little bit of time between execution and ordering to fill in this isn't this also then non-deterministic though if i like of course i mean you're right that the details would have to be figured out there but like if i if i'm like 10 block 10 transactions away from the from the current tip of executed transactions then all 10 or before me could either like fail because they did not like they like they are if they are all that this type of they still need the witness transaction right then i don't know if the witness will arrive in time or not

and then so i don't know in which like which uh actual execution path i will end up with and so which witness might be the one actually necessary so right i think at least taking the determinism like taking the non-determinism out of that queue is it's probably doable it's gonna be complicated um i believe that it's definitely doable i i was assuming a regime where minor attached witnesses and if miners attached witnesses then you don't need to wait for them to arrive like you'll be able to like as soon as they're included you're able to know what the result will be wait but then we are back with stateful minus no right yeah i've just been assuming that like i think

non-stable windows are not possible and i have to be proven wrong on that uh we don't have to solve stateless mining in this it isn't it isn't a hard requirement for us we we we kicked it off of the table and said like uh biting off too much at once so we don't have to find a solution that's conducive to stateless mining it's worth thinking about but it doesn't have to steer our uh road map maybe one last point on that it's just that i wanted to to point out like um because as paul was saying right like that they can at least do this this kind of this dual system where you basically have a transaction type that that has binding access list and a transaction

type that has optional axles and then it's up to the miner to be stateful or stateless and decide depending on which it just process only one or both types of these of these transactions um and at least what i personally find very beautiful about this is that that basically would kind of leave it up to the market right where you basically you just over time see if it makes sense for miners to even to still like call the state if it's more expensive to open state then then the additional fees that they collect if basically rewriting your applications that they they are kind of uh ssa right if that is so complicated that that most like a lot of the apps still need these dsa transactions or if maybe over time they'll all move right through the economic pressure of only or even just the the usability

that only like every fourth block still accepts these asian sections or something right so if it feels like this would just basically in the short term support both and then the long term basically let the market decide which which route to go or give us gives us more time to come up with a more elegant solution i think it's a great idea um just to close it off i had a post i just posted stateless mining strategies that's precisely what anster says said was the martin i'm glad that we have access lists now they're not mandatory they can't be mandatory because of undecidability but they could be binding meaning that we already have binding access lists in the form of simple balance transfers we

know the sender and the receiver we can generalize this to uh arbitrary but if but we require this this non-mandatory but binding access and then there will be two classes of transactions with the access list and without without might have to be mined with you know witness with the block uh and uh yeah i think we discussed some of these earlier things early uh last year and i'm glad we're coming back around to these things that's it what do you mean by binding okay uh you you have an you're assigning a transaction you have a choice you can include it's not mandatory to have a an access list but you have a

choice i want to include an access list or not you do already with simple balance transfers because just by signing the transaction you include the receiver and you can recover the sender now if if you include an access list you can make it binding meaning i i promise i don't know if there would be an extra flag or what i promise that i will only access leaves or you know data within this access list and i will not go outside of this access list uh by making this promise uh and if you invite if you violate this promise your transaction isn't valid so it would be a validity rule violated at execution time uh did i explain uh what i meant yeah so yes you did but but essentially

so if the gas costs were infinite uh if it was outside of the access list that was declared wouldn't that be same kind of binding or would it be a different kind of binding since it would actually make the transaction valid just not um runnable it would never run to completion yeah there's this edge case of because i mean there's different kinds of validity in your form of binding i take it to mean that you mean that if it that someone first has to determine whether or not the transaction is valid if it touches something out of bounds then nothing is actually deducted and all that examination was not paid for which is a problem

i think yeah i think that that's what's solvable in terms of like charging for the gas in the access list up front it's like you can count how many things are in there you can charge for that's like the intrinsic gas cost if it didn't provide enough gas then it's invalid and then in the event that it touches something outside of that the whole transaction is reverted but they're still charged for all of the the yeah yeah i think that's the important property so i think that's what paul what you what you were saying with like the the decidability right so you you can cannot do that the access list variant where the transaction is invalid if it if it accesses outside the access list because then you

indeed you run into all these issues but it's still it's basically like a ballot but like a failed failing transaction so so and and i personally prefer the variant where the miner would be free to still provide the state that's missing but basically if a block um has like one of these binding access list transaction types and the access state outside like basically they try to access state that's not provided either by the transaction or by the miner then it just fails but but it still has to be paid for and then the other way like that the non-binding excellence transaction that would be the other way around so if that were to access state that's not provided then that would be a minor mistake and so then in that case the whole block would be invalid so so i think those those would basically be the two cases

are we mixing up access lists and witnesses here i i feel like half of us are saying access we mean witness and vice versa yeah yeah uh make a good point i i think that one of our design goals for statelessness is that there's a one-to-one correspondence with access with leaves and witnesses um i there is there are very there are subtleties and i can explain them uh if we have time but yes i think there should be a design goal whatever our binary uh our mercalization rule our binary tree format our regenesis whatever our design goal is there's a one-to-one correspondence with access list items you know the leaf and the witness to the loop i've been drawing the distinction at we

probably we're gonna have some format for a witness that we pass over the wire and we're gonna have some concept of an access list that's well it's an access list and in the consensus protocol we probably only deal with access lists and in the networking layer we deal with both but the the the witness is something you can generate directly from the access list and the idea is not to bake the witness format which is going to be intrinsically tied to the tree format and the merklyzation rules and things like that back into the protocol so so if i send a transaction over the wire and only send an access list and i never bother to send the witnesses

what happens that transaction well so the transaction probably has an access list encoded in it but the over the wire portion might have the witness alongside of it so i see so i would just not get propagated if i didn't include the witness that's that i mean we're making things up as to what the protocol might look like but yes that's i think roughly what it would look like like that's the precisely what the great alaska pipeline uh we could that's what would happen precisely we wouldn't include the witness we would just include the access list and the witnesses are to be propagated perhaps we would need the witness to that account so we can check the nonce and check the uh balance and that we can make the transaction things like this uh but that's precisely

the point to not include the witnesses just include and then let the alaska pipeline i had by the way this alaska pipeline uh i there was a post and i had something almost identical uh i called it uh consensus transaction pools and i'm glad that every these ideas are coming up independently maybe that means they're good ideas but uh uh that's the point micah that we have a uh we don't include it so then we allow that critical time when the block propagates uh it doesn't have to include witnesses those can propagate later and the consensus transaction pool or the great elastin pipeline whatever you want to call it uh will will allow delayed execution during which time

you know the non-critical time the witnesses will be propagating so that solves a few problems okay i wanted to ask um if stateless mining isn't um necessary why can't the minor attached witnesses um just be done again just require that yeah yeah i think i think there should be a block limit for because there's a critical moment uh when you mine the block you want it to propagate fast or perhaps you uh you want it to be big for for whatever reason um i think that we should have both and the miner can do it but i think that the block uh there should be i don't want to use the word discount i don't want to back ourselves into a corner but there

should be a higher cost to including witnesses in the block for example if there if it has to be included there's uh not an undecidability or if they don't have the the binding access list with the transaction um they have to be included with the bach but i imagine that those and we discussed this i think at fcc those uh those transactions would be more expensive so there would be incentive for the for the adaptdevs to make everything uh deterministic and so that they they allow uh uh access lists uh to be decided uh a priori um and but but the dice games would have the witnesses would have to be included uh with the block that's my that's my vision of it i don't know maybe

i don't want to force that but that's i think a nice solution to a lot of these things yeah i mean i think that's part of the goal with regenesis is to have a certain amount of state that's assumed in the light minor case that they can attach and then there's various mechanisms of you know how we can deal with more expensive later state getting back in um one thing i wanted was i definitely wanted um i don't want to um well i did want to you know have an opportunity for piper um to give a little bit of description about some of the good um networks no let's let's do that next week um robert because we should continue this

discussion we only have 15 minutes left i think oh okay i thought it was going around my my one was there only if there was time but this is an important topic so we should continue on this thanks okay i'm unsure if we've so i don't think that we're going to make it like we don't we're not going to figure this out on this call um i have this short list of like problems that kind of have to be solved here for us to figure out witnesses which are basically dealing with the dsa thing you know there's going to be transactions that you can't predict um dealing with the mimpool um if there are witnesses flowing around with

transactions they potentially have to be updated and that's a weird problem to deal with the binding versus non-binding access lists seemed like a pretty nice direction but one of the other bits is in the actual validation of transactions that um i guess that's the same thing with the mempool which is that that we were talking about making it possible for for not necessarily miners but for clients to participate in the protocol in a stateless way and the mempool is dependent on all clients on all nodes on the network

being able to validate transactions and so if we make transactions stateless we've got work to do on the mempool itself because right now it has an implicit assumption of state access in order to be able to validate transactions um and then there's just the the core thing which is we have to charge for this stuff um we we want to charge at the protocol level for the witness information which is the access list and in theory the underlying business itself um to be sent around the network for those of us that are a little slower can you uh give a quick uh reason why the mempool requires validation right now the

mempool doesn't actually run transactions but it checks if they can pay for them and so if uh if you did stateless if we if we did a bad version of this in which um transactions got just propagated around one of the things that clients do is check that they have they they calculate the intrinsic gas and then they check that the account has enough money to pay for that similarly not stuff they make sure that it's not an old knot and a lot of them probably that it's not like a way far in the future knots as well could couldn't we solve that by just having certain pieces of witness are always required and those are ones that

don't run the dsa problem like nonsense balance of the sender account uh yes these are totally solvable problems um so i but but say it's a congestion period and i broadcast my transaction over metamask or whatever and it lands in the mempool and it has a small proof against a recent state route that my account has the right balance but it doesn't get included for a hundred blocks is that proofs like is a who's going to say okay so someone else can can change your balance so the nonsense problem is only you can change but the balance can change right or yeah yeah no but but also in the right direction

only in the right direction right your bounds can only ever go up so you can never take one palette but just you just might yeah yeah previously we talked about this i think we had all decided that um this was a solvable problem i just posted a link to our previous discussion on this one thing i just wanted to point out if people are looking at the chat or not danny wrote a good note here um which is capturing i thought i was going to interject as well which was um there's definitely i think a useful context here which is that um i think it's definitely conceivable that statelessness won't get into the protocol until

you know around the merge or potentially after the merge and so looking at what each you know the eth1 execution chain needs to do for statelessness in an eth2 mindset you know danny is kind of pointing out again that you know it is uh you know although e2 has this idea of um shards kind of jumping around and so forth um assuming that the eth one shard on each is still a singular chain um then you know we can still you know put requirements around stateful you know heavier state for the miners to be holding uh if this was like true execution in e2

where validators would be jumping around between shards more and then even then i didn't realize these were the numbers so that's helpful to just keep in mind again that the current estimates for e2 reshuffling of shards is once per day with a one day look ahead so that is actually longer than i thought i thought didn't realize it was that long that shards would have in order to look for even if the eth1 chain was running on multiple shards um that would still leave a lot of time to catch up to the last regenesis checkpoint for instance yeah i thought that those timelines were going to be a lot shorter minutes hours you know bouncing around quickly

yeah i mean i think i i think there's a combination here of like yeah definitely you know regenesis allowing there to be a kind of a shorter time frame where you could assume that you know uh either all miners or most miners are you know holding state but like onsgar saying and also was in some of the previous discussions onscore scores just bringing it up again this point of you know allowing miners to opt in to either adding state or to requiring transactions to have full state witnesses and letting the market decide kind of how much it's worth so that you can

you know pick which mechanism that's uh that's kind of powerful i guess if i wanted to extrapolate that up one point i mean if you're a person who has a wallet and you hold all the state necessary for a transaction and you know your transaction is ssa so you're able to you know commit a state witness that's good for all time you can you know put it in and you know that state witness is going to be valid the whole time your transactions in the mempool on the other hand if you put it in and somebody along the chain a relayer or the first miner that you hit from our pc before it goes on the wire among potential miners um as a state witness

that's another spot and then obviously the miners can be adding it there so there's a couple different spots and from an economic standpoint um you know this is just extrapolating that point that onscore is bringing up again if the protocol allows people to be incented to add state at different points then it allows the market to sort of give users a choice of you know which cost profile they would like to choose um and you know i don't know to what extent i mean the problem that i keep hearing that you guys and i definitely have seen also is that when we think about the edge cases that's where we get kind of caught but um you know i don't know like there's that end-to-end argument if you

punt it back to the user of you know trying to put in a transaction with the right amount of money to pay the right people or take care of it yourself then um you don't necessarily have to solve everything the protocol because the user is the you know intelligent person who can make their choices and uh you know hopefully uh make sure their transaction gets in eventually um i would love to use the last six minutes to just quickly like touch the thing that i'll talk about next time um because it's it's a bigger idea and i want to at least hope i infect

somebody with it and it's right along with all of this in terms of trying to figure out how statelessness and users and everything work um the conclusion i have come to is that the stuff that we are working on this group is really important but it only gets us stuff that works really well at the protocol level and gives us really nice stateless infrastructure and it's useless to everybody else that everybody who uses ethereum like that we cannot build a useful stateless client based on what we are talking about doing in this group we can build a piece of infrastructure

that will hold the network up but the client will not be useful at all and that's because the client won't be able to send transactions and it won't be able to generate witnesses because you can't get at the state so we're building stuff into the protocol right now that allows the protocol to like merge into eth2 and be stateless at its like core level but the functionality stops at the protocol and and the use of the protocol is still not um viable and my assertion here is that we want stateless clients and for a stateless client to be useful it's got to be able to send transactions and if you want to send transactions then you have to be able to participate in the

mempool and you have to be able to estimate the gas for the transaction and maybe you have to be able to generate a witness for the transaction all three of those things require on-demand access to the state whether or not it's your own copy or this magical network that i want to build um the eth protocol is not well suited for this and we also probably don't want to change it a lot because the eth protocol is what holds up the core of the network um i wrote a bunch of blog posts i gave a talk if you want to go listen to them or read them or whatever it'll outline a lot of this i'll probably talk about it in our next call but i

think that if we that there is a very necessary and probably equally large component of work to be done to actually make stateless useful at the client level and if we don't do that work i'm not sure that the work that we're doing here is going to matter that much because the clients won't be able to be stateless because if they do no you won't be able to use them for anything yes you can turn them on and they'll help hold the network up in some sense of the word but they won't be able to expose the json rpc api and you won't be able to send transactions through them and they won't be able to

participate in the transaction pool assuming we don't make systemic changes to that so the things that have to be figured out i'll go into those later but there's a bunch of other work that's going to have to be done i think it's my assertion in order for us to enable clients to be truly i mean it's neat if we can have a client that's stateless at the protocol level and executes blocks but if it can't do anything then it's not really that useful and we shouldn't expect the clients to adopt these protocol things because they don't actually gain them anything um

that's the gist it's a like i i to get into specifics is gonna eat up the last two minutes in a moment um but there's a there's a talk you can watch there's three blog posts that i wrote that are all essentially just a three-parter of the same thing um trying to stab at this idea yeah i think maybe it's useful just to point out that like currently you know wallets which are clients are stateless in the sense that they rely on in fiora or something um but what you're talking about here is uh you know a version of the clients where the clients basically you know encapsulate the inferior

functionality in a decentralized way right yes it's yes it's that if geth built in a stateless mode that was built on these protocols where the changes were talking about doing that it would either need something new or to depend on infera in order to be able to send a transaction because yeah does the solution you imagine look something like another mine's data marketplace no i do not think that an incentive based solution is going to get us very far i think that there's a lot of room for incentive-based solutions um but i i am looking for a non-incentive-based solution

that allows for really really awesome ultra lightweight clients before we end um i want to ask because part of this discussion is seemed to me that you know some of it needs to occur more often like historically this these calls are you know one once a month but some of the people here could really benefit from um you know like more frequent from frequent calls like for example and asgard on our team you know um you know he he'd benefit i think but the whole group as well would benefit if we call it like a witness working group or or something like that so my question is

for these more frequent things you know are there ways that we can help facilitate that or because you know i think it is good to have just a monthly call like um where we can talk about you know the topics at the higher level but we we need um you know maybe weekly or me even more often like working group kind of calls um i won't commit everybody to a weekly or bi-weekly call at this point but if we want to meet next week or the week after that to continue this and to talk kind of more about uh what i well i mean i would be happy to give everybody what i've come to

think is what we need to be doing um or the extra work that still needs to be done also um i would love to see that because i think that apart from the theoretical issues um what you've been discussing piper and i know you've communicated and a number of us have kind of been thinking about it as well that there's an architecture in terms of different kinds of networks of state and there's the pull side of reading the state from it and then there's this other thing which we're really talking about on the witness which is kind of adding back the state as needed as it propagates in so it's kind of a state writing network and just having that picture uh which as

joseph is saying can get kind of broken up into working groups once there's a common framework of this picture is the ground that we're operating on yeah and i and i think that there are units of usefulness in the network design that i'm looking at that might make some of this stuff with how do miners mine block statelessly more feasible so um one to two weeks uh any like i don't know how to get signaling for this but um we we shouldn't necessarily decide on this call um let's throw it in the channel and get something scheduled for one or two weeks out and see if that's gonna

work yeah yeah that sounds good we can we'll schedule something in the next week or two as a follow-on to this and we're not gonna call it like a regular thing because it's really as needed but i think it's reasonable at this point to see if we have enough that we can have uh can i make a suggestion about this sort of scheduling no more calls so we actually talked with the tim about it uh recently the the the the one of the problems with the regular calls is that it's sort of uh hard to predict what will be discussed and some people don't want to come to every single one because they

might not be so interested in what has been discussed so perhaps the better approaches do have a more regular calls but to have the different topics discussed in each of them rather than trying to bundle everything in every single call and more often than not missing parts of it then just say okay let's do one topic per call and then we will chart them out in advance so people can come to the discussion they really want to participate rather than having to slog through every single week and you know there's basically it's better that you have people really go come prepared and focused for for fewer calls than to have them essentially burn out and not

come in turning up anymore after like few weeks so maybe we could i know that it it does require a much more prior work uh for for organization but yeah it's my suggestion maybe even instead of that replacing these regular codes we could also just kind of see if we can form some working groups on some of these topics and then have those just meet independently and then every nouns often just kind of report back in these big calls these occasional ones or something yeah i think having them is like working groups on specific topics alexi that's right on and um no i'm not suggesting the working groups because i

know that we tried working groups as well and i didn't make it work didn't manage to make this work so i'm simply suggesting to have group calls but at the one topic at a time and predetermined like for example piper's the discussion uh at this state uh a great alaskan what's what is it called great alaskan pipeline that that day because we haven't even talked about it today right have you noticed um thank you thank you for catching that i shouldn't say working out because i also agree that working group has too much permanency to it it's more of having a well-described agenda people can opt in the other closing part for it i think

that uh if we do those topic discussions then uh yeah we can try to actually have a summary to allow people to catch up um for the next topic and so on so um you know to the extent that we can do that that would be cool okay all right so we will uh we'll set down a couple of topics and again i think um uh i think for that part also uh if we can yeah we'll kind of suggest it let's go through it in the chat piper uh and others and um um you know people have ideas for that we'll open it up as kind of a document with uh discussion around it so we can kind of decide it's a group what we want to

uh have in these uh more frequent topic focused discussions perfect all right hey thanks everybody for sticking on so long uh this was really informative for me i hope for other people who are just trying to follow along it's uh helpful a lot of a lot of really good ideas and i think we can thank you very much for doing that thanks robert thanks everyone thanks guys all right a year all right