All Core Devs - Execution #102

Transcript

[Music] [Music] [Music]

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

[Music] so

Hudson Jameson: hello everyone and welcome to ethereum core dev meeting number 102 um i'm your host hudson and today we're going to be going over just a few agenda items the first one is an update on yellow v3 and the berlin client updates and also a sub topic of that is the outcome of the 2718 breakout room so should we do the 2017 breakout room first do you think james uh just to figure out what's been decided there to then see what people have implemented from that if anything already

yep

yeah we'll start with that and then if there's any client stuff uncovered related we'll move from there

okay

sounds good uh you can take it away then or who wants to take the update oh yeah actually let me click on the link and we can give just a quick the quick summary um and does anyone want to go over the decisions um it looks like a light client gave a good story there yeah why don't you go ahead man if okay yeah

Lightclient: so basically the main thing we were trying to decide is how we wanted to serialize the the type transactions and we've you know we've already decided how they would be serialized over uh

in the consensus in the consensus protocol and the question is how do we serialize it over the wire and the main outcome of that was that we were going to wrap the transaction rlp bytes in a byte array string and so whenever it comes over the wire on wp2p it will be wrapped as a byte string and so we'll decode that byte trig and then decode the transaction that was the main outcome the other couple decisions were everybody was in mostly an agreement already

Hudson Jameson: all right any questions from anybody on that um is there anyone who needs some clarification

on what this means for their client implementation

okay

Artem Vorotnikov: i have a question so i'm looking at the uh the the outcome the final civilization block and the decisions uh in the issue and so is it correct that this will be rlp within rlp basically or what is the uh format for the by string length

the byte string

Lightclient: yeah it's essentially rlp with an rlp um we've got the the transaction byte that's concatenated in front of the payload and the payload for the 2930 transaction is also rlp so it's yeah it's essentially

rlp encoded rlp

Artem Vorotnikov: uh and so about the motivation why did you not opt for uh rlp within

sse

Lightclient: i think the main reason we didn't do ssd is that at this point people are a little you know fatigued of the ssd rlp discussion we need to ship 29.29 and we need to ship it a few months ago and so it's a lot faster to just go ahead and ship this with with rop now and and figure out

rlp or sorry i figure out ssd in 2021 okay any other questions or comments

Guillaume Ballet: uh yeah so uh our rlp is fairly recursive and yeah i'm sorry i didn't follow the conversation at all but i'm just curious why do you do rlp inside rlp and why like what do you have this intermediate step of turning it into a byte array why don't you just include it directly

so

Rai Sur: it's actually better not to think of it as rlp and rlp to just think of it as an opaque byte array i think it ends up being kind of like that just because of what the value of the the type byte is but we could potentially have the type by concatenated with you know an sse encoded thing or anything in the future so yeah i think it is best to just think of it as an opaque binary for now that just happens to have one 29

one transaction which is 2930 which is rlp in this spec but there's no requirement for that in the future

all right anything else

Hudson Jameson: all right hey thanks so much light client for that update um so now that we have that um decision outlined we can go over yellow v3 and the berlin client updates um james do you want to take that one on and go through all the teams

yep so just an update on where the implementations are just updates in general for the yolo v3 spec for each client is there a client that's burning to go first nope okay uh basu can you go

tim

rya's

Tim Beiko: actually the one working on the implementation so he'll give a better update to me all right

sure

Rai Sur: so i'm still working on 27 18 and 29 30. um yeah everything else everything else is ready but yeah i'm still working on that

okay

and uh geth is did martin make it here

Lightclient: i'm doing the implementation and guest so i can say that the implementation is mostly complete the main thing that's missing is i'm still trying to work out this news the serialization format for the list of transactions

Hudson Jameson: i think martin also is here so y'all can both give updates

yeah uh i mean it's mainly same as

visual we're it's just 27 18 30. that is the big one the one we're waiting for which lifetime yeah

Tomasz Stańczak: so the last time i worked on 29 30 27 18 just to make sure that i have a feel of how they look on the implementation side and that went very well and then i just waited for a bit more clarity on the final serialization format so it's about finishing in the testing but i'm pretty confident that you'll be fine because uh most of the berlin

items that were there before we have already had them covered implemented and tested uh with the consensus test so

it's 29 30 17 7 18 define implemented contested okay and open ethereum yeah we uh yesterday we merged 27-18 on our dev branch and we are mostly ready

Hudson Jameson: and then i think um what would be is there turbo geth here yeah yeah

um okay

Artem Vorotnikov: i guess i can take that uh we

have uh yolo v2 and e2929 from gf1921 we made a release yesterday so i think that's that

and was is was turbo geth planning on joining berlin i i don't remember they weren't planning on joining yolo v2 or yellow v3

Artem Vorotnikov: uh so we have merged uh what was in geth basically i'm not sure if anyone's tested it to be honest but perhaps we have that

okay um it's

then so most clients are on the tail end of finishing this the

last few changes based on the meeting the update that we just had from light client um is there so the holidays are coming up launching yolo v3 is that something we want to try to do in the next week or so or what's some general thoughts on that

Martin Holst Swende: i don't really see how that can be done

but i don't know i don't know i don't have a grasp of the time where i left work like the time left working for the last stuff plus the

holiday stuff's all going to be happening so

Hudson Jameson: yeah i would say let's kill the whole week of the 21st through 25th as any kind of work week because some people will be traveling if you're um able to and then um some some people will just be off for the holidays um and then of course around new year's probably that's not a way to do it um we could do it the week of new year's maybe if enough people are done like the 28th 29th kind of a thing

do we need i guess

Tim Beiko: we can just launch yellow v3 we don't need like a call or anything to do that like you know we can like if we don't

have the next call was supposed to be on christmas days it probably makes sense to skip that so you know if we keep working on the implementations now you know whenever they're ready they're ready um and i think you know we if if over the holidays or you know right after new year's or whatnot like people have bandwidth to set up the network then great and i guess worst case i i don't know is it realistic to expect that like the implementations of the eeps will be mostly done by like oh as it was like january 7th yeah january 8th would be the next call after this um and like if we're lucky that maybe we can set up you know v3

before then

the audio is super quiet your audio is a bit quiet uh adria yeah

Adrià Massanet: i think that we can just just adding clients it's up in a very relaxed way it's a test net so no worries

okay

Hudson Jameson: um and what we could do is let's have a date that we check in with all the clients on discord and then from there we can make other assumptions that might be better because

it sounds like we don't have a good like a consensus grasp on when things are going to get done across majority of clients how does that sound james just pick like we could pick a date like in late december to like check back in

yeah i was gonna say i can check in next week and then uh i'll check in on clients next week just to see how it's going and then

Hudson Jameson: uh the 28th would be good too because people will might still be out might be on the 28th but some people will be here at least

yeah so i'll check in next week and then on the

28th like okay or is next week the 28th what day

is today it's the 11th today so the 28th is in roughly a little less than three weeks yeah so like wednesday of next week and then the 28th like mid next week and then the 28th i'll check in again and if if usually geth is the one that's been launching these but if a client has time and wants to and they can't really just go for it and then people can join cool does that fit uh fit martin like if someone wanted to just roll it up would that be something they could do and then people joined sure

cool so i'll follow up next wednesday and then see if anybody's burning to lot launch and deploy and then that's good okay

Hudson Jameson: any comments or questions um about the topic of yellow v3 or berlin or anything that needs to be cleared up

Pooja Ranjan: just a quick reminder for the authors of proposals included in yellow v3 uh out of five four proposals are still in draft so we would like to see that in at least in review if not in last call and the fifth proposal eip2565 that is in

final uh that is in last call and i think the duration has has been over so the author might want to move it to final now

Hudson Jameson: yeah and if you do that uh contact me mike zoltu or light client to get that merged and we can help you with that uh other comments or anything okay next up we have other eips and discussion items tim had an update on eip 1559 and kind of a broader picture there i think

Tim Beiko: yeah um i won't try to summarize too

much of it here but we had another 1559 call last last week i believe um and the big i guess uh takeaway or new thing was um tim rufgarden who's a computer science and game theory professor from colombia uh released uh paper analyzing 1559 from an economic perspective and and trying to uh understand is it actually better than what we have today um i just shared the paper in the chat uh it's pretty extensive uh and the the ten takeaways are shared in the third page so if you don't want to skim the 60 page paper uh you can just read that um and overall the paper is pretty positive

about 1559 which was nice so just in terms of ux you know he makes it clear that a having the base fee as part of the network really helps kind of people converge on the optimal bids for their transactions um and that's a good thing um and that the incentives for miners uh to carry out uh the protocol as intended are the same under 1559 as under our current mechanism um the one i guess uh or sorry the two kind of more negative sections of the report uh was one around miners where he highlights that um today there's a lot of negative behavior we could see from miners on the network that would

theoretically be possible but that doesn't happen and we don't have like a good explanation for that aside from you know maybe the miners are eatholders or they care about their health of the network so they're somewhat altruistic um but he says you know that could potentially change under 1559 so if uh you know if for some reason miners decide to engage in behavior that today they could but don't take up that's a potential risk um and then the other uh this is a much more minor comment about it is uh the way that the update rule works in 1559 we increase or lower the base fee by up to 12 and a half percent uh if we have a full block

or empty block and it's just a linear increase in decrease based on on the gas used and he says that this is maybe not like the optimal way to do this um given that uh once you if you have a very quick increase you might then need to have a bunch of empty blocks to lower the base fee enough to reach uh the the price that people are willing to pay so it's not you know uh the end of the world but it's it's slightly inefficient um so we have someone who's looking into possibly just a better formula for that to have a smoother update um and yeah so i guess i just recommend anybody who kind of cares about 1559 and its impact on the network to

at least have a skim at the report it was quite good in terms of utter progress uh we've been working uh we've been working on the implementations a lot so there's a there's a draft pr against the geth code base that's that's up um the implementations still don't have eip2718 so none of them are kind of ready for um you know being merged in clients and master uh but they're they're interrupting together we have a small test net um so that's you know that's a good sign and we've kind of held off implementing 2718 until it was it was done in clients for berlin um and the i guess yeah the last outstanding thing on the client

side that we need to figure out is the transaction pool management so um because the base fee changes uh from block to block like the naive sorting of transactions uh in the transaction pool uh if you take a naive approach you can end up resorting the transaction pool every block and that's a pretty bad outcome uh so we're working to find some better heuristics about how we can efficiently manage transactions uh and the quilt team is helping out with that so i guess yeah at a very high level i suspect you know in another month or two we should have like most of these issues figured out that the implementations ironed out with 27.18 um then there'll be you know a bunch of

work there's a bunch of like auxiliary work like updating the json rpc specs and whatnot but the bulk i think of the 1559 implementation should be done um and one yeah sorry one last thing we're working on is uh large state test nets so because one of the concerns was how would clients on mainnet handle 1559 um one part of that is like the the what's the database has a pretty huge state it becomes harder to process it might become harder to process blocks that are twice as big so abdel from our team has put together a i've got a large state test net generator which can generate a new network with an arbitrary number of accounts and storage

slots in a contract so we're we're setting up a new testnet now with a hundred million accounts in a contract with a 100 million storage slots which is you know more or less uh with what we have on mainnet um and then once we have all the clients kind of running on that network we'll spam it with a bunch of 1559 transactions and see if the clients can handle the load for like you know half an hour an hour um which is the max upper bound of what you'd expect on mainnet and that's pretty much it

yeah

Hudson Jameson: anybody have comments or questions on this

Rai Sur: yeah i just wanted to get people's general opinions on what we're going to do

with are we going to introduce a new transaction type like 2930 that has the 1559 uh gas fields so it'd be like a different type or how are people envisioning those two interacting

Tim Beiko: as i understood it the plan was always yeah you create another 27-18 transaction i we we haven't defined it yet to be to be clear but i think that's generally what people want to do

okay other comments

the quilt team is the team that's that's

tackling account abstraction right now and the uh cat herders just did a peep and eat with them about account abstraction stuff so that's something else if you're wanting to look into what they're doing in approach it's like it's a good overview and they deep they did a deeper dive into like what are the transaction rules and things that make it that safer or they're trying to make it as a safer thing so core devs that are interested would be good to get him to get update on that

yeah

Pooja Ranjan: and the video will be released on monday on the characters or twitter

and youtube okay

Hudson Jameson: uh anybody else

and do we have any other um agenda items or things that we missed out on or that people want to talk about before we jump off the call

so i have a little if i can have a couple of minutes yeah go ahead um yeah some guest

Martin Holst Swende: updates so we today released what's hopefully the last of the 1.9 versions and the big stuff for us going forward is going to be these the next release which we're gonna launch the ability to do snap sync um but what i wanted to mention really is the security process we have now started to include to publish our advisors by

github and that means so to github people and other like node operators and downstream projects can subscribe to the event feed and get notifications and we're also pleasantly surprised by how easy it is to to get cbe assignments for vulnerabilities through the github flow so i can recommend that we also publish vulnerabilities.json uh through our github pages and downloads page will be basically the same place and the new gut version can actually can do a version check

so it fetches the latest vulnerability info and checks it against itself so a user can optionally do these kinds of version checks and see if there are any security related vulnerabilities that they need to update and this vulnerability.json file was inspired by what's already present in solidity the format they use where they also include a regex for the vulnerability for the well how to detect the vulnerability if it's present so we did that as well and this means that we could also use it on the fork monitor so if you go to to forkman.dsdevops.i

right now you will see uh a couple of warnings for like the inferior and alchemy nodes and things like that and when you click it it will show the information which is best from the vulnerability info uh and what i kind of wanted to highlight here is that if any other clients decide to have a similar kind of vulnerability release where they also publish a regex for checking it against the reported node version then we can integrate that as well in the fourth one um and make it generally easier for these kinds of well for

everyone to check their security posture uh so if you do start work with something like this and implement it please let me know and i'll add it to the portfolio monitor

yeah that was about it yeah

Hudson Jameson: i just posted a link to the fork mon in um chat and yeah it's really cool everyone go check it out and uh congrats on the update martin and the geth team really cool

yeah

Tim Beiko: this is really cool um where is the json file in is it in the code base

Martin Holst Swende: yes and no because it lives on the github pages branch

oh so there's a gift underscore and then there's also vulnerabilities.json.minisig which we use to verify the signature of it

got it okay nice thanks

Hudson Jameson: today i learned it looks like cloudflare rolls their own geth is that right when it says cloudflare geth martin yes yes cool okay uh anybody else have comments or anything else for the meeting

Pooja Ranjan: yeah i may have a kind of quick announcement regarding uh one five five nine um we are going to arrange the categories are

going to arrange another peep in each session for eip155 that is scheduled on tuesday uh the if people are interested to know about it and have questions the zoom link will be published on the all core dev discord and now that we are moving ahead with uh berlin and i know there are some proposals which are already ready and that would be seen in future upgrades cathedrals are collecting feedback from projects and other infrastructure providers on their thoughts on the network upgrade i'm sharing the link in the chat so we already have reached out to miners and people we know and we have contacts for but if any

project they would like to leave their feedback about the network upgrade the frequency and what could be done to make it better here's a link and we would appreciate your answers to that

oh

Hudson Jameson: i'm on mute um uh thanks for that puja what time is that on monday

Pooja Ranjan: actually it's on tuesday it's

1 30 p.m et time okay east yeah 1 30 eastern sounds good

Hudson Jameson: um anybody else have comments or things they want to talk about i know like client mentioned in chat

maybe discussing what comes next after berlin i don't know if anyone had thoughts on that i said in the chat that i kind of assumed that today people didn't wouldn't have that much on thinking about the order or anything like that but if anyone does feel free to speak up or anything okay sorry um all right if that's the if that's all then i guess we could have a shorter meeting today uh congrats to the eth2 team um they launched uh since our last meeting uh the beacon chain uh so i guess we'll just congratulate danny

and just say that he is representing the eth2 team today on here um hooray on that um and yeah that's about it um thanks everybody the next meeting will be on january 8th at 1400 utc and uh happy holidays everyone

have a great rest of your week and uh holidays coming up holidays happy [Music] cheers

[Music] [Music] [Music]

[Music] [Music] [Applause]

[Music] so

you

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