All Core Devs - Execution #72
All Core Devs - Execution · 4 Oct 2019 · 55:09
Ethereum core developers decide that the Ice Age EIP will not be included in Istanbul, recap the Ropsten Istanbul fork, promote the Ethereum Roadmap 2020 session at Devcon and cover testing updates.
Speakers
Topics
From All Core Devs - Execution, hosted by Ethereum Foundation.
Transcript
[Music] [Music] [Music] [Music]
[Music] [Music] [Music] [Music] [Applause]
[Music] [Music]
[Music] [Music] [Music]
[Music] [Music] [Music] [Music] [Music]
[Music] [Music] [Music] [Music] [Applause]
[Music] [Music]
[Music] [Music] so good morning evening everybody welcome to core developers meeting
number 72 small crowd today so everybody must be on the plane Def Con we have a pretty short agenda so it should be the longest chord F call and yeah you can jump right into it so the first item on the agenda was the Istanbul the Istanbul Robson fork recap I don't know
Tim Beiko: if anyone wanted to give just a quick update about what happened there
do you wanna go ahead yeah there's nobody else so essentially you're up stand up stand for came about two days
earlier than we expected for kind of a surprise but it turned out that somebody is mining rock stone wood about 1.5 gigahertz so that's I don't know 50s or so GPUs or if as long if the calculations are correct either way it's some of these pushing rocks are really hard and essentially so it came to two days earlier we had kind of a scare because it looked like the fork failed and then it turned out that no actually the fork did succeed the problem was that this miner who is pushing with 1.6 dashes Robson it's actually pushing the non forked chain so
we have a huge miner on nan Istanbul Rob stone currently and so for the past couple days we've spent trying to figure out what's happening in Robson because the network currently is really unhealthy and it kind of boils down to the fact that most people did not upgrade yet their nose to Roxton and so most of the nodes are non Istanbul nodes and since there's also a really heavy non Istanbul chain it makes upgraded nodes minority upgrade and also to say quite quite annoying to operate correctly and it it that it did surface also a few issues namely that it's
essentially character what's happening is that non upgraded maps and nodes are eclipsing the upgraded ones and so for guests specifically we do have I think I already posted on the or collapse Cole and also on Twitter if you do have a flag if you run it with that then well it will filter out the non upgraded chain and you should be ready to go I'm not sure properity but long story short it's a bit of an issue and we have a few proposals on on how we can avoid this scenario in the future but up for Oxton it's already too late to to retrospectively add those fixes so it's for ups them
it's kind of we need to ride the wave until until the upgrade Istanbul chain gets heavier than the other one or enough people update so and until then it's kind of a fire fighting model you can run get with this whitelisting flag or the other clients I'm sure they can give you some options on how to get on the correct shape yeah it was
Martin Holst Swende: a bit to that so the last time we worked is Robson it caused some problems for developers who do is finalized testing on that I think great and riding team but this time no one from the deaf communities actually reached out and so on on the previous occasion I thought it
was really really good test of how trying stand alone changed but there was kind of a bad bad feeling from the Deaf developers this time around it doesn't appear that anyone is actively complaining and from an infrastructure perspective I think it's super interesting to see this how we trying to behave when there are longer higher TD side chains which within the blocks and as Peter said we have a couple of proposals a one on impeachment forgot one of them and we have some new issues features that we're going to implementing guess to make just an ELISA NARS banner so I think it's really
really valuable and worthwhile to to actually do this as a force it brings a lot of stuff out for attention
that's about it for me yeah
Péter Szilágyi: just to add one minor thing that even though Rob's turn for countries was a bit of a show there's no we so there's there are no really no worries that a similar thing might happen for me not since since we don't expect main enough to be all of a sudden pushed by a 10x miner on and on for King chain
Tim Beiko: thanks for the for the recap market
Martin and and Peter I don't know if anyone else has like comments or thoughts they want to add about this okay and I guess yeah just to be to be explicit about this even though there were some issues on Rob's than all the other tests that's we're still going forward as is there's no specific action we're taking aside from the changes in death and the sort of proposals you want to implement but those don't change the other
test that's correct yes how he was trying to find a button so the country I guess there are two more test nuts that
I mean that I'm familiar with that's rinkeby and gurney but both these test nuts have essentially they are proof of Authority test nuts so as long as the miners upgrade you cannot have an alternative so it's a proof of Authority bestnet we're only the majority chain can progress so either you have non upgraded chain progressing or you haven't updated stop watching progressing but you cannot have two concurrent ones so from this perspective gold and rinkeby are completely immune to the issue that happen often got it so we should
Tim Beiko: at the very least
make sure that we cut a message clearly to people to validate there's all these test nuts that they really should upgrade so this is probably like an action items for the cat herders to just follow up and make sure that there's like clear communications about that there was one blog post already written about the test nets on the cat herders blog so we'll make sure to get that spread widely anything else
please go ahead so
Péter Szilágyi: contacting validators that I guess the guerilla team probably has a list of people they need to think as for inka be the foundation is kind of running three validators and we have
four more validations running by Oracle ice auger akasha and I'm not sure who the fourth one is now but we can definitely reach out to them and we're also regularly monitoring the status of the updates on the rinkeby stats page so rinkeby is probably safe but as for girli that's not for the girl looking to reach out to make sure
Tim Beiko: great so yeah let's keep this as an action item for the cat herders to reach out to the gordy team anything else on the test net upgrades
okay if not
Tim Beiko: second point on the agenda was just still a quick shout out
to do if the roadmap session at DEFCON so this will be on the first day of Def Con and basically all of the afternoon will be splitted to a session to discuss the each one world mapped and it want the e2 roadmap and then they eats to roadmap and I think there's some time at the end of the afternoon as well for if working groups form or want to discuss specific ideas so if that's something that you're interested in it would be great to have a lot of people from both the court outside as well as the the broader community side they did discuss these things I don't know if anyone has comments thoughts about this okay so next point on the agenda was ice
age and I think Hudson had a comment about whether we should plan to delay the difficulty bomb in Istanbul or in the following fork which is called Berlin and and more generally to know do we have an idea of what the difficulty bomb will start being activated again and and when we have to
defuse it no I thought it was going to prepare I am NOT I have
James Hancock: I have some should be verified back in a hand map that I've done as
last year TJ rush and I did really investigated today difficulty bomb and hackathon and then worked with fatale ik and Lane to make a script so there is a script somewhere floating around that predicts it alright I predicted it fairly well from my memory it took about 12 I'm just checking back historically it took about 12 months for that forehead to start showing up last a 14 months when it started showing up last time and given that we're about half the hash power it should take longer for it to show up than it did last time is there the way the absolute hash power actually showed has it show
up earlier or later relative to those numbers so given that it's in the June April May June like April May June July range that we might see something
Martin Holst Swende: because the previous postponement said that if I recall correctly but the next time would be like winter this coming winter but you're saying it's not until spring
them
James Hancock: when the fork was implemented on March 1st last time
when at least the block times went down yes I need to go back and figure that out figure out how far we pushed it back I think we pushed it back even farther than we did last time as well
you know
Danno Ferrin: went from 3 million blocks to 5 million blocks I think Byzantium was 3 million Constantinople was 5 million really push it back two more million blocks which is roughly a year
ok
James Hancock: so then yeah it would be still on the March but it should fill up slower because of the hash phrase so much less than what last time
Danno Ferrin: that was gonna show up earlier with less
a shrink
because it's an absolute advant hardness of pastoring the for
James Hancock: my research before because it adds the read the hash rate before the block hash rate before and the current one then actually the larger the magnitude the more of an effect it would have so it showed up earlier and more aggressive last time because the hash rate was so high compared to the time before so this time if the hash hash rate is less it will show up later and less aggressively
Martin Holst Swende: I can I think I pasted the link a link to the EEP in the
world credit channel it says in the rationale but they calculated back then they estimated that it would hit 30 second block times at the end of 2008 exhaust you oh sorry that's not latest one
you
Danno Ferrin: but I think could take away whether it's a month one way or the other is this is
something we need to address probably in the first
order yeah yeah and
Péter Szilágyi: just after that I would I think husband's question was where they want to address this in Istanbul or not but unless it is extremely urgent to do something I would really be against doing it in Istanbul simply because we already defined and what Istanbul is and Robster already forked so if we start to redefine what Istanbul is and the Rob stand fork is kind of invalid unless we do another Petersburg number two to do to do a double for conveying that and the hotfix for con unwrap them
so unless there's actually a reason to push the delay soon that I wouldn't and also we were talking that it would be real nice to do a second heart for the second part of Istanbul in a couple of months called I think that was named Berlin but is the tentative name for it and it's supposed to have it the idea was that it's not a hard fork that's open to adding and if everything rather very focused hard fork for adding some cryptography and we can always say that it gets the cryptography plus the delay and done or alternatively we can try to go down mark and suggested
pathway of preparing the IPS and forking one when something's ready by the way I wouldn't do it in Istanbul
Tim Beiko: yeah it seems like there's no major reason to do it if James calculations are remotely correct we it should give us well enough time to to plan this for another Fork and not delays they're both does anyone does anyone sort of disagree with that
Péter Szilágyi: well I guess if if the ice age cannot be even felt currently not even a bit then I don't think we should be in a too much of a rush
in
James Hancock: the delay of the last fort also I think would affect our initial target of around Christmas or whatever because it ended up going out two months later almost so the year would still be March the year mark
you right
Tim Beiko: okay um so the next agenda item was testing updates I saw there was a comment about the consensus tests and it tagged both Martin and Danos I don't know if either of you have had an update
Danno Ferrin: all the tests except for the 220 tests
that Martin and I put together and merged into the reference tests now there is one concern about a particular random state test 94 clients just need to be aware it's gonna consume about a trillion gas when you run it so to run in parallel it's gonna consume too much memory no issues like that but reference tests for everything but the 220 are committed
great any other comments on the testing now I can you small updates about the person so yeah it's in keeping passing stuff millions and millions of times and
I found nothing so far
Tim Beiko: okay thanks Martin dad oh um I see we also have Lois on the call who joined I don't know if you wanted to bring up anything
specifically Lois because we're kind of at the end of what was the most important thing scheduled for the agenda okay so
Tim Beiko: okay so next item on the agenda is reviewing the action item so before we do that does anyone else have anything they'd
like to discuss or bring up
so Peter wouldn't know make good time about the 4kd Oh oh yeah yeah I thought we are going to get that so it's just
Péter Szilágyi: just a panic proposal although the idea would be to get some feedback on it anyway so what um long story short one of the issues with Roxton so the reason current eruption is having a hard time doing anything is because networking wise the
forked Network before the pool of fork nodes and the pool of non forked nodes have no idea that each other so the noes have no idea whether appear is forked or not the only thing currently they can do in the IAM protocols is try to they try to advertise each other's for chains and blocks to each other and they download it from each other and then they realize that okay something deep down is not compatible or some block is invalid and the problem is that if we don't do anything to somehow separate the peers from each other at at the more more lower level at the networking level then
it's it just puts a really nasty strain on the whole block processing block validation everything and way back we had a proposal with we do the food Felix about half a year ago so when I heard two peers do a handshake with each other currently they exchanged the Genesis block the I mean the hash of the Genesis block and the idea was that this way we can have multiple the problem is that this one cannot detect if two peers share the same Genesis block but then forked away from each other kind of like if your mana theorem classic or Rob stone and Istanbul etc and the idea was that instead of instead of exchanging
the hash of the Genesis block we should exchange something else that contains both the Genesis hash but also all the forks somehow meshed and we figured with Felix we came up with this idea of a fork idea which is kind of like just to check some of the the Genesis hash along with all the fork block numbers and the proposal we had any IP it's already accepted and version and my proposal would be to publish a new version of the East portico so essentially bump the eighth protocol to each 64 and the only change would be to replace this Genesis hash in the handshake to - this fork ID and what it would allow us to do is that when two
peers connect then even if they have the same Genesis block they will be they will immediately know whether they are compatible or incompatible with each other for Christ and this would actually if if this would have been implemented unwrapped and currently then the two networks the ones who didn't fork into Istanbul and the ones who worked in Istanbul they would have separated really cleanly at a networking level and then all of these messy synchronization law processing problems would have been solved and then the idea that so I think it's a really elegant solution if anyone wants to take a look please take a look I linked in the IP and as the proposal is just to replacing a single field in a
handshake the question is whether does anyone have any objection against publishing an e 64 version well since if the eath namespace is is they're officially theorem protocol we don't just want the gap team to publish a new version unilaterally and say that this is the version 64 but but we would really like to do so and it's really a more or less trivial change so that's why we're kind of optimist that the effort to implement it is really tiny and the benefit would be huge especially for test networks and of course even if we do implement it that would definitely
keep speaking the old protocol side by side so it's not like we want to roll out something incompatible rather it would be just an updated version so action item does anyone have anything opposing to us defining is 64 as this fork ID thing and rolling it out
so any positions
Danno Ferrin: there is a thread a lot of other ideas for sorts of things that are going to 864 stuff relating to like archive versus partial nodes doing things like not sending out the the log bloom on the transaction message produced burden on the wire protocol
should we consider if there's anything that's easy to put in that's quick as well a matter do you really are you committed to just having this being a one feature change 864 and moving all those suggestions to a neat 65
so
Péter Szilágyi: the problem with these suggestions in general is that there are a lots of suggestions and I don't know which impact state those suggestions are in for example we also have a new an idea for a new synchronization protocol which would be really nice to have but it's not yet fully expect out so I don't mind adding anything else that is fully SPECT out and fully agreed upon the reason I was suggesting to go with the single change is because this one is so we have
test cases we have everything and it's something that is easy to roll out and it's something that's needed I will I'm really open to adding other stuff but I don't want to start a whole research thread and the one-year delay just because we don't know what else to add or how to add them so anything that's ready we can add but stuff that's not ready I would postpone
365
Danno Ferrin: right I think a deadline on that would help a lot ready by now we ship in 865 I'll ship sometime next year
yeah Adam
Martin Holst Swende: I don't really agree I mean it's not like coordinating hard forks where everyone has topped it
simultaneously as long as there are no conflicts you know that the guest team defines 64 this way and then someone else defines it differently because I never problems but other than that as long as we kind of coordinate okay so 64 is this thing and 65 is this next thing I don't really see a problem with doing many releases or any versions
criminally yeah so one advantage of doing money I mean
Péter Szilágyi: one advantage of doing 64 just is a tiny thing and a 65 is the next tiny thing is that it's easy to a lot easier
for a client to implement and make sure that it works and that income and the next thing and make sure that it works versus if we create an is 65 that's or each 64 that contains a ton of features and it's it's just really hard to to make it's a lot harder just to make sure that it's implemented correctly described clients agree on it etc etc
so in the dynamic sense same theory I kind of also like when
Péter Szilágyi: I would also say that if we can make smaller releases to the protocol smaller version bombs than that is probably a bit healthier but I'm but from okay I'm a bit from this
perspective I'm a bit partial because because I do see some urgency in installing and networking aspects whereas the rest of the things are kind of niceties or optimizations that definitely should go in for example transaction propagation is another thing which should be solved but it's not an immediate urgency whereas this whole network thing is it stresses the network every time we do a fork
Danno Ferrin: be nice if we could possibly ship it before
they mania assemble but definitely
Martin Holst Swende: I mean we can ship it on Monday
so the problem is you cannot so if you want to upgrade the network so
Péter Szilágyi: this one will probably won't have any effect on Istanbul because so the whole idea of so if I if I add this extra field in the window into the handshake and then peers can decide that they are on a different chain that also implicitly means that people who did not upgrade they also need to be able to speak this new protocol so essentially if you didn't upgrade then if you don't bother upgrading then you won't have this update which allows you to do this fancy handshake so essentially what I'm saying is that this won't fix Rob stone and this won't fix click girly and rinkeby
or may not well if people update and the main that fort won't happen for I don't know one two months then it might help a bit but but realistically it's probably it will probably have for the next
artwork
James Hancock: so a change like this does need to be paired with a hard worker it doesn't need to be
okay it does not need me read retain backwards-compatibility only 63 but if anyone wants to speak he's 64 of them we exchanged the four KD that's actually the reason so the problem
correctly
Péter Szilágyi: the problem with roxton are with nose that didn't upgrade but if nose don't upgrade then they won't have this e 64 either to solve the problem so that's why I'm saying that it is a solution for a for a future hard fork I mean it will help a future ha are for plan everybody in the network will
be actually running a 64 already so dope uniform this week to say yes to it but I like it I was gonna say is it worth also just posting maybe on the
awkward elves get er to see if we like if we do want to do this
Martin Holst Swende: yeah it's been posted to the PM and it's been a public Eve for half year and accepted
but
Danno Ferrin: I think what's needed is probably the post and say we're gonna should be 64 is just this change bring your objections to call for des in two weeks
James Hancock: maybe if we treat it like the the EIP fork centric process that if there are things that are currently ready to be added in then they can be talking about but things that need to be good that need to get ready to be added in should
be a different conversation
so Pharisee yeah okay so yeah let's just
Tim Beiko: I guess share this proposal probably on the court have skitter and maybe like a neat magicians shred and and see if there's any any comments in the next two weeks and otherwise we can kind of accept it on the next corner scoff officially does that make sense okay yeah no objections was there anything
else anyone wanted to bring up
okay in that case quickly going over the action items there was one around David palm will talk to a caring to see if 2,200 should be self contained ways not on the cob I don't know if anyone has an update there okay okay so I guess what if that is a continuing action item and the other one
was for the catheters to write a blog post about Istanbul that was done I can share it in the chat here if anyone hasn't seen it yet and great so i n't updates just in the updates research updates that people want to share oh
Péter Szilágyi: I do have one of it go ahead it's completely independent of Istanbul but we did get released a couple of days ago it was one nine six I think and among
them quite a few fixes we actually tweaked to level the be a bit and if you defy think this tweak reduces your disk i/o by about half and if you don't think it reduces by a factor of ten so it we it kind of reduces this guy you buy an entire order of magnitude and we are kind of really happy about this so if anyone wants to once the benchmark it and see how how the you guess performs we're really curious to see to see numbers out in the wild
Tim Beiko: that's it that's that's impressive nice any other
updates okay then I guess that's it
unless there's any final discussion items people want to bring up I posted a link to the research I did last year on the Ice Age for people who are interested in going back on then okay thanks James in the all quarters and in the chat awesome thanks for the link okay then in that case I guess this is
it for today have a nice weekend everybody and I guess we'll see some of you at at Def Con next week just a good question yes so we it's like the second item on the agenda if you look there's a actually a late so on the first day of Def Con in the afternoon there's a it's called etherium roadmap 2020 agenda item and so the afternoon is kind of split and in for the first part is like the each one roadmap the second part is the transition from East one to e to the third part is to and the fourth part is for working groups to work on anything
that comes out in those sessions so yeah the first afternoon of the first day of Def Con is is that session okay awesome thank you let me just pull it up that's called agenda yeah like basic I'm just not sure if it starts at 1:00 or at noon okay so the it's one dollar one day dialect session starts at 1:00 p.m. in the convince and all the other ones are just back to back after that I saw I said wouldn't be in yeah I put my talk
you have you talk sorry what oh okay just check your talk is like at 3:30 so that should be doing the eat to session or actually there in the working groups so like they eat one the transition and the two sessions are all before your talk Martin oh next awkward devs call from puja that's a good question I assume two weeks from now same time so the week after DEFCON does that make sense two weeks or DEFCON okay no sorry the
week after DEFCON so two weeks from today okay okay great so I assume everyone here is going to be there and I'm some of my Cody gather and the formal meetings with some of you guys know great awesome okay I guess that's it thanks everybody thank you I like these napkins quickly efficient okay then I guess that was it so thank you very much everybody
bye-bye [Music] [Music]
[Music] [Music] [Music] [Music] [Music]
[Music] [Music] [Music]
[Music]
Speaker names adapted from ethereum/pm, CC BY-SA 3.0.