All Core Devs - Execution #123

Transcript

[Music] [Music] [Music]

[Music] [Music] so

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

so [Music] [Music]

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

[Music] [Music]

Tim Beiko: okay hi everyone welcome to awkwardev's call number two three um i'll share the agenda in the chat here uh we don't have a ton of things on the agenda today um yeah just uh some updates on the merge um updates on the december fork and then there were a couple uh eips that uh we hadn't had time to discuss for the past couple calls um and i think we'll

probably be able to get over them today um so first on the merge side um miguel or danny couldn't join the call because they're both traveling uh i've seen that like various client teams have started working on uh implementing eip 37's 3675 as well as the uh the merge api um yeah i don't know if teams just want to share generally where they're at right now with uh with supporting uh the execution side of the merge

Justin Florentine: hey this is uh justin florentine from baysu we are currently

in testing on that um that's one of the things that's going on for our on-site folks i believe we've had um success uh interopering with dieth and besu as far as

tecu is concerned yeah

Justin Florentine: that's yes that's a better way to phrase that thank you thanks

yeah yeah in other mind

Marek Moraczyński: we are passing this vectors provided by marius and we are still have some work to do uh and we want to run nethermine with one of uh consensus clients soon

so yeah that is the plan

Tim Beiko: cool

Marius van der Wijden: yeah for gas go ahead i've implemented the spec and i created some test vectors for the other teams to use for helping them implement it i haven't started looking into a consensus layer client yet so i don't know who's with whom we interrupt right now but i think uh it's taku and lighthouse

um so uh yeah things are chugging along

uh i don't i don't see peter in the in the chat but it seems he has also made some progress on the sync algorithm to be confirmed but uh yeah looks like

that

Tim Beiko: um and i think did i see andrew yeah andrew has there been any update on aragon

Andrew Ashikhmin: sorry was it about the merge [Music] no sorry no update no i still we still

have to actually uh um to start working on it in

honest

Tim Beiko: got it um and i see peter just joined um peter uh right before you joined marius was or sorry guillaume was saying there might have been some progress on the sink for the merge i don't know if you had any updates you wanted to share it there yes

Péter Szilágyi: it's done

Tim Beiko: love it

so

Péter Szilágyi: uh no so essentially just a very very quick update and we can discuss the merge next week i mean the thing stuff details but the only update is that uh

now i mean it's not merged obviously and all the all the disclaimers about bugs and whatnot but essentially what is functional is that an e-2 client can announce a new head header arbitrarily many or few or whatever and gath will actually do a full reverse addressing to that so from being beginning from that announced header up to the genesis and then backfill it whether it's full sync or snap sync uh whatever and the whole thing works and you can leave the client and keep announcing you have headers and guests will just keep switching and if you if

the client announces a fork then get the switch and pretty much yeah

Tim Beiko: that's yeah that's awesome um i know felix had a sync spec that he shared like a a call or two ago um have there been any changes to that or is that basically what you implemented

Péter Szilágyi: um much simpler approach that i've been working on for the past three months so felix felix shared that you can essentially these two clients and equal clients can optimize a lot of things if you take into consideration finalizations and whatnot

right as for me i went with a really simple approach where there's no assumptions and there's almost no requirement from e2 side i mean if the client just gives us the new head header and that's enough we don't care about anything if you have other api calls maybe you can optimize it but my goal kind of was to make the bare bone thing work solidly and then if by a few other api calls we can make it a bit nicer it's okay

Tim Beiko: got it yeah that's that's great um there's two questions in the chat one do you have a pr number and two how long does the reverse sync roughly take

Péter Szilágyi: well uh

okay pr number i just opened the pr against my racist thing the problem is that it's it entails insane overalls of guests internals and request id handling and everything so it's a it's a five thousand item good luck um as for how long it takes i mean uh i tried it on mainnet yesterday and downloading all these reverse headers took maybe 20 minutes after which you just start backfilling them like normal snapsync would do or title forcing just obviously you don't need to download the headers anymore because you already have them so my expectation is that i mean

synchronization will take the same amount of time it takes currently there's nothing but specifically in there that will make it faster or slower

Tim Beiko: nice uh yeah that's that's really cool um anyone else have questions on on that okay um anyone else had just general updates they wanted to share about the merge or questions that they have or problems they've come across okay um

yeah so i guess people can expect more progress on that in the coming weeks but it's good to see all the teams are kind of starting to make make pretty serious progress um so next thing on the agenda was uh basically the december fork um so on the last call uh we uh we discussed a bunch of small eips and uh because they were small and some of them kind of added a lot of value immediately um we we wondered you know should we have these in a december fork alongside with the difficulty bomb um the challenge there being that if we do introduce another fork uh or sorry another eip in the december fork uh

we'll actually need to fork all of the test nets rather than just mainnet because uh the difficulty bomb is only on mainnet um and that would add a lot of overhead and and require client releases to be ready quite soon um so i i reached out to all the client teams uh in the past two weeks to basically see what they thought about it um and basically everyone agreed or at least uh three out of the four teams you know preferred not doing anything except from the difficulty bomb uh one of the team was uh was just pretty much indifferent um i know there were some issues raised about uh dos vectors for 3860 with the init code um the teams the client teams

that were most affected felt that they could kind of mitigate those issues um and and you know that it wasn't the end of the world if this eip didn't make it in until after the verge um so i guess you know first of all like i just want to leave the space does any client team kind of has has any kind team like just change their mind on that or does anyone like still feel strongly we should push for a december fork that has more than the difficulty bomb

okay nothing's changed on the base you team

Tim Beiko: awesome thanks okay so if anyone feels or if no one

feels really strongly about that um then i think the next step just to provide clarity to people would be to create uh an upgrade um for december and name it so uh i think axic had proposed aero glacier as a name uh just because uh we used muir glacier last time um for this for the difficulty bomb only upgrade and also because people have started associating shanghai with you know a fork that will have a bunch of of new features in it so i think it allows us to just keep talking about shanghai even though the date is is obviously not set um but also just highlight that there is something happening in december um

so and we should create just an eip there to delay the difficulty bomb um it's probably still early to decide by how much we want to push back the difficulty bomb um but uh i think we basically need to do so in the next month so that towards the end of october we have a value that's been updated across all of the clients and then uh two weeks later uh we can have a client release mid-november uh with the actual fork block and um and and eip implemented uh so that uh people have a couple weeks to upgrade before the the bomb goes off um so i'm happy to create kind of the

the spec for the for the upgrade and to also create the placeholder eip and and you know talk about different values by which we could push a difficulty bomb i think we'll know better in the next two three weeks you know how many months we want to push it by uh so yeah we can discuss that then um yeah does this generally make sense to people that people have strong oppositions to it otherwise uh i'm happy to go ahead and do this okay no one objecting that's good um

so okay by the next uh cordev call i'll i'll i'll have all of this so we can properly review it and one final comment i'll highlight is um uh tj rush said that if we do just a difficulty only fork in difficulty bomb only fork in december it might help extend open ethereum's end of life where a lot of people would be able to just add simple support for that um and because it doesn't require much additional testing and whatnot it's quite an easy change um so i'll also give an extra couple months to everyone who's still transitioning out of open ethereum um yeah if we if we go that path cool

so uh that was quick 17 minutes the two big things on the agenda are basically done um we had uh two i guess three other eips that uh yeah we we uh we've just haven't had the time to discuss over the past couple calls um so we can run through them now uh first was eip 3436 uh this is about the clique blockchain the clique block choice rule um i think dano you're on the call yes daniel you're on the call uh do you want to give us some context and just kind of share where where we're at with this

Danno Ferrin: yeah um i brought this up back in march

um and there was promise to take some of the discussion to the ethereum magicians i got only one response that i responded to that reply and it's basically gone quiet um but the big impact of this is you know earlier in the year the gorilla network had a couple of natural halts because of the way that clients can choose which blocks to follow when they detect a fork that the all the validators can split into basically two groups so what this eip is doing is establishing rules when you see two forks a priority list of how to choose which one to go to and right now the only um rule that is universally implemented is the first rule which is of course pick the heaviest chain

the second rule would be to pick the shortest chain that's a rule that geth implements and that's outside the spec um so this eip would enshrine that in the spec but then to ensure that when you see a series of forks because it's possible still with that rule to have two equal length um uh forks that can still halt the system so that's the point of the third block which is to look at the current epoch of the last 3000 blocks which everyone who does click should be fully aware of and pick the one i think i've gone back and forth on it but basically the one that as it's currently written who's validator has least recently had an intern block assignment that's designed to maximize intern block assignments there's a formula

that i think when people read it they miss to determine what that step three means um and then the last one of course if there's still a tie after all of that um because the most recent least recent intern block producer produced two blocks on that chain or has on two chains producing blocks um is to choose the one with the lowest hash and the hash is of course the last step to present a hash rate between different clients so up to step three um you're narrowing on a specific validator whose block you should choose and then you pick the one the lowest in the event that they're producing multiple hashes so if the clients following click were to implement this these natural halts would not be occurring because in the presence of a fork um the clients would have a rule as to

which one to go down if they're aware of the fourth if it's a full net split i mean you can't solve that problem but if the split comes back together you're not going to stay on separate forks if we follow this so this is something i would like to see the clients implement um and so i really need you know i think i've got a pr ready for basically to go in once this is approved so really just aragon and geth and uh nethermind would need to uh give feedback on this before it would be adopted to be my thought

Tim Beiko: thanks for the context um thomas has a comment in the chat saying that uh they're thinking about implementing this for the merge because it would simplify the merge testing on clique

um anyone else have have thoughts

Martin Holst Swende: yeah um sorry my mind is a bit hazy about this uh i recall starting to implement this at one point and there was some snag about it which i don't recall right now do you know um directly what like what are the hidden if there is any hidden fit for snag um in this proposal

Danno Ferrin: so when you decide which uh in your fork choice detection logic you need to have the status of the current um click epoc um of who the validators are and what their slot assignments are basically

um with that they click you know the mod of the validators and the current block so when you do that choice you're going to need to plumb that information through and that's probably where the hard part is that's where the hardest part basically is is plumbing that logic into the fork detection logic and um because basically does object oriented we just have multiple subclasses so we need to switch out for plain old proof of work we just keep the proof of work one then we can put the fancy click fork choice rules in so if you're if you don't have plugable architecture there you're gonna need to have some flags to say well this is a pouch don't do these checks so those are i think again the real bumps are gonna be

Martin Holst Swende: so i think i remember now the the catch was that there is no four choice rules

per consensus and it's there's on a global work choice rule but with the changes that gary made for um for the new consensus engines for the merge i think he refactored it so we have a you know a plugable consensus engine with that with its own port choice rule uh right so and with that it will be much easier to adapt your proposal cool

Danno Ferrin: good to hear so unless i'm hearing objections i'll clean up my patch on basu and try and get it in for the next major release so because another thing about this is this is compatible with people without it

it's just we don't get the real value until the majority of the validators implement these four choice rules

Tim Beiko: cool so i guess does it make sense uh does it make sense it seems like i know geth can implement it uh you can implement it in base soon nethermine is thinking about doing it so um seems like people want to implement this uh i'm not sure how this gets like accepted into the clique spec because clique itself is another eip so i guess i'm not sure what's like the

process to make this like part of the spec and and also the type of delay around that given that like people can just implement it when they want so yeah i danno do you have a feeling for what you would want the next like official step to be here

Danno Ferrin: um it's hard to say because you know micah's not big on amending previous vips so we could put a reference in eip of click saying um for please use this for the form choice rule but not actually merge it into the click eip um i think the people who really care about the eip process aren't on the call quite right now but i think probably thing to do is move

it into like um a final call and leave it there until we have everyone's implementations and then close it off

Tim Beiko: yeah that seems reasonable so okay let's move this to last call and uh yeah keep track of the different clients who implement it and we'll move it the final ones uh basically the the four clients here have have implemented

Pooja Ranjan: so i would like to mention one thing here when the proposal was originally proposed it was under the networking type now it has been moved from networking to core because it was believed that it's going to bring some of the consensus changes for uh click part uh i'm wondering if that would be following the usual uh core eips process for

getting implemented maybe a part of the upcoming upgrade

well because it's a click it's not gonna be on the main net yeah and it's

Danno Ferrin: very compatible it's not a hard four could be more equivalent to a soft fork because you can come onto a network and not have this implemented and for the most part still participate so it's you're not gonna be too surprised it might take a while for you to figure out what the real live chain is but eventually you'll figure it out

Pooja Ranjan: sounds good

Tim Beiko: okay um yeah there's a question about like not sure if this should be a core eip dyno do you know off the top of your head if

the clique eip itself is a core eip

Danno Ferrin: uh no i don't want to look it up

Tim Beiko: okay um but i guess regardless of the actual stat category i think it makes sense to move it to find the last call now um and then move it to final once clients have implemented it does anyone object to that okay yeah

um two to five

Danno Ferrin: is the click eip and that is core

so okay

Tim Beiko: we can discuss this offline if people feel very strongly about it but it seems like intuitively the extension the clique should also be core if the actual clique

ibe is core um but i'm not willing to die on that hell and if people are that we should just discuss this on the discord

and

Pooja Ranjan: just to give some more context it was discussed in the last eipip meeting uh so maybe the recording of that might help we were discussing about networking proposals with felix mica and then generally it was uh decided that it should not be a part of networking eip and should be moved to korea so this is a recent change and yeah we can follow the discussion there

awesome thanks

Tim Beiko: okay uh thank you dano we had another one uh micah is not on the call and i think

this was his uh but it was around eip 2976 the type transactions over gossip um i don't know if anyone else had context here otherwise we can we can talk about it another time

Pooja Ranjan: yeah that is another networking proposal because in the last meeting we were discussing about cleanup of that particular category uh so this was uh moved to last call and the last call period is ending on october 6 so if people have any question common concern this is the time before it gets moved to the final status we just wanted to let everyone know about it this this networking proposal is going to be final soon

Tim Beiko: okay um so yes please review that uh yeah so it's about sending type transactions over the gossip network okay great and then uh oh andrew sorry you have your hand raised

so i have a question about uh if 2976 is it just a clarification of the existing practice or is it a change does anyone undergo am

Martin Holst Swende: wondering the same thing and basically uh whenever we send anything over the network

we have an oral key packet it's it's rlp so if we send a transaction it's going to be inside of an rlp list and yeah i don't i don't really i think it's just clarification i don't think this changes

anything

Tim Beiko: yeah we uh we just had micah join so micah we're talking about your eip 2976 and people are wondering does this actually change any behavior or does it clarify the existing behavior and if you are speaking oh

i believe it is already implemented just never merged um okay we can give you a couple minutes but it seems like uh yeah martin and thomas you are right with this

Martin Holst Swende: um but that so most of the peer-to-peer specifications do not live in the east rifle but leaving the peripheral specification i might be wrong about this but

um [Music]

Micah Zoltu: yes so the so i wrote an eip for it uh back when 2718 was written and um it just never made it in and it wasn't

clear at the time whether we wanted to actually use the iaps for networking specs because they seems like they generally aren't used other than just kind of ad hoc at the end after everything's already merged someone goes and writes an eip that just for the sake of it i recently talked to felix and he would like to continue to use the ap process and probably try to be a little bit more diligent about it so um when in the future when networking specs go through it would go through the standard eip process and we'd have it on all core devs call and talk about it and all that um but that's going forward this eip was before we came to that agreement and so um it kind of just sat there and it should mirror what everybody's

implemented if it doesn't then that's a problem we should fix it

[Music]

Tim Beiko: uh andrew

Andrew Ashikhmin: uh yeah just uh one comment uh only slightly related to the skip because um in for type transactions um it's actually how it currently works even on the consensus level the ebit cells itself says that um transaction type transaction should be prepended with the transaction type byte and then the payload follows and that payload for existing transactions is rlp and that works for calculating transaction route but in the

block i think it's additionally this this um this thing is additionally wrapped as an rlp array so there was this kind of gray area which was not exactly specified by ip2718 whether to wrap this additionally as an rop into an rop array or not and i believe there were some issues on the networking level um also related to this ambiguity whether to wrap it additionally or not so to my mind it's good that we clarify it but we should we should

probably describe what most clients already do rather than introduce changes

Micah Zoltu: how it goes into a block should be specified somewhere i'm looking right now to see if i remember where it was either in the 2718 itself or in the type of like 2930 and 1559 but that should be specified somewhere i know we wrote it down at some point

Andrew Ashikhmin: well where was it just sorry just a moment i i think it

was not but it does okay it doesn't matter too much uh i think we followed gas implementation but i'm sure there was a decision somewhere whether to wrap it in in the byte array or not

Micah Zoltu: yeah so in 2718 and the specification section under the transaction subheading or the receipt subheading that first sentence specifies how the patricia patricia tree should be calculated

uh yeah that's right that is specified but when you consider blockbody the the uh rlp the transaction rlp prefixed by

the transaction type is additionally wrapped into rlp byte array and that i don't think that was specified in the for for block bodies yes

Micah Zoltu: that that's in 2976 you're correct that is not in 2018.

Andrew Ashikhmin: ah okay okay

Micah Zoltu: yeah i think for 29.76 like i said if the clients can just review it make sure it matches with your implementations it should i've talked to felix about them i believe felix thinks it matches implementation um so if it just matches everybody's implementation we go merge it as final and be done

Tim Beiko: sorry i couldn't find the unmute button

um and do clients feel like that's something they can do in the next week just because uh the last call period is supposed to end on october 6th is it fine if we yeah just just because we we've haven't discussed this the past two or three calls i think when it's about the agenda other people want more time to just look at this or is it trivial to do

Martin Holst Swende: i think it should be sufficient uh given that this is already the fact

though

Tim Beiko: okay cool so yeah let's um let's uh

um move it to final uh on october 6th assuming nobody in the meantime has comments about it great and then the last thing we had on the agenda is eap 3607. um basically this was the one uh rejecting transactions from senders which already have deployed code associated with the address um it's already been merged in in geth and andrew was asking if we can move this to final so that we can also add it to the yellow paper and make it part of the formal specification

Tomasz Stańczak: um

yeah i believe it's also implemented in the mines already

great uh how about basu and aragon uh in aragon

Andrew Ashikhmin: it's not yet implemented but we can implement it

it's not a problem

Justin Florentine: i'm unfamiliar with this one i have to get back to you

Tim Beiko: okay um so yeah it should be a small change um and uh i have micah in the chat saying we should move it to review so this is this is kind of good timing so i think we can definitely move it to review like

now so after the call today if uh marius or yeah miraculous one on the call so i'm gonna pick on you uh if you want to move it to review um then uh basically we can move it to last call uh on on the next call um once everybody's implemented it and then it'll go to final so i speak in like the next couple weeks we can we can get it to final um and also for the yellow paper i feel like once it's in last call maybe you can just open a pr against the yellow paper and we can just merge it once it's in final does that make sense

andrew uh there is a already apr so yeah but

yeah happy to imagine when it is in last call

Tim Beiko: um so i'll um i'll just add that to the agenda also on the next call so we we remember to uh to follow up on it and that's everything we had on today's agenda uh was there anything else anyone wanted to bring up

Pooja Ranjan: um yeah i just wanted to mention about one of the actually two of the proposals that were discussed in the previous call i suppose uh that was that uh where uh

networking proposals um um the number is uh two three six four and two four six four uh these were in draft now has have been moved to uh stagnant by the eip part and now actually we are working towards cleanup of the repositories and a lot of proposals which were not active for over six month period of time they have been moved to stagnant status by the bot so i just wanted to let uh all the eap authors know that if your proposal has been moved to stagnant and you still want to pursue that you might have to create a pull request again but for these two particular proposals we need to get this to move to review status so we can move it forward and

i know this is not active right now but that is required for proposal 2481 which is like 866 and we cannot make it final unless we move the proposals which needs to be final before that so uh if i may

request the are there two proposals that are like stagnant basically 864 and each 65 yeah right so what needs to be done

Pooja Ranjan: so i i made a pull request but in my pull request it was proposed to move from draft to review but now that it has already been moved to stagnant so either the author has to make a new pull request or i am happy to uh

create one but it might require approval of the author

Tim Beiko: right and so peter is the author on those two um so basically what we need is a pull request that's approved by peter to move it from stagnant to review is that right

Pooja Ranjan: correct

Tim Beiko: okay um oh did you say something peter sorry i was just trolling people good luck getting those reviews sorry i didn't get that it's like you're very far from the mic

never mind i was just trolling people okay

Tim Beiko: um yeah so uh

okay so yeah if you can just uh either open the pull request or puja if you want to open them and peter just approves them um so we can move those two to review and then we can actually move um yeah we can move e66 to finally cool anything else anyone wanted to bring up okay well short call thanks everybody um yeah i will see you all in two weeks and um yeah looking forward to more progress on the merge in the coming weeks

cheers thanks bye

thank you nice weekend bye see you bye [Music] [Music]

so [Music] [Music] [Music]

[Applause] [Music] [Music] foreign

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