All Core Devs - Execution #104

Transcript

[Music] [Music] [Music]

[Music] thank you [Music] [Music] [Applause]

[Music] hello everyone and welcome to ethereum core dev meeting number 104 i'm your host hudson and today we're

going to be going over uh first of all yellow v3 and the berlin client updates if you click on yellow v3 it'll come up with the client spec and you can also go back and there's a new spec document that i think james and micah worked on for berlin so i'm going to post that into chat and that one kind of goes through a checklist and a readiness checklist for clients for people who are curious and we'll get some of that confirmed today so i'll give this to uh james to talk to people about yep so we can i i wrote up the the network

specification

James Hancock: this is a lot like the hard fork eips we had in the eip repo but now in the ethosphexy probe because they're we're keeping those kind of world separate and if you go through it the where we are is the final eips implemented into geth and then deploying yellow v3 and getting like a security green light and proposing a fork block for test nets so i was hoping to get an update on the status for the 27 18 29 30 um testing and implementation

if martin is here or whoever would like to want to get

team yeah so my response

Péter Szilágyi: will be a bit underwhelming i don't know because martin was mostly the one who finally in these parts and i was mostly focusing on just getting our next release out

so maybe if martin shows up you'll have an answer

Rai Sur: i can speak to a little bit of it um since he and i've been working on it so uh we've been working on generally just like unit testile stuff um but he just updated transaction t8n tool um to support the new transaction type so hopefully we can

get reference tests soon um yeah that's the phase we're at uh and um 2930 is a new transaction type

so it makes sense who would have to have new different kind of tests that we haven't had before because we've always had one yeah is that kind of what's going on is figuring out what to do about that yeah actually jenna we need to we also need to support something on our end right we support them tool we support retest death um that was

Danno Ferrin: the original spec and that's what we were running off of um i don't know if the retest that tools go to support the rpcs or not that's to be determined but um if that's not interested in supporting retest yet then we should move to the

t8n uh hi what's wrong with it uh we do support testing just not to retest

this uh legacy api

Danno Ferrin: the one that was originally expected that's three test deck with the uh http stuff you have the t8 and cli so i consider those two separate things

all right but re-test this is a i mean re-test it

Martin Holst Swende: is a tool but you're referring to the retestive api specification but the request is tool is now able to use a binary like this the transition tool as a back-end instead of the rpc api

yeah because

Danno Ferrin: you wouldn't support the legacy api

so that's why we're moving there

yes so martin we're going over um i guess where i was going over some of the testing stuff and once he's done you can kind of fill in the gaps for any other updates for the 27 27 18 29 30. the like testing updates for that yeah that was all i had oh okay cool um the so we've kind of focused a lot

James Hancock: on getting this done to go for a yellow v3

but i'm kind of thinking it would be good as a group to consider looking at setting fork blocks for test nets in sort of like a parallel path so previously we the it was sort of like a linear path if you do yellow v3 then we wait a while and then we do the fork box but i think it would be or i would open it to feedback to start independently talking about fork blocks and when we could or could not expect setting them

yes so

Martin Holst Swende: i would kind of agree that it might be good to try to

yeah schedule something this approach about just rolling it out when it's ready i had high hopes for it but i'm not sure it's gonna pan out as i had hoped so it might be

yeah might be actually time to try to schedule something and just to be clear yeah would it make sense to have yeah to have the you know

Tim Beiko: say we scheduled a test that blocks it needs to be a few weeks away anyways you know obviously we need to to finish the work but even past that you need to put out a release and then people need time to download and update that release um so it feels like in parallel to like

you know when that release is being deployed and adopted by people we can also have

yellow v3 and run the fuzz testing on it to make sure everything's good does that does that generally make sense [Music]

James Hancock: is there a sense for how like like a band of when we should start thinking about it like anywhere from two weeks to uh two months or um something that given your knowledge of how much is left or what needs to be done we can start looking at for targets

yeah

Martin Holst Swende: it's kind of a chicken

egg problem

[Music] but i yeah would it be easier i know theoretically we can

Rai Sur: set them in parallel to yolo would you feel more comfortable just setting them after yolo

yes well and also we can do it not after yolos we can do it after yolo's launch but also just when we know yellow is launching yeah when the when this one

James Hancock: when the features are ready or whatever however that's defined

did you want the chicken and egg when the egg

is hatched or the chicken has the egg whichever one yes

Martin Holst Swende: should we then decide on when to launch

yellow v3

Hudson Jameson: that sounds good as long as we have a fairly confident estimate of when um the rest of the eips and geth would get done um because i know i think that was just reviewing um stuff that's already been written right um sorry oh so eip 2718 and 2930 and geth those are not those are implemented just not reviewed

right or

no yeah well it's both then it goes hand in hand there is still implementation ongoing um and why and it's being reviewed as well but i mean i pushed code to that prs latest last night oh cool okay um so

Hudson Jameson: uh in that case for to your question of what should we set a date for yellow v3 i think it's in my opinion i think we could because then if things mess up and we have to change it that's not too bad to change or anything but it at least sets us a goal and uh expectation

Rai Sur: we don't really need to set

a date right it just whatever as soon as it goes up it goes up and then once we're comfortable we can set four blocks oh okay cool yeah i mean yolo doesn't need to be like yeah we don't need to say like oh we're gonna launch yellow on this date just launch it and then people will join

if the clients will be right but

Tim Beiko: we can also decide on the fork block acing right like i think i think once you know once we were in a spot where we can launch yolo which means that the work's basically been merged in death i feel like we could probably have you know say i don't know like something like four weeks from there for the test network block gives like two-ish weeks for clients to ship a release and it gives you know

two-ish weeks for after that people to update their nodes um that doesn't necessarily have to be you know like we should obviously confirm it on a call but we can we can make the decision

and just add that to clients um whenever yeah but uh i would like to they set an expectation so right um i think it would be really cool if we could get the uh testing and the get the yolo version b3 running the coming weeks week if we work together okay to get beta and get off on it do you think that would be reasonable

yeah i i think so and not necessarily making it into the mainline yes the pr but i mean it's i think it's fullest efficient if if it runs off the pr uh it might need some more weeks to actually get it merged to uh yeah to ensure in safety and stuff it doesn't screw up things and how are you

Rai Sur: in your model what's your like dependency structure between the reference tests and uh launching yolo um because we might need to maybe that one week is not realistic if we need to do extra support for

t8n tool right no um

but we don't need to have the reference test when we ship pillow v3 perfect yeah no that's all

Rai Sur: i was asking i was just asking if you saw that as a dependency or not

but okay if you don't then yeah no i know great okay so yeah go ahead that'll be that'll

James Hancock: be a goal for next friday and then for next call we can we can talk async as we know more about things before fork blocks and then talk more about it next

awkwardness you're muted oh

Hudson Jameson: just so i understand though um so yeah we're gonna launch yellow v3 when we launch it

as far as the async convo for fork block that can happen immediately after yolo's launched is that kind of what we're doing or do we want yellow to run for a little bit

before we start talking succinctly about it

James Hancock: i'd say let's focus on having yolo v3 be the launch for this next week and then the week after that as we can we can start talking about we can start bringing it up i don't think it's worth yeah we don't know it's really waiting at all yeah yeah so like the week the following week we should start thinking and talking about it

okay sounds good to me any other anyone else have comments okay uh james what other pieces do we

need to talk about today for yellow v3 or berlin that's all okay next up on the agenda or other eips or discussion items if you refresh your agendas everybody i just added a request for eip 2937 update from light client uh who's here today

Hudson Jameson: um but first let's talk about the ice age and future network upgrades because that was um that was it requested i guess um and the gist of it is that according to eip 2384 the ice age will be back around around july 2021 so will there be another hard fork and if so i think we should start planning

we'd love to hear what the

court devs think is the comment um so who has um does anyone have like just initial feelings on this otherwise i can kind of take us a direction so i just yeah just to be clear

Tim Beiko: i confirmed the number over the past week with um tj rush from uh quickblocks so the 20 the july 2021 number is is accurate

oh good so

Micah Zoltu: in the past when there has been a large price swing that has significantly increased or affected the guess um does that play a role here because i'm surprised that the original guess

is still right

given that we had a massive price swing

Hudson Jameson: uh to be clear what does the price swing have to do with it

does it just make

Tim Beiko: more miners come in and so for the time during which yeah the hash rate goes up quicker than the difficulty adjusts so it it creates blocks quicker for a short period of time and so it's i guess if you get multiple price swings you know you get multiple phases

um not

James Hancock: not just that but if your hash rate is higher you can actually artificially keep the ice age happening by pushing out when the ice age would show and when it would be too far because it uses the hash rate as a function within the ice age formula so if you

have a big hash rate you can the ice age will be smaller longer

Danno Ferrin: it'll move it out at best

two weeks to four weeks yeah yeah but yeah so if that's the

James Hancock: it would be great to see

some of the like calculations or stuff he'd use yeah i'll share the repo here in the comments um i didn't write this code uh but it's what we used uh last time i believe um and it seems like yeah as of now there's no like uh acceleration if you want of of the kingdom um but this could obviously change

okay

Hudson Jameson: um if anyone has comments just speak up but otherwise i would say this i mean clearly i don't believe this would be going into berlin at this point um i think there would be another hard fork that would happen later on before the ice age would hit or as it's hitting or basically doing our best to avoid and estimate when we can get a hard fork in that has some sort of significance and isn't just an ice age delay

that's kind of my gut reaction and can we just disable the ice age in once and for all and not return to this topic in the future

no

Tim Beiko: i strongly disagree yeah um i guess the reason is uh one i think we've actually found it useful as a forcing function for forks in the past uh two with the transition the proof of stake happening in the merge uh i think we want it uh it does it like it creates a barrier for anyone who wants to not upgrade when there's an upgrade that they need to maintain a fork and at least remove the difficulty bomb um and and they don't get to like just stay on the network and and uh and block progress so i yeah i think the fact that it you know both for us as the core devs it it helps us uh you

know like ship stuff uh but i think for anyone who wants to a pose or something it creates a not very high but a barrier to entry uh and it means they actually at least have to like fork the client remove the ice age and and you know share whatever changes that they they want

um yeah

James Hancock: and the but you can always make an eip then we can talk about it i would i would agree with that we should keep it and we should not and we should address it when it's showing up

there's probably is an eip already to remove it um i i remember we talked about this last time yeah i don't know if it's still open though

yeah peter what's up so

Péter Szilágyi: i just wanted to add a quick few comments um on on one end i don't think we should touch it for berlin simply because uh if it's not too urgent then it's fine to have a second fork and another good part of laying it a bit and having us enforcing ourselves with another hard fork is that there is some uh it's essential with this 1559 and a few of these uh so there are some conflicts on twitter so not everybody is fully

agreeing with 1559 and people have different opinions different uh rationalizations but there are certain fears that 1559 could cause some trouble and actually having the ice age fork happening and forcefully happening in a few months can actually help us to solve an issues so generally 1559 legit introduces some issues i don't know which ones now i don't want to be specific but if we legit have some issues then kind of the ice stage forces us or gives us an opportunity to actually handle that issue really quickly versus if it's just one of those annoying issues but it's we don't have

anything to force miners to upgrade or force people to upgrade that it's uh it's a lot harder to address any potential issues so i think in in our current position it might be valuable to to not touch the ice age for

for burden uh but

Artem Vorotnikov: you understand that the ice age delay it's approx it's like what a one line change in the code i'm pretty sure that all the dissenting parties they will have the resources to change to change that one line and uh live without ice age on the fork chain

Tim Beiko: uh i think you're underestimating the the distribution right like yes it's easy to change

in the code but then you need a way for peop you need to get that release to users and they need to adopt it

and

James Hancock: that code needs to be somewhere and people need to be able to find it and they need to be able to trust it

yeah the

Micah Zoltu: trust i think is the hardest part like there's just some random dude on the internet who's anonymous from china publishes a version of guests that supposedly has ice age removed how many miners around the world are going to download

that we've had every

Hudson Jameson: hard fork we've had ethereum gold and ethereum diamond and all kinds of scams that actually some of them are actually smart contracts that people go and check on and they get they get trusted enough to go in and actually people give their private keys over so yeah i'm on the anti-scam

side of things whatever can be done to pr like most prevent that

i guess yeah and only know truth be told

Péter Szilágyi: the ice age if we're thinking about it long term i kind of agree here with everybody that the original purpose of the ice age was to switch over to force the depth to switch over to serenity now it's it seems a bit weird that we're going to kill the ice age right before actually getting that point so we might as well if we stuck it out for five years we might as well go all in and just leave it

yeah but

Hudson Jameson: i am curious artem like because the original purpose of this is still

set and it's still doing what its purpose was is your argument just so i understand it that it's kind of like annoying and it's forcing people to into something they don't need to be forced into

uh yeah

Artem Vorotnikov: it actually causes us to waste time on this oh the discussion or uh own discussions on fixing it on delaying ice age we forget about ice age

for example that's true that that kind of sucked but i feel like that's not going to happen again because at least not

Hudson Jameson: this time because we're early enough in the

process that we've figured out the date so i hope so yeah as long as we get it right and it doesn't shift drastically but i mean there's no nothing's nothing's guaranteed

we haven't forgot about it today it's pretty good okay so i'm seeing mostly pretty much um i guess

Hudson Jameson: most of us are saying that um yeah we're not going to put the ice agent in berlin definitely and then we need to evaluate in the future um when another hard fork that would either depending on what eips are out there

because i guess an eip will need to be made for um delaying the ice age versus disabling it versus anything else people have ideas about

um and so that that can happen later volunteers making any ip to delete ice age just to get the conversation started

James Hancock: i can do it it's one of the easiest eips to create so yeah yeah i can do it and then and then to your to your point of view if the price of heath goes up it's more likely for the for the ice age to be delayed further than to accelerate

okay um all right is there any other comments on this before we go ahead okay the next step is eip 2937 update that is the eip for set indestructible op code i think vitalik is the author he's not here but um who else was working on this light client maybe you know some stuff yeah there's two two people that have been working on it i don't think they made it to the meeting today but i i know that martin had some comments on it last time and there is a discussion on east magicians still i think irony one

part of that out there's a pr to adjust the specification so i didn't know if anyone had any other comments on this this eip so uh yeah so i posted some questions uh on the forum and i'm not sure was it you who answered or who who was it that gave the answers because i'm not sure if like uh no it wasn't me it was um yes

Martin Holst Swende: i couldn't figure out that these if the answers were like the canonical answers from the someone who actually um they were like i

think that blah blah but i'm wondering what the actual answer is to these questions because i yeah it's kind of hard to i mean i could not based on the specification i could not implement this in geth if i wanted to because i think it's too much that it's not explicitly said yeah um yeah so the person who responded is one of the people who've written an implementation for it and during the implementation there were a few small changes to the specification from how vitalik originally wrote it it was originally written with you know a globals a variable that stored every address

that called indestructible within the transaction call graph and what they decided to do is to scope it to the frame of execution and um also propagate uh propagate up these whatever it was called within like a delegate call or a call code so that's that should be updated on the spec on a pull request to the spec but the talk hasn't been able to approve it yet

yeah because like some of the things like

Martin Holst Swende: what is supposed to happen if i delegate call a contract which

immediately says said indestructible which i mean and that's the intent like you're not supposed to be able to destroy a library so every every well-behaving library will do this but yeah so if you delegate call into it it should not allow the address that it is the code is executing under to self-destruct because if you were to ever call the library directly where its address is you know the executing context and that the set indestructible would protect that address

but i mean martin

Ansgar Dietrichs: martin has a point there right because that would mean that if we implement that way then um you could basically if you if you as your contract relies on using self-destruct at some point you could not use libraries that start with set instructable at least not if they kind of are part of every execution path um because then you can't be

self-restricted anyway as well the question is maybe that should not happen so so maybe like right because the library would still be right yeah and

Martin Holst Swende: that becomes a bit problematic because in the evm execution context you have the address which is the current executing address um you have but one thing i think you maybe not always have is

like the current address where i picked the code but i'm not actually executing under um but but what the e basically says is that if you are if you if you run into a set indestructible and the code is from somewhere else and not actually at the address where you are currently executing then you should ignore it

um i think right now the erp says the opposite no i thought right now there he basically says if you delegate call somewhere somewhere else and then that calls set indestructible then the call context address it becomes indestructible for the rest of the call

yeah or i mean it's that's it that's kind of vague in the e and that's what i try to ask for more clarification on it's as as the current colleague to the global indestructible um and what is the current quality in for example the delegate call uh is the current you know yeah that's okay that's a good point we we can work on making it more clear and i mean that is a good point with the libraries um i you know i wasn't really sure how just how most contracts implement the self-destruct functionality like it

are they always delegate calling into something and that this has kind of like all of the functionality in which case yeah that doesn't really work because then you you aren't able to self-destruct your wallet or something but just just to be clear by the way um the pr that i also put the link to in the chat that that um my client mentioned um that indeed kind of clarifies the language around uh callee so so that's not no longer kind of the the whole kind of sentence with callees is removed and instead it's very explicit about what happens in case of a delegate call and and everything so um it's still an open question is that the the behavior that we would want to to happen but but at least it's i would say well specified now in the

piano okay was it you who answered my question on on the forum no no i think it's one of the two like like i think right hand if you want to give some context i think there was like some so sorry was it no i finally saw on the pr it's actually a name for who angela lou wanted to answer yeah angela liu and another person tyler has been helping implement this learning about implementing things in guests cool

Hudson Jameson: anything else on this

i think that's it we will work on getting it better specified and then think about how to address the issue with the using you know libraries and how to self-destruct

the code that's calling them okay yeah i think

Martin Holst Swende: i think it would be good if the specification was written more hands-on with the well-defined terms such as address uh of the current executing contract and and because the even the pr now says if contract x does delegate call c and self-destruct um but that's a bit too high level in my opinion

i mean it's good with high level description but it's also a low level technical specification but at any given point you know exactly what to do and not like have to try to figure out

was did i arrive here by a delegate call um yeah okay thanks martin micah you have your hand raised uh yeah i was just gonna ask can we get um going forward in general and specifically for this

Micah Zoltu: can we get a channel and discord for each eip that's going into an upcoming hard fork there's usually relatively by the time they get to the hard fork we're usually down to like two or three so i don't think it'll be too big would burn on channels we can delete them afterwards but i think it'd be nice to have a place like when martin just wants a quick

answer for something like this you can just pop in that channel and ask and the right people are there

i mean

Martin Holst Swende: i think it's fine with the forum um except when when the forum grows stale but if the quorum girls stay then probably the discord would also grow stale

Hudson Jameson: um i think that's a good idea micah for certain major eips for sure beyond that i'm skeptical the value like martin's kind of saying but we can always try it once we come to like a medium-sized eip or one that's having a lot of acd discussion no no no no uh no problem trying it for something in

the future but this one sounds like it's active enough in the forums

yeah p1559 has three of them better for worse for better for worse yeah okay so um um i think that's the last thing on the agenda does anyone have anything else i have a small thing um so as uh i guess people know by now

Tim Beiko: uh i'll be taking over all core devs uh soon from hudson and uh one of the things i've been doing in the meantime is reaching out the folks who are involved with the process uh to get their feedback about how it's going and how we can improve it

um and you know uh thoughts just in general on on awkward devs uh if you have strong opinions on this or just want to chat about it uh yeah please reach out happy to take some time to chat and over the next couple weeks i'll try to put most of the feedback i've received together and and share it back here

um yeah sounds good and

Hudson Jameson: so they can probably reach you on discord and if not discord telegram and if not telegram twitter dms and if not twitter it's ham radio

yeah

Tim Beiko: discord and twitter is the best my dms are open on twitter i'm on the

east rnd discord cool what's your ham radio sign or

whatever they call it don't get on the one that's just the shanties all the time there's a new one for that um okay so that's it for this uh call thanks everybody see you in two weeks [Music] [Music]

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

so [Music] so

[Music] [Music] [Music] you

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