All Core Devs - Execution #106

Transcript

[Music] [Music] [Music]

[Music] [Music] [Music] [Applause]

[Music] [Music]

[Music] [Music]

Hudson Jameson: hello everyone and welcome to

ethereum core developer meeting number 106. i'm your host hudson and today we got a pretty full agenda so we can go ahead and get started the first one is the status of yellow v3 james is out sick today so we'll have uh tim taking over that um as well as pooja for some um any support uh for some of the timing questions under berlin and then we'll talk about london uh but first let's do yellow v3 so that's gonna be um actually that won't be tim that might be tim but it might also be other people who are doing yellow v3 stuff who has an update

Rai Sur: um is synced to yellow v3 uh i still

need to look into more close detail about whether we align on the rpc but i think we

do cool sorry no the mind is in sync can you love me free at least it was sinking very fast each time i was launching it great similarly top in ethereum we are thinking on your tree i still need to check some rpc calls just to set the track okay great uh what about the death team yes um so yes it's sailing all the way through

we've had several issues but no none of them recently anyway related to actual [Music] consensus changes but rather peripheral things but we are we're still working um a bit or quite a lot on the actual pr but hope to merge it to master pretty soon um we are also married just doing work so fasting transactions and sending them to yolo v3 uh which was one of the courses where we found another issue with the sealer and yeah we'll continue doing that

but it looks kind of good so far and yeah so we he's been passing it with the 2930 type transactions and also check in the um some of the other ifs that are included the subroutines and maybe mod expand and show away at least looking good so far

Hudson Jameson: okay great anybody else have any yellow v3 commentary before we move on to berlin timing

so the f1 0 spec is updated for yellow v3 it is updated with every client's uh recent update except for another mind no it's thinking for basil and open

ethereum as mentioned today we do not have update from ethereum js and trinity all fine and it's all merged yeah and i'm i'm not sure if as far as i understood it trinity do not really consider themselves to be a 1.0 client i think they've kind of given up on that and i might as i'm sure they might use components of it in research and things but they are not trying to be a follow-the-head mainnet client oh got it okay i'm okay

Hudson Jameson: yeah and then i can get you in touch

with ethereum js if needed uh we can see what they're doing but i think they do want to be a 1.0 client i don't know where they're at with um uh if they're going to be a part of yellow v3 or not though

all right yeah

Martin Holst Swende: i might add some other details so there is uh there are some tests for 29.30 that are in the standard test repo and i ran them today i found some problems with them uh so i must i can i'm kind of guessing that none of the other clients have checked it out um [Music] please do that the the there's a pr on the test repo which contains a 2930 test and

these will require some change in the clients because so obviously they have access list in the transactions so yeah they'll need some coding so please check them out and see if you run into the same problems that i did

yeah that's it okay thanks so much martin thanks puja

Hudson Jameson: um next up on the agenda we have berlin timing uh we have the um pm repo switched up now um and it if you go to the read me there's drop downs for the agendas and then if you want to add something to an agenda for

a specific meeting you make an issue so the issues from the readme or their i guess there are agenda items in the readme that are then linked to issues where you can have further discussion instead of one agenda issue where there's a lot of mixed match discussion um so this is another way to kind of improve asynchronous communications um so thanks um i think tim and puja and james did this right or was it just tim and pooja

team tim okay thanks tim this is

Hudson Jameson: this is working really well i'm seeing a lot of good conversation in these issues and i'll pass it over to you to talk about berlin timing and if you click on issue number 248 there's

uh some charts and discussion in there

sure uh yeah thanks hudson um i just shared the issue in the chat here for for people who want to pull it up um both i guess on that issue and in the all corners shot there was a ton of conversation about you know what blocks do we want for the different networks for berlin um on the last call we'd said february 24th that's obviously five days from now and you know that's not gonna happen um uh so you know i think there was uh there was a proposal like afri had a couple proposals first um there was some concerns that there was enough uh time from like yellow v2 being

up and running uh before the first fork um and so that led to like a third proposal but turns out we have euro v3 up and running um already so i put a fourth proposal today um that would be a a bit that would get us on mainnet a bit sooner um so i don't i put it in so i guess it's kind of my preferred approach and i'm curious what other people think about it here but basically this is like the last comment on the agenda uh sorry on the issue uh where um we fork robsten then gordy then rinkeby have them all be a week apart so if anything goes wrong on either of them uh you can just you know release a a new version

that disables burden um in order to have kind of a decent delay between like agreeing on the date and you know all the clients putting together a release and communicating that and whatnot uh the first test net would happen march 10th which i think is is uh three either three four weeks from now basically um so it's four weeks from uh wednesday two days ago um and then every week you kind of fork another test nets on the march 10th before crops then uh march 17th before gordy and then march 24th rinkaby uh open ethereum said that they're gonna handle coven on their own probably post berlin um and then main net we would have happen

kind of three weeks after the last test nets or six weeks after the first one uh so that would be mid-april um and one thing that's worth noting also there's another issue that we can cover in more detail later about london uh so because the difficulty bomb will be going off sometime in july um we probably want to have you know more than like a month or two between the two main net hard forks um so this like last scenario scenario b gives us uh basically three months uh between main nets on the two networks uh there might be a bit less delay between the test nets themselves um but yeah so at least the main net upgrade would have like a three-month delay between

uh berlin and london um and i guess that the main blocker is knowing you know the clients think it's realistic to fork the first network in in about three weeks so to that means if we want to communicate it properly we probably need like a release out in the next week or so from all of the client teams which has the block numbers um because then we can put a blog post together link the releases and whatnot yes we have

Hudson Jameson: comments on that as far as the clients think of the dates or whether they think um having roughly you said how long would they have to put a release out

like a week

Tim Beiko: so the the the first test net would fork in three weeks right so it depends you know what's the delay people are comfortable between how you know between putting out a release and having the fork happen i suspect about two weeks is probably what we want at a minimum uh so that you know people can upgrade and you know hear about it and whatnot um yeah so that means if we if we have three weeks total it's basically one week to you know ship the new version and then two weeks to just communicate it

yeah i think so the first one is roxanne and obviously i think no matter what we do it's going

to get screwy on robson because someone just leaves you know their computer mining and it keeps going and then we have two chains and it's just it's going to be messy no matter what uh however for the click networks it's kind of like if the sealer switches then the the clients who haven't upgraded they will just buy um so that's going to be nicer but it's good that there is some more time for people to get notified about this so they can also update so are you saying you would fork uh

your ring be first okay i'm just saying that i think it's gonna be messy on robson no matter what yeah and also robson will have like the most unpredictable block times right whereas the two other ones should be pretty yeah pretty easy to predict one thing that i think we could do better on roxanne than we did beforehand so in the previous i'm not entirely rich forks but on quite a few forks it happened that we shipped the fork and then turned out that no miner was actually started on the fourth block and then there was somebody mining on the on the old block and then things got really really screwy so one thing that i think would help

would be if every client could just start up a small node small mining node i'm not talking about starting up a gpu anything a small cpu node to just the point would be to have multiple clients crunching on the hopefully correct chain and if out of the four clients somebody implemented something incorrectly then at least let's not have that one mind the change so that's kind of a personal request that each team please have some small miner running somewhere for a few days after the fork drops

Tim Beiko: we can definitely do that

tape wise i i don't mind these states

Tim Beiko: to be clear this is like the the last proposal right like so the first fork scheduled for the 10th of march

Martin Holst Swende: yes

Tim Beiko: does anyone have an issue with these dates

sorry if i i missed it um why robson first instead of uh wrinklebee i think

Tim Beiko: it was because it was the

more the most messy um yeah okay so get the messy out of the way first yeah and also yeah isn't it also like girl is closer to

production i mean people run more actual almost production things than garlic and robson is more like it's a chaotic testament yeah and the problem with drinkability is that it's a more or less a guest only tesla so other clients can sing but as far as i know all signers are get only which means that rinkaby is not really suited to find consensus issues okay

Micah Zoltu: uh should we keep it in the schedule like that

then if it's not gonna help us or can we just remove that line and just go really of mainland like do we gain anything from me cleaner could be in that list and having it have its own week or two by itself

Péter Szilágyi: well no the point

really is that if anything goes wrong then you want to minimize the damage and on drops so if girly and drinkaby are more productiony than uh if you fork girly wrinkly and robson at the same time and something goes wrong then you just messed up three networks whereas if you mess up props and then at least you minimized it to one network

out of three another yeah

Tim Beiko: another reason is in previous forks i think we've wanted to have i think like somewhere you know four to six weeks on test nets um you know and and so even if we remove wrinkabee from a week you know like if if we don't have it fork one week later for example

i'm not sure we'd want to pull main net one week earlier um we we might but like yeah historically we've wanted to have you know like four to six weeks of test that's before mainnet goes live

um these also like reasonable arguments to me

Péter Szilágyi: one question this is more like a rollout question let's suppose that we pick these and we go with these numbers the question is should clients release i mean if we put out a release next week should we hard code all the block numbers straight including mainnet or should we only hard code the test and block numbers and let's wait two more weeks

with mainnet before just telling everybody to

run with it this kind of a logistic question from from a

Tim Beiko: just like communicating to the community point of view i think having them all in one fork or in one release is better because you don't run the risk of people who like think they've upgraded to berlin uh but they've just upgraded to the burden test nets um although you know for the like call them professionals you know like folks like infer ether scan and you know exchanges i suspect they can handle that nuance um but i guess from just general communications it makes it easier to say like

this is the this is the release for each client would burn in um that's not like yeah if there's a stronger reason to not have them all in the same release i think that's fine as well

yeah

Hudson Jameson: we were going to have it at two separate releases then we can just as easily if something goes wrong have that second release be some kind of well we're delaying things um you know we're doing it we're taking out the block number we're doing a different block number etc we can do that just as easily as for some reason having two separate ones just to be safe and not have mainnet number on there yet

Péter Szilágyi: okay

i think my side i'm just having two releases for

the safe for the safety reasons nothing more i see that for logistics it is easier to say this release just download use it and you're okay but for being safe if something something happens on the test net i wouldn't like to have blocks for the minute there yeah but it is for the clients to decide to be perfectly honest i guess yeah

Tim Beiko: we don't have we don't need actually it might be the worst option if clients do stuff differently even though there's no there's no uh you know rule that forces us all to agree but yeah i think that will be the most confusing for the community to say

you're good with open ethereum you're bad with basu you're good with

geth and you're bad with nethermine um yeah that would be pretty bad but i i think whether it's worth the risk or not probably comes down to what we think the probability of needing another client release before maintenance if everybody thinks that yeah you know there's a 99 chance we'll be able to go to mainnet with this updated client then it seems like an obvious win for just uh include the hard fork number if we think there's like a one percent chance that these clients are going to be the ones that actually work with maintenance then i think you should definitely prefer the opposite so i don't know what people how do people feel about their confidence

Martin Holst Swende: one

thing that we've done historically in gas is to have a always added command line switch so the block can actually be moved or just disabled by a command line so if we put out a client with a specific port number um then the miners or people who run large infrastructure they don't have to pull a last minute new update just because the poor got pushed a week or something they can just postpone it a bit with command line parameters and don't have to you know redo the entire devops infrastructure setup so that's i think a pretty good thing to

have in place

Dragan Rakita: then most of the clients are okay can we stop only one release

Hudson Jameson: sounds like that's what it's coming to do we have any other client issues with having one release with all the block numbers

i'll find from our perspective and basically yeah we i've been pushing for it so oh that's true i guess we can do that and i saw yeah afri you proposed uh block numbers for the test nets um so i guess we can just you know i don't maybe just discuss them uh on

the on the chat or i don't know if people wanna yeah we probably want to have people review them before we make them official but yeah use those as tentative and then uh if there's no issues on the chat we can we can take those yeah

Hudson Jameson: let's try to decide today though i think so people can start prepping the release

for people who do sure um so the block numbers yeah maybe just for people listening the block numbers uh that afri proposed on robston there's it's uh nine million eight hundred twelve thousand one eighty nine and gordy would be 4 million for 160 000 644 and on ring b would be eight million two hundred and ninety thousand nine twenty eight um these all match up with the dates

from the table above um and yeah i think we can go with those just probably want to have somebody else double check that they make sense [Music] yeah am i missing something missing maintenance missing yes we need a block number for maintenance

Hudson Jameson: that one is harder to come up with because of variable block times i'm guessing is that right after or is there a reason maintenance off there

i'm just doing it in parallel and i just didn't have a number for mana did i can do it right away oh it takes one minute he posted this three minutes ago okay cool all right so maybe at

Hudson Jameson: the end

of the call we can bring this up one more time and just agree on it pending someone checking the math and then by the end of the day have a up or down on chat so that could be helpful all right let's go ahead and do that any other final things on berlin before we move on to london uh discussion okay so yeah end of the call we'll have the numbers we'll go over them one more time we'll have someone check them and chat and then we'll approve it in chat today next up is london timing uh that's issue number 245.

um and uh tim added that one the agenda so go ahead tim

yeah so this one will be quicker it was just so people are aware uh so

Tim Beiko: because the difficulty bomb is going to hit sometime in july and in practice it might hit a bit later because the hash rate has grown but you know i i don't think we want to make that into her her basic assumptions uh but yeah the difficulty bomb goes live on mainland around july so that means we probably want london to go live on main net around july with an eip to push back the difficulty bomb there's already one written uh eip3238 and ideally we probably want more than just a sort of mere glacier part two fork for london um so that means if we want to actually

choose test you know eats and and have a proper rollout uh we need the test nets to happen sometimes in late may early june so that means that you know in early may and whatnot we need to have the blocks chosen for those test nets uh and and most of the testing done basically the equivalent

of where we are today with uh berlin um and so that means you know we assume that april will probably be mostly testing and debugging ephemeral test nets like we've done the past month or two for for berlin um and that brings us to march uh to basically select the eeps and start testing stuff um and so there is uh no canonical list of eeps for london yet um and we're already kind of late

february so i suspect this means that in the next call or two uh not today we kind of need to come to a decision about which eeps we want to see in london um so it's kind of all i had i just wanted to you know put that out there because when you july seems far away uh but then when you kind of go backwards from there it means like the next two calls is when we need to decide what goes in um yeah and

Hudson Jameson: unless there's something catastrophic with berlin that we would need to figure out during a call which a lot of that would be a sink anyway then we can focus on the merge and um and london eips the next two meetings would be the idea

right tim

yeah exactly like i think we'll probably need like i know i i think it would make sense for either next call to like be focused on eeps for berlin uh and at the very least choosing what are the big things that go in um so you know i've kind of bias here but i've been working on 1559 that's a big one but i know there's other big projects that are kind of ready um i suspect because of this short timeline we won't be able to do like you know multiple big eips but i feel like if at the next call we can choose you know what are like the the big things we want to see in and then you know we can probably add some smaller simple eips also uh after that um but just for

clients to have an idea of what what the scope is um yeah so go ahead we we don't need to rush any heaps into london we can just have it about uh the difficulty bomb and then um take more time to evaluate eeps later on why do we need to rush it for july

Tim Beiko: so i guess that's what i'm saying is if we want anything more than the difficulty bomb for july then we need to make the decision about that in the next one or two calls yeah it would be but sure so if we don't want anything aside from the difficulty bomb that's fine but we can't like i guess start in may and be like oh

we want this eep in because there just won't be enough time to test it properly

right and there might be some quick winning ips that we're not really thinking of or that people have been working on that we can like decide in a meeting or two as like really good good calls

Vitalik Buterin: um it's worth mentioning that i think the safe margin for the next fork might also be a little bit after july um basically the uh hash rate like went up by about a factor of two since uh the la the last time i think those calculations are done because of the price rises

and um every hash rate doubling buys us about two and a half weeks yeah so yeah july would be kind of

Tim Beiko: the worst case scenario yeah um but i guess it doesn't change that

much so it's like maybe instead of the next two calls we need like we have the next three or four calls to decide um yeah so it still has to happen

kind of pretty quite soon yeah so just for quick reference like uh like when we were deciding about berlin and before that istanbul and all so we had some eaves which were in like almost ready condition but they were not considered because of one or the other factor they are listed here in the at one dot or spec repo uh in the project bought it but uh what we are looking for is like clarity we have we have two eaves going for sure that 1559 and difficulty bomb as you mentioned but there are few lists of

eips that have already proposed that they want to be considered for uh the upcoming hard phone so what we are trying to get here is like client making decisions on the list of the eips which are listed there if they would like to like move it to the next section and consider it so where should be the one place where we have a list of proposed eips from whoever um should that be an issue in the pm repo like a new issue maybe uh no that is there in the ith1.org repo i just have shared the link of the project board but i'm going to share the link of the issue where people are submitting their uh eeips to be considered for the next upgrade and we have quite fair list of eip just

like eip29382681 uh the two five eight four convert to binary try two nine two six chunk based code marketalization so what we need to analyze here is like how ready these eips are they already listed that they want to be considered for the upcoming upgrade but the readiness status and if the readiness status matches with them to go with london upgrade okay so some of them though i would say say considered for inclusion in a future hard fork but it doesn't give like 2926 chunk based code mercallization from piper doesn't give an indication of how finished it is just that it wants to be included in a future hard fork potentially

um so that's why i was saying we might need something that's more london specific because otherwise we might be considering eips without the author here to tell us if it's done or not so maybe one thing

Tim Beiko: we can do is yeah if people want their eip to be considered for london to open an issue and we can add it to the next agenda or the one after that um and have like i don't know maybe the next two calls kind of focused on not necessarily the entire call but have part of the call over the next two calls focused on potential vips for london

yeah

Pooja Ranjan: i may have a fair list of that i'll be happy to share that in the next call to uh bring you further further discussion

Hudson Jameson: wonderful if you do have a list of that and you make that list somewhere where

other people can add to it or comment on it um just post that in the all core devs chat uh and then we can kind of start to ask around to the eip authors um if their eip is ready and should be included on that list or not

yeah

Hudson Jameson: thanks a lot puja for that um any other comments on london timing or uh getting eips decided on in the next month or so

Lightclient: is it completely out of the question to try and put it and push the difficulty bomb out another two to three months in berlin that way we're not forking on top of ourselves

Hudson Jameson: probably at this point too late

but i mean not impossible that's what my guess would be client devs

Péter Szilágyi: let's not go there so the thing is if you want to push out difficulty bomb somebody needs to do some rough calculation which is more or less meaningful then somebody else needs to check that calculation ideally there would somebody needs to write up a test just to make sure all clients behave the same way and we're already and it needs to be deployed on rockstar within three weeks so so if there would be an already done pre-calculation everything eip and we would just tell everybody hey include this eip these three lines of

text in your code that could probably work but if we start thinking about it now then it probably won't nobody will trim it up sooner than at the end of next week and that's in my opinion a bit late

Hudson Jameson: i think we can start on a fast this is a good opportunity for us to start on a faster cadence for hard forks as well just kind of dip our toe in the water with trying to do one within a three month or three and a half month period to try to get more out during the year instead of once a year and if we find out that that's a bad idea we can change it

too

Tim Beiko: to be clear also we're not doing the hard fork in three months right like we're doing a hard fork in like

five six months and they'll just end up hitting mainnet three months apart right

got it

Hudson Jameson: yeah that's what i meant

sorry all right just for record uh there is an eip for difficulty bomb that we could use for any of the hard forks it's 32 38. okay thanks oh

Hudson Jameson: that's just for um difficulty bomb delay in general and we would just tweak it with whatever numbers are effectively what we're using is that what you're saying

uh the number doesn't really matter when we activate it because it just calculates a fake block number right oh yeah that's right okay

uh yeah it sounds good anybody else have comments all right thanks everyone um the fourth item on the agenda is the eth one to eat two merge requirements overview um we have uh danny mcmahon and uh guillaume here

Hudson Jameson: as well as um vitalik and other people from the eth2 team who uh can kind of give us some um information on the merge and you know what i'll let danny kind of talk about the purpose of this portion of the agenda and then um have you all go through it

Danny Ryan: yeah i'll give a little bit of context and then turn it over to probably mikhail and others

i just shared the link to the issue and i just shared another link to uh the recent online workshop a few weeks ago in which uh mikhail and guillaume presented on their work from the past like six plus months um up until this point there's been more of like a smaller working group working on um what does east one look like in the context of the beacon chain consensus essentially swapping the proofwork consensus for that of the proof-of-stake beacon chain consensus that has been bootstrapped and is in production today um and from a specification standpoint it's a essentially moving the cradle of

removing the cradle for work and adding the cradle of proof of mistake and kind of keeping the guts of the application layer the same there are a number of minor changes that have to be addressed for example what is the difficulty in this new context how do block routes work and things like that and opcodes like that but things largely can remain stable that's from a specification standpoint from a software standpoint really what has been created over the past couple of years in an e2 client is really a sophisticated proof of stake consensus mechanism and that can be coupled in a software layer and has been demoed with teku and geth with utilizing ethylene client as kind of the application layer

so in addition to the actual consensus specs there are these there's this e182 communication protocol spec which allows an each one client the application layer to be driven by a to client kind of that consensus layer that is an opinionated way to build a merge client you can also build a merge client without that and so specs likely will not kind of reference that that implementation detail but because we do have many e1 clients application layer clients and we have many e2 clients likely this kind of modular approach is a really fruitful way to go there are many things to think through especially once you get to the edges like what does state sync look like and

how do these pieces all plug together but now is definitely the time to turn this working group more open uh discuss some things on all core devs maybe set up a monthly call from here um to dig in and and refine specs and and and go to help test them so you can build out you can run chestnut today i think uh a different chain is actually utilizing the the tecu plus guess merge client today for production test nets and is claiming they're going to go to mainnet with it soon so that's kind of cool maybe somebody will do it before us we can learn from them um yeah so that's that's that's kind of high level context um there is a merge room in the east r d discord uh we might end up

making a sub category and have some sub channels now this conversation i think will happen more and yeah that's it i'll turn it over to mikhail and guillaume who will go through some of the more technical things here um and and there's some draft specs this is like in a hack md document but on the e2 side of the specifications that's going to go into the spec repo very soon and begin to have some tests in place there's also a kind of side conversation that needs to happen i'd love to talk to some of the eip editors about how the unification of these specs might look

obviously we have kind of the proof of stake consensus components and the z2 specs repo we have the eth1 application layer specs like scattered about eips and in the yellow paper we kind of need to think about how the marriage of these specifications looks in the in the coming weeks

a month hey kyle

Mikhail Kalinin: um so thanks for the introduction danny um uh just a question do we want to go like into discussion into details um how how much time do you have now

oh for the call

Hudson Jameson: um i would say let me look real quick at what time we have left

um you know how much how much time uh do we want for removing evm features who put that on there

Vitalik Buterin: um i put it on there again i'm like i i i definitely don't want to

like literally take up half the call or anything close to that like this it's just 15 10 15 minutes be okay yeah yeah totally okay yeah so let's do go ahead and um go till 15 or 20

Hudson Jameson: past the hour how about that uh merge people

thanks plenty of plenty of time and thanks okay so yeah then you just describe like

Mikhail Kalinin: almost everything but if we go a bit deeper into details so um for the ethereum clients

uh that we have them now uh we'll have some uh a lot of like user um stuff like json rpc will remain the same it's going to be adjusted by including the finality and probably some of the methods of the json rpc will have to be adjusted due to consensus but most of them will stay the same and it means that the uh that developers and user infrastructure build around it will also mostly stay the same uh the evm uh will it is gonna be featured with new

codes that will allow for applications to read the beacon state to read the new consensus one of the use cases is to implement the withdrawals from the the validator withdrawals to the ethereum accounts so and yeah also the uh how do we do uh according to the most recent proposal uh the beacon block will contain the application payload which will which consists of uh the user transaction state route and receive three routes and yeah it means that the

part of the network in stack that is responsible for the block sync is going to be deprecated um and also uh consensus swap means that the it hash and other verifications that are related to it will all are also going to be deprecated and that might be um some kind of big change in terms of inner structures of uh the current ethereum clients um so but yeah probably guillaume can give more details on that a couple of things more here to mention is that we have like a few breaking changes the change that might break the current

applications um like one of them is the is around the block hash um the problem here is that the block hash is like used as the source of randomness on one hand and on the other hand it's probably also used by applications to verify block headers so removing the proof of work means that the source of randomness is going to be broken it's just the that the block without the proof of work bits will become pretty malleable and

it could be easily manipulated to rear all the dice and yep could be just exploited by block producers the other thing that is going to be broken is the is what peter mentioned during the workshop is the guarantee of uh full notes or in the whole history of the blocks in the network um it doesn't mean that nobody will store the history anymore the full history but it just means that the history is not necessarily needed for the consensus purposes and it could be not stored by

consensus nodes

so um yeah yeah it's probably worth saying that like that is a

Danny Ryan: a nice thing that falls out of um some of the things with finality week creativity and stuff and so like the user experience of being able to prune is available obviously uh from like a strong defaults from even like sampling nodes and kind of rejecting peers that don't have the full history you could still induce that as as a load requirement but it's definitely something that we should examine um here because it's an opportunity to potentially change the load requirement

so i just i will uh with interrupt so there's

Péter Szilágyi: i think there's a very very important question that we need to decide here and this kind of drives the whole discussion a bit forward in that the current model that catalyst and tekku does is that essentially the eastern client feeds the block to the eth1 client that kind of means that the all the block uh synchronization and propagation is delegated to the eth2 network this means that if we go down this path then we as ethon clients will not be able to for example retrieve history if the user wants it so our hands are tied we can only do what the eth2 client permits us to do and that i'm from

from a short perspective if we were to launch a new shot i think that is a completely acceptable thing to say that uh blocks are pruned after finality but from an eastward east burst perspective it's a bit of uh i think that one needs some serious thought because that would mean that we would lose the history and i'm not sure we can afford to do that just out of the box so that's a bit of a steep change and the reason i'm saying it's important to re to figure this one out because if two clients will be i won't call them stateless but they will very as far as i understand they want to very very heavily prune the chain so that they don't want to maintain chain and in that case

if we want eth1 clients or the merch chart to still be able to synchronize the chain then we probably need eth1 clients to retain the chain and be able to swap it between each other which means we cannot just delegate our block synchronization to e2 so that's a big design question

Danny Ryan: i i agree there's a lot of like moving parts and things to decide around there and one thing to note though i mean at least there is there are a number of kind of expected changes at this point emerge um and so you could potentially change certain guarantees uh it's potentially a

good point to consider whether some of the guarantees can be changed for example being able to sink from genesis on maynet i think i would argue that it's very very very unlikely that blocks would be lost they might be lost in the context of the pdp network uh but i i don't suspect that blocks would be lost forever um but you wouldn't be able to necessarily get them on the van but yeah i i agree the the there's certainly a lot to think through on some of these more uh nuance points

well i guess my

Péter Szilágyi: my point really is just that if you want so our goal with the merge is to make sure that the ether network continues to live

beneath too and there is no there won't be funky e2 classic whatever forks and then essentially you don't want to break too many invariants until too many existing user experience things so that's one thing that's why i'm saying that for if we launch new shards with evm i think it's completely fine to break everything for eth one shard that's a big question mark and another thing from a technical perspective that i do want to emphasize is that eth1 clients put a ton of work into this whole block synchronization and i don't want to to belittle these two clients but they haven't really been battle tested yet so

uh if we were to just drop a 300 gig chain on an easter client i don't know how well they will perform so that's let's try not to delete too much stuff before we prove that the alternative is

viable yeah i understood i have

Danny Ryan: a question about the effect of user experiences being able to sync the chain from genesis rather than starting somewhere in the middle and getting a state via some sort of state sync is that uh is the primary user experience reconstructing an archive node what are the what are the other ux considerations there

my personal thing that i think people don't is

just access past transactions fast logs past receipts so it's not necessarily about re-running the transactions simply about having the transactions available i have one question or about clarity peter said that every block from it from ethereum 2 is going to be fed to attain one client but is that all the blocks or just newly created block that's created for that particular client question is more how it how that new block is going to be distributed to the rest of eternal clients right

Danny Ryan: um so in the current designs post merge

the eth1 application payload is embedded in in the beacon block the beacon block is like the primary consensus object in um these two and so in that beacon block there's application layer stuff which is the user transactions and some other data as well as consensus layer things which are primarily attestations and other validator messages um from the perspective of east 2 the east 2 is kind of like building this chain and building this this core consensus beacon beacon state and the idea here is that uh the e2 client already manages this like beacon block subnetwork uh where

gotham network where these things are being passed around when i received a new block part of that block has an application layer payload needs one payload and i use the adjunct e1 software next to me to verify that component and then the ec client also verifies the like outer consensus components that so from the perspective of each one of that context the like adjunct proof of stake client is is the driver kind of like how the the the small like the proof-of-work module is kind of the driver of an e1 client today or the clique module and instead this would be like the eth2 module which is an adjunct piece of software um does

that answer your question you

have any follow-up on that yeah that means that block distribution is done in it ethereum to climb correct in this design okay okay and

Danny Ryan: that would be obviously post merge so like the prior to the merge you don't really have this like outer container that's driving things but

post america yeah it could be somewhere in the museum right

Danny Ryan: and if you look at that that e182 communication protocol um it's unidirectional currently uh because kind of like the e2 is like the brain of the the driver the consensus yeah um and it makes requests to to the e1 client

similarly like when constructing a block there's a a request like give me the application layer payload

and this is similar to like get work instead of returning a hash actually returns the transactions and things yes makes sense thank you okay um and

Hudson Jameson: so uh continuing on was that the end of it or was there more commentary

well

Danny Ryan: we got to that juicy item at the end the guarantee of storing entire block history

i mean

Vitalik Buterin: is there anything to talk about in terms of like the process for actually doing merge like

how the transition works

Danny Ryan: well for one it's probably the most likely point in ethereum's history for a

proof of work attack so this is true security is important what is

Micah Zoltu: what is the attack vector let's let's say all the miners decide they want to prevent proof work or ruin our day what's the worst they can do

realistically they would just say they would want to try to break consensus on which state route gets said to be agreed on as the genesis state root of uh kind of one as um as a subsystem of used to um right so everybody would

so you could everybody just like reminding the last block like just keep reminding a new head over and over and over again pretty much yeah they just keep on making as many chains as possible like at the flag height

Danny Ryan: it depends on yeah depends on the choice mechanism like if you had uh proof of stake transition happens at a certain uh proof-of-work block height then one attack would be all miners turn off all their nodes you never get to that height that's not like a great attack it's probably also not a very realistic attack but if you have the choice being on the proof of work block and you've given a little bit more power to the miners whereas if you you know if it's instead on a slot time and a slot height

then the trigger happens

but you still need to have consensus on what the latest head is yeah again my like i'm definitely kind of moving toward the position that the choice should just be on the proof of stake side like we should just modify each two data voting so that you can also vote on a flag and like as soon as 512 of the 10 24 miners vote on the same state route with a flag that says let's do it then you do it um the nice thing about yeah well i was gonna say one thing that you also get here i mean even if you don't have a pre-vote once the slot height is triggered and you have uh the the the state route embedded in in the uh or some sort of previous pointer embedded in the

state block you're getting votes via attestation at that point um so you do get a kind of a voting mechanism native once you move over uh and there can be certain rules that allow you know what is what is the correct state route there but uh actually the question so [Music] i was gonna ask so if the 2.0 change selects where to pick up the 1.0 state route then that in place doesn't that mean that the 1.0 chain is oblivious and continues indefinitely and we have suddenly in support ethereum from a i mean from a perspective of like

the the east to east one like merge software running together um it would be a essentially a time well there would be a trigger at which point the eth1 client was listening to the proof of work and next point is listening to this proof of stake rpc um and so that could be a block height trigger that could be a uh a slot trigger that could be some more more sort of sophisticated voting trigger but at that point the at the the combo software would then be listening to the the e2 driver that if you weren't running the combo software and you continue to listen to proof of work then absolutely you'd have two chains no different than any other any other

hard fork though right right right except like in this case there's literally no incentive for miners not to continue at least for a while yeah that's fine yeah but i think there weren't the ideas at least to maybe incentivize like the mining of off base like an

Ansgar Dietrichs: empty dummy chain for like at least a couple days after the merge just to exactly prevent this

Vitalik Buterin: yeah um i mean that's definitely a reasonable idea

Tim Beiko: but then i said the cost of downtime right

so either no it would come it would come at the cost of just like someone providing those rewards right so the idea would be that like

after the flag height we would just uh like the simplest way to do it is to just have some organization like say we're gonna give um you know two e for blocked uh miners who make um the uh a thousand or a couple of thousand of um empty blocks on like after the flag hide and then like from a application and usage point of view no one would care about those blocks like that would just be there as a kind of tail of the chain there's

Danny Ryan: a lot of options here

Hudson Jameson: interesting okay and are these enumerated um and the documents that are listed in the uh issue that you linked in the chat

or

Danny Ryan: not entirely i think

they're probably pretty light on that actual point of the merge yeah and there's a lot of ideas floating around so we need to kind of get that in one place i think one thing that tim and i want to do after this call is enumerate all the things that need to be done one thing that we haven't talked about is convincing ourselves and convincing others that uh the beacon chain is a safe home for ethereum for the application there and and so there's a number of different things you probably want to do with respect to

benchmarking testing um many many many things so there's that's that'll be part of like the list enumeration right

Vitalik Buterin: i think the general ideas that we're focusing on

making sure we have the post-merge behaviors backed out as a somewhat higher priority than specifying the merge process and there's a couple of reasons for this one is that it would actually provide more opportunity to test what happens after another is just to give ourselves the opportunity to do a yeah a fast emergency merge if we have to and just give us the capability to do that as quickly as possible

Danny Ryan: right so accompanied with any version of the specs i think we want to have like an emergency version which would be stripped down certain features for example like you could remove uh validator withdrawals from the beacon chain back in the application layer um

in the event of

emergency emerge so you don't have to deal with that extra consensus logic and other things right like the emergency marriage would just say there is a slot and like the spec would contain a salad and a state route um and everyone would just agree that that's what you would import that you want state with that state where to keep going from there um i saw greg emergency yeah right yeah yeah i mean censoring it's minor attacks right

Danny Ryan: there's really no recourse from a 51 attack on proof of work other than changing the proof of work algorithm or

moving to proof of stake and then greg said um what constitutes an emergency and uh do we have a that was the answer that was the answer oh okay

i thought that might have been further that's fine yeah that sounds good um okay maybe to just mention uh briefly and i i i think i agree with vitalik that like the kind of specking out that the actual like the the end state the the gold state is more important than speaking out the the merge process but like just to briefly mention that like one one um open question as well is just to how can we kind of make execution around the point of the merge as smooth as possible right ideally we don't want to have like like a chain halt even even like a short one and i think that their ways kind of around this but but it's like one of these things that just ideally we want like from the user perspective to to have the whole transition process not even be

noticeable of course and let's see if we can if we can get there okay um we tell you muted in case you're talking

Vitalik Buterin: i'm sorry i was just saying there's definitely ways to make a merge that has a very short or close to zero downtime

micah did you have a comment uh yeah i was wondering

Micah Zoltu: so we did this um phase zero are there any other changes that we could make to partially introduce without going all the way to phase 1.5 is there any intermediate step between where right now and 1.5 that we could do

um i mean one plus

Vitalik Buterin: one step that could be taken of course is to

modify each one client so that they watch the e1 voting in the approved state chain as a kind of canonical marker of like what is a finalized one block and like that's what just basically reduce kind of 51 minor attack risk quite a bit though i don't think it would reduce the kind of complexity of the merge process

by too much right

Danny Ryan: yeah so i mean if you do that you end up with something that looks like eip1011 um which was the hybrid proofwork proof of stake where you have a proof of stake mechanism that is finalizing a proof-of-work block proposal mechanism um and funny that the the next so just in terms of

like history and context the um that would have taken eth one blocks and added an additional uh like validator proof-of-stake payload um what has happened instead is there's now a proof of stake block and there will be added an application layer payload needs one payload um the ultimate result is very similar

uh than the past with a different a different path to get there yeah

Danny Ryan: i was just thinking in terms of how can we reduce reduce risk and make people more confident before we do the big merge like the more things we can do in small steps the lower the risk

so i

Vitalik Buterin: agree i mean i think like one big risk lower is just getting the post merge spec

um working and i'm probably just i'm just running it on test that's a couple of times

yeah yeah but i i i i i figuring out all the things we can do to de-risk is important in the next month so we can do them and just i guess back to like

Tim Beiko: the previous conversation about london is there anything you suspect that we need to include in london um related to the merge

um the bls is is a nice thing to expose in the application there

i think it's it's bls is used like very natively in this proof of stake mechanism um there are very robust implementations um but ultimately it does not affect the utilization of the beacon chain for the consensus you know bls is there it's used heavily and you can slot in things inside the beacon chain to come to consensus on so the e1 application layer so that it's not requisite it's very nice to have though

Mikhail Kalinin: um one of the ideas was also to use the difficulty bomb for the point of merge

so right so timing a yeah time

Danny Ryan: timing the extension of difficulty bomb

on our estimate on when the merge is is uh valuable to consider

the bomb will finally be used for what it was intended for

Tim Beiko: i think uh and after you might correct me here i think africa's eep times it for summer 2022 so basically 18 months from now roughly

but i do feel like because because it's important to manage expectations we shouldn't kind of we could be like i think it's important to stress that it that that can be variable in both directions right it could could also be earlier so like no one should rely on that not happening before this point or it could of course also be late or something but yeah just a bit of time no but yeah sometimes people hear that and then

for example i did i did hear like the valid point that for example i think it would be unfair for miners to not at least have like some period of time of like head heads up i mean unless there's some conflict case or something and like if we were to communicate now that it's like summer of next year and then all of a sudden it's like december of this year or something i feel like yeah it should be clear that like yeah this is not like what

Dankrad Feist: stops us from being able to do it in around one year i mean i feel like one and a half years is like too too much

i think

Vitalik Buterin: it's just compensating for the planning fallacy i mean if it can't like yeah i don't i definitely don't think like um like we definitely should

not commit ourselves to a path that forces us to either get it done within some fixed time frame or have incredibly huge problems but we should also um like not close the doors to do it um it's uh doing it quickly as well like because it definitely is

Danny Ryan: yeah i mean there's also just a number of people that have that need to touch this thing that have not um and so i i think some of us that have been touching it have something in mind but uh there's a lot more work

that needs to be done right i would just rather plan for a one year timeline and see it's like i would be there if there are problems then like we push it back

rather than starting with a very loose one and a half year timeline just yeah i i guess my main point is like i don't know right now this at this very moment is probably not the time to set the timeline uh but hopefully soon we can begin to have a beat up but one i guess one small change we can do like

Tim Beiko: we can push back the difficulty bomb more than one time right like so if right now again i'm not sure on this but if the difficulty bomb is you know pushed back 18 months from now maybe we can make that be like 12 months instead and then push it back again so it's like you know not saying that this is the timeline we need to use for the merge but it's like better to have the difficulty bomb go off soon

right and re-push it then

the opposite then like we wish we had it going off six months earlier right i mean

Vitalik Buterin: one thing we could even do is we could even just say all difficulty bomb extensions from now on or only six months and then it just becomes a part of each

hard fork

Dankrad Feist: yeah i would be in favor of that

yeah for something yeah so i guess that's something yeah on the next call we can kind of discuss what exactly do we want out of the difficulty bomb for uh for london and even kind of async uh before then um real quick metallic

Hudson Jameson: did you say earlier that the price of eth uh kind of affects the upcoming difficulty bomb and that it might delay it

some for the hash rate oh you're muted by the top

you made it sorry

Vitalik Buterin: um basically what happens is that the way the difficulty bomb works is it increases the difficulty by um in every block by a number and that number goes up exponentially and so if the difficulty of the chain itself goes higher then the the increase needed for the bomb to be substantial also goes up and so the time until the increase that kind of goes that high also um gets longer uh so if the hash rate and so the difficulty doubles then that gives us another 100 000 blocks which is about 16 days

and

Danny Ryan: in relation to the price the price

increases

driven uh increasing in difficulty because the amount of miners that are coming in the network and continuing to grow correct there yeah and one thing to keep in mind is that there's a good chance that the difficulty is going to keep going up from like where it is now even if the price stays constant or even decreases somewhat like the reason is basically just because difficulty is a lagging indicator right okay so it's moon math meaning if we go to the moon with price then it goes up got it correct all right i had to throw that joke in there okay so that

Hudson Jameson: for the uh eth2 talk um is there is the plan was the plan originally to also have eth2 on here next week to kind of go through some more updates

or

i i mean

Danny Ryan: i'm kind of here here and there i've had a scheduling complex in the past few times but i will be prioritizing this to talk about it anytime people want to both on this call and offline um definitely um we want to produce a little bit more documentation on all the things that we need to have happen and and and talk about that and maybe once that's produced and disseminated we might bring it back into the call to talk about that i also think that it probably makes sense to do at least a monthly more in-depth think on this in a different call and we will talk about scheduling that relatively soon

okay

Hudson Jameson: where can people go

to um talk about this

a sink or at a chat room yeah so on the the ethernet

Danny Ryan: discord does have a merge room right now um that is under e2 research uh i i think as i mentioned earlier we might make a sub category for the merge and after we've enumerated some of the sub topics that we want to address so we can talk about things in a little bit more granular fashion

okay so that merge room is a good place right now um it might evolve soon okay perfect just announcing

Hudson Jameson: the core dev chat if that happens and then we have micah and peter who had comments um so mike if you want to go first with whatever you were going to say we have three to five minutes on this topic left about

sure as you can see regarding the documentation i think it would be

great to have a specific card out of that documentation that explicitly says this is the minimal amount of work that needs one client dev team needs to do for the merch comes that way because i know that each one client teams are very very pricey and so being able to so they don't have to go learn everything just learned this core piece i think would be very helpful

Danny Ryan: yeah and uh guillaume can probably help with some of that documentation and it will be evolving uh i think especially when we start thinking about things like state sync but we can do a minimal version of that really soon

Hudson Jameson: okay and peter

Péter Szilágyi: so my personal request is that i think a lot of a lot of decisions kind of revolve around what we want the final chain to look like so i

think it would be super helpful if um if we would have some form of documentation so to say sdc which would say that post merge what how will the ethereum one chain look like meaning what variance does it have how many blocks does it want to retain do we want to support or don't you want to support accessing historical stuff etc in my opinion it's these two merge is a golden opportunity to just delete a lot of junk that we've accumulated so i by all means i'm in favor of trying to simplify things and trying to throw out things but before we start working on a technical solution i do think it's

it is essential to somehow agree that yes this is the model we're going with and we're searching for a solution for that specific issue

okay so what we can do is we won't necessarily fill in the gaps of what the answers to those are but we can write down what the questions are um and maybe right some begin to come on a coalescence insane answers to those solutions um and we'll take at least the list you mentioned um and anything else that we can come up with and then extend it from there

Hudson Jameson: okay that sounds very promising do we have any final words on the eth2 anything anything with the merge

anything like that uh i have one comment we are looking for

users uh for contracts that are writing like they're using the instructions difficulty and block hash to do something else then generate uh randomness so if you really depend on those uh on those instructions it would be nice that you got in touch with us

Hudson Jameson: great um and when you say get in touch with you how would they get in touch with you

uh yeah with uh with danny i guess he's the maybe r d discord maybe that's what i'm thinking yeah east indie discord is great yeah absolutely perfect okay yeah i think pretty much all of us are on there um okay if there's nothing else

we'll move on to item number five um removing evm features that's issue number 250 and that was brought up by metallic so vitalic you can

Hudson Jameson: take it away we have about 14 minutes till the meeting's over and we need one minute for an announcement so 13

minutes okay great um maybe in the meantime can you like paste the there's a link in the um in the issue to the doc um so would be good if people can read it um but basically the um idm is um that the merge um kind of ends the

Vitalik Buterin: the time before the merge presents this opportunity that's probably a much better opportunity than anything we'll ever have after the merge to a kind of do a cleanup of some ethereum features that were

probably introduced with the gun of not that good a reason and that it makes sense to either remove or kind of backwards incompatibly change in certain ways um and this uh like and the reasons that have to do this are either just just simplify the spec or sometimes just uh to introduce some new invariants that make it easier to do things that uh to do things in the future right um so oh by the way likewise i'm asking the question why exactly is emerge the best time to do these things i guess to be clear i'm saying either the merge or before the merge right um the reason why either of those two periods are better than after the merge is basically because any clients that gets developed after the merge

could potentially end up by kind of losing the ability to process um ethereum or kind of pre-emerge ethereum history and so it would be able to just like not needs to ever have the code to actually process those things which is just good for code simplification um so like i put in a couple of examples into that document uh so one of them is the self-destruct op code um and the basically um and you can follow along the dock but then the case says that the self-destruct top code was originally added as this kind of clean up feature to potentially help the state go back down um but it it just and ended up completely failing at i

think that objective um and the self-destruct opcode is actually quite terrible because it does break some uh kind of really important invariants that we like right so one of those invariants for example is just that like it allows you to send ifta addresses without actually calling them um another really important one is that self-destruct um only because of self-destruct there is no upper bound on the number of state objects that can be modified in one single block right like a contract with a million state objects can self-destruct itself and this is potentially really nasty if like it because it severely restricts the kind the ways that we can change the

uh the way that we store the state in the future right so this is thinking about like binary trees vertical trees potentially other kind of polynomial accumulators that we haven't yet invented yet basically if if we have an invariant that says um we can um there is a maximum of like say 5 000 objects that can change within a block then like we it becomes much easier to say treat the state as being a single layer structure and if we treat the state as a single layer structure it just makes it much easier to kind of able to like implement second like new ways of storing it um and a better abstractions for creating uh for how we deal with the the state um and it was room for bugs and all of

these things um and uh another book a couple of examples in there have to do with uh gas observability um so this and this is a topic that and i know we've all talked about many times but just one um removing the ability to make calls that have a partial amount of gas is the big one and the reason why that might be good to remove is basically so in order to make future changes the gas costs are kind of much easier and to like restrict the kinds of consequences that future changes the gas costs could have um so those

are those are probably the um are the two big categories and i saw there are some other changes as well like things like getting rid of call code because i was like um almost no one uses it there are a couple of small things as well um so encourage i you know i encourage everyone to read the doc i have some more kind of arguments in there about why i think um it would be a good idea to remove a couple of those things um and some of the ways in which we could uh kind of mitigate the consequences to existing applications as much as possible um i mean it's also like a reason why i think it's good to just kind of start talking about this early and start talking about this explicitly is that it's good to just

give application developers a kind of maximum possible amount of lead time so that they can be sure that they're not dependent on any of any of these things and like to be clear i think the the overwhelming majority of applications is not dependent on any of the things that's um that's expected to break here so it is it is a very small percentage um so this is just um kind of this list those kind of things in evm that would be worth uh trying kind of changing or moving or simplifying of course in addition to this there's also non-edm things so we're gonna we talked about block hash a bit and uh like the way that um changing the block hash um changing the

uh tree structure like will end up removing or backwards incompatibly changing the way how introspection works but it's still ultimately a good idea but it's like important to talk explicitly about it so

that people could depend on things being done the old way can kind of move away from that as thoroughly as my comments on possible uh yes so obviously this will break some things um and i'm just wondering like how do you see that let's say there are cases of ether which

will become stuck if self-destruct disappears is that um we should just kind of accept or you know i think

Vitalik Buterin: um uh my expectation is definitely that the amount of isa is low enough that we could probably just organize a yeah a community funds to compensate for people if there's any really serious cases oh um micah suggests a suggests some a one-time heart a kind of hard fork to rescue

this ducky i guess that's that's a winky face micah is that a real suggestion um i i i wasn't intending to start another war sorry i don't know i mean i've always been

before it but

Martin Holst Swende: uh yeah i heard another question which is refunds uh so we discussed this fairly recently removing those would be kind of great and awesome and i'm just wondering couldn't we do that even before even a lot sooner um we we could i you know i actually think removing refunds is definitely i think plus even the least risky of any of the items in my proposal um and like it does have benefits right so like for example if we remove like in london some people are concerned about eip1559

increasing block size variance but like if we remove refunds then refunds currently are another big source of watch size variants like it basically like right now we already have with refunds you could already have blocks that contain up to 25 million um executed gas and so if we remove them at the same time then that could address people's concerns

Péter Szilágyi: so i would personally definitely vote for refunds going out together with 15 59 i mean getting rid of refunds go hand in hand with 15.59 and i will personally both target it for london

Danny Ryan: i agree

is there an eep i assume there's no eep for getting rid of refunds yet right there's just your document vitalik

Vitalik Buterin: correct there is not yet an eep for any of these things

yeah so

Tim Beiko: that's one we think can make it into london i think if we could have it eep for the next call or the one after that would be that would be really good

we're under the same problem we hit with 2929 where there will be some contracts potentially they can no longer execute because they're just um so in

Vitalik Buterin: in this particular case actually no um and the reason why is that refunds um only apply after all the execution is

over um so you know like the worst that can happen is that some things become twice as expensive

yeah okay but

Martin Holst Swende: but it should be noted like for for anyone who's listening to this that if refunds go away then gas tokens will become useless or worthless so and i don't know how much money is tied up in gas tokens right now

um about 15 million dollars right so it's good if we talk about this openly and that might put a damper on the price so people can start

getting out of it and burning it

Hudson Jameson: um so for the gas token thing they have a website and they like i think listed in your document metallic it says that the website says there's no guarantee that there won't be changes in the future to make this obsolete and if this is right if this is phil's it's phil's group doing gas token right yes he would absolutely put a big warning on the side if we ask him i think about it

Martin Holst Swende: i think there is a big warning about it it basically says like this there's a large likelihood that this loophole will be fixed in the future

i think they expected once they made the

loophole public in a token that they expected to be fixed much sooner than it has been uh yeah

Hudson Jameson: actually i was about to ask about one inches chai and gst2 does that use the same mechanism do we know

it does okay no i do yeah trent and thomas said it does um i mean

Tomasz Stańczak: some of them are using uh self-destruct some of them are using uh refund so they're trying to find the optimization so what brings back the most

cast

Péter Szilágyi: but essentially both of them are based on refunds and getting something back

to you and all of them are basically a quick quick question i'm not an expert in in these like how how close to like a 2x

box size can put basically using those get us today because i would expect that once we kind of have a fixed date at which those become unusable then people will especially shortly before then we'll really kind of rush to to use all of them so that might give us like a transform period of like sustained uh larger blocks um is that a potential issue

Péter Szilágyi: i think we already have pretty much these large blocks i don't think it's an issue that we have people use it better if they use it up than if they get angry at us for not giving them the

headset makes sense now like if at all i think it's just argument for like giving like a like a long advanced warning not no no

no no whatsoever yeah we could do some outreach yeah that's exactly and

Martin Holst Swende: that's why i try to highlight it right now

so yeah let's

Hudson Jameson: start getting the word out i don't know how many people watch this meeting actually i know how many people watch this meeting only 148 right now so we need to we'll tell more people um there's about one minute left of the meeting um so let's real quick who is going to make the eip for some of the stuff that was just discussed including the refund mechanism and it could be multiple people assisting on it at the same time

[Music]

Vitalik Buterin: i'm happy to help

Hudson Jameson: okay um so vitalik and then anyone who wants

to help reach out to vitalik anyone who has updates

on folks okay thanks martin to this list the

Hudson Jameson: vitalik made talk to vitalik and the etherndy discord or just getting the authority discord and find a place to talk about it i think we have a bunch of chat rooms in there that would work um and for the last minute uh pooja will be announcing the stakeholder call that we have coming up uh go ahead

puja

Pooja Ranjan: so ethereum cathartics are hosting an eip call for aip1559 for uh inviting all the stakeholders of the union community this is basically to address any and all kind of concerns with the proposal uh we are inviting panelist to

a list of panelists includes erp champions researcher developers and all the details are available in the blog the call is planned on friday 26 february would be moderated by hudson jameson and the live stream link is provided in the agenda

okay

Hudson Jameson: thanks puja and yeah just to be clear we are addressing some concerns in there but there's nothing core dev meeting related about it it's going to be a lot of people airing out their concerns and getting information and just having kind of a discussion more so than any kind of this is going into a fork this is being decided on nothing like that's happening this is completely

separate from the core dev calls and run by the ethereum cat herders so just to be clear nothing no substantial decisions will be made from that call it'll just be an opportunity for discussion

i guess maybe one thing

Tim Beiko: one thing that's likely to come out of it is um you know miners are obviously kind of unhappy about uh 1559 because they lose the fees uh they've been proposing different uh alternatives you know whether it's uh uh having something to fight against asics whether it's raising the block reward or changing 1559 um one thing i hope is that they can kind of

align on one and you know then if they want to propose that on all core devs they're kind of free too um but yeah i think that's kind of one of the things i'm expecting to get out of the call is a sort of uh uh i don't know um just like concretizing yeah if that's a word uh they're they're very consensual rough consensus on a proposal from them yeah exactly from them right like and yeah we won't take a decision about that proposal there but i think that's that's likely what's to come out of it um and you know then all core devs can consider whether or not a they want to do 1559 which is still not included and b you know if we do it uh whether or not there's one of those proposals that makes it in alongside 1559.

cool did you have anything final yeah i

Pooja Ranjan: just wanted to um let people know that if there are concerns it's not possible to accommodate everybody on the call so we are having this reddit boost that is mentioned in the blog people can go ahead and write their questions that would be shared with the panelists there to get answers all right thank you all so much for uh coming to this the next meeting is going to be on march 5th 2021 at 1400 utc that's a friday uh thanks everybody for coming out and we'll see you then bye

thanks everyone thanks everyone bye okay

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