All Core Devs - Execution #126

Transcript

[Music] [Music] [Music] [Music]

so [Music] so [Music] so [Music]

[Music] [Music] [Music] hello everyone

oh

Tim Beiko: hello everyone welcome to awkwardev's number one two seven one two six um a couple things on the agenda today um as mentioned on the consensus layer call last last time uh we're going to spend some time talking about kinsuki and the the upgrades we have there and then we have a couple eips uh and and and things about the merge to discuss uh but first um just wanted to mention aero glacier so the aero glacier upgrade is happening uh on december 8th all of the clients have a release ready uh i'll just share my screen real quick

uh there's a blog on blog.ethereum.org with all these releases um otherwise in the execution specs repo there's also a link to the spec with all of the client releases associated with it um yeah so you can find them here there's only a single thing in aero glacier so just difficulty bomb push back and nothing else going in so that was the first one um next up kinsugi so i'm curious uh yeah have any clients basically made progress on the specs any issues people want to bring up

Marek Moraczyński: i can give you an update so in other

words we implemented eips changes in execution engine api of course we have to do more tests we have to reject ourselves process and we need to add message ordering however even without these changes we are ready to start testing with consensus clients uh what is more we pass test with march mark and test vectors so yeah that is update from another mind nice anyone else

Marius van der Wijden: yeah so from cats guess i created a version with

eap4399 enabled i'm not sure if like we have to decide whether we want to run the first test net or the testing on monday with 4399 enabled or disabled because it changes the block hash and yeah so i have one version with with uh 439 enabled but i can also create another one without it and yeah i created test vectors for like the test vectors are without four three nine nine but i can also create test vectors uh with four three nine nine and uh

mario created a really nice tool to run test vectors and to create easy test vectors uh for the con for the execution layer and um yeah currently it only runs with gas but uh we tried we hope to extend it to other clients soon

Danny Ryan: couple things there the weekly devnet launches which we like to take any gear next week will be on thursday uh rather than on monday so there's a little bit of time to coordinate between now and then and i'd say if possible it would be best to just do it full feature unless we have a particular reason not to um

but i guess we should circle back on on uh perry put a proposal together so that on monday tuesday we can iron out the last details before thursday

Tim Beiko: uh yeah just to confirm nethermine did you guys have uh 439 implemented as well

Marek Moraczyński: yes

Tim Beiko: awesome

Danny Ryan: cool and i asked y'all to update if you have done m1 which is just getting implement basic implementation and testing together mark it on the on the spreadsheet so that people can do a little bit of pairing at the end of next week there is also something raised by

merrick on the test vectors uh as a response for the update forks choice if there's no execution payload it's geth is returning 0x for payload id um is that the behavior we're expecting or one thing because the spec seems to imply the null value or not doesn't exist on the object

Marius van der Wijden: well what once again what's the case uh when it should be what's that until default is updated if there's no execution of payload there's no excuse there's no payload id

and so i understood it should be known

yeah yeah oh it's just then i write my quote i can fix it okay

Mikhail Kalinin: i'm also wondering what should cl sound uh when the focus is updated when it uh literally creates the first initiate the build process for the first payload in the network so what should be the portuguese state that passed on this call

yeah because there is no yet a lot that

is they had

Danny Ryan: right i mean semantically setting the head as a proof of work block might be you know as as the for four block you're building on might be the correct thing

Mikhail Kalinin: yes so yeah that's what we currently need

yeah i think

Marius van der Wijden: okay because we need the consensus layer to send us the hat that they want to build on

Danny Ryan: yeah which makes sense i mean if you had two viable competing terminal for fork blocks the consensus player needs to pick one and to build one um and so that i think should be the way we do it

Mikhail Kalinin: yeah right it sounds correct but just was wondering because this is something underspecified yeah right it's just it means that with this call the uh choice rule will be switched to the proof of stake of choice rule as well

right which again i think makes fun yep

Tim Beiko: cool um anyone from aragon or base you have updates

Andrew Ashikhmin: um yes so we have a team member julio

who has started working on on the march in aragon but it's still uh still um very much uh at the beginning but i believe julio is on the call so he might give us an update if he likes um okay regarding ap for 399 i'm i i started looking at it yesterday so i'm still like trying to understand how we can implement into aragon but yeah nothing yeah nothing new for now since

Tim Beiko: that's cool so yeah and you're still basically implementing the the eip3675 as well i guess the actual merge

eip yeah yeah right great um anyone from basu is there i don't think we have anyone from basu on the call

Fabio Di Fabio: uh yeah i can talk

Tim Beiko: oh yes sorry i'm trying to scam the grid awesome

Fabio Di Fabio: yeah about this uh gary is mainly working on this and i can't add too much looking at the issue uh that seems to be a lot of progress lately so but

uh gary can uh for sure tell more but it's not online at the moment

Tim Beiko: okay no worries um was there anything else aside from like the client updates and and the the issues we've touched on that people wanted to discuss about

kitsugi

Danny Ryan: yeah i have a quick point about the 3675 spec which was slightly different than amphora and i just want to highlight that if you take a look at four choice rule in 3675 if you look at the first note in italicized that's the proof of mistake

a ps4 choice updated event must be respected even when the transition block of the four choice is not a terminal before block from the view of terminal total difficulty they're essentially in the consensus layer although the consensus layer and execution there will both be shipped with terminal total difficulty but in the consensus layer there is a potential manual override which can only accelerate the merge so make a lower terminal total difficulty or set a hard-coded terminal block cache and because of that and to avoid complexity of having to do this override in two places and some of the errors that might occur there it's only on consensus layer and

so the consensus layer might have a view where terminal total difficulty might be earlier than what the el has hard coded and so it the el must listen uh to these four choice updated events even in the event that it seems a bit early compared to the terminal total difficulty so there's no need on the proof of the fork choice rule to validate ttd but yeah i'll still use local ttd to turn off block gossip and block import for the p2p and i linked the second thing i linked is a deeper discussion of that design consideration and i just wanted to there were there was some

testing and some different failures and different logic changes around the validation of ttd in el so i just wanted to point that out that the spec says slightly otherwise than what it did in amphora question okay um if you have any questions around this logic change just pick me

Tim Beiko: cool any other issues related to kentucky

that someone wants to bring up

Mikhail Kalinin: um i want to bring up a small issue let's just drop in the chat uh this is the issue to discuss the validation error format which will be used by el to send the validation error that happens during the execution of a block or validating the block header uh this is mostly so initial thought was this is mostly like for ux purposes uh so the cl client will be able to just log some message if the payload is invalid and it can read from the logs and without the need to go to the

el client log and match the payload hash and what happens to investigate what has happened so um it would be great just you know to see more opinions before making the final decision how it should be done for more yeah el client developers so that's it

Tim Beiko: okay thanks for sharing anyone else okay if not i think miguel it's also

worth it uh to go over your related point about the fork identifiers for the merge before we dive into the two eips we wanted to chat about

Mikhail Kalinin: yeah cool so we have okay so we have to specify fourth next and for cash for the merge eib for in 36.75 and [Music] from what we have discussed during amp print drop these numbers and these uh derivatives should not be affected by the merge so literally work next just stay zero

uh and for cash is the same as of the previous fork um but when it's turned into the spec change uh the question of how uh how it should properly be implemented um yet again so i just wanted to like uh just discuss this and like make a final decision to make their respective change to the eip um and my main question here is if we have the fork hash um [Music] let's just suppose the mesh has happened and the fork hash hasn't been changed uh and suppose the proof of work network keeps progressing

um and considering the fact that uh the same process and the the like the fortress rule and everything else will be like coming from the cell side to el and also considering that block gossip will be disabled what can go wrong in the worst case if the fork hash of the nodes that run in the proof of stake network will be the same as of the nodes that are running in the proof of work network that keeps progressing so that's the main question if uh my my god is that

nothing bad can happen uh they will [Music] these notes may exchange with the transaction messages but i don't think it's a problem so yeah we need to decide because we can't update for cash easily like retroactively or uh like with the the how is currently specified in the eip is that the fork hash is going to be updated when the real um transition block number is known but if it's done it could like split the network um for

because nodes that are in sync and not yet know this transition block number uh their fork hash will still be the old one but the nose who has that has passed the transition will have a new fork hash and they just can't talk to each other that's the core that's the problem

Danny Ryan: right so someone go ahead danny uh i was just gonna say is this this helps uh filter peers when things are well

specified and known in advance and uh if we don't utilize this mechanism for this upgrade because it is hard to get right and can cause the splitting because of the dynamic nature of the fork block it if i understand correctly it would only reduce our ability to filter our peers but if we have stable connections and peers we'd probably be in good shape anyway is it is maybe avoiding this mechanism here a potential path so that we don't have to worry about the issues

my

Micah Zoltu: correct understanding that

the someone who just continues running proof of work and does not switch over to producer's stake the only network that they're still gossiping on is the transaction network is that correct like they otherwise don't share any connections is that accurate

um yeah i think

Mikhail Kalinin: yeah but other methods will still work like blocks and yeah and there's no dates that were snapchatting stuff

Danny Ryan: right those more direct requests other than gossip that's still very

Micah Zoltu: well as soon as the first block comes in

you get like your execution layer will node will say hey i'm not expecting any more blocks you're bad i'm disconnecting you i guess the first block after first finality i think it's more accurate is that

Danny Ryan: like somebody's got occupying proof of work blocks beyond

right yeah like that's in this background

Micah Zoltu: right so the network should split after the first finality is that correct like everybody should disconnect from each other basically and they'll stop trying to talk to each other and so we should get a nice clean partition at finality that personality is is that an accurate statement

Mikhail Kalinin: i'd say yes that's a good point

Micah Zoltu: and so if that's true the duration of this problem is for the time from the

fork to first finale i i heard a groan from i think yeah martin

Martin Holst Swende: it was for me martin uh i think if if we have if if all that happens is that one side disconnects the other um that's not the clean disconnect split it just means that the disconnected partner will try again and succeed to connect and then eventually get kicked out again and it will continue that way if we want something clean i should think we should think about how this type of how

we could integrate this with quark id somehow and i know there's been a discussion about that 4k is usually based on numbers and after the fork we do know the numbers so we could i don't know if we like retroactively could modify the fork id in hindsight but during runtime as in not like putting out the new client but the client dynamically modifying

yeah right but according to the yeah to the eip uh instead of once the transition block is

known uh we're going to do that for ready transition

Mikhail Kalinin: i'm worried that according to this pack um the node that has just started to sync with the network and will try to connect to those that has that just passed the transition even even they reach the finality and whenever the fork hash has changed it will be different and according to the current stack it should just not connect to this node because it doesn't know it's not it's not this is a known uh fork for fork hash or for the node for the local node that connects to the remote one

and it just drops the connection that's my understanding of the stack i mean obviously iep that introduces fork if you if you yeah if you said it retroactively um and you're in run time so uh you can only do this when you know the exact number right but if you yet this number is not known for the local node because it's still syncing and

hasn't reached this block it will it will use different four cache and it will need to connect to someone to to give uh to pull the chain data and get some but it can't connect because of all cache is different

Martin Holst Swende: yes

Danny Ryan: so is that strictly true though that you can't connect if your core mesh is different because the way four connects i need to dig a little bit deeper into cmp but i believe the way the fork next is that if your peer doesn't know about a fork that you can still connect to a cert in a certain capacity and you wouldn't

totally disconnect from them because they may be

thinking if

Mikhail Kalinin: you can recreate the if you can get the same cache uh using the fork next and the upcoming four caches then you can connect if you can't do this you should disconnect or you must disconnect according to the spec this is my understanding probably it's wrong but i've like read it like for several times

Alex Stokes: no i think it reads that way i think the thinking is that this would have been a for work that happened in your past and according to your past it's not something that you're respect so then you ignore it

this

Micah Zoltu: is the expectation with fork ids that all of them are known at startup like so when you boot a client you know all four ideas that your clients should be able to sync with up to and including the latest i think and the issue here with if i understand correctly is that with because this fork doesn't have a known uh sorry the fork ids currently are based on block number or hash

Péter Szilágyi: block number

Micah Zoltu: okay so the issue here is normally for every other fork we know the exact block number like from genesis block like if you just start up a client brand new and you have genesis and a config file you already know the block number for every

future fork that up to the download client and so therefore you should be able to connect to anybody because you all agree on the fork numbers the issue here is that we have a fork that we don't can't hard code the block number in at least until the client releases after the fork happens and so we're in this weird situation where you you don't actually know that from genesis and therefore when you connect you don't actually know what for what block number to say is that hey i'm expecting this for the fork id is that all accurate

Péter Szilágyi: actually you can't even hard hard-coded after the fork because if you are good after the fork and for example i restart my client and

i say that okay i did a four ten blocks ago and everybody else will drop me from the network because they will see that i'm at block 20 million i didn't work 1 million block ago but they are again similarly unlocked 20 million but they did not do a fork one million dollars essentially them and i am on two separate forks based on the four id rules

Danny Ryan: so we could create a synthetic fork num block number where essentially it's like everyone should upgrade their el client to be proof-of-stake capable by this number and this is also the number that it would be using for for cash and then ttd would be some time after that

Micah Zoltu: yeah that way we get the nice clean separation of networks which will basically be people who upgraded to proof of stake and people who didn't or rather people who upgraded their execution clients to a proof-of-stake capable execution client and those who didn't and once that block number which is a fork block with essentially no code changes in it once that's reached the network should partition cleanly and um then when we get into ttd we don't need to worry about forklifting that i know you're trying to describe danny

Danny Ryan: yes

Mikhail Kalinin: um i have a question um before this walk identifier um it's also used in

the in discovery right

Mikhail Kalinin: okay yeah we can pick like large walk number that will definitely happen after gtd as well

Micah Zoltu: i think for for danny's idea i think we'd want to target before ttd

Martin Holst Swende: yeah that was nice

[Music]

Tim Beiko: and i do think there's maybe value in that because it kind of gets people downloading both clients like anyways there's going to be a change to the consensus layer before we hit ttd so we can tell people to also upgrade their execution layer clients at that time and then they're going to have to

upgrade their execution clients once more as we get closer i guess

Mikhail Kalinin: uh and what's the purpose of setting it before dtd because if somebody really needs the proof of work network after the match so it will also include this number as well

Micah Zoltu: uh no so if you upgrade your execution clients to the client that has the code that says there's 4k there's a new fork empty fork at this block then we know that your execution client assuming you didn't hack it or whatever will turn itself off when ttd is reached and so we're confident that you will at least not continue on on a proof-of-work network like you you will you'll just stop at ttd worst case

scenario

if you don't notice something

Danny Ryan: a bit funny here uh with my interest essentially if they intend to not do the fork then we will uh disconnect from them at this point

oh

Tim Beiko: yeah right but they still have that's not actually true though because they still have an incentive to mine all the way up to the very last block like they get paid so they're basic if they disconnect then if the disconnect then it basically says you know like we're losing this amount of hash rate and that might actually be a useful data point knowing like x percent of the hash rate is not even

going to bother mining close to the merge

um yeah so that is

Micah Zoltu: that is true but you have there's it's like already there's kind of incentive for miners to leave early because sell your hardware off beforehand um this is just one more incentive like we're basically saying you have to do this last upgrade or if you want to stop a week early you know you don't even have to bother upgrading your infrastructure or it'd be nice if we can just say hey miners don't have to touch their infrastructure just keep running your old clients right up until the last minute um you don't need to do anything and that way we keep retain as much as possible so we don't have a precipitous drop in hashing power at the last minute

now i don't know how strong that incentive is i don't know how difficult you know upgrading client software is for miners and you know supposedly there's some mining pools that are going to be switching proof of stake and so they'll probably upgrade anyway so maybe it's not a big deal but it is an incentive

Tim Beiko: so i think in practice assuming they want to keep making money um you know some of the miners as you said are mining pools a lot of them will also use something like flash bots or or whatnot then like if they want to keep you know yeah basically making money on mev as well they need to upgrade so i don't it feels like if they're gonna drop you know if for them the calculus is like i want to drop before the merge

uh yeah they're probably going to drop anyway martin

Martin Holst Swende: yeah i was uh so i understood one of the one of the drawbacks of having a dynamic 4kd thing is that it makes difficult print notes that are in the middle of syncing or are wanting to do a sync right around when t3 but i didn't really understand peter you're what you said about this being impossible or being the problems that you saw with it and i'm switching to another work id

Péter Szilágyi: so the entire network simultaneously switches

to uh swaps in a new four kind that's fine but if part of the network swaps in a new fork id and the other part does not for example because it requires a new client or requires a restart and what happens is that the clients who swapped in the new fork id they will suddenly advertise a fork in the past that the other clients are not aware of which means that chain-wise they aren't compatible with this command

Martin Holst Swende: yes and that's exactly what we want to achieve

Péter Szilágyi: i thought that the suggestion this

particular suggestion was that we wait until uh pos arrives and then we just retrospectively say that oh by the way yesterday's block was the pos block

Martin Holst Swende: um yeah well we reached the third total coming the terminal difficulty block and when we see it we switch work id

Péter Szilágyi: if we do automatically an entire network does it that is fine

Martin Holst Swende: that's that's the idea yeah

[Music]

Marius van der Wijden: but what if what if there are two two uh blocks on the third terminal different

Danny Ryan: yeah i think probably safer to do with a finality if you do it

Marius van der Wijden: yeah the

only way to do it is with the finality

club yeah

Martin Holst Swende: okay yeah but so the idea would be that the entire network that does continue on group stake does so um at basically the same time

Micah Zoltu: we can't actually do anything at the same time though right no like within like one may see finality before someone else and then they see finality they advertise to someone else who has not yet seen finality and then that advertisement results in them saying oh you guys we disagree on fork id disconnect each other

Péter Szilágyi: there's no disconnection happening on for the updates so the forecast is only

verified when you do an initial connection or in the eos figure out whether you want to connect or not yeah current existing connections will not blow up because the forecast changes just if you want to establish a connection then that might be rejected

if you're in the middle of yeah good

Micah Zoltu: so if you're in the middle of sinking and you're let's say almost caught up you're like a day behind or something or an hour behind head almost caught up with syncing and then you're you you shut down for a reason restart your computer or your power edge whatever and you come back up you won't

be able to connect because you don't think that because you're past the fork block and so you try to connect to people and they all say hey the fork block was you know back there that block you downloaded and you say i'm past that block that was not the fourth block because you have not yet reached ttd is that the issue

Marius van der Wijden: but that cannot really happen because you before that like for you to reach that point you would have to have a consensus layer client already running the consensus layer client would then like feed you the current hat and you would could sync up to that

head

Mikhail Kalinin: um okay

once again everybody has transitioned and switched their fork identifiers in the network i'm like the the new one the new guy and just starting my notes like let's say uh a half of an hour after the transition has happened i'm trying to join like my execution layer tries to connect to everyone that has the new fork identifiers but i don't have it locally because i don't know that i don't even know that i should change something you know in in my el client to be able to connect to each other to other to the to the rest of the network my question is in this case how would this client that doesn't know about the

fork id has updated how would this client be able to sync with the network

Péter Szilágyi: in that case there's a actually a chance that so yeah i know that in one direction it is permitted so you will connect as long as you consider that you have enough data to download i'm unsure what happens at i think

it will allow connections because on from one side the peer that you join to they will see that you your advertising the next block will be focused for you so they will say that okay homestead is at block 1700 something you think that that's the next fork you're outdated you are just wanting to sync so the the fear that you joined will allow you to join because they they don't know that you're you're on some other form the only information they have is that you're at genesis and the next work is homestead it matches up you want to connect so from that perspective the connection

will be allowed from the other perspective you what you will see is that [Music] the other person is actually on the fork id that you have you know nothing about and that might actually cause you to disconnect because the other side will actually advertise for i did if this hash checks on that you cannot compute because you're missing the the thing so actually i think you will refuse to connect to anybody who's already on eos so in that case possibly there would need to be a

upgrade a client release with the hard code otherwise you will be able to join

Mikhail Kalinin: yeah that's that's my understanding too also uh i don't think that if we said this walk next uh before uh the actual transition it would differ much from if it were just zero because if somebody wants to keep keep mining and continue the work network they will just take this client release with this fork next

and remove the ttd and other stuff and do other stuff that needs to keep supporting the proof of work network and just use this client and the same fork next will be there so as if you're just zero so i think it should be after the transition has happened if we want to split um these two networks

Péter Szilágyi: honestly i think it doesn't really matter whether it's a little bit before the transition a little bit after the transition um generally the reason why we introduced forecast was that especially on the test mats we have generally maybe 10 of the nodes

upgraded to a new fork 90 percent didn't and then it was for the rest of the 90 percent it took three months to upgrade so during these three months it was really annoying to finance peers because you were constantly finding peers that were stuck on whatever old block or old chain and meaning that the way to somehow separate the two networks so obviously previously we did it very very precisely because to be precisely new but there isn't i don't think it's necessarily essential for this fork i need to be extremely precise so if we can just update the fork id i mean hardcore

the fork id to an approximate block where the us could happen and essentially that block will be the one that will split clients that upgraded versus clients that did not operate and it's not this is actually a protection mechanism against malicious people so if somebody is malicious and they want to download the code and they download guest source to their ability to qualify or they try to convince other people to run malicious modified code we i mean we can't do anything they could as well take the 4k so 4k is kind of like to prevent naive non-operated users from causing too much annoyance and from that perspective i think it

it doesn't matter whether the fork id gets updated a thousand blocks or five thousand blocks before pos or five thousand bucks after pos it's just the idea is that it shouldn't cause havoc for three months straight after the [Music] pos switch i mean yeah of course it's definitely better the more precise it is but i don't really see any particular downside if it is not that precise if there are a couple days plus or minus which in my view it just do the same

Dankrad Feist: quick question what speaks against just updating it well ahead um so the

i i don't know all the details on the peer-to-peer network but here's one reason why that could be good basically people who forget forgot to update their clients would then see a gradual degradation and thus get a very strong signal that they did something wrong and potentially be nudged into updating it in time and so you'd have fewer people who for some reason went right for the upgrade

Danny Ryan: yeah my primary argument against that is that if a contingent of miners want to run the chain beyond the proven stake upgrade and intend to do so then they wouldn't upgrade their software to proof-of-stake software mode and thus you might create a partition

between those that want to upgrade a proof-of-stake and those that do not prior to the merge and we might have delays in the merge because of dropping tpd i think

yes

Dankrad Feist: does this change fork id change the consensus part at all though or is it only in a networking thing

no it's not working

Dankrad Feist: right because like i mean do we actually know like because miners might not actually just use the normal peer-to-peer network even they might use specialist servers that like guarantee them faster fusion of blocks and stuff like that uh they might get that their blocks from block builders flash sports whatever so

like i'm not sure if we need to worry too much if they are still connected with him sent here to be a network like it's very easy for them to be connected to two peer-to-peer networks

i mean blocks are

Danny Ryan: they certainly insert blocks into the goth network uh and right they do at some that they don't use traditional means that would be locked out if they didn't

do

Dankrad Feist: i mean i i'm personally much more worried about people being exposed because they forget forgot to upgrade their

notes i think i would i also have with with the anchored here i think red

Micah Zoltu: i think i have a weak

preference that i'd rather find out sooner rather than later um there there's a contingent of miners that plan on continuing to run proof of work

um i

Dankrad Feist: i honestly don't think you will find that i don't think you'll get that

Micah Zoltu: sure we might not

Dankrad Feist: like i mean i as a miner my incentive is to definitely stay connected to the p2p network that's going to switch so i do that somehow even if that means running two nodes so i don't think you get that signal that people will not distribute their blocks on our peer-to-peer network anymore

which

Micah Zoltu: which would be great i'm just saying like if if danny's theory proves out i'd rather know you know a month in advance instead of a day in advance of the fork like i'd rather not see the ttd drop off you know in the last minute i'd rather see the ttd drop off you know a month ahead so that way when we set the ttd we can set it appropriate to the actual hash power that's going to stick around to the end

Danny Ryan: and this isn't necessarily my theory i mean the synthetic fork before was my idea and i i kind of like it i just that is the primary risk is that we accidentally fragment the miners off the network because they do not intend to upgrade it for sick um but i i don't know if that i wouldn't say that that's necessarily what i think is like

the outcome but i think that is the primary

Dankrad Feist: i mean if if venice if that is rifts that we see then we can also easily add a command line flag that says yes like follow this new proof of stake fork id but do not switch to proof's sake like an override flag for that and then miners can easily just do that and don't have to worry about modifying the clients and stuff for that

Danny Ryan: which is another risk in another though they make contentious work

Dankrad Feist: do we really think we can stop that fork

existing yeah like i am i doubt it so i i'm not worried about adding that i i just want it to never be the default option like the default option should always be if you just do the normal thing upgrade your client you should end up on proof of stake and you should never on that path you should never just end up on a proof of work for and everything seems to be working and you didn't notice

that's like you're off

Tim Beiko: so

[Music] it seems like we have a couple options on the table um there might be value in kind of thinking through them a bit more explicitly off the call like i don't know if we need to make a decision about this right now i i don't think we do

um does anyone

Micah Zoltu: does anyone currently have strong opinions on this or is everybody kind of meh on all the proposed solutions i know personally i'm meh on all the solutions i have my preference for just a fake empty fork block ahead of time but i'm not going to die at all

that's my weak presence

Péter Szilágyi: question what do we want to always fall for so essentially what is the problem that we're trying to solve here um because the fork id originally the idea behind the forecast was that we needed to separate and upgraded versus non-upgraded networks apart after the upgrade happened now if this is the goal we actually have an interesting other thing that we can abuse for this purpose specifically that uh as far as i understand it directly if i'm wrong after eos mode the total difficulty of the chain of conceptually remains

constant so there's no more blocks don't have a difficulty anymore right

Micah Zoltu: yes

Péter Szilágyi: okay so in that case if for existing nodes once pos happens and let's say finality also happens so that's four plus i know 15 minutes or something like that essentially after that point when i'm in fully eos mode whenever an eth handshake happens i can actually just the both sides advertise their total difficulty with one another now if somebody advertises a total difficulty that is

higher than my dtd or not sorry not the dtd rather higher than the the total difficulty of my last block the pos block from which point the whole thing is locked in then i cannot disconnect it so with this trick essentially eos aware clients can always disconnect non-upgraded clients if there's actually at least one more block mine on top of the

dtd

Mikhail Kalinin: yeah that's interesting but yeah as you have mentioned as you have pointed out that this is more important for like to force uh it as an indicator of um

as an indicator in the signal for a user that uh it just forgot to update it's fine software so i mean this fork id so it will um after the like after the client release um yeah so it's not gonna disconnect or will it will it disconnect the notes that has different fork next or just set of zero like my client is updated and somebody tries to connect to me uh the the and has the fork next set to zero but my client has the fortnite step to

correct value i i think it's permitted right

Péter Szilágyi: i think in that case you will be the one your client will be the one disconnecting if once it goes past yeah oh no wait actually if there's only the torque next it's different then clients don't disconnect because then it just means that one of them might not be up to date but as long as that work didn't happen it's fine but once that work happens on the updated side then the fourth next will be zero at that side and just the four cash will be different and that will trigger it

Mikhail Kalinin: right so uh if we want this for this kind of purpose then we should set it before transition before connects to the full transition and i think it's

reasonable if it's not like you know there is no security implications in that also i think i know what to do with respect to the stack so we can just have another constant that will say that the spec will say that next should be set to this constant and decide on the constant later on so what it will be that's the right i guess approach in terms of the stack

Micah Zoltu: regarding your suggestion second ago peter do the clients already share their their view of total difficulty like

during the hand connection handshake exact information we already have okay so we already have the messaging and everything this would just be adding a line to the client that says disconnect if uh total difficulty reported is higher than the ttd that i think should exist right

Péter Szilágyi: yes the other thing is i'm not sure that will probably not help us for a client that is just joining and maybe that's the hard part that we actually want to solve but let's see if we use the sorry i know but i still kind of feel that if we if we set a fourth block that is before eos i mean we just have work id

ten thousand locks or a week before ttb is supposed to happen and we just have a couple loads on the network that just relay blocks between the two networks so you could just somehow have a node that so essentially if i understand correctly the the thing that we're afraid of is that if there's uh during or right before the court there's a set of miners which don't want to upgrade we still want to consume their power blocks and i think we could do that by simply having some peers on the network that quote connect to both networks and just replace the blocks across them

Micah Zoltu: it sounds like a lot of engineering effort

Péter Szilágyi: i'm not sure that it's um [Music] somehow get away with it without i don't know

it's

Danny Ryan: run two nodes and use local rpcs to drop blocks between each other but you wouldn't put it into the gossip from there anyway

Péter Szilágyi: no i was actually figuring i was just wondering if i can create a note that can depending on who it connects to just can advertise different work ideas essentially just lie about the fork id and just fly itself onto both networks

Micah Zoltu: what's your fork id i don't know what's

your fork id

oh

Péter Szilágyi: yeah the handshakes are transmitted concurrently so it is perfectly fine to wait for the remote handshake before sending yours

so if some of these lying nodes connect to each other

Mikhail Kalinin: to your point uh we can use hard code ttd

to disconnect uh years so it will be hard coded and everyone will know it even if if not just starts to see

Péter Szilágyi: yeah but the problem is that you don't know what's the you you just know the tv the terminal difficulty but you don't know what the actual life total difficulty will be the final one because you know that it's going to exceed ptp but you don't know by how much and that's the problem

and uh yeah i see way man yeah again yeah right i mean i guess you know actually if you're a fresh joiner then you don't um anyway

Péter Szilágyi: uh i think we shouldn't really hold up there

if you're the first scheduler wouldn't you have the weak subjectivity points and so you would know what the ttd was or does that not kick in until later

Danny Ryan: and a fresh joiner could mean i reminded my note from a week ago and the transition happened two days ago so i still don't have information about what happened okay

Péter Szilágyi: so i guess most of this complexity is just right during the transitional right after the next few days or a few weeks because after that it's kind of probably the whole thing is going to stabilize and most of these mechanisms will get thrown out

Mikhail Kalinin: yeah

i prefer to have a full transition so that's a good indicator uh for a user too and yeah like a good fact it's one of the factors that they should update

notes not propagating them

Péter Szilágyi: the simplest solution is to just hack in this uh this lying no that can just join both networks just to translate the blocks through and then just have that running for three days until the transition happens and then you can just lift up one u.s happen it's a bit of a dirty hack but it keeps

the code cleansed the the production final code that is the same place

Tim Beiko: so i i don't is it for we've already kind of been discussing this for half an hour is it worth maybe continuing async and bringing this back up again on the next call it's not something we need to implement for kinzugi um yeah i don't know unless people have a strong opinion about something but it does feel like there's a bunch of weak opinions and there might be value in just kind of thinking through them a bit more

Péter Szilágyi: yeah i think especially here we need a

few people who just be willing to just explore their own preference and then just see how what it actually takes how messy it gets and if it works it doesn't work because we have a few ideas with every i need

some caches and yeah

Tim Beiko: yeah does anyone on the call want to volunteer to look into that in the next couple weeks

Péter Szilágyi: i can take a look at what it could take to make the malicious look that's always fun

Tim Beiko: sure um cool and

yeah i guess miguel danny and i can chat about uh the next steps for like the other approaches and um yeah see how we can kind of flesh those out a bit more

Micah Zoltu: so i think from a technical side the faux fork block should be absolutely trivial like it literally we just introduce a fork that has zero code changes in it so every client has a mechanism for introducing forks this is just me another forward just like every other it just there just happens to be no code associated with it

Tim Beiko: um cool yeah just to be mindful of time uh unless anyone has any like urgent comment about this i think you should

just move on because we have uh we have uh two more eeps we wanted to discuss okay um so next up uh ensgar and bartabay are here to give an update on eip-4396 which is the one that proposed to change how eap 1559 works uh in a post-merge context um yeah and scary barnaby do you want to give a quick update of kind of what you've looked at over the past couple weeks

Ansgar Dietrichs: um yeah i can maybe start with a summary of the breakout session from last monday uh so basically um what uh yeah splitting splitting up the the erp into

two parts like the the why might we need to do something and then what exactly to do kind of sides of things um i think the the main result from monday was that there's generally uncertainty around how urgently we need to do some things like is there something that can wait until uh shanghai or is it something we should do at the at the point of the merge um there was also some some talk on the mechanism side but then and and i kind of spent some more time since then kind of looking into the mechanisms and i i think that's that's really solid so the question is really more is is there needs to to do to do something basically and um just to recap that briefly so

um like there's one small concern in general about just like that empty slots uh have have a negative like have a distorting effect on the base fee where there's this brief base v spike usually after after missed slot but the main the main concern is about the throughput loss so every time after the merge there's a missed slot basically that the overall throughput of the network is just reduced by whatever like by the 15 million or whatever the target would be in an average block in that slot which just didn't happen um these these kind of through productions can be compensated in the medium term um through gas limit adjustments so if we see that say three percent of other datas are offline permanently we can

just increase the gas limit by three percent and then on average it smoothes out um there were concerns around specifically uh how well will we be able to adjust the gas limit after the merge so right now so of course that's that's uh the role of the block builder so right now the miners and then um after the merge the validators um it's already not trivial to coordinate miners around changes every time there's like a there's some change it takes takes a while and then of course after the merge um validities are even more decentralized so so there's more people we'd have to reach out to before before we get to 51 of people signaling a different guest limit

uh one thing that could help actually is the centralization that's probably going to be introduced by the flashbots um [Music] proposed merge architecture which by the way i think should be a topic for for one of these oco devs as well because that might introduce some general centralization concerns but in this case it acts to our advantage because it means that you basically only have to reach out to flashbots to adjust the gas limit um and then uh yeah and so basically that that's that's that all helps for medium term adjustments but the issue remains um for short-term adjustment and that's really basically the question really is like how important are these short-term

adjustments and do we have to do something about it in the merch and so again the facets there are like for one there's the concern around dos vulnerabilities and this is important this is kind of not the what we used to talk about in the dos context like say slow blocks where basically transactions kind of like take very long to compute this is the different form of course this is kind of like identifying the the real identities the ip addresses behind this individual validator and then targeting them and bringing them offline right before they they were producing the block and um there's more incentive to do that if they're um if if there is a um if that basically results in a

throughput loss to the network so you can actually attack the network through that whereas if the throughput is compensated for then of course you don't have much of an immediate incentive anymore so so that could be mitigation against these um those attacks and then also there are the other situations though say like a big staker goes offline for a couple hours uh for some maintenance a reason or something that just could be like a 10 throughput loss for a couple hours of network which is not great um or in this in the scenario of like a client bug or a consensus issue or something that they could be um they they could they basically say we have two j two forks and both have fifty percent of our

debtors then um at least until the gas limit starts moving which again could take like a day or more um but like uh the the the forks will only have half the throughput um yeah so that's uh that that was made mainly in other necessity sites so there's a lot also to report on the mechanism side but it's more like detail oriented and so i probably first want to just stop here and um get feedback on like do we need to do something and then if people generally think that we want to do something then it's probably then we can and then what's the point of it maybe we can talk a little bit about the mechanisms but yeah um so what are people people's thoughts on

like is this something that is bad enough so kind of these throughput losses and the dos incentives and everything is that something that is um bad enough uh to do something about it now and that was just basically on monday people that our conclusion was basically like yeah how to tell kind of like on the fence um mechanisms i i'm really optimistic about but yeah

yeah i see danny yeah i mean

Danny Ryan: yeah a few weeks ago i was naively optimistic that we could shove this in here uh tested quickly and there wasn't

much complexity to deal with i personally think that this would likely delay the merge on the order of a minimum of a month if not two just because of where we're at in engineering cycle and attempting to have sex frozen although i do think this is the good and arguably correct behavior i do not think it's critical to have at the merge and that personally i think if we're sorting things merge sooner is better than um getting this in but i would i would be a strong strong

advocate for putting it in shanghai there are obviously various concerns as you enumerated but i think between having the gas having the the gas limit as a lever even though a slow lever uh we can mitigate that most of those concerns there

i guess the

Tim Beiko: does anyone see an issue with potentially raising the gas limit the offset kind of the average throughput loss um

and i think like right now miss slots are like less than one percent if i if i recall correctly um so we you know we should expect them to be in that like single digit percent range so that solves kind of the general case issue the issue where it doesn't solve is if a large subset of validators goes offline for a while then we have like a throughput reduction in the chain

um yeah i

Micah Zoltu: i'm against raising the gasoline for any reason just because i think the gas limit is already too high so unrelated to this conversations i'm not a fan of any increases

right

Ansgar Dietrichs: but they are just vulnerable there because um i mean like at the end of the day because somebody's just a number right like what you're probably concerned about this is the general throughput per time and that will change

Micah Zoltu: state growth yes yeah so if i if i see an opportunity to lobby for reducing state growth i will take it and so if there's a dis an active discussion for should we increase the block should we maintain the block throughput or should we decrease the block throughput i will vote to decrease it which is just what i'm saying here again though i recognize this not related just questions asked would anyone be against it and yes i'm against it but for totally unrelated reason

Ansgar Dietrichs: okay so you're not against the instrument you're just against the

yeah

Micah Zoltu: yeah i'm looking for opportunities to lower the black panther and this is one

okay

Ansgar Dietrichs: yeah just just to point out that like they're while they're there of course i mean so so from a state growth point of view of course i don't think there should be any concerns um well except for maybe that the gas limit increase could be sticky where once people come back online maybe it's hard to bring it back down but besides that there really shouldn't be any concerns because it just keeps the state growth um rate constant um because it only compensates for people offline um on the peak kind of networking

constraint side of course that it does um um propose a bit of an added strain because um well the average remains constant like basically the peaks like instead of having one block every five seconds maybe with a couple percent offline we have like on average one vlog every 13 seconds but it's ten percent higher some bigger or something um so that's ten percent increased peak networking strain but it's important to point out that like after proof of uh in improved stake we already reduced the peak network strength quite a bit because under proof work we had these uh stochastic um block times so you could have like two three four blocks within a couple of seconds and now we have like this minimum of 12 seconds in between blocks so there's already like a big reductions in peak strain so this kind of small

added increase again when we increase the gas limit should not be concerned under that

um viewpoint either

Tim Beiko: right but it's worth noting that there's probably so if assuming you go with this like you increase the gas limit to offset the average miss slots loss um you're still in a case where like you might have an effective lower throughput if somebody goes offline in kind of an emergency fashion right like and that's kind of the case we're not solving for so if a validator goes offline for six hour you know sorry a large swath the validators go off offline for six hours um probably not enough time to coordinate raising the

gas limit uh so what happens like for the little six hours you know the network just has lower throughput and that's kind of the basically the price we pay to not by not implementing your proposal right is if there's a case where a large part of validators drop for a short enough amount of time that we can't actually coordinate to raise the gas limit that throughput is kind of lost forever

Danny Ryan: correct

Ansgar Dietrichs: correct

yeah then i

Fabio Di Fabio: um so we're moving from a system where blocks come in on average every thirteen seconds because the same real blocks

coming on average every 12 seconds so to some extent there was also a slight increase in capacity coming from that which maybe offsets the fact that some blocks might be missing

Tim Beiko: right if like less than eight percent of blocks are missing it's still a net increase

Ansgar Dietrichs: yeah um maybe just because yeah it sounds like right now we are really pointing in towards pushing this to shanghai which i'm personally absolutely okay with maybe just there's like one last attempt though um i was just wondering danny you you were saying that um you think by now we're already so so so late

in the process that it's probably going to be unavailable that this would delay the match um and i was just curious to hear like a little bit more about that because i'm just wondering i i definitely can see that for these more involved um proposals there was this extension section um but with the base mechanism it's to me it really seems like five six lines of code change in the execution clients each we of course plus a few other tests and everything so i'm just curious

dude

Danny Ryan: i think the intention right now to have a king test net up in the first week of december to

stand up through the holidays to begin to make decisions in january about very concrete and realistic timelines um i believe if you don't put a evm change into that test net and then are working on test nets in january with that change that you've very likely in practice delayed the merge because of our need to have thing on test nets even though there are a couple line changes i also and correct me i'm wrong but i just the discussion and analysis that i think

we'd probably want to throw behind this thing uh is probably still not totally done is everyone comfortable with where we're at and so i like shoving it into kenzugi it can 2p devnet in two weeks time doesn't seem likely to me

Ansgar Dietrichs: okay um if if if that's the case um then i agree that pushing nutrition is the better choice i would say

Tim Beiko: yeah does any client feel strongly that we should have this for the merge okay um

i guess i guess that's pretty clear then um so yeah i i also personally feel this is something that would be really valuable to have in shanghai and there's a lot of interesting conversations to have also about like the elasticity factor and whatnot that might that we might want to change uh for shanghai so um yeah i but i think it makes sense to just uh not include this in the merge

and when we

Ansgar Dietrichs: one last briefing though just because it came up and it's not really related to it itself but it did come up um in the discussion on monday and that's just um because we talked a little bit about the elasticity and one of the extra concerns that um martin had uh last algorithms was about

like the slow block dos attacks on the network and how that could make it worse and even if we don't do this efp now um basically of course slow block attacks in general are still a thing and one thing that did come up on monday was the fact that the impact of these kind of dos attacks would be different after the merge than they are before the merge and so it's just maybe something to keep in mind to that this could be something worth valuable to to test on test net basically just created have a test net and just really crank up the gas limit all the way until computation like the computation time of blocks kind of starts to go close to say six seconds or something so so we can see how our network would react under this kind of situation because

if not implemented ideally in execution clients the impact here could be worse in a proof of stake than it is in underproof work so just something that came up it might be relevant even without the

cfd why why would it be worse than a pretty stick so basically they just um yeah

Tim Beiko: yeah just so we have time for uh like clients and

uh your voice is the ip

Ansgar Dietrichs: right yeah so like just 15 seconds basically just because the nature is different like improve work you basically just create your block and then you start

like just trying to to find a head to to to mine on top of it ways in groups they give us fixed windows like this more specific timing considerations but like if you miss your window this you can't just do it later or something so yeah just in the difference of the nature and like if you implement the exclusion plan correctly it shouldn't be an issue but if they are like some non-ideal behaviors that can be worse but yeah we should discuss all that

Danny Ryan: right uh okay the both of them would result in many uncles uh but and maybe slightly different behavior but i'm not

convinced

Tim Beiko: cool yeah let's continue this in the merge channel

um cool

Tim Beiko: last but not least uh like client and your goes have an eip oh

and alex have an eip that bounds the historical data in execution clients uh yeah guys do you want to share give some context

George Kadianakis: yep hello there um so i will do a small summary i don't know if we have enough time to really like exhaust everything but i'll do a small summary of the proposal as it is so the high level thing is that we want to specify how clients can treat historical data like you know old blogs states receipts and that kind of stuff the obvious benefits is that there is a variety of use cases that don't use those data so we can prune a lot of uh

hard disk space with that and also execution engines don't need to keep the old evm versions around to parse those blocks so there are a bunch of benefits so that's like the high level uh thing and now in terms of specification what eip for force does is that it does two main things one is it specifies the time threshold below which you can start pruning historical data if you want so as a client and another um important thing that it does even maybe a bit controversial is that it specifies that clients must not serve

um all historical data over the p2p network and right now the proposal uh eip4s is forcing clients to not um serve such historical data because it does not want to make it optional and then have other clients rely on that optional feature and then like the quality degrade over time as more and more clients uh ditch this optional thing so that's one thing um these are the two things that the proposal does define the time threshold and specify the networking logic also this has implications in thinking so since

historical data won't be kept till infinity our clients won't be able to do full things and this kind of things and the proposal basically piggybugs on the weak subjectivity system so that clients can still um sync basically to a safe uh checkpoint uh but you know the way this should happen is out of scope for eip4s um finally um the proposals also contains a bunch more discussion on various like miscellaneous things so for example various ways that such historical data

can be retrieved or how clients can sing from genesis or how the ux should be but you know it just basically touches on them and then um it leaves it for other eips or other um topics basically um so that's it so far um we pushed the iep to wherever eips get pushed and we've gotten a bunch of feedback most of it is around the networking logic and whether we should like force clients to not serve engine data so whether that should be a must

clause or a should clause and also about the dev p2p responses that our clients should give out when they ask for such data so that's it for the eip44 summary alex or litecline you can see more or we can go into the discussion i guess does anybody immediately have questions or comments

martin had his hand up first

Martin Holst Swende: uh so this looks very much like something that peter started thinking about in and percent that i talked about in i think prague a couple of years ago

it didn't pan out eventually i mean we haven't implemented it but i'm curious peter what um since you considered this a couple years ago if you put your thoughts thought on it now in this context

if you are still here yes i am here

Péter Szilágyi: i have a little bit in the current context i know that we back we're talking about shampooing right yes so way back um one of the biggest problems was that we kind of needed a way to distribute room chains because we

kind of felt that so there wasn't um so currently in ethereum one world promise is that the chain is accessible and whether that's past headers blocks or even receipts are accessible and apps kind of rely on that and for us to just replace this guarantee with some other infrastructure we kind of needed something that is um as reliable or almost as reliable as locally having the box available available and i know that the best suggestions was that we could have some form of

infrastructure ran by major players and like yeah consensus whatever a lot of people we could have bigger bigger companies running this infrastructure and they could just serve the past historical blocks it's a bit wonky because it's outside of the protocol so it's um i we never we really were a fan of it and the reason why we kind of dropped it is because it just requires a lot of bureaucracy a lot of politics to to dream up such a system so it's not the challenge here is not really the technical aspect whether it's the whole

governance aspect of who is going to be part of it why et cetera et cetera and then essentially we just had other things to do that's why we dropped it do you think that with the reliance on weak subjectivity checkpoints for starting clients that the technical issues of not having those blocks available is alleviated

[Music]

Péter Szilágyi: the problem is not synchronization i mean we could have synchronized so we could have just released hardcoded blocks or start the cache that they didn't get

and just say that well you're going to so this whole week's objective could be because i can get a long time ago the problem is that that's rely on past state being available and ethereum users are either one promises to have that available and that means everything is built on this assumption that you can always access the transactions in block 5 or the receipts on block 5. with this merge i think that's an opportunity to go back on this promise so to say and just say that well long term for the long term half of the network we're going to change these

invariants a bit

but uh yeah

Danny Ryan: well and and it does reduce the debate like you could argue releasing checkpoints and proof of work they're like oh well that's not pure whereas in proof of stake you must have a recent piece of information to safely sync the network and so that that the the need to have all historic block headers on the network uh to be able to find the channel head does uh become reduced because of the security model shift um that's not defined at the crux of the issue

Tim Beiko: um yeah just because we're running we're basically at time andrew as you have

your hand up so we can um go over your thoughts and then wrap it up i've shared the discussion link in the chat as well for like async conversations

Andrew Ashikhmin: um right so i'd like to notice that um aragon at the moment doesn't uh have snapshot sync we rely exclusively on uh sync from genesis so this change will broke aragon we'll have to think of a workaround um and also to my mind uh like on on some general notice it's better to do this change um closer when we have a solution on state expiry without like to my mind it should

be bound to state expiry other than or or some infrastructure for state delivery or at least wait until all clients have their own system of reliable state delivery i i agree that like there was a promise in if one that all kind of historical data is is available and we cannot break this promise without having either like proper infrastructure in place or some other mechanism or maybe look like either either individual mechanism for each client or some agreed upon mechanism but to my mind it's pretty much your right to be clear we're looking at like

this happening in maybe 12 to 15 months so this is very early in the cycle

Péter Szilágyi: so just just emphasize two things one of them is this wouldn't be implemented and brought out now the only thing i can personally feel that is important to say is that common emerge we should and must if we want to ever do this whatever then we must at the merge explicitly state that the state order i'm sorry the chain segments blocks older than x years

i don't know will not be available as a photo so their full names don't guarantee this now whether we will implement this in one year two years five years or never that's a different story the idea is that we need to get people to stop relying on on the subject expecting blogs to be forever available and the reason uh just answer the other note that you said that you this whole thing should be rolled out together with state uh rent or truly or whatever i the two things are a bit separate for one the blocks currently outweigh the state four to one or three to one or something like that so they are significantly

happier but essentially what currently one one proposal protocol improvement proposal are for witnesses and status clients or varying degrees data science but all these require some witnesses that need to be retained besides the blocks and these weaknesses are significant in size so they are maybe about one order of magnitude larger than the blocks themselves so as long as there is no pruning on blocks we cannot implement witnesses because

it's just going to blow up the stuff we store on this to unimaginable proportions so essentially all the business work depends on an aggressive learning strategy

Tim Beiko: um just because we're past time there's a comment in the chat about maybe doing a breakout session next week i'm not sure if there's like urgency here like given this is something we you know might want to do in the next like uh you know year or two if we can also just discuss it on the next awkward devs and kind of pick up the conversation there um yeah so

does anyone have like a strong preference for a session next week or is like the next awkwardness fine with people

i

Péter Szilágyi: i have one strong suggestion next for my goal is fine solving the technical aspect of this issue whatever is fine there's actually no rush but i do think it is super urgent for us to decide what guarantees we want the chain to have after the merge and start trapping people accordingly

right sounds like we should discuss it next awkward that was done

Tim Beiko: yeah and i feel like this the thing is

this also kind of benefits from having a lot of different people involved in the conversation and we uh when we have these breakout rooms we tend to only get a subset of people so i my my hunch is like we should probably wait until the next awkward end so that we have kind of more people uh but also center the conversation around kind of the guarantees we want to provide and stop providing around the merge and eip4444 is like uh you know related to that but not the exact same thing does that make sense

Péter Szilágyi: yes although i would again if you bring a lot of external people i would emphasize

that this session is not whether to prune fast stuff or not prune that stuff the discussion should be centered around how we stop paying growth

how do we stop well sorry uh the unbounded girl

Tim Beiko: right yeah yeah

Péter Szilágyi: that is the goal and that essentially if you want ethereum to stay alive for the next 10 years that problem needs to be solved and just saying that while we're just kick the can down the road that won't work so we need to stop we need to start deleting stuff

Tim Beiko: right

Péter Szilágyi: we can debate what we delete but we cannot debate the need for the mission

Tim Beiko: cool ah that seems like a good place to end uh we're already a couple minutes over time so appreciate people for for staying over um yeah thanks everyone and i will see you two weeks from now

thank you goodbye have a nice weekend [Music] [Music]

so [Music] [Music] [Music]

[Applause] [Music] [Music] so

so [Music] [Music] [Music] you

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