All Core Devs - Execution #105

Transcript

[Music] [Music] so

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

[Music] [Music]

[Music] [Music]

Hudson Jameson: hello everyone and welcome to ethereum core developer meeting number 105 i'm your host hudson and today we're going to start off with yolo v3

and berlin client updates so um i think yellow v3 launched but let's get the latest from james

James Hancock: it did launch i saw messages from basu and geth popping around was everyone any updates on that or on status for syncing for the clients

Tomasz Stańczak: so we just started syncing at another mind we went to the some of the first blocks with transactions and now i'm fixing some of the decoders so i should have it sinking very soon because all the apes are there it's just

the serialization things for the network

site we okay

Dragan Rakita: we start from the beginning and yeah that seems fine

and that's uh open ethereum yeah and then cases in sync space is in sync well

James Hancock: that's great so that went up last friday and so now we're while that's sting sinking my mike asked a question is bay suit production ready

Martin Holst Swende: just like to uh make a note though

oh yeah i mean there's been some transactions in the beginning but i'm not sure if there's actually been any um yeah any transaction load to speak of uh so it's really nice that the clients are thinking but i suspect that we don't really have a lot of coverage from it aside from the basic kind of base coverage

James Hancock: and then is it at a point the fuzz testing work can kind of start

Martin Holst Swende: yes it's at that point but it has not really started

okay

James Hancock: um i mean that's good the four updates

from yolo that's good so upcoming art is doing actual using it for testing and then also doing fuzz testing for testing the clients are all syncing um uh we talked a little bit in awkwardness this morning for those who aren't there about possibility of timing for what's next um meaning scheduling test net fork blocks the mainnet fork blocks and i don't want to like really rush into it but i wanted to open up the conversation so we could start getting an idea of getting some of these things out and

about for the for the network

i just opened up something that's is that me uh i can still hear you is that what you're asking i need to rejoin really quick okay sounds good

Hudson Jameson: while that's happening we can continue with um the conversation um so basically yeah we're going to just discuss some of the timing for the fork blocks on test net and mainnet um it looks like this morning a few clients chimed in and specifically we were looking like

um test net fork blocks potentially first week of march and the main net last week of march as something we threw out there do people have any initial thoughts on that and i can just repeat what martin said in chat that if the last week of march was the aim for mainnet i'd rather do the test that's even earlier i'd rather rush and bork a test then have two shorter tests net time and bork mainnet good point

Micah Zoltu: what's different between yolo v3 and

berlin testnet

Martin Holst Swende: only the transaction i mean the load

or did i misunderstand the question

Micah Zoltu: i think that answers it yeah we don't have any intentions of changing anything or adding anything or moving anything right no no

yeah that's that's for sure um okay let's see oh james are you back yep

James Hancock: i'm back but you asked what i was gonna ask so that we can just keep going

Hudson Jameson: cool and you've got some blocks for the midweek first week of march but if we were to do it earlier that would be what last week of february then

Tim Beiko: i guess maybe it makes more sense to go

the opposite approach like how much time do people think we need to just send out a release for test nets i'm just concerned like if we say it's like the last week of february you know like is that enough because we still need to every client will need to ship a release with the blocks set in them and then every you know user needs to adopt those um so i i i don't know what's like the right kind of amount of time we need for that first step and then however much time we want to see to see it on test nets before it goes on main net um yeah so i'm curious what people's thoughts are on that

Martin Holst Swende: peter didn't you once publish the

suggestion on these runtimes for the networks

what what

Péter Szilágyi: what did i publish

didn't you publish at some point

Martin Holst Swende: like the stepping stones towards rolling out the hard fork in like some devops classification this is how we should do it

Péter Szilágyi: yeah but we never actually follow that yeah so yeah my only suggestion was that's uh that's different from uh from the current approach was that we could as an initial step we could shadow for crops then or something essentially just uh create a private network that is attached to robson and

then just place all the network connect i mean all the transactions from roxanne just it's mining its own old site chain side fork and then the idea would be that that way at least we would have some transaction throughput that some actual use case an actual test load before actually working roxanne potentially but kind of that was my mostly my idea on how to do things

Tim Beiko: um it feels like we might get we might already be doing some of that with the yellow networks right it's not exactly the same thing

but it's

yeah we're missing out the transactions

Péter Szilágyi: essentially with yellow is just mining empty blocks so it's not really testing anything currently

Tim Beiko: oh yeah yeah but i mean the previous versions where we did we did send transactions on them right well yeah but those aren't really live transactions

so okay got it yeah yeah

Péter Szilágyi: the problem is that these are kind of some synthetic transactions that somebody dreamed of but they aren't really stress testing anybody maybe just running some yeah so essentially it's just some synthetic thing the only true test comes when when you start like running live transactions

and at that point if you for crosstalk and then realize that there's something wrong then that means robson needs to be rewound or something or unforked versus if you were to create one of these shadow forks and at least uh if it goes to pieces then robson didn't so it doesn't damage roxton but we don't really have the infrastructure ready to to bridge the two networks and just the transition send transactions across them so i i don't think it would be too hard to pull off but uh it won't be it's it probably requires

some minimal effort and somebody would have to do that

James Hancock: would that be something other than you guys could do

well

Péter Szilágyi: i mean probably any client do they just you know you just need to make a custom client that attaches to two networks

James Hancock: yeah which is we're already doing that for

robston

Micah Zoltu: i think this is similar to what we talked to previously about uh having a fork test net of maintenance testing against real estate load and you basically need to just fork off mainnet have a eip or something like it that on the fork block decreases difficulty by you know many orders of magnitude

and maybe change the chain id and in fact in this case it only don't think you want change chain id i think you want the chain id to be the same um so that way you replay transactions from mainnet on this shadow network so you can play or robson or whatever you're forking so you can get real transactions like the real mainnet transactions would be playing on this shadow chain which is just running a slightly different rule set the berlin rule set in this case

Péter Szilágyi: so come to think of it probably what you could do is uh essentially just launch a private network with a different network id that should be so essentially just robston genesis with a custom network id so that would ensure that clients who want to join in on this hacky network

they are separated off from from the live network and at the networking layer because that's kind of important so that we don't start screwing with each other synchronization and whatnot and if you can get that done then what you only need is one single load that is uh relaying transactions and um yeah i mean that we could probably hack that together just to have a have a node running on drops and then just somehow stream it across to another node not running or off so maybe just for every transaction that appears on rust and just call a send transaction on the other side so that's probably fairly easily hackable

together if we want to do that

Micah Zoltu: and that can be done by someone other than a client of that would require i mean sorry i mean the ease on the signatures [Music] sorry i mean the forwarding of the transaction so you wouldn't change the chain id you'd only change the network id so the network id would be different so on different networks but the chain id is the same so that way all the transaction can be replayed

Danno Ferrin: but clients are set up to reject transactions that don't match the chain id

about the chain right so the chain chain ids match for robson and shadow robson network ids do not match for robson and general

James Hancock: in general that sounds like a better

direction to go to is that something we could do in the next like in the next two weeks is have that be done and then look at forking robson the week after that

Martin Holst Swende: so i think i think doing doing this it might work pretty well but it will be kind of flaky since since probably uh some transactions would fail that succeed on robston which will affect the state and these state changes will kind of uh snowballed and eventually nothing would kind of work

is there

Tim Beiko: is there a way we could test

something like this i don't even if it was not for berlin like as as kind of the equivalent of the yolo networks on on on you know the next time around so instead of launching empty networks we basically launch shadow shadow forks um because i i don't know it just feels like it might work in two weeks if like everything goes right the first time but given we've never done this i i can see a pretty likely scenario where like it just doesn't work like we expected and uh it ends up taking much longer and and i'm wondering if yeah instead of maybe doing these yellow networks next time around

something like this might be more helpful

Péter Szilágyi: well i guess the thing is that um but martin also mentioned that probably the networks would eventually diverge simply because you have a different miner and some transactions would get included in different order and that kind of means that if we create one of these shadow forks then fairly quick so i don't know how how fast but eventually the networks will be so much diverse that the shadow fork would just be reverting transactions because it would have just a different state and all the transactions would be doing stupid things

Micah Zoltu: that's my hunch my idea i i think the hunch is correct i don't

know i also don't know on the how long that will take but i think is if we can make the process of creating a shadow fork easy enough then you know we just run it for two weeks or a week or however long it takes to kind of diverge sufficiently and just reset so basically it's reset to the head of rosten redo the whole thing and if you're back on track and you're back to syncs basically

yep

Péter Szilágyi: that could be done the only annoying part is doing the initial sync so synchronizing grupsten or even girly starts to have weight so uh if you have to reset every two weeks it gets

in the wink oh yeah it's

Micah Zoltu: definitely much easier for

people or teams who already have like roxton running because you can just copy the whole folder basically or your whole database and then just change network id and move on um it's much harder if you're not syncing rosten already for any reason

James Hancock: it would be nice if we could if the next yo look at all her life is so is the problem that currently yolo is great for testing clients but it isn't great for testing what's actually happens with data um so the shadow forking robston is would be able to test like real-life data so is there something we could do to yolo that would then also have that by thinking in

advance like thinking forward is there something we could do yolo that would have that same property no no so it would need to be either one of those two of like not doing yolo or something else or any keep going you're going to say something

now also the

Péter Szilágyi: the issue here is that you need um that all the all the networks even the test network but especially not it's constantly evolving and the transactions are constantly changing and even if we somehow try to build some um some pool of transactions to test things with uh probably it will get outdated fairly quickly

so that's why i think that usually just lashing onto a live network it's always it will always get you the juiciest stuff so we've i think there was a time when um i'm not entirely sure which hard fork was it but there was a hard fork where everything went uh perfectly for austin and then when we forked mainnet it blew up fairly quickly and i i don't remember which one or maybe maybe we realized that it would blow up and it never did blow up but there was some issue that even in the past where some fork wasn't properly tested by not even robsten so that's why we're kind of reluctant that yolo is is kind of cute just to test out these synthetic tests for example tests

that are included at the eyepiece just to make sure everybody seems to handle the forks okay but the real test starts with the with the test nets which we previously broke we can try not to break

it

James Hancock: so doing the shadow fork would make it less likely that we break

robsten

Péter Szilágyi: well it would be one more data point that things seem

okay

James Hancock: yeah yeah it would be conclusive so is it worth um trying to hack together the shadow fork thing this time or just moving forward with doing a block on

robston and saying okay let's go

i think that's if go ahead make it micah i can say

Micah Zoltu: if the client teams think they have the bandwidth for it i would say it is worth it to do it sooner rather than later because i think the same technique can be applied to shadow 14 mainnet and being able to test real mainnet state real mainnet transactions even if it gets out of sync in a week that is hugely valuable for reducing risk for uh final launch um so i think this general avenue of testing gives us massive gains in my opinion in terms of real world testing that we're never going to get from rosten or coffin or girly or any yolo network like we're not going to be able to achieve that so i think this

is a path that we should try to do and the sooner we can do that the better because risk mitigation is good but that being said i'm not a client i don't know if you guys have the bandwidth to actually do that in parallel with the current plan

or not i think martin you had a comment

Martin Holst Swende: yeah i mean i i agree with with the assessment that if we have bandwidth it would definitely be preferable but then i also think that maybe we should just yeah

yeah i'm usually not very careful about the test steps and i think we should use them for testing and if they work so be it so i would prefer we just go ahead with the testing but that's just i i can see that other people may think otherwise

Péter Szilágyi: well just to give you an example of why i think it's problematic is because for example um currently i'm not entirely sure whether the project is selected or not but reddit was doing their pilot project of this community token whatever they called it on on paparika

and essentially this means that reddit was actually running production to systems even if just by the project but production pilot projects on winkerby which i think is somewhat forcing or pushing the limits of rinkaby yet i kind of think it's somewhat still within the realm of acceptable use

Hudson Jameson: even if it wasn't if they're using test nets more than test nets we can't really stop people from doing that they're going to do it

well yeah

Péter Szilágyi: of course so if somebody's running some full production thing and we accidentally break it then i won't

have sleepless nights but uh that doesn't mean we shouldn't threat carefully so that we don't break it too too easily

Hudson Jameson: yeah i think that it'd be good if we try the new shadow fork approach and then push the test net fork block one week out from the last week of february date so it's the first week of uh march yeah first week of march for test net fork shadow fork one to two weeks before that when it gets done is how i think it would be pretty cool unless would we be able to get that done in the next um two weeks

James Hancock: if it's something we had the bandwidth for for doing by the next call then i'm like oh it might be a good idea otherwise i'd say it's worth doing it for the next like realizing that this is a model we should implement for the next fork and like build that into the process

Péter Szilágyi: my guess is that we could hack something together here the the catch is that uh if you want to shadow fork robston or mainnet then we need a special fork flag to be able to nuke the difficulty out obviously because if we shadow fork may not uh we don't want to have

a mining tool behind it so that's uh that's an extra feature so besides changing the network id and somebody implementing a bridge we also need all clients to support this nuking of the difficulty and if you want to shadow fork rinka bienger or girly then again we need a special flag in the clients to forcefully replace the authorized signers

and

Tim Beiko: i feel like that will take much more than two weeks like it'll take you know maybe it's easy to implement but we need to test that the different clients do it right together

Péter Szilágyi: yeah so so robson and maynard is probably easier because changing the essentially is just

an extra four crew which just drops the difficulty but uh the wrinkabi and girly nuts that might be a bit interesting because you have voting sorry sorry for the background so you have a some problem with the with the votes across this

uh threshold

James Hancock: would it would it be okay i'm like i'm envisioning the coordination of getting all the clients on to this would kind of be hard but if we had just even one client or so go through the process so that we could set up the process for all the clients to join next time is that still valuable

Micah Zoltu: i think so i was able to say the exact same thing there is any of the clients feel like they have lots of breathing room compared to the others i think maybe it's the real question out there they're like man i really wish i had more work to do or maybe like it sound would that be

James Hancock: um so if like the guest team would want to do that would someone else want to join them on that or would it be

okay

Martin Holst Swende: for me personally i would rather spend the next couple of weeks on

and then setting up this actually

Hudson Jameson: yeah and i'm not hearing a lot of um other clients talk about their love for the idea i guess

yeah

James Hancock: so if someone wants to do it then they should speak about they should speak up now otherwise i'd say we should move forward with the for robston and then realize that this is the better thing we should do next time

Dragan Rakita: then be quiet i think idea idea is good but we don't know about how much time we will need to

properly do it there is a lot to know as for mother but burning is something that we pushed a lot maybe it's better to leave a shadow fork for the next

heart for the games comes okay i mean that sounds good to me personally yep

Tim Beiko: so i guess then we're back to the original question like what's the timeline we want to what's the delay we want to give people to have a fork block on test nuts you know what's like an acceptable delay and this is what like i guess first week

of march is what was originally proposed uh and i don't know i i thought like four weeks gives all of the client teams one or two weeks to ship a release which has a block and then it gives you know two to three weeks for everybody to upgrade the people feel like we should do quicker or slower than that or is that generally fine and then we can set i think it's fine to set the main net block you know if we want to have four weeks or six weeks of test nets we can just set the mainnet block farther in the future and it's not like we're going to be blocked by working by of working on anything else in the meantime right like the test net is just going to go along we'll see it happen um those issues will fix them

but i think yeah i i'm just a bit cautious of like us also breaking the test nets if we set a block that's like in two weeks and then half the people have it upgraded

um yeah

Tomasz Stańczak: from our perspective it's fine to rush it a

bit more so um rather rushed so what did would rushing mean that we do the reason but not to mean that

Tomasz Stańczak: so if you if you want to push for february then

we are totally fine with

that

Hudson Jameson: yeah there's i i'm feeling like there's more value in having more testing time rather than waiting while worrying about the risk of a borked test net or that people don't get on fast enough because yeah i i think there's more value and more testing time as i'm feeling like

James Hancock: so could the could all the clients be ready to fork robston and all the other ones in two weeks so like next court of calls we have all the releases ready so then we could have it be the middle of the week after that

yeah yeah should be fine yeah all right

Tim Beiko: so we're aiming for like the 24th would be like the say it's like midweek it would be feb 24th is when we'd want to target the fork block for the various test nets right that sounds good to me cool and i guess we can hash out the specific blocks async on the chat uh find some nice blocks on every network yes that sounds good yeah and do we want to so i guess do we want the release to also have the main net

locks um the main net block in it uh and if so it would be helpful to just have like a tentative date for which we can also find a block

um the block 12 121 um what number is that 12 million 111 000 is wednesday march 24th

Tim Beiko: so that would give us a month a full month literally day for day of

test net being live yes one question if we bork the test nets how the client users we're going to go to the older

version it would be more safe to to have two versions of the clients one with blocks with testnet another one with blocks with a minute i'm not sure how into his how in the past this is done but i agree that's not yeah if you have problem with testnet it will propagate then someone else had something was it

was it mica or yeah

Micah Zoltu: i was just saying that this is a decision each client can make individually um if we have a 10-foot day before maintenance a client can decide whether to release that in their production clients or not it sounds like people don't want to but we don't need consensus

James Hancock: yeah we can we can wait on the on them if we do the forum the 20 what was the date we just said the 24th the 24th then last week of march is pretty realistic we don't need to really set a up for block date now uh with that as like a target makes sense

Tim Beiko: so that's well i guess it's yeah it's then a question like how how early in advance do you want to have the

releases out with the with the block because i know you know there's a lot of folks we talked to that would rather not like upgrade their mainnet for client you know a week before the fork um so that's just the kind of the only thing to consider because there's not only just the consensus changes that go into the clients you know there's all the other updates um and so having a version that they're somewhat that they've run for a few weeks to know that there's not like another issue is is important um so you know it's not like the end of the world but i think we we it's a bit unrealistic to say you know we fork the test nets on the 24th of february then on the next

call two weeks later or whatever we decide the main net block and then we expect everybody to be ready for our brain network two weeks after that

um yeah i

James Hancock: uh if we did the main net walk in two weeks is that still

Tim Beiko: yeah i think that's definitely better yeah and it's fine then if it's two different versions of the clients or one like micah said you know different teams can make the trade off there um but yeah if i think two weeks from now is fine but like four weeks from now is probably cutting it very close if we want to uh to have a release and have people have enough time to actually update

cool

James Hancock: so then that would that just

summarizing for no taker and the rest of the call on the we would have clients be re clients be ready next all courtes call for of um a fork of the test that's and then the 24th we we would choose a block for the 24th and we'd also choose a mainnet block that day and then clients could decide accordingly how they

handle that

Hudson Jameson: that sounds good to me

Tim Beiko: yeah so we should choose the testnet blocks before the next call though right like we know it's feb 24th we can choose the blocks you know basically today on the chat but then on the next call we can choose the

mainnet block

yes

Hudson Jameson: unless clients want to bundle both into one release but does anyone want to do that or like or i should put it this way unless does anyone need the the block number before the dates we just proposed yeah i didn't i didn't think so i was just going to check

cool

James Hancock: then i'd say that's good for now uh on that and we can move on to the other things unless someone has last thoughts on it or wants to share i'd say we've taken a good amount of time today

hudson back to you okay

Hudson Jameson: thanks so much

um all right finalizing the e-66 uh network specification um that was discussed a little bit in chat and it looks like some clients had opinions on when to find when to finalize it i think i was getting out or can someone summarize the discussion

yes

Martin Holst Swende: so e66 add request ids two messages need 65 not all of them because there are also things like announcements which do not request at least but all the things which are on form request reply and of those messages all of them except

one are currently you make a request and the response is a list of things but one is a bit special and it's to get block headers which there's a request which has four or five parameters um and the current specification adds a wrapping so that all the new messages are uh rlp encoded as a request id and then a wrapping of the previous format and the observation was made by peter that we don't actually have

i mean for the things which are just the list we we do have to kind of do this wrapping but for this get block headers it would be nice to just add the request id alongside or before the other existing fields um yeah because the reasoning being that it was lower on network traffic a bit smaller and that's kind of the discussion

Danno Ferrin: so my concern is i think we're over fitting for a little bit of um network traffic overhead the pattern of

them of the what the eip came in initially was you take the 865 packet and you wrap it in a list which is being done with all the other lists and for that one packet there it's an overhead of like one or two by one or three bites at most the impact comes into the client implementations if you're streaming from the rlp data you'll be fine because you just read if you're in 66 you just read the header and then read the rest but i see that there's other clients that do an index based read of that particular packet and they're going to have to write significant fork code for that to read the package twice in two different ways so from a from a design perspective keeping it consistent is good

and it's also going to have more of an less of an impact on the client code if we keep it as specified so that's the author has a preference for this i have a preference for this it's not a hill i'm going to die on but i really i don't see the need to to make a special case for one packet

Martin Holst Swende: right yeah let me just add to that actually so for for go there and we don't have this streaming thingy and the original implementation of the spec was slightly cleaner and the implementation where we have to uh marshal it so unmarshally differently is actually slightly uglier because we have to create a new type of message and

marshall into instead um so it did it i mean we didn't go this uh we didn't don't prefer the smaller network classes because it's particularly nice for our client but we yeah i thought it was worth it anyway but i think peter you're the you're the like main proponent for the do you want to speak on it

sure

Péter Szilágyi: so my main issue is that it seems we're kind of designing the spec backwards so we just look at how clients implement certain things and then we make a network protocol that tries to adhere to the existing code as much as

possible and my biggest problem is that that is a very slippery slope on the long term because then it means that instead of having clean network protocols our natural protocols will be full of interesting quirks just because at some point or another there was one client that implemented it this way or that way so from that perspective we want to add so currently the eth packet i mean we have a bunch of requests and for example there was a time when we wanted to add a new field to the handshake that was the fork id and that was just simply added as an extra field and so my question is that if we just added it as an extra field

there and now we want the request id why is the request id more special and why should all of a sudden we add extra wrapping just because so if the fork id didn't require wrapping then adding the request id seams i mean it just seems that we're not catering for implementation instead of

Artem Vorotnikov: um actually it is much cleaner code to add request id as like a separate field and like the rest of the contents of the packet as a separate list because like i'm just imagining this in rust terms it is much much easier to get much much

easier to implement because i can make like a wrapper structure uh with two fields with like request id and some generic request basically so this just the separate separating request ids out of the general list it is it leads to a much cleaner implementation and um i think that that should be the way forward

Péter Szilágyi: but why would you want to really separate them implantation wise the request study from everything else

Artem Vorotnikov: uh like i said because it is simply much cleaner code

but if the code that processes the request will require the request id either way then what did you save by adding an

extra wrapper it's enveloping and

Danno Ferrin: separation of concerns when you're matching up packets that separate code from processing a specific packet so if we unwrap the envelope we have the list of whatever we don't care about and the request id and we match it up with existing incoming upcoming packets that has nothing to do with whether requesting hash ids ranges on transactions to process that map that up path that further down and we isolate it this is sort of enveloping that's seen in other protocols the concern of what the map of the request id matching up or not is is disconnected from what the actual content of the packet is now about fork idy different work id was put at the end of the list not at the beginning of the

list so if the request was to put that at the end of the list there would be less resistance for me but putting at the beginning of the list doesn't match existing patterns when we provide what our packets look like

Péter Szilágyi: so yeah uh my only the only defense i can say is that the death peer-to-peer and these theme protocols do not have a notion of headers or or non-header fields that would for example that http or all the other protocols explicit layouts that you have the metadata fields in the headers and then you have the content there's no such notion of that peer-to-peer and essentially this debate is introducing it but we are not really naming it a header

but kind of treating it as a header so it just seems weird making a design decision on being unaware of it

either way it's easier when you have separated request id and rest of package because if you want to check rest id you will check it in the first layer of your application and just send the rest of your package to the person yeah but this is exactly easier is the data set it's not it's fine i wouldn't say i would basically model my my code to handle both cases but it's a little bit easier to have wrapper on every package

[Music]

Péter Szilágyi: that this is exactly my problem that none of us are approaching this that what does it make sense how does it make sense for this network packet to look like what we are approaching it from the direction of hey i have i would implement it like this so let's make the network packet easiest to him to process or to consume with the code i would write it with and that's not necessarily a bad idea to keep that in mind but i'm not a fan of designing with implantation in mind or i don't know

maybe i'm wrong here so

so i started out on the side of most of you guys here and i was convinced by one particular argument that i think peter or martin made which is that by the time you get down to the request id you've already narrowed what you're going to handle down to exactly one packet that is to say the the actual header is higher up the stack like you've you get you get in a payload off the wire and you find out what the message type is and but once you read that message you know the exact thing you're going to do serialize that into there's no more like like these are not actually like packets that go together like they're coming

through like one funnel these are already dispatched like you've already dispatched them to their final destination there's no more like okay i've got four different packets coming in through a channel that's you know i now need to dispatch you've already dispatched them by the time you destroy it by the time you hit that request id and so for me that was the convincing thing is that it's just the key there is that you've already dispatched this down to a single handler like you do not have multiple handlers at this point anymore in the code um if the request id was higher up the stack like before the message type then i would 100 agree with everybody else here that we should be you know having you know an envelope type thing where you have the message the request id

and then some arbitrary payload but that's what we have we have a message type and then arbitrary payload and the message type to arbitrary payload is a one-to-one mapping there's not one domain yeah

Martin Holst Swende: i think that's a pretty good observation and i think we've heard from all the client devs except another mind do you guys have any thoughts or opinion

Tomasz Stańczak: i'm quite up and i was looking at the request like these approaches changes various changes everything seems to be all right and i'm okay for you to design this one

okay

Hudson Jameson: uh what other opinions are there on

this because i'm i guess i'm i think are there two concerns right now i'm i'm a little lost

Martin Holst Swende: i mean no well i mean it's just a decision that needs to be made i think no one is ready to die on any hill um yes we're for one approach it sounds like open ethereum and visual for another another mind what seems okay with either i think that does that sum it up

Hudson Jameson: yeah does anyone disagree with that one or with martin's assessment all right this is when we put pull out

our coin and flip it um no i'm just kidding we're not gonna flip a coin to decide this

um hmm there's

James Hancock: someone from like network design philosophy we could ask or like reach out to

[Music] let's try

Martin Holst Swende: to decide something here and now so we can just ship it

Hudson Jameson: yeah it's an implementation issue more than any kind of network design issue right or like per per client implementation

how they've implemented in the past

Micah Zoltu: i think that's exactly the debate is this an implementation question or is this a design question

but that's a problem it is a network design question not an implementation question

Hudson Jameson: i guess i meant because of how people have designed it and their client implementations before it's turned into that is that not true

Micah Zoltu: i think it's more how people have designed it in their heads so oh okay once the people has a mental model that is x and another people has a mental model that is why and those two mental models have different desires because uh in order to change jump sides you have to change

your mental model to match the other side and so that requires of course much harder to do so neither neither side of course wants to change your mental model because now thinking becomes harder

yeah

James Hancock: and your reference micah was the other one like if you were to have one i just read that like client said he preferred the proposal

peter's specific so i originally yeah

Micah Zoltu: i originally was against peter um and then i was convinced by the whole one-to-one mapping that occurs higher up the stack so this is not a one-to-many mapping which like the the current wave the idea is written makes it look like it's a sort of dynamic dispatch situation or um one of the many mapping but in reality if you look at the

broader protocol it's not actually and so that that again that was what convinced me

i don't know

Danno Ferrin: then are we putting this in the wrong place with the payload should it be up with the message

id then

Micah Zoltu: so we talked about this and the feeling i got from the conversation was that everybody kind of wishes that it was more like that but that's a much bigger change

Péter Szilágyi: correctness that's the correct answer what were you saying peter so i i mentioned uh we had this uh discussion on the all correct channel team that you cannot really move it higher up the

stack because uh so the the naive uh idea or i wouldn't call it naive because that was also my first impression the first impression idea would be that hey we can just move it up into the death peer-to-peer stack and then problem solved the request ids are handled at the higher level or deeper level however you prefer it by that peer-to-peer itself the problem is that then you end up with a really really bad kind of forms because on one side um request ids work well for request reply patterns but you also have network packets which do not follow request reply patterns for example transaction propagations those are just one unit

you need directional packets so you don't have request ids and the other thing is that if you essentially the whole point of request ids is that you make a request and then when a reply comes you can funnel it back to the original piece of code that made that request but that also means that you need this multiplexer the multiplexer to constantly track all the currently active requests now if you move this request tracking up into defeating here it means that you have some deep layer tracking mechanism which needs to be aware that hey this sub this program module is waiting for reply

but what happens if the reply never arrives then all of a sudden deaf people needs to start caring about cancellations and timeouts and and whatnots and that's why i'm saying that that is a huge can of worms to dump onto the

death beauty pierce that so we're back to having the implementation drive the actual details

Martin Holst Swende: yeah um in that case unless anyone has changed their mind i would consider this being i mean that we let the specifications stand as is

and not change the thing that we agreed upon back in the day how does that sound to you peter

[Music] [Music] this is the ng i i have always ever seen you that maybe miss click sorry no problem um okay so what do

Hudson Jameson: the other clients think about um martin's proposal is that something people can live with

is that something that people want to try to find other ways to um come to a conclusion or

veto no i know uh so the proposal is eve 2481 as it is on eb's ethereum orc right now yes yeah what

Martin Holst Swende: i'm saying is that we propose to make a change and we're getting some pushback and i guess we'll consider that proposal to change it and not accept it and yeah so

okay and that goes

the current uh the

current looks good to me i say we should take it and implement it

Danno Ferrin: agreed i could take anyway as long as there's a firm decision on it

okay and peter where are you saying something peter's change

James Hancock: so that's not dude not accepting peter's proposed changes

Péter Szilágyi: yeah i can't do that okay now so actually so what i was saying is that essentially this whole e protocols are not set in stone and if you want to evolve them in the future if it turns out that this was a bad

decision we can always go back and just

look them up so

Hudson Jameson: oh that's nice then cool all right i think we've come to a decision on that uh for the note taker um let me say the decision and then someone correct me when i'm wrong um we are going with eep2481 as it is written today without any modifications to the pr

Péter Szilágyi: i have one slight request for modification the eip mentions that this protocol spec is consistent with the request reply pairs in lds and that statement is not entirely true because les has some different methods

and all in all my suggestion would be not to refer to alias when saying i mean in the discussion and rational session sure but when specking it out the spec should not refer to other specs because then the whole thing is cleaner so let's just drop that single line

and i'm happy

Martin Holst Swende: yeah also i mean i have an open pr to modify the the spec and i'll change that vr so it doesn't change the spec but just as a test case

just a bit of clarification

Hudson Jameson: does that sound good to everyone is there anyone opposed to dropping that line and um maybe martin cleaning it up a bit but having the same

uh content

Artem Vorotnikov: i don't think it needs to be discussed really let's just move on

Hudson Jameson: sounds good all right uh what we got next is evm 384 update that'd be axic i i'm guessing

oh um actually

can maybe do a better job than me i put the post um up so maybe i was prepared to give the update so maybe i should but if exec wants to give it he can give it uh either one great um i will give it uh the i'm giving an evm384 update uh i will talk about our gas cost uh

document and then an research post that i'm trying to bring attention to uh recall evm3d4 proposes three new app codes which cover bottlenecks of a large class of crypto uh and it'll allow user deployed fast crypto systems the word fast means if we remove the the overhead of the system uh namely the interpreter loop and things like this uh we would approach speed records uh implementations but we do have some overhead from the system and things like that so we're doing the best by fast i mean we're doing the best we can given the system and there are ways to improve the system itself so there's potential so first i will

talk about the gas cost updates uh jointly authored by pavox casey gerard and uh in case you haven't read it i'll just hit the main points uh i won't go into too much detail by the way the links uh are in the issues for this meeting um so we gave a background gas has some inherent limitations gas is attackable um so these sort of play into our design decisions uh for example that we want uh simple constant gas costs uh we propose uh two gas cost models oh by the way the gas cost model is a systemic way to assign gas costs to an app code

there's a model which has some machinery maybe includes some heuristics security analysis and uh in the end there's some maybe systematic way to to derive the gas cost for a given up code and our proposed costs for evm384 app codes which are admob 384 submit three or more month 384 are we have two models the aggressive model costs are one one three respectively and the conservative model gives costs two to six respectively for those three outposts um so based on these these proposed costs based on these models uh we do did experiments uh just to see

what they mean in practice uh so we applied these gas costs to metering heavy cryptography but they are a baseline implementation by baseline i mean non-optimized and the design decision is if it if this optimization brings too much complexity don't do it so we noticed bottlenecks in our experiments and uh for example the implementation optimizations that i mentioned but also some op codes are used very much and they become one of the bottlenecks for example push and dupe as well but in particular push though i'll talk about some ways we can get around those bottlenecks uh also note very notable is memory

manipulation uh mem copies uh we copy buffers from one place to another we do it naively with m load m store there are other ways we can do it so there are there are ways to fix these optimizat these these bottlenecks for example an m cap an a new app code called m copy bulk would save us you know thousands or tens of thousands of gas maybe uh another a new upload maybe i'm just giving some examples you can read details inverse mod 384 would be a candidate for a new op code because there are three app codes plus minus times and inverse mod sort of corresponds with division so maybe there would be some it would be sort of justified and nice because we have we have before

operations um but i'm not convinced we need it yet uh so so but but these there are many options there are more sort of aggressive options uh to remove these bottlenecks uh one of the main ones is repricing now there are simple repricings and more more involved repricings the involved ones will require of course you know a model many benchmarks arguments security analysis but the the major repricings would benefit everyone a lot even the minor repricings that are not controversial will will benefit people and there are other things we can do including major changes uh but these are more sort of significant and risky

and on the consensus layer and we're not dependent on these changes but but we'll we are exploring them uh two i'll name two of them one is using immediates right now the only output with immediates is are the push cap codes uh and if we had immediates to the evm 384 app codes we would remove the overhead uh for setting up the the i guess execution contacts of of each app code um but this could require uh this could break some old contracts that were implemented naively but they were still implemented so it might break semantics so we might need versioning to evm which we don't have yet that's a that that might be a big discussion and a huge topic maybe worth doing maybe not that's up to other

people to decide another one that i will mention is uh called particle gas cost maybe other people call it fractional gas cost that gives us a higher resolution i think of it more as gas rescaling so maybe multiply gas times 10 so we have a finer resolution uh you know within the execution context and then when we leave we we sort of round down or whatever or we divide by 10 and around and through the floor something like this is again a major change uh clients have to be very careful of course uh about security but but these are there's a lot of potential to remove these sort of system overhead bottlenecks

Hudson Jameson: paul real quick i think we had a hand raised from martin if we could just get that question in

and then we have about five more minutes on this topic till the next one

yes martin yeah

Martin Holst Swende: i raised my hand because i didn't want to interrupt really um do you want to finish and i just wanted to ask oh yeah sure we're done

okay

uh i don't have much left um so we have figures based on all of these sort of various options we don't want to be aggressive and say we must do this we're dependent on this but this is open for discussion some of these more aggressive ones certainly we wouldn't we wouldn't uh want to want to even we want to have a big discussion with everyone involved and we can come together to a conclusion um and i i want to bring attention so i mentioned fast crypto systems before but i want to i'm

sort of re-evaluating this because i have i'm trying to bring attention to an eth research post called serving pre-computation methods and cryptography requester help and i think we can design new algorithms so right now we sort of adopt uh algorithms that we use locally to just put them on chain just word for word uh we just translate them to evm and we and we do that operation action but in fact we can perhaps come up with new algorithms there are different constraints so notice that on chain we have different constraints than local and what i call pre-computation methods take advantage of this that we can take some more time to sort of set up the computation uh on chain and then we we we leave just the the very minimal part on chain so we

partition algorithms into two parts and i gave a bunch of examples one of them uh just to give an idea we have a 5x speed up if we versus you know on chain or off chain uh just by designing the algorithm in a way that we just do the hard part off chain and just leave the unchained part to just be as small as possible um and i'm trying to bring attention to to this eth research post and we will move to questions hudson and

martin yes thanks

Martin Holst Swende: so what i was wondering so i have been positive towards even 384 because it was my uh i i understood it as being a more

secure and minimalistic approach to letting the layer to do crypto stuff uh but i kind of get the impression now that that may not be the case because if we go with evm384 there will be lots of other things that we also want these kind of repricing and fractional gas prices and like localized fractional gas prices and like large changes which like in the end the when we reach there we might have a lot more complex system than if

we just went with the precompiled so what i'm wondering is are there any other dimensions um where you think that evm384 is better brings more than going with the precompiled approach and it sounds like you do think so that you talk about new cryptosystems um yes john just wonder aside from this like simplicity thing uh is that what

what other benefits are there to use event 384 over fixed big compilers

so i don't know much about pre-compiles i'll just talk about evm 384

uh user deployed innovation i mean who can who could have foreseen crypto and sort of uh when you give users the opportunity to or the ability to permissionlessly permissionlessly innovate i think uh some some surprising things can happen uh so martin there's a if you build it they will come uh element to it but there is already potential uh in my earth research post to design new new algorithms and things like this what what will where will we be martin uh there's you can ask other questions you know uh what does the world look like with evm384 and without evm384 where will we be in 10 years what will

be obsolete in five years these kinds of questions and i think that evm 384 will not be obsolete in 10 years and it could uh create a renaissance we already have interest from cryptographers that want to want to implement their crypto systems and evm 3d4 so there is potential but uh i don't want this to be overpowering uh the system is itself the stability is is very important so the core devs know what's best i can only say that there is there is potential um but i i don't know what the design decision should be i'm just here to just

give some ideas

Alex Vlasov: i think i can make a like a proper comment to martin uh i have one very specific case in mind when not even strictly vms384 with an ability to work on the elements which are roughly like 258 maybe 260 beats uh like model arithmetics may be handy in the future uh other than this i think in 10 years everything which is uh which we have now will be absolute anyway and um like it may be handy but it still doesn't neglect the fact that

hyper optimized especially for bls 1231 curve in the pre-compile which will be factor standard for is 1.0 and 2.0 later on based on maybe a single c library uh is still a great case but i believe that in 10 years even 384 in its current form it will be useful but not for building uh such a complex cryptosystems which we have right now not like trying to make a pairing primitive in the as a smart contract but for more like simple cases when you actually just need to do modular arithmetic over the modulus which is a little bit larger than 256 bits and you will need to do maybe like 100

operations like this and not the full pairing uh which is uh potentially like thousands uh like two thousands for them uh so this is more or less my point and at this point in ten years there almost like it will be discussion like well guys how we implement an efficient for example latest based algorithms which models we choose to make it hyper optimized because everyone will want it uh so like it would be good to have it but not like well let's wait for another two years to implement fractional gas costs and other optimization gas cost changes and everything to make it even viable compared to at least one or two specific

precompiled

um one quick comment when i say evm384 i mean the evm384 family of opcodes so there's already interest from cryptographers for evm 768 which would be just precisely modeled on evm384

uh it's

Alex Vlasov: for the same reason of like one specific recursive case yes you can have it would be great to have uh but such approach i still will believe i believe will be obsolete in

ten years okay uh so we gotta wrap up this piece um so the two

Alex Beregszaszi: could i just give one question um alex when you say it's

you need repricing to make it feasible i don't really get that the repricings and all those um you know other work items are useful but they are not necessary and and that work if any of that work is it just depends what you take feasible like i don't take a feasible a ten times difference compared to the hyper-optimized pre-compile compared to kind of optimized hundred uh ten times sorry uh yeah i don't think it's a hundred times

Alex Vlasov: is exactly at least 10 times uh at like even in the hyper like

uh uh pricing case when you had your old implementation may be less optimized but you had a one for every every multiplication which i tested by myself and which i presented in the previous results so this is compared to the pure naive execution time uh of your test routine which i had accessible in the go repository as i go for as a guest work sorry uh compared to what i was able to run for uh blast uh implementation

Alex Beregszaszi: so just being conscious what uh hudson said you know that we are over time you know when you say it's 10 times if you look at these prices and if you compare it to the suggested price of the pre-compile it's not the

10x difference so i'm not sure what exactly you're talking about but what i want to just change just to close this off get could i just finish please so what i wanted to say is that if you do any of these repricings or any of these extra proposals that wouldn't just benefit even 384 but would benefit evm in general

Alex Vlasov: well i'm two hands up for repricing of everything which is not properly priced and potentially inflates the gas cost by users but it seems like people are overly like skeptical about like having multiple implementation of the same pre-compile and in principles there is a precedence that well there is a c library for signature verification

if everyone agrees to use the same c library for like bls 1231 as the reference for uh for an evm to avoid forks have the same behavior even if it may be inconsistent to them today while there's an exception but we can live with it uh then if you compare it to this one to the one which is hyper optimized not for generic case not like a legacy of one 1962 like the proper special one for this curve which is a part of the pre-combined proposal single curve then it's ten times compared to my like kind of pessimistic estimates which are written right now in the

uh in the precompiled proposal with aspect that well we don't take only this fastest one or like two fasted libraries but we take any from this batch in the list then yeah it will not be 10 times it still will be like few times

Hudson Jameson: so yeah we got to take this to the forums i'm sorry guys uh but thanks so much paul for bringing this um and everyone for commenting the two links are in the agenda um and it's under paul's comment uh i don't know how many down but yeah paul's comment has both links so yeah next up is uh 1559 performance test updates i think that's tim

Tim Beiko: um yeah i have a quick update

can i share my screen actually yeah sure cool um so uh just to give some background one of the concerns about 1559 uh that was raised a few times on this call is um whether we could actually process blocks that were up to 200 full um so you know 1559 allows blocks to go over twice whatever the gas limit is um and so we wanted to test this out um and the way to do that uh was not shadow 14 main net uh so we took a slightly different approach where we built the tool that can generate a new network from scratch with an arbitrary state size um and the way we do that is we just specify how many accounts and hum and uh we create a new smart contract and and we specify how many storage

slots we want to fill in it um and then we also built a tool that basically spams the network with a large amount of transactions um so to get roughly the main net size we set up a testnet that had about a hundred million accounts and a hundred million storage slots in a smart contract um and then we synced uh four base u for get nodes running 1559 on it um and basically spammed the network for uh almost two hours using one second blocks uh and each block having 20 to 80 million gas per block um this was kind of our first just dry run of the test uh we were happy to see basu and get did not crash um i've i've linked uh you know the actual data in in the

hackmd if anyone wants to have a look um but next week next week we're going to do a you know more proper test uh we'll have nethermine along and and um try to monitor the nodes as we're going uh so i guess my one question was like is there any specific metrics or data that people would like to see from this um yeah to just assess kind of general network stability um as we'll be kind of monitoring it a bit more closely the the next time around

Alex Vlasov: uh can it be a little bit related to the discussion with the amount of empty blocks because like if you have a very large box and potentially like you still have a probability that you will mine an empty one hearing possessing the previous one

so can it affect your results a little bit

i mean it looks like you can but uh to

Tim Beiko: what would you like to see like whether the fact that we have big blocks

Alex Vlasov: i guess we'll decrease the amount of like if you have a big blocks then you will have like more empty blocks which on average will decrease uh like it shouldn't decrease that much to some like stable level or

Tim Beiko: but are you saying that with regards about the the block processing or with regards to the transaction fee so are you saying because we have big blocks they propagate slower and like we start building just on the header

and and then that results in more empty blocks or are you saying you want to test like when we have big blocks it raises the fee and that means that there's like a lack of transactions that are willing to pay that fee which means we then get an empty block

to lower the fee

Alex Vlasov: no my my comment is not related to the fee model it's just that like a naive execution time like while you process and receive all the data for a previous block not just a header you still have to like miners will mine on the empty block and well it will kind of decrease and average bandwidth uh in some sense

got it what do you think is the way so right now let

Micah Zoltu: introduces a new way for minors to prep blocks where they can put them incrementally so we actually should see if clients invent this we should actually reduce a reduction in empty block money because you can start a block add one transaction and because your block is not going to be full you just add them in and then as you see new things you don't have to prep a new whole new block and so you can do this kind of incremental block production and so you can start mining a block that has one transaction and then just update to one that's just mining two and then just update to one that's mining three and update one two and four until you get up to a full block and so i suspect that if clients implement that feature we shouldn't see a reduction

Alex Vlasov: uh yeah i mean is it a hard requirement

or like it's like a recommendation i think like it it depends on the finals whether it's miners and the difficulty of implementing it

i mean yeah

Micah Zoltu: certainly so this is going to be a potentially competitive feature for clients to compete on so if you can provide miners with slightly increased revenue they're more likely to run your client and so maybe you know another mind if they watch more people running as clients that it might imply this feature well it's whereas geth may decide that's too much work so this is definitely not a consensus consensus issue this is just how miners mine and you may even see some minor implemented themselves and just run it secretly and you just notice that they have less empty blocks

than everybody else

Alex Vlasov: yeah but i mean uh miners can't even do it right now like um they still like losing a small amount of fees by doing this like very small maybe one percent uh but there is nothing in existing clients yet so i think this topic wasn't taken as a as a serious issue in its existing implementation so like uh maybe martin can answer like why it was never considered just because no one asked for this

James Hancock: i don't know if going into that necessarily is still on top is still on the thing but like uh

something that has come up previously tim is like if the network latency between the nodes so you if you have four highly connected nodes versus if the nodes are a few seconds apart because one was mined in russia and one was mined in the us or whatever

because

Tim Beiko: yeah so we can definitely i think for this test all of the nodes were running uh in the same instance but we can definitely for the next test have different uh regions

yeah yeah

James Hancock: because then if they that would simulate more of what mainnet would probably be like

Tim Beiko: yeah to a very small degree though like to be clear like we're not trying to simulate the whole networking stack here yeah um but that's yeah that's good feedback we'll

definitely try and have nodes in separate uh regions for the next

test to basically clarify um with regards to the exact metric is it uh really that

Ansgar Dietrichs: we are concerned about empty box or is it that we are more concerned about like there may be a potential increase in anchor rates because uh like the interesting thing about 50 59 is that like uh the like an increase or a slight increase in empty block rate would not in any way affect the like the throughput of the system just because like that's what the whole mechanism is about to kind of balance that out it would of course kind of increase the variance and that's probably an issue in itself but i'm just wondering if like the empty block rate is the important one or if it's more about like an uptick in in anchor rates for

like

longer process sometimes thanks

Alex Vlasov: uh well it's more about what's the exact quantity of such empty or under-filled block will be at the end of the day taking into account potential network latencies and uh processing time by the nodes not like the node doesn't crash and keep up with the network eventually but that it doesn't affect miners which are like a huge part of the

ecosystem

Tim Beiko: but to be clear though for most blocks that won't change so the the reason we're concerned about this scenario is that uh most blocks under 1559 will be basically the same size as they are today except when there's like a large spike in demand

and that'll happen like a small minority of the time and what we don't want is a you know for that tiny amount of time to crash nodes because they were really at their max throughput already and b um we don't want an attacker to be able to spend you know significant resources uh to then uh to then you know dos the chain because or even have nodes drop off because they can't process blocks but like under normal operations there's not like it's it's uncommon for blocks to be 200 fold because the price basically goes up 10x every five minutes so you know the amount of sustained demand you need for that is is incredibly high um yeah so so like

what you're going to say just the average propagation and whatnot that shouldn't change too much

Ansgar Dietrichs: although just to be clear i don't think b that it will be uncommon to see for like two two times four blocks it's just uncommon to see like a long streak of those i think just because with proof of work they kind of we have so much variability in block times anyway so it's that like let's say you have a block that comes in four seconds after the last block then that block will almost be empty at 259 because it will have like a very small set of transactions to include and so and likewise if you have a block after 40 seconds then that will be overflow so it's just about these streaks that will occur very very rarely

Tim Beiko: um yeah just to make sure you know does

anyone else have anything they wanted to see or any feedback on how we can do the test so that it's it's a bit more realistic

i think micah has his hand up but i don't know if that's from earlier okay

Hudson Jameson: um where do they go if they want to give more feedback just the eip channel and

r d yup that's the best place cool

Hudson Jameson: um all right next up is all core dev feedback um if you click on that it has a hack md file that tim made with some really good um information on feedback he got go

ahead tim

Tim Beiko: uh sure i can share my screen again do this quick um so over the last two three weeks i tried to talk to basically every fine team um to understand you know what they like what they don't like about awkward devs um how we can make it better uh i have this long document with a bunch of feedback tried to summarize it uh you know to reduce uh bandwidth um but at a high level you know um i think people generally like awkward f it's not inefficient it's not very efficient but people feel that it works um i think the the other thing that came up a lot is that um we there's like this desire to spend more time discussing technical matters on some of

the calls um and and stuff that client developers care about but at the same time you know this is basically the only place where we can get consensus on controversial decisions so we really need to balance those two things um another bit of feedback that came up a lot is uh people feel that it's it's kind of the bar to bring up eeps on the call and and bring them up repeatedly is sometimes too low and and that tends to take up a lot of bandwidth on these calls um and finally um another bit of feedback that was that was pretty common is that uh we tend to be very focused on like the next release and the the eeps that are right in front of us right now um but that uh it would be good to have just like a

a higher level world map um with regards to stuff like say the e2 merge and just you know generally all the long-term things we want to do um i had a whole bunch of different suggestions but i think you know three things that are fairly easy to do that that would have probably a high impact or like a just having one or two calls right after berlin to discuss the road map at a higher level and try to think through you know not only the next hard fork but realistically we probably only have two or three hard forks before the merge so you know what are the most important things to ship in those and and how do we how do we think about the dependencies between them um with regards to this point about you know wanting to discuss technical things but also needing to have

controversial decisions or important decisions happen on the call one thing that can help is just having like a longer term agenda so um you know instead of having just the next two weeks having like three months so that we can schedule stuff you know like artem you you posted something about the transaction fees right that's the type of things that like well right now you can argue it's urgent but most of the time it's not like the most urgent thing on our agenda so if we can schedule it in advance and say look we want to spend a call you know discussing this problem um people can prep for it and similarly if we're planning to take decisions on a call we can also you know make that clear and anybody who wants to be there can show up people who don't want to i don't have to come and then there's

like basically three things you know i think probably makes sense to have like a longer discussion probably on the on the chat but just you know what's exactly the process we want to have to bring eips on the call um the idea of having a code of conduct came up a bunch of times so you know this was a simple one that was proposed um and finally um and we're at time um the you know i think a lot of the core developers i spoke to were had a hard time articulating exactly where the bridge between like what decision core devs make and what decisions the community should own is and i think one thing that could help there is just trying to explicitly clarify you know what our core developer is optimizing for um

one thing every single dev i spoke to basically said is like the security of the network i think this is clear there's another point around you know the long-term like sustainability or success of ethereum um and but then that beyond that you know core devs don't necessarily feel comfortable making all of the calls and having a sort of mission statement or just like scope uh could help just clarify to the rest of the community you know what's the level of of um you know engagement that we have with with the different proposals um i guess yeah we're already at time i can bring this up async but you know does anyone have like strong objections to at least the first two proposals

the three other the three smaller ones are

kind of a can of worms um but yeah the first two are pretty straightforward that looks good to me okay so yeah i'll i'll get started on the first two and we can discuss the other ones later uh nothing in this is really urgent but um and yeah if there's any feedback i guess the alcor dev channel on the youth r d is the best place all right awesome thanks so much tim um for both of those updates uh we are at time does anyone have any final things okay the next meeting is february 19th

at 1400 utc thanks everyone for coming goodbye [Music] so [Music] [Music]

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

[Music] you

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