All Core Devs - Execution #128

Transcript

foreign [Music] foreign [Music] welcome to awkward devs number

Tim Beiko: 128. uh we have a few things on the agenda today uh first Aero Glacier went live yesterday then we can discuss kinsugi in the merge then finally at eip4488 which uh yeah we've discussed a lot in the past two weeks um I guess starting with Aero Glacier uh it seemed everything generally went well with the fork one thing uh I noticed is there were two Chinese miners uh I think okay X and hyobi that I did not upgrade uh I was unable to check this morning to see if they had I saw like two blocks mined on the old chain I don't know if

anyone has any more context on that or just anything else they wanted to share about the arrow glacier okay um yeah I'll try and dig into this later today uh to see uh if the two miners have uh have upgraded um it's been a bit harder to get a hold of them since the mining ban in China um next up

uh kinsugi

Tim Beiko: uh so we launched another devnet this week um does anyone have any kind of updates they want to share about their progress

Marek Moraczyński: on the merge generally foreign there was a little chaos mainly because of renaming however all clients teams quickly delivered fixes and now we have stable network with Gaff never mind loadster Lighthouse Taco nipples has some issues that we should investigate together I mean uh gas determined at Nimbus teams as far as I know prism has a known bug and they are

working on it Mario's performed spamming but he hasn't destroyed the network yet in another month we continue working on things what is important we updated instructions on how to run Netherland with every consensus client so everyone can try to sync with the devnet and that is all I think

Tim Beiko: cool anyone else

Gary Schulte: yeah I can speak to uh basically we uh we're a little behind on the getting onto the devnets but uh we're we have the V3 spec implemented and we're

interrupting interopering uh locally with uh the merge Mock and teku and uh we're just waiting on one more PR before we're going to be uh joining the devnet basically where we need to get our uh backwards sync PR emerged in and as soon as we do we uh have instructions and uh get that out there so that other people can be working with that execution client also

Tim Beiko: cool anyone else um okay and I guess yeah more more

generally um I was talking with uh Mikhail yesterday oh Miguel you're here yeah um it seems like uh the the kind of big buckets of things that are that we still need to figure out are uh optimistic sync so there's some work on specking that and uh kind of addressing some of the edge cases one thing that we also discussed earlier on was basically the auth mechanism between the the uh consensus and execution layer nodes uh that's still kind of something we're going to need to figure out and then Marius you had found some issues with like the the fork choice if there's competing proof of work uh proof of work blocks uh at the merge uh that's still something that

needs to be addressed in the specs and in tests um so they seem like the three kind of big outstanding things uh obviously testing all around the more we can do the the better um that said it seemed this week when I was talking to people that uh we should be able to launch kinsugi as kind of a more long-lived devnet next week um uh Perry and and his team were were working towards that that it seemed like we have kind of all the infrastructure set up to not only launch the devnet but have kind of a UI that uh people who want to interact with it can use um so I guess we'll we'll be doing that in the next week or so one thing that would be

really helpful from client teams is uh you know having like some instructions about how to connect your client to the devnet even though it's not merged in a master branch and it's it's maybe a bit uh it maybe requires a bit of like manual wrangling um I think that's really something that would be good over the holidays so that people can kind of try out different clients and and see them working on on

kinsugi um yeah

Marius van der Wijden: so yeah go ahead so uh um I have two small uh things one one one thing was um when we launched uh Kentucky uh when we launched a definite uh three um

there was some issue with clients not proposing any blocks or just proposing empty blocks after the match and so I was wondering uh what's the correct Behavior there like uh if you're like I think that there's a case to be made for for validators just proposing empty blocks um but there could also be a case uh case can be made for for just not proposing a Blog because you know like uh you will like your validator is Uh something's broken and you need to fix it and um if you uh like if you validate and you

if you test to um to a block even if you know that this block should contain a payload but it doesn't um then uh it's better for the network because the network keeps on moving um but not really not if everyone does it so yeah I think like I'm not sure what's the best behavior to do to to do then if uh like empty blocks a proposed post merge and so that's that's probably

yeah

Tim Beiko: what's the reason that empty blocks are proposed post merge is it just when there's competing proof of work blocks

or is that all the time

Marius van der Wijden: no um it was because the execution layers were not uh or the consensus layers were not connecting to the execution layers correctly right so they they figured out that the merge was done but they didn't uh produce um they didn't call execute payload or prepare payload correctly and uh so they didn't didn't get any payloads so they just proposed empty blocks as far as far as I know I I I don't know what really happened but this is like what I what I think happened empty means that no transactions has

been in those blocks empty I think empty meant that no payload was in this block

Mikhail Kalinin: you mean there was like zero payload like uh before the

match

Marius van der Wijden: yes

Mikhail Kalinin: oh then it means that uh actually if it happens it can be considered as the merge has been done because the consistency acquired starts to um switch the logic uh into the transition process once it sees uh non-empt to pay a lot so this kind of preloads if if the transition is already in progress in the

network then if this kind of block is published with the payload with all of zeros uh the honest behavior is to reject this kind of blocks because this is not valid blocks anymore so I I we can try to figure this out like a fine that's

kind of time that

Marius van der Wijden: that's that's just what I wanted to say and uh the other the other thing is um yesterday night I had the great idea to just go ahead and Shadow for girly and I think we can we can do that pretty

easily and um we plan to do like once the once the devnet is um is merged uh once the the the the test can still be test net is running um then we're going to start trying to um create our own shed of work of curly and so if that is something that you're interested in joining then reach out to me uh and and uh Perry uh probably going to set this up that's it

when

Mikhail Kalinin: when do you want to do this

Marius van der Wijden: um after the chestnut is done so I think it's it's Pro it's probably

uh a thing of like a day or so to figure it out um and it will like it will not impact the normal operation of girly we will just uh soon curly notes and then say that the total terminal difficulty is reached which means our for our notes will Fork off off early and then we'll continue on the on the on the merge chain

Mikhail Kalinin: and you're going to share an example with the girly nodes after the merge after this

yes

Marius van der Wijden: let's see um not really because we will have different fog IDs

um but uh yeah like at least for some point we would we will still have some of the same Productions um but then the the networks will diverse probably

Mikhail Kalinin: okay

Tim Beiko: that's really cool um yeah looking forward to seeing

it

Parithosh Jayanthi: just continuing a bit on kinsugi planning um is everyone like could we have some consensus about who's going to take part from the execution client side

for next week's test net and is it okay like is everyone on track for Tuesday or should we be looking at delaying it to Thursday or something like that we are okay with Tuesday okay sounds good um I just tossed a message about um features and things like that in the interrupt channel on ether D so just have a look whenever you guys are free and then we can take a discussion there

foreign

Tim Beiko: yeah and I saw your message on the r d Channel also Paints the consensus layer

team so that's definitely something we want to make sure um and yeah it seems reasonable if if delay in your couple days makes an extra team kind of able to join the network we probably should

Parithosh Jayanthi: um exactly yeah but yeah we can discuss that on Discord I don't think we have to um unless someone has some specific point I don't think we have to continue again

Tim Beiko: anything else about the merge in general

Mikhail Kalinin: um yeah I have a small announcement we have I've opened up a proposal it's been

mentioned during the previous call um it's the get feel odd bodies uh it's now a PR to the engine API spec um so the get payload bodies function reflects the logic of the get Block bodies message of bth protocol this is actually the Crux of this proposal um because it's apparently it's easy to be implemented it's just basically it's just exposing almost the same or literally the same logic uh in the in the other part of the client in the other API so let's take a

look any concerns any issues that you fail with this proposal go to this PR comments and let's discuss I'll keep it I'll keep it open for a while and then just merge if not no no this thing you're talking about where is the link there somewhere oh yeah I've just dropped it in the chat oh you see it yeah so uh the one of the concerns uh there is an issue uh there is there is a discussion threat in the issue one of the concerns uh was like if we expose them this method which requests the

payload bodies by my hash um it actually doesn't allow for using the linearity property of a blockchain like it would be if we were requesting those bodies by numbers which doesn't allow for like if the linearity property is utilized it allows for um more optimal requests for the same data to be done on disk in terms of disk uh queries so that's that was one of the concerns but as long as this reflects the eth protocol message I think it's

okay um probably not so worst thing worth taking a look at

Tim Beiko: and to be clear this is not something we expect to have by Tuesday right like we would have this I guess in the post uh the post uh kinsugi version

Mikhail Kalinin: yeah right so it's not it's like for uh yeah for after

Kentucky versus back yeah that sounds good yeah

Martin Holst Swende: just a quick quick feedback like if

you're if you're worried about the like optimality of this uh thing so they forget we have the whole transaction thing stored as rlp and also as snap the encoded rlp um probably doesn't make sense to like return and snap encoded but we could do return rlp list but the way you proposed it we would have to I guess Marshall it and and then serialize it in some other form maybe it doesn't matter right yeah quick thought

never mind

Mikhail Kalinin: yeah see so yeah the the the

form uh which these transactions are in the response in the response is actually the same form as they are in the execution payload structure so the consensus layer can understand it it doesn't understand the ROP

Tim Beiko: anything else on the merch okay

um so I guess next up uh we had discussed on the last call eip4488 uh for people who uh like don't have a ton of background the EIP proposed to decrease the call data uh costs so the the extra data that sent along with transactions um from 16 gas provides to three gas provide them to add a cap to the maximum amount of call data on the Block as well as a stipend for uh transactions with only a small amount of call data and and the goal there was it would make roll-up transactions cheaper because they use a lot of call data to settle uh on on mainnet um there was some concern raised about

the fact that you know Roll-Ups aren't super cheap today already and they might get more expensive uh and uh uh this EIP you know is is a fairly simple change and we could potentially do it even before the merge if we wanted to uh and this way we would kind of future proof uh ourselves with regards to costs on Roll-Ups um talking I talked to a bunch of people this week about this and it seems like there were a lot of varying opinions about how we should approach it um not 100 sure where to start but I guess uh the get team shared kind of their position in writing this morning so that's maybe a good place to start from

uh about this uh oh I see and Scar you raise your hand do you want to go first

no it's

Ansgar Dietrichs: just uh wondering because I would say the death position is already kind of diving into the question of should we go ahead with the fork for this or not and maybe it could make sense before that to just briefly talk about the the kind of the analysis on on different levels of stipend and different minor profitability because that's more like a neutral neutral topic before we get into the details

though

Tim Beiko: yeah okay I like that um yeah so and you've been spending a bunch of time in the past two weeks looking at that you want to give some context and share your analysis I think you had a link also if you want to share

this in there actually yeah yeah I can or if you even want to share your screen as you're going through it whatever works best for you

Ansgar Dietrichs: uh sure sure I can do that give me like one second of course um uh let's see like this okay [Music] can you see the screen yes Austin so um again this completely separate from the question of whether this Erp should go ahead or not but just just in general the the question was

there were some concerns raised around um for one that now that we have two separate constraints on blocks basically that there's a tab on call data and then at best still the gas limit cap that mining could become more complicated and so if you run a simple mining algorithm like you would probably find and get or other execution um clients whether basically you might be out competed by um minus who who might run and close Choice sophisticated algorithms um and then it is it turns out that this this is also interesting for the questions around um specifically like what basically what

level of stipend about what level of transactions to still be included or not and so so basically uh all I did here was just a sample um works from from mainnet Over the the like the one one week um prior to to 2080p analysis um and just kind of like basically simulate it um what if um at the very beginning of a block you would basically always already use up all the Call of a call data because the currently of course um which is what's important to say that can blocks always have only used a little bit of quality and so if we just simulate those blocks the the caller couple would just never be reached and so in order to simulate

what happens if we call that caps reach I kind of just added a high call data filler transactions in the beginning so that the this one megabyte limit of the efp is already used and you can only use this stipend to to add all the other transactions and then I went through the transactions and simulated different mining algorithms either and specifically three different ones that I learned here so there's a naive strategy where you just literally do the same thing that gets us today you go through the um through the list of transactions sorted by how much they were paid to you as a miner and whenever you reach a transactions that's not includable because of the collateral limit you just skip it um so that's that's basically um that was part of the the prototypation we did um that's that's basically one line one

line that changed um then it turned out as part of this approach that there's a slight modification of this that actually makes a lot of difference and that's what we call the backlog strategy where basically and sort of completely throwing away that transaction if it doesn't fit you just set it aside and then if later on because of the stipends because they kind of accumulate if they are not fully used to that if at any point you have a little bit more room in the block again you just go look at your bike lock and you keep that partially sorted so so it's efficient and see if any of those that you had to skip initially now become available again and that way basically you don't you don't have the inefficiencies of just throwing away transactions that might be includable wait on doing the book

um and then with the Benchmark to compare that against of course just the optimal strategy so so for that I'd like to end up using an abstract solver to actually find that the best thing and theoretically optimal Miner could do and then looking at the results um so basically this is as a function of the stipend size um which which makes sense right because if you basically don't have any stipend then you just can't include any transactions that all once you you call it a limited speech and if the stipend goes up of course at some point it just doesn't matter anymore um and uh as you might expect the optimal strategy kind of like starts with only being able to include basically that those are just pure each transfers initially 40 or something of blocks and then it goes up to too close to 100 as you raise the stipend size and

importantly though um while the naive algorithm is indeed especially for a small call um advertisers is a bit um much less efficient in being able to include all the transactions the backlog mechanism um which is still very simple to implement um almost like follows this optimal equip um perfectly of course at the beginning it's a little bit below but then even if you go to to relatively small circumcises around 200 to 300 bytes it's it's basically it's within one percent of each other so basically a minor who would run the backlog um strategy would would not have like at all noticeably as a smaller profitability from from like a closed Source

um and then um a as I was saying basically part of the as part of the analysis it also like happened to come up the question of um how would this Erp affect the ability for normal transactions to still be included uh in blocks and especially that's just um maybe already relevant then for when the get teams is going to talk about their concerns in a second and because one of these concerns uh that I read there was that basically transactions Above This diaper and again the Erp right now says type 300 but we might end up with something like 260 actually look better even better because it's just sufficient maybe um so then any transaction Above This 260 bytes in call data would just would

basically have to compete with um very high budget uh roll-up transactions but then the interesting kind of result of this is that actually because you have this accumulating nature of the stipend right as if there are 10 transactions and they all only use you always get this extra 1C and that accumulates it so then you can have one a bit bigger transaction afterwards um and so because because of the the nature of the accumulating um stipend and actually even at say something like 260 the backlog strategy lets you include over 99 of all transactions uh within the next block that they can

usually would end up in anyway and that already includes current a roll-up projection so like really big correlated transactions and of course those those I mean those would be the ones in front of the not the ones that have to compete in the back of the block so um basically um if you exclude those it means that all normal size transactions would still be excludable as normal without any issues in them I I did look into the just now there's a bit more basically found that 260 specifically the median size of of like the excluded transactions here or something like 2 400 bytes so that gives you a feeling for like that really only these very big transactions would have

would basically have to now compete for these potentially more expensive parts of the block and everything else can just be included as normal so I would say these kind of concerns are probably like um and end up not being an issue with this Erp um but yeah there are enough other valid consents to to continue talking about but I think that's that's all I have to say on this um any specific yeah specific questions or comments up oh Peter yeah I do have a question so um with this whole backlog mechanism

um the idea is relatively simple but um so what's an interesting problem that can happen let's say that I have at the I fill up the blog space with your alarms and then I have a high paying but high gas usage sorry High space usage transaction let's say I have a transaction which pays a lot of money but it requires say 10 kilobyte worth of data and I have smaller transactions that are cheap but they require let's say only 500 bytes now if I go with this backlog approach and what will happen is I will keep

adding timing transactions up onto the point where I free up 500 byte space and at that point I'm going to see that oh I have 500 bytes I can shop in one of the more expensive transactions but I will never actually consider the super expensive transaction because the super expensive one is 10K 10 kilobytes and I'm never going to have that big of a gap because there will be all always something smaller that will just gobble up that space so definitely this so my what I'm kind of afraid of is that um the deploying a contract will become this crazy expensive thing because it's

going to be a large core data so you cannot use this backlog hack to just uh stash it in somehow because you always have somebody else beating you to the function and the Roll-Ups will theoretically throw us become popular than olives will consume the block space and they will have significantly more funds so essentially if you want to for whatever reason to deploy a very high gas of certain very high space using transaction on on ethereum layer one then you're going to get a bit not a bit lost but doesn't that just mean that the contract deploying transaction has to

compete fairly with the Roll-Ups for log space yes like I guess I'm wondering why this is a problem they might have to pay a little bit of a tip to get included with the roll-up transactions uh I'm not so I I also mentioned this on a little document that he wrote down I don't necessarily consider this a problem this is just a rebalancing that people need to be aware of some people need to be aware of that if we Implement 4488 potentially deploying contracts on level 1 will cost an arm and a lag even though even now it costs an arm so it's it's going to

potentially it can make it significantly more

expensive yeah

Felix Lange: we should have been a bit clearer about this basically it's not also there was this point was also raised by junkrat um it's maybe not written in the best way right now you know opposition so basically the um it's not so much that there's no [Music] you know that you know like it's a it's it's it's not you know generally unfair that you know like big transactions have to uh compete with other big transactions it's more than because uh there is this limit uh then

you know like it's kind of like it shifts really like you know this version you're like what what can you do kind of really depends on if your problem fits into the limit or not and we think that's just kind of something that you know it may not be intended or I don't know we just wanted to highlight it because it wasn't really highlighted in the Eep was like one sentencer I don't know

Dankrad Feist: so I guess in practice what it means is that um transactions with large call data might have to pay a bit of a tip right

that

Felix Lange: that's the practice they will become more expensive is what Peter is

saying

Dankrad Feist: and yes and they can well I mean but they also do profit from lowering of the call data price right so will they become more expensive than now

Felix Lange: it's not okay for us I think the main we are not really trying to stress this point too much uh for us it's like the main thing is we are just really I can just you know summarize it really quick so we are just afraid of the two-dimensional nature of this scheme and this is the sole reason why we are complaining about it so much we feel that you know like there are there can be like unforeseen consequences from that and um we are trying to basically stress this point

because we feel like you know it's already like you know something where it took us a bit of time to figure out you know like what are the consequences of the scheme uh just by safety staring into formula and discussing what we kind of figure that oh you know it's actually going to mean that uh contract deployment is gonna you know it may cost a lot more or you know it's it's just it's in a different it just means you have to think about it like a lot more we're just worried that this is you know like this this change is not really like you know super it's not super clear what's going to happen like I mean obviously you guys are researching it right now so you know I guess eventually

we'll be it will be very clear what's going to happen

Dankrad Feist: yeah I mean that's fair I think as a practical comment though we need to be also aware that the consequences of having Roll-Ups in practice means that it will always become more expensive to use the layer one itself because the Roll-Ups are just more competitive right so roll ups just make much more efficient use of it so in in the ultimate end game layer 1 transactions will become more expensive due to that but I think that's okay you should use your laps essentially

okay but there are

Péter Szilágyi: one counter argument is

that if prolapse are so much more efficient than why subsidize them even further

Ansgar Dietrichs: this already drifting into the moment that kind of the substantive discussion around whether like if it makes sense or not just just very briefly saying this as well that unlike the the specific aspect of this two-dimensionality um of that workspace constraints now um I I would probably frame it a little bit kind of like the other way around where currently there's no protection of say a quote unquote normal transactions

against roll-up transactions so as we're talking about like the very long term scaling plan for ethereum is for everything to move to roll ups and so like in the long run the ES1 execution will be more and more just roll up management of course the question is how long that'll take but and basically at some point it blocks start to just be full of robot transactions and that can already happen without the CNP and normal translations would be more model competed um the of course the the kind of the the saving Gracie is that right now it's so expensive that um it may be Robert opportunity a little bit slower and we still we had more time whereas if we

introduce this Erp it becomes cheaper and so roll up adoption might speed up a little bit but importantly and I think this again this is what I kind of wanted to say is importantly with this Erp I I understand it as a protection mechanism for normal transactions because now with the call with the call it a limit and the the second mechanism basically the once we reach the level of adoption for Roll-Ups where they feel a significant portion of each block they are basically limited to the first like to some part of the block with this tip because of this call data limit and so the rest of the block would be left untouched for normal transactions whereas without the Erp if we don't introduce the AP once we reach those adoption levels um basically normal transactions have

become completely unviable because the all management sections have to compete with royal transactions so it's basically once for each adoption without the AP I think we will be in a much worse state for normal transactions the questions just might be a piece like um uh speed up adoption so much that on on that it's still it's still a bad effect but I think the AP itself is very much of like a help from phenomenal um transactions

oh yeah we know I thanks uh vitalik you have your head up

Vitalik Buterin: um yeah and I think one point I wanted

to make on the economics and just on the issue of like well um you know if Roll-Ups are supposed to be cheap place up why subsidize them one of the good Generations here is that there's a difference between like the first cost of data and the persistent cost of data um right and right now they're called Data gas costs are primarily set based um based on the birth loss of data um so like based on the question of like oh you know if all data if we had 10 times more called Data than the worst case blocks would like to really break that or probably get people to Pure perspective and the long run roadmap is that there's going to be this dedicated

data availability space and like there's going to be shards to hold this data and so data markets and uh like we're one execution markets are going to be more separate and that would actually like basically allow the cost of the codes like it would allow it would mean that the actual cost Control Data impulses on the network is uh much more based on what the persistent cost is because like there would be a target for layer one execution and then there would be a separate Target for all data consumption and so you wouldn't have this much of this this much volatility so I guess uh like one way to another way of looking at this is basically to

say much well if right now from a perspective um call data is uh priced correctly but from Asia persistent uh perspective call data is overpriced then adding some kind of two-dimensional limit basically it is the way to make it more correctly priced from a uh from a persistent perspective without like I'm this pricing it even more from even more from a birth perspective um but then of course like we have to ask the question of like well like if we only care about the persisted issues then like what would the correct gas cost to fall data look like um and you know what would it look like in the context of VIP 444 when it's

going to happen and all these things um but like basically like one way to just analyze the economics of this was start by asking the question of uh you know if we only cared about birthday issues what would the women be if we only cared about persistent dishes what would the limit be and if those two are misaligned enough that the miss that the misalignment just means that there's a lot of applications that could run without hurting things not being run that

Péter Szilágyi: it makes sense to try to separate the system I guess one one thing that we should

also consider um so if we just take a take a look at the costs and and seeing that well we're starting um the cost will be a lot better aligned and so on so one one thing that is kind of bothersome about the CIP we also highlighted is that it kind of says about 444 will fix the state growth problem and and kind of passively eventually and so the app he kind of says that 444 should be implemented either at the same time or soon after and so this seems like a super hand wavy approach to drop two terabytes of data on the network every year because it's

not obvious how 444 will be implemented it's not obvious one if we let's say we deploy 4488 next year early next year then we okay we now we again have to make a decision do we we do have a client a lot of us that are focus on 444 to avoid the chain growth issues or do we focus on the merch so again we we just opened up some next set of problems that we need to solve and um I don't know at one point is this whole complexity worth it to delay the merge so much wouldn't it be more meaningful to push through the

merge and then we could focus on these ones and especially I guess if the merge is done then these two clients can actually focus on sharding and the whole two things could somehow progress concurrently because I guess the ideal solution is for all of the rule updated to be on the charts so shouldn't we rather focus on getting the shots up and running as soon as possible

Felix Lange: yeah we didn't really want to mention this in the document but that is kind of like one of the things that like if we you know are allowed to make like very far ahead sort of planning suggestions and we kind of feel like you know ultimately the place for Roll-Ups is you know

short

and

Martin Holst Swende: yeah one thing also that we didn't add in this document is that the change proposed is from 16 to 3. which is a pretty drastic change um normally I think historically when we would like change some protocol contents we may be changed it in 2X or 1.5x or something but this is it's a very large change in one go

[Music]

Ansgar Dietrichs: and just just briefly on the question of

what of motivation um I think you're saying that like that you think long term shots should be the correct way to to increase data throughput and I think uh that we all agree on the question is really just do we want to incentivize the continued development of technologies that make use of this increased data throughput by already giving them a little bit of that benefit in the short run or do we basically want to just tell them please continue developing this

even though right now it's economically a little bit iffy because in the long run it will become cheap and I think that's actually I don't uh I I think that's a good question I don't I don't think either either one of those options is necessarily the better one but I do think that uh it does make quite a bit of difference say optimistically starting could arrive in I don't know two years but that already feels optimistic um so it's maybe two years something like that um whereas this could really tour through I think it would be on minute in a couple of months and so it would make a difference for one two years which I think would be enough of a justification if we think it's worth it

Péter Szilágyi: um but that's not really true really so

when you say that we are mainland in two or three months yeah this could be a manner but it also requires four four four four four which will most definitely not be enough for me that so I mean just so this Incorporated just makes the opportunity makes things cheaper and then it's kind of occupied with developers to survive until 4444 eventually hits the pipeline

Felix Lange: yeah I guess we should make a more structured approach here to talk about it because some people already said in the comments can't we just go through the document um we have touched on basically all the points now I think uh except for layer 2 Readiness which is maybe a topic

on its own um the thing about [Music] the 4444 is that we think it's not going to be so easy to implement and we have been talking it through multiple times also over the last couple of years like how to really achieve this like you know historical data pruning and I feel like the earliest good opportunity for this would be after the merch because uh the merge specifically also binds us to the reach subjectivity already so it's like when uh in order to participate in

the ethereum network after the match one must accept the weak subjectivity initialization so I feel like you know once we're past that point we can think about how that initialization is going to look like for uh for the ex yeah for the execution layer because at the moment it doesn't require this kind of initialization except you know implicitly with the Genesis block which I guess everyone has accepted by now so it's like we we need to make a solution for initializing the client with you know a snapshot for example and there are so many questions to solve like where are they going to

get the snapshot from and how they're going to put it to the client these things are like it's it's easier when there's already like the need to do it for the for the for the consensus layer I think

Marius van der Wijden: so quick question is anyone um is anyone really pushing for this to be included before the merge still because I like I'm I I don't think that the proposal

itself is is bad it has uh a lot of question marks in my opinion uh a lot of things that we have to um that that we have to to to verify to think about doing these large changes without uh too much data is uh is not an option for me um especially like taking taking a look at uh can the network even handle it um stuff like this and so like we're not really or at least I'm not

really arguing not to include this change in the future I'm just arguing that we don't have enough data to meaningfully make a decision about it and uh we have enough uh stuff on the timeline already to work on um that that that is not uh 4488 so I I I'm I don't know like I haven't heard anyone really pushing for this uh before the merch yet

Dankrad Feist: so I I would still be in favor of doing it before the merch I think like I mean I agree with all the technical points here but I still think that uh the

economic and the ux like I guess like the future planning pushing people towards store Labs showing that they are the future like that that side that went basically not really discussing here is I think still very very strong but um the reason right

Felix Lange: that is like a political reason then it's basically like it's when you say you know like

Dankrad Feist: yes absolutely this is this is political but like I mean how to like the community as far as I see it is in favor of doing it so I think it's fair to it to say that that to address this

political reason right and not only the technical parts

Felix Lange: so we have you tried you know not to include changes based on the political reason

Vitalik Buterin: I think we should open up a broader discussion at some points because uh I do think that this distinction between Tech and political is overrated but it's uh something that's probably worth having a longer chat over at some point

Tim Beiko: yeah and I I don't know I spend a lot of my time trying to gauge this stuff uh I I think there's probably like some folks who feel strongly about merge and and some who feel strongly about

like the reduction I I don't think you can make like a clear case either way that like people really want for 488 before the merge or people really want the merge before obviously you know if you ask brought up operators they'll probably tell you that like they have 4488 before uh and if you ask other parts of the community who are more concerned about say the environmental impact or you know the issuance of proof of work uh they'll tell you that the merge is more important before um yeah so I I think it's it's a hard call to make like it's there's definitely a uh yeah there's definitely folks on both sides

um and not like a

clear-cut

Dankrad Feist: I mean I I'm I'm clearly against it if it would delay the merch by a month but I I just don't see a reason why it would

wow

Péter Szilágyi: um one of them is that um I don't think it's fair to to debate whether we should do the brush first or whatever we should do 4488 first because uh actually we had a fixed timeline so I think if if we want to equal four for eight days before that then four for eight eight needs to have a very strong case as to why it's good why it's important enough to to replace the existing timeline so I

think it's not a if none of them were would have been scheduled until now then you can debate whether which one is more important or more urgent but once the timer is that essentially every team both with your money through two teams are working out towards the merge it's it's a bit weird to to somehow try to hammer or push in something in between and but again what I still want to emphasize is that 4418 is only addressing the monetary problem it does not address any technical problems related to chain growth and so I mean honestly I would say that 4488

and 444 should be implemented together it's it feels like um a very disingenuous thing to ship for for eight eight and then problem solve and then if the client has problems on on actually making four for eight eight viable and so if the if the 4480 VIP itself says that 4444 is kind of needed for it then to me it seems up to two VIPs should go hand in hand not uh not that we ship one of them now and then the other one maybe next year probably not depending on how the merge goes

Tim Beiko: I'm not sure who had their hand up next but Martin Michel and Scar the three of you

Martin Holst Swende: okay I'll I'll go quickly um yeah don't go instead of delays the marriage for one month and I think it definitely would I mean if we did the postponement of the difficult form and we've done that so many times now that we can basically do it in our sleep and forget about the the work that's come out because we know it's going to kind of work but this kind of change I I agree it's not like very complex but such a change in rolling out that fork would take non-insignificant amount of

engineering it catholically says and test it out on the test Nets after having done so and the fork is rolled out maybe there would also have to be additional resources going to checking the the this increased Network i o and handling any Fallout from that and and seeing do the boot notes croak and what can we do about that because another you know problems that might need to be solved in all the clients [Music] so I do think that if we were to say yeah sure we want to push through for

the 488 um in a fork before the March I I definitely think it would delay the merge um definitely that's my take that's it

Tim Beiko: thanks for sharing uh I think uh Miguel you had your hand up for a while

Mikhail Kalinin: yeah I I just yeah quick note uh probably I'm missing something but as for me like one of the purposes of 4488 is like the end goal is to reduce the transaction fees is this correct I mean by uh leveraging robots infrastructure

Micah Zoltu: quite correct I think the the goal of 4488 is to correct a missed pricing for certain op codes or certain things um call that in particular is arguably mispriced because it needs to be priced on several accuracies and we basically chose the simplest mechanism to price on those axes originally and we should fix that at some point

Mikhail Kalinin: okay let's see because if if this like the end goal and if this is what we will get in the end yeah that's make like this kind of change is very important uh from my opinion but

thanks

Péter Szilágyi: but you guys are saying that the correcting the best price but essentially currently you are paying 16 guests for storing data indefinitely in the network and you want to replace that with three guests for storing data indefinitely that's all that yeah he does you are still you are making it five times cheaper to store the same data

until eternity

Micah Zoltu: yes with the minor caveat that um chain history can go theoretically on a hard drive not

an SSD yeah but if you're

Micah Zoltu: purely theoretical

and understands not all clients actually implement it that way I do think from a gas pricing perspective State shouldn't be priced differently from historic data just due to

access requirements [Music] but let's say uh in next year or December the chain history won't be 300 gigabytes rather it was going to be three terabytes so when anybody wants to synchronize even if your client via casting snaps inclusive

whatever they will have to wait two weeks on the downloads just to download the free terabytes that's I mean that's going to kill you yeah I'm

Micah Zoltu: I'm with you on yeah I'm with you on the 444 needs to come first

oh

Felix Lange: sorry Phoenix go ahead maybe I should I should just try and say it I think it would be good now kind of to come to sort of like conclusion here regarding this because obviously we are not going to settle this today so we are we have uh our position is

that we think it's not suitable for inclusion before the March we are not saying it's not suitable for inclusion ever it is absolutely possible to do more research and figure out the hard questions and then you know like Implement something like 4444 to you can you know there is always the possibility of including this particular ebook we feel like the necessary work is not possible to complete uh before the match so that is our position other people feel differently they feel strongly that it should be included because it's a good signal to the community that we are committed to a future where Roll-Ups are

much more important and this these things we cannot reconcile these points at all and um so I just wanted to say that basically I think we need to have more in-depth technical discussions about the individual aspects of this for sure but I'm not sure if you know like this call is the yeah

Tim Beiko: I think that's reasonable I think this call is has been valuable to like highlight the different concerns um there's all you know uh light client has organized like a 444 call this week and and I think you know we we definitely want to keep like a parallel tracks to like solve the you know the different concerns um but yeah I agree we can't address all

those on today's call I think we've managed to highlight most of them on today's calls uh today's call sorry um let's go you've had your hand up a while and then Andrew gonna go after

Ansgar Dietrichs: so yeah I I think I agree with Felix the thing is practically speaking given that I think it's by now clear that we won't at least decide that we will do a pretty much uh 4.84 on this call and so um I would say within the the holidays in between everything I think the window for even if the next local Dives in four weeks or so we we would revisit this which I said we would only do if there

was some very significant change in circumstances or whatever even then it might already be too late for pre-match box so I should just practically speaking this means we we can we won't do that um I just would want to say maybe it's like a few closing remarks one I think it's important to say give a given that time teams seem to be very concerned about the worst case that would become more practical with this Erp but then that means that this should generally be a concern because the worst case without the Erp is even worse it's just that it's maybe a little bit cut out because uh Roll-Ups need a bit more traction to actually feel kind of box currently

because it's more expensive but it's only only more expensive by a factor of five if you account for overhead of robots maybe in fact a four or three and this might make a difference of a couple of months but not more so if uh whatever what kind of like terabyte several terabytes history growth per year is a problem like this problem would survive without the AP maybe a few few months later so we still have to prepare for that that's that would remember one and then remark number two I think it's just that I would say going forward we should continue the discussion around the key role of all core devs um in relation to the rest of the community and like what decisions should be part of the awkwardness process versus potentially

other venues because I do think that it's kind of telling us Maris was saying no one on this call is very strongly in favor of the cap I mean but myself as well like of course like the AP but I think the people who really really strongly aren't the CRP are just a very broad set of of people that you might find on Twitter who just aren't represented here at all and so have no voice in this process and so I'd say going forward we should really think about kind of how our governance on ethereum can ideally kind of include all the stakeholders but I think for today the decision is clear we won't go ahead with this before so and that's fine with me so yeah

uh Andrew sorry Andrew's at his head up for a while

Andrew Ashikhmin: uh right so uh I think uh we should definitely agree on going with uh 444 along with uh four four eight eight uh or like at least commit to four four four four four and uh from Aragon's perspective it would be preferable to do for four eight eight after the merge because it most likely will delay the merge and it's like so uh to my mind we should start like discussing the shape of Shanghai a little bit so we can perhaps tentatively say that we are going to to at least start investigating

four four four four alongside four four eight eight in Shanghai and there are also quite a few things that we wanted to do in Shanghai so at least we can try think in terms of the priorities in terms of what's more important less important but realistically should do in Shanghai invest investigate prioritize and so on so we should start thinking about post merge scheduling and what's important there

try

Tim Beiko: not to bring it up to keep our focus on the merge um I think you know as we start wrapping up the merge it makes a lot of sense to start looking at what's next and what the trade-offs are for anybody kind of

interested and just like the general things that have been proposed in Shanghai uh the ethereum PM repo in the issues section has like a pretty good list of I think most eips that are proposed for Shanghai so if you just look into that there's a bunch of proposal to include x in the Shanghai hard Fork there's actually not one for 4488 so if uh one of the authors wants to just create one after this call uh uh not necessarily for Shanghai but just so we can kind of track it there that would be valuable and then the other thing that's not included in that list is Beacon chain withdrawals uh which is mostly uh which mostly has to be

implemented on the consensus layer but there still needs to be some mechanism obviously on the the execution layer to credit those withdrawals uh and and that's also feels like a a pretty high priority thing um but yeah I think as the merge kind of wraps up we we definitely need to have that conversation and and if people want to start kind of forming opinions and discussing that now it's it's valuable um Peter you have your hand up

Péter Szilágyi: yes [Music] potentially not something that uh perhaps some of the Opera calls is not

everybody from the ecosystem who has impacted in with money or the other is present here so we might uh it's hard for us to save other 444 is important sorry for for ethics is important or not important or very important to say how important it is and we should reach out to or maybe organize a different value um one was I I agree with the general idea that um it's it's nice to have feedback from the outside I think uh it's very very important if we if we reach out for external feedback then obviously if we say that hey do you

or don't you want or forget it I mean that's kind of like asking do you want to raise the gas limit by thenx or not so the no-brainer answer is that obviously everybody wants smaller fees so if the gas price if sorry the gas that it goes up by 10x speeds go down by 10x hey everybody's happy so accept the clients who actually have to maintain it so from that perspective I think it's it's fine to to take four for eight days out and ask the community whether it should be included or not but I think if if we do that it certainly energies then yeah it needs to be fully self-contained I think you cannot just take four for eight days out and leave

444 in or out of the acquisition because the two things go together so I'm completely fine with the community saying that do you or do you not want 88 along with 44. so the two together that's a valid thing that can be debated but it's unfair to just ask Outsiders whether Ada should be implemented when we are clearly know that technically it's uh with shooting yourself in the foot and obviously we know what the answer will be from the outside yes they

want it

Dankrad Feist: so the quest would have probably have to be about whether 444 should become sooner because eventually it will have to be implemented anyway

yeah and

Vitalik Buterin: I think we should like find ways to ask the community to get a clear answer of like what sacrifices are people willing to take so like for example if the question is would you be willing to break the ui7 of applications that demand um things um that demands access to receipts older than a year if that means a 2X production and Roll-Ups um like that's a like actually a question that includes both sides of the trade-off like it's not necessarily that question but like actually saying you know look what do you find what do you find more importance what are you actually going to sacrifice because yes like if you just ask let me know do you want things to be cheaper they'll say Yes um but uh like if we ask a question then

includes a sacrifice they might say yes even like even when they know what the sacrifice is or they might not one second

Felix Lange: I'm sorry I don't I cannot raise my hand I think so what I want to say is since I'm not here often in this call I want to say uh I would really prefer if in the foreseeable future the all quarters would stay to be like this forum where we as the client implementers can like speak our mind about you know the issues and um you know like he keep that role and basically I mean if if there's a way to figure out you know what the community whoever that is once then it's like

really good to have that represented here and uh we can for sure discuss it but like you know this this call is I think a forum for client implementation and has to stay this way

Tim Beiko: yeah I think that's the reason right we can't like yeah it's very easy to spend an hour and a half just having like random viewpoints on this and and not you know uh not uh discussing like basically having client implementers kind of be be shut out from it um I think in terms of trade-off you know like another thing that I'll put out there that's worth uh bringing it up is there's a world where like we do the merge and then we could decide to prioritize four four eight eight and

four four four four as a top priority and then the trade-off there is maybe Beacon chain withdrawals right and that's another another case where it's like are you willing to wait an extra six to nine months where we can change withdrawals if we can get you know four four eight eight out before um and if transaction fees plus merger going to validators uh and I think that's another kind of kind of world where like it seems like the most complicated thing for Shanghai is probably the beacon chain withdrawals it's probably the only thing that reaches across execution and consensus layer um so maybe having like a execution layer only upgrade prior to how having something with withdrawals means we can ship it quicker and and you know focus on on something like four four four four

and four four eight eight um yeah so that's another an another trade-off basically and and um one where it's like valuable to get broader

inputs they're just trying to preventers uh sorry Ansgar I kind of cut you off there oh yeah but I kind of uh well I just wanted

Ansgar Dietrichs: to say to Felix um to explain because I think it's generally true and very important that like this venue specifically for most difficult client teams and other technical people who to discuss these technical aspects is is important I would just say then that it becomes problematic mostly when we then start to introduce somewhat

political questions in here because then it kind of it tries to basically take the legitimacy of the technical competence and physically just implicitly uses that to make political decisions and for example uh that's why I was just so for example I really like the the gets dried up on the it kind of made me feel like all those technical contents everything but for example there were also aspects in there that I would call political around decentralization of Roll-Ups and these kind of things um and I would say this is at least we will have to be careful there because if it basically uses the legitimacy of the kind of the guest team as the kind of the technical Steward of the ecosystem which in a sense it kind of at least is an important role there to then old political points then I think again then

we'll be starting to get into these precautions so if you have a pen if we also have this political topics we really need to have broad participation of of other people so anything we have to do it either way either just like stay only at the moment technical points or have a broader venue but then also include other people

Felix Lange: yeah so I can answer to this that as the guest team it is basically in our interest to be as neutral as possible regarding all possible uses of ethereum and this is a view that we have always held so uh we are never to discriminate against any particular use you know of of the system however we also feel that it's important um basically to to like

stand up for that and basically say that yeah I mean there for sure there will also be uh applications which are disadvantaged for example by the 4488 and this is uh maybe why we are taking uh this kind of stand you know like the the it's not you know like we we don't really know that part is more you know like we just kind of feel like there's it might put other people at a disadvantage and you know like we would like to speak up for those as well and I think this voters need to know you is okay to have as a client

implementer agreed

Ansgar Dietrichs: and I didn't mean it as a criticism at all it was just basically something something to be careful about but but yeah I think I think you'll be

all right

Péter Szilágyi: um I think we also mentioned in this test that um there is this change that it might prefer roll ups over using layer one for for normal transactions which is again fine so there's nothing wrong with it and there's nothing wrong to succeed politically prefer Wallace because if we decided in the long term ethereum should go towards roll out because they scale then that is a complete device task to make I think from our perspective it's just important that the eif highlights the implications that it will have for layer 1 transactions it's fine we can

say that yes we are going to make everybody else's life more expensive and we're going to take a hit for it that's fine we just need to be explicit about

it foreign

Tim Beiko: it seems like we're not gonna do this prior to the merch we keep the merges the next uh next thing and our Focus there um there's a lot of like technical concerns raised about uh you know how to best deploy this uh I know like client you've been kind of asking questions

about that in the chat and others as well like what do we uh what do we want to see specifically uh 44488 to be kind of you know considered more um and then there's basically the solving the concerns around four four four four um so that seems like something we you know pretty concrete we can work on as the you know merge work gets gets finalized um and along with that we probably need to start thinking uh about what Shanghai starts to look like in the trade-offs there between the different proposals uh if you know we want to include 444 uh um yeah if we'll include four four four four and four four eight eight uh

shortly after the merge um yeah does this sound generally reasonable Peter you have a con

Péter Szilágyi: yes I just wanted to add that um essentially 4444 is kind of also incompatible with the current uh invariance of ethereum because currently if there are promises to keep all that data and that's a promise that we said that once the merge is done this prompts are going to be re-evaluated because if we want to go towards scroll UPS if you want to go towards request status clients Witnesses Etc This Promise needs to go so it also feels a lot more

natural for 4444 to be implemented after the merge because then it's not breaking any promise it's just upfolding the new invariance of the new version of

Instagram

Tim Beiko: yeah and Michael had a comment about that in the chat uh do we have time to discuss uh basically the the post merge historical guarantees for data um yeah happy to take the last 10 minutes to discuss that if if uh there's nothing else on on 4488 that people want to bring up

Lightclient: I I do hope that the conversation focuses on what we can do now related to four fours I know that talking about

after the merge is important but there's also like questions that are circulating right now about what we can do over the next three to six months to make it so that four fours is in a place that clients are happy to implement

post merge

Tim Beiko: yeah I 100 agree with that it is a big EIP and it's not just like something we can decide once the merge is done like Hey we're gonna do four four four four because we're going to realize there's just a ton of work so any work we can do in advance uh you know like the biggest area seems to be like how do we actually standardize historical retrieval of blocks you know you need to prototype that test it and all that is kind of beyond the scope of like the consensus changes in a way and and we

probably want that to be if not like fully working yet the verities prototyped by the time we decide to include four four four four into a specific upgrade um yeah so there's there's a lot of value in in starting those those efforts

Protolambda: now yesterday during the breakouts call or for first we already kind of concluded that's there are d-stops and you could think of it as the ability to import data in standard formats into clients without removing the ability to surface on the current Network layer the next the uh experimentation with the distribution

of the data and then once those first two points are really solid then you can run the removal of the current ability to serve the data

and

Lightclient: it feels like most of the feedback from the breakout session yesterday is that people are not happy with the proposed solutions for Distributing the data and the the main solution that we discussed was chunking blocks into you know certain ranges that have been pruned and providing them over some sort of BitTorrent and that would be the solution until we have the portal Network fully

operational but I and I I just generally see those two solutions as complementary in the future rather than just relying on one thing so it feels like that's the current biggest blocker and I would like to hear any feedback on on that or ways of Distributing the data that people are more comfortable with

I

Micah Zoltu: I would mildly prefer to keep that discussion and breakout runes mainly because we have six minutes left and I would personally prefer to discuss ethereum's chain history guarantees which seems simpler

Tim Beiko: so what do you think the chain history guarantees

like related

Micah Zoltu: yeah so yeah I'll set it up real quick um so right now our ethereum chain history guarantees is basically that uh for a client to be you know a correct client and not all clients are you should be serving chain you should be saving all of chain history and making it available to your users and over gossip the this is not a sustainable strategy indefinitely um it is a sales strategy for some period of time and different people believe this will last different amounts of time and so the question is is post merge can we change that guarantee and say

that there is no longer a guarantee that ethereum's chain history will be available Forever at some point it may disappear it may disappear from some clients but not others it may disappear from all clients it may disappear from the face of the planet we are not guaranteeing that if you want to keep that data you can guarantee it some other way in some other mechanism but the ethereum clients that's not their job their job is no longer to guarantee that chain history will be available forever and so the reason if we can make that assertion and say say that we agree that is a thing that we want to say it going forward then it opened us up a number of doors for us but we really need to tell users this far far in

advance of actually doing it like long before we actually started dropping chain history we need to make sure users are aware of it so adapts need to stop using chain history as like their storage mechanism and like layer twos like use their chain history as storage like that is how they do store storage in most layer twos and so um I think with the merge for a number of reasons it's a good time to change that stance and again we're not putting a timeline on this we're just saying at some point in the future chain history is no longer guaranteed by the ethereum clients you if you want to guarantee it go elsewhere and so I guess the first question is does anyone disagree with this is there anyone who thinks that we should continue to make strong guarantees about chain history

Felix Lange: so we feel that with the merch we are already basically dropping this guarantee because the beacon chain also does not provide this guarantee is kind of already this step where we are you know going away from this you know like history is available we still have it you know formally available for the applications but it's something that you know we have been working uh towards removing it for a long time and I I am strongly with you on this timeline to say that we should announce it but at some point we got to make the announcement so yeah

which part of History not provide

Felix Lange: what I mean is that like the beacon

chain fundamentally the way it's built is like you know it doesn't need all chain history

Lightclient: okay we don't I didn't catch that

Felix Lange: no

I

Lightclient: I mean we don't need historical death for the execution clients either

Felix Lange: well yeah but that's something that you know like at the moment you do kind of need it

Mikhail Kalinin: so um um yeah for what it's worse uh after the match you don't need ancient block headers to prove um that the chain is the valid one in terms of the proof of work sale because

we are on the proof stake and it uses other mechanisms

Felix Lange: yeah so at that point it's like basically optional like it's just not a matter of do you want to have it or not and we're not going to drop it right with the merge but yeah

Péter Szilágyi: one more thing I wanted to add is um and essentially um as far as we know other clients already started skimping on on chain history I may be wrong here please correct me but I think aragons doesn't served receipts anymore at least not by default never mind implemented chain pruning so you can just prune your own nodes so

essentially we are seeing that clients are leaning towards already pruning stuff that they might need or at least making certain pruning uh medical Essence available via flags and users will most probably the flags are available they will most probably use it because I mean who wouldn't want to drop 300 gigs of data from their hard drive so it's a essentially the desire is already there to get rid of all that data and if we want to explore features that would crowd this data significantly faster like Witnesses or or Roll-Ups then the desire will be even stronger so

I mean we're going to end up in that point sooner or later so might as well buy the bullet and do it properly instead of interactive way where everybody implements something else

Tim Beiko: so it sounds like so far everybody is mostly in

agree with this

Micah Zoltu: is there anybody who disagrees and we should keep these guarantees if not then I propose we just start announcing to the community now that hey chain history is going to go away one day

Péter Szilágyi: I would this a bit however I think it's super important for us to to support I mean to have archives and to have a very strong

case on how how we will still have some Archives of that data so it's fine to say that ethereum clients will not have access to it but I think we can just say that well it's everybody's problem sorted out so that seems like um way out so it would be nice to also

Micah Zoltu: yeah yeah I think in my in my mind we step ones we tell users ethereum clients will no longer guarantee chain history and then step two we probably go out and try to build something else like torrents or portal Network or whatever and then

eventually then we actually make good on our step one guarantee um that's just pragmatically that's how I see things falling out but I still think there's value in removing the guarantee first or announcing the removal of the guarantee even before we have a solution to archives nodes and all those things but I do agree like someone should build up and that would be useful and that'd be something that maybe even people in this room will build

Péter Szilágyi: so I personally I think we should have um a solution even if it's a domino Simple Solution maybe if it's just um an ipfs or whatever base solution different based solution I think it's important to

have something an idea at least from the get-go on how we could serve that data just so that people won't be freaking out that we were just deleting the history

Micah Zoltu: you're saying that when we make this announcement you'd be more comfortable with making it if we make it in in the form of ethereum clients from the long guarantee chain history however before we remove that we assure you that we will provide some alternative mechanism that you can use um voluntarily but it just won't be artificial clients necessarily such as we'll give it a BitTorrent or something like that

Péter Szilágyi: so my personal uh thing that I'm afraid of is that we announced that clients

will not need to maintain or will not maintain history and then a lot of sudden clients were super aggressively start pruning it and just referring to this notion that while the promise was broken so they can just prune it and then it will be up for the last client standing to to keep that data before it gets it gets lost thank you yeah the announcement will cause an exodus is what you're worried about no well I mean the announcement will give legitimacy for client implementers to very aggressively delete stuff and they might prematurely

Tim Beiko: um already uh sorry guys uh I just see Felix has had his hand up uh uh for a while so I don't know yeah I'm not I already said what I want to say Okay um so definitely you need to continue those conversations uh we can have them on on Discord I think yeah if you are listening you know clearly the guarantees around historical data is will change post merge uh it's a question of when and how rather than if um so you know I think there's a lot uh there's a lot of you know uh room and how this can be implemented but uh it's

something people should start paying attention to um I think it makes a lot of sense to spend time on four four four four uh going forward and making sure we we continue to to kind of Flesh that out and you know regularly kind of present updates about it here um and then worth noting this is the last awkward dance for this year the next one would have been on December 24th we're going to cancel that um but next week there is a consensus layer call scheduled next Thursday at 1400 UTC uh we will discuss uh updates on the merge and kinsugi there uh so if folks here want to show up there as well the first part of the call will be uh dedicated to kinsugi um yeah thanks a lot everyone really

appreciate also just like the tone of the discussion worth calling out like I know there were a lot of uh strong feelings about 4488 uh and I appreciate everybody being respectful I think we had like a really productive conversation and uh yeah this was a really good way to end the year uh for awkward deaths uh thanks a lot everybody

Felix Lange: thanks

Lightclient: thank you

thank you too thank you everyone Lounge hi everyone [Music]

[Music] foreign [Music] foreign [Music]

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.