All Core Devs - Execution #53

Transcript

[Music] hello everyone and welcome to episode 53

of the core dev saga I'm your host Hudson I'm really tired today what are we talking about first let me see if everyone can hear me yeah they can let's talk about the Constantinople postponement that was a lot of fun right everyone Hudson I think you're not the only one who's tired I think there were some engineers that pulled some all-nighters to make it possible so I think we should first of all just express gratitude to all those people I agree thanks everyone who chipped in to help with the postponement the people who are

involved in the decision and then everybody who reached out to all the exchanges and miners and major stakeholders to help delay the fork so the first part of it is the difficulty bomb update and someone told me that the next time the difficulty bomb is going to update because it's already gone off is block 7 million 100,000 so I'll paste that in there and the chat yeah Hudson I can jump in on this one quickly so um just as a recap I think we spoke about this back in like November I did some analysis of this using a script that the

talaq wrote for the previous one and had the help of three or four other awesome people and the short version of the story is the difficulty bomb has already started to tick right so I believe if you look at the block times we've had like one visible tick up so far above the current difficulty level we were originally predicting a lot of times to reach 30 seconds in May so I guess two important points to make the first is that since that point the hash Power has declined by around 20 percent which means I think it will happen we would hit 30 second block times closer to the end of April and the second point to make we just need to keep reiterating this is that while it took you know six months or whatever for that to happen into 2017 it's gonna happen faster this time

because we're at an overall higher much higher network posh power than we were last time so we still have a few months but it's ticking okay sounds great thanks Lane anyone have any comments on that or I think we're gonna get to the part where we talk about when the next hard fork should be so we can even wait for them okay so the next part is I think everyone by now knows kind of the story about why the reason the fork was delayed so we've been talking about how to mitigate or whether or not to even include the EIP in the next and the

renew hard fork so that let's let's go ahead and talk about that a little bit we had a report from trailer bits and chain security on some potential mitigation efforts there's also a talk page on F magicians that has some ideas and there's some recommendations there and then I know Martin has been talking a little bit about it so is Nick so let's see is Nick on line it probably doubted I think it's really late where he yeah okay if we want actually could change security kind of

give like just a real quick overview of what their recommendation is or just an overview of what they found if you're talking you're on mute chain security I think it'd be the chain security here oh there you go up you're unmuted you're good so quick recap what was found is that gas changes discussed especially in one of the VIPs can have an impact on

previously re-entrance e safe smart contracts entering the search for those we together with set of bits and some others in the community discovered multiple cases most or all of them not holding significant value luckily but still deployed smart contracts which would have been suspect attack about with re-entrance e attacks after the VIP change so that does a very quick recap and think for the recommendations is someone here from trail of bits yeah I

would happily let you talk to them because he compiled those yes there was currently six proposition in the umpire and we started to review then as fast as we could the first exhibition we were come on is to simply drop the e IP one to eight VIP otherwise there is one proposition which is corporation 500 British on 7 according how you want to cut it which is a bit better than the other one I

know if like many people or with you we'd have to go over each and every one I don't think but if you want to go over the one that you all landed on as the best potential one and then if anyone else in the room wants to go over there potential recommendations as well because I know we have some people who came up with some in the room so if you want to go over the the most recommended yes sure so solution is simply to kind of keep the original gas cost that you already implemented but implement the IEP using the were phone system so hours execution

we have exactly the same cost but it will be cheaper to to use suppose mechanism so honey it was proposal five there were one thing which was not clear in the proposal five and time of kind of food in death proposition so the publisher files proposal was to increase the cost of writing to data Scott to five thousand cans and to give back as we found four

thousand eight hundred cats so it was not clear if this should be like for all the data storage that's why in the report we kind of create a slight version of this professor well instead of changing the Guster's to five thousand we want to just use a gas cause that was pre AIP like you you you keep the same cost computation but are you change over four mechanism of the storage in case of data storage that make sense and I'm going ahead and I'm pasting some

links to relevant earth magicians threads on this so people can take a look and by the way from chain secure beaking want to make sure they you guys get to introduce yourself if you'd like so this is Matias been working together with soo wet on the medium post and I'm running here the operational side of the business wonderful and then Jocelyn your from help up saying your name right you're from trail a bits exactly wonderful okay um who has some comments or questions or anything that what was just said I have a Marcin go ahead first

oh thank you no I I'll make it brief I think it's probably going to be a very long discussion if we go into details about all of these and my preferred approach is to exclude the EEP from from the next from the nearest hard work list called Constantinople so I propose that if we have a champion who wants to speak about a particular proposition then we could do that but otherwise I'd prefer to say we we don't decide which one is the best and how exactly they implemented to just exclude it that's my just as a thought experiment even if we decided on updating it today

would it the amount of testing and reconfiguration of the court along with code changes be reasonable in the context of getting this out for the difficulty bump if we make any kind of modifications to it that would add a lot of test complexity in happen where if we simply drop it that's a lot less testing required an easier to to generate in the emergency call the other day we at least had tentative consensus during that call the the reasonable approach was to get down the curb so that so but yeah it's a good idea for us to talk

about whether or not we're including it rather than what the right decision is you guys are right that I'll wait that always sometime so um who else had a comment I think Alexi maybe yes sir I had the so first of all I do agree that the simplest way to proceed right now is to just excluded and I just very short I don't I know that Martin suggested not to go into details but about the the seven whatever the proposal number seven what I wanted to clarify is that this will somehow reduce the likely the desired effect of the CIP because of the the cap which we know exists for the era funds so just to make it sort of known

that it's not exact the replication of the semantics it's actually slightly less makes it slice that's less powerful to change anybody else have comments yes so I was wondering gay regarding him or not in the comments the comments made on one proposal so I don't really see how it's in how it breaks anything that anything that we desire to have when it preserves the original intention of the e with including it's a or if it's a

benefits and as far as I can tell he doesn't break any if any scenario that's say actually that's lacking to be real world so could you elaborate on that please number one now which is at a condition to a straw that causes it to revert if less than two thousand three hundred gas remains yes because I mean even if the guy if the gas left is below number its then before the EEP it would cause a revolt anyway because I leave out anyway so he doesn't change that behavior

and with the and when you do have enough gas you do get the benefit and this way you don't have to deal with complexities like their refund limit so it's it's essentially a one-liner fix so I'm trying to understand why do we need anything more complex is that now it's just that I think people are thinking about what kinds of options exist I mean it's not a totally straightforward decision because adding this particular condition is you know it's kind of a weird condition to be honest I mean it is kind of an elegant proposal I agree but it's just you know there's there's a lot of things that you know a lot of other things that could be done and I

think what everyone kind of wants is to is to reach a conclusion where the with the proposal that's accepted isn't you know when we investigated this we also found that several smart contracts out there have higher gas limits they pass on to other cards it also depends on which version of this salty compiler was used at the certain time so those existing contracts might still be attackable and in addition it would obviously enshrine into the like formal semantics of ethereum certain like

workarounds which just happened because of the way people used for some time let's say in five years the code or solidity at that time which we are at of course depth in the future when people ask like why does this yellow paper version 5 have this case of if less than 2300 gasps do that which which is technical that we would have to carry along yeah that's a I mean keeping you keeping yeah they were keeping your log of the reasons behind such decisions is essentially anyway because I mean me you know if we had if we had there there may

be a maybe there were the whole problem it could have been prevented it's a mean if we if we remembered exactly why we had the limits in the first place so we should that we should keep this regardless of whether we take this solution of that solution but with but if we change the gas limit we need to also think of another gas limit their refund limit we need to think carefully about the reasons why why would we chose to limit it in the first place and and that's and I mean my sense is that this is more complicated you know understanding how it affects miners everything I would say that in order to

answer your question you have is that if we make a thought experiment and move ourselves situation free prior to so let's say that we were currently deciding whether to include this EAP or not back let's say a couple of months ago and somebody comes and then we knew about this vulnerability and one of the proposals was to add this check about three two thousand three hundred so would have we actually accepted it back then with this particular workaround probably no no so that's I think the enough reason to not do it right now because we kind of in a similar situation now we don't have to rescue the main chain from this so we are we basically by not doing the

Constantinople we brought ourselves back into the situation we want to be where we can have this freedom of making may see change or not making the massive change so that's my opinion in that third grade I want a second what Danny said before I think the right question to ask right now like I think we could debate forever how to fix the issue but I think the real question is how to move forward with Constantinople and should we you know move forward with it without the EIP in question I'm curious to ask anyone who strongly opposed to moving forward without that EIT that might be a good use of time yeah look they can help on that so I can I can go first so basically I think that the it is kind of

a useful app and I think that you know if if we keep the discussion time-boxed it might actually be beneficial to think about what can we do how can we change this how can we change it Eve so it's so it can still be included so I'm strongly I'm kind of strongly opposed to like moving forward without it because I feel like like taking this EEP away is going to make Constantinople even less event you know it's just it's gonna be even less of an of an overall improvement so why is that a problem though like I I'm personally all for like really pouring hard Forks yeah but I mean the thing is that you know how

folks don't happen every week so there there aren't like you know so many chances to include protocol changes I mean when's the next one gonna be like off year from now so that no that's that's a good question and maybe we can't answer the first question without discussing the second one I think a free could probably speak to that but you know he tentatively proposed something like October which is not that far away okay so I mean if people feel like you know if I feel like if people can come up with a solid with with the with a solid fix to this to this particular within let's say two weeks and and and and it's it's pretty clear to everyone that this is a good fix and it might

still be possible to include it I would say it's not because if we changed the IP we have to change implementations we have to adjust our tests we might want to like test was on test net first this is nothing I think we can do within a couple of weeks yeah I agree about that totally I mean if modified implementation basically then we're looking at months of time for testing and dropping it we can do that quickly moving forward with it as it is yeah we could do that quick as well if the analysis had shown that yeah we're nine times and certain that no contract is

effective unfortunately we're not there with a scenario be realistic where the CIP is not included the hard work is made within a few weeks and then roughly like three months after that so like early summer well before summer a properly designed version of the EIP is launched because the only option mentioned so far was to the potential next hartford could be in October I think if we postpone this I mean if we take that asteroid the cassava fork and want to add it back at some later point and it has to wait

until the next Hartford so I'm going to doing emergency hard folks just to get this feature back in yeah I couldn't agree more so what we are doing now is going to like a fixed hard Fox schedule this means we have like at least two hard folks here scheduled I mean this is like two more hot dogs than we had last year so what's wrong was about waiting another half a year just to get in this proposal I don't see why we should have hard folks every three months this is like a huge overhead for the client developers and yeah I mean October is not half a year from there kind of what we debated for quite a few times already

that kind of nine months is more or less a reasonable amount of time to get features in and to properly test it so by wanting to do a hard fork three months from now we are essentially breaking everything that we talked about until now those perhaps not haven't been in that lot can quickly say what kind of timelines you are looking at for hard Forks like how many months before a hard fork or network upgrade do we need to agree on all earpiece to include how long would be the review time test face and so on offer II had a some kind of

scheduled timeline for that stuff I believe yeah I'm working right now and what I was proposing let me just quickly organize us before before we discussed port Powell and before we had this contention of the incident I was proposing a timeline for subsequent hard Forks so what I was saying is after a hard fork like Constantinople I want to schedule in subsequent hard-fought like nine months after this this means we have like another three of five nine three to four or five months to discuss proposals it should be included the deadline is

around five months before the hard fork then clients teams have one to two months to implement it and then we have tested hard for around two months before the maintenance scheduled hard for understood thank you so it might be interesting to add an additional like a specific time perhaps in parallel to the implementation but ideally after the implementation in the clients - - yeah test this more from the like let's

really try to break this perspective than just from the let's see if Ross doesn't diverge perspective yeah conversation on what to do about future hard fork and EIP inclusions and what security measures to take it I know Martin's been looking at that a little bit from a I guess audit auditability perspective I'm just asking because of the timeline and implications no no what I'm suggesting are like deadlines so we're saying we cannot have the tests not hard fork in less than two months before the main a type of because we need at least two months two weeks

there's a stable Testament and then we need another six weeks for like releases to be pushed to the user this is like the deadlines I've been proposing I'm not saying that there cannot happen anything in parallel so Felix was your opinion shifted anyway from what we just kind of described as far as potential deadlines ago and how long the next planned hard fork would be yes well I mean I just I think I have I'm just way less way less professional than all of you guys when it comes to making changes so I feel like yeah

certainly there's yeah I mean if the if you guys feel that you know this it's it's best to be very conservative and wait for a very long time then it's fine I mean there's it's just gonna be safer this way okay sounds good is there anyone else who's or is there anyone at this point who is very opposed to what's the phrase I mean I'm just way too tired to be doing this today - waiting for - taking out the EIP and having a hard fork and like 2 to 6 weeks yeah and actually we need to figure out if that's

the case how long until the next hard fork whatever we call it constantinople v2 or something offeree had you looked at that I thought I saw something written by you how much time we need to prepare another hypothesis yeah that that was the question I would say six weeks it's optimal because we have time to properly push releases for the clients and do it like some testing and thoroughly but would be nice to hear some opinions from from from the testing teams Keter so had an interesting proposal about

sort of how does like what to call this hard fork relative to the others and how to kind of update main net relative to the test notes and stuff so that might be worth also bring you know if it helps the decision hey this is Ben from the truffle team we're pretty close to having a variant of ganache that has the EEP removed for testing purposes yeah I'm curious if the meter is only called how long it would take to my eyes and then we generate the tests I'm here could you hear me yes okay so if we removing this maybe all we need to do is just to regenerate the tests to make

sure that no clients perform operation this way they do it exist yet people's not removed crying to not include this change regenerate the test and then see that all those other clients also behaving like this disabled on this plane so are we talking about like a couple of days or what do you think I mean yeah I think he'll take about a couple days what well to make sure that every client is updated I think one week all developers can use those tests to

verify their own clients yeah and after that there will be doing a black box I would like to propose an alternative to this whole rollout so as far as I understood this would be kind of redefining what Constantinople is meaning that we just removed the IP from Constantinople regenerate every test everything as if it didn't exist and go ahead and remove it from the clients only problem with the in my opinion is a huge problem is that Robson forked over and enabled this feature five months ago rinkeby enable

it give or take one week ago I'm going to worry about whether other private networks or other private proof of authority chains enabled it the problem here is that if we decide that Constantinople doesn't contain this and we just wipe it out of the clients and it means that we are going to break every Network out there that already had this feature enabled and well I'm not sure whether so basically we're telling developers that hey we're going to roll back five months blocks worth on Rob's turn so might as well chill drops them because it's it's useless at that point and the same goes for Inca be that it's rolling back but actually weeks worth of

transactions just to undo this seems like a really bad idea for me if we can fix it in a more elegant way and my proposal was that instead of removing this from Constantinople and wiping it we can define so to say a second hard fork which only removes this code so essentially every client would have at least clients that have tests that were capabilities would have would also in so basically would in half gone they would leave Constantinople as it is now just fork it and implement the net esto changes and then have the second I

don't know Constantinople to fork which disables this code path and essentially on main that we would Constantinople won and Constantinople to trigger at the same block and the effect of this would be that we could upgrade every private network every test network could cleanly upgrade and cleanly disable this VIP without having to roll back any blocks and also testing wise then we don't need to regenerate any tests we just need to add a few more new tests which verify that after Constantinople - there aren't any it's not enabled anymore it's a tradition and then I would add to this that later on when we reset all the

nest nets after a while maybe then we can really just simply remove that code right yeah no but what I mean is that it would only apply in for the test net so if we at some point in time reset all the test net because they become too big then that would mean that we can just move that code for the net store changes our scale would need to probably reach out to a community to make sure nobody's private network gets broken because I don't know we have the poor networks and X died and other networks I don't know whether they enable to Constantinople or

not so we kind of get more careful so X tiny neighborhood the view a so called chestnut a neighborhood they managed to pull up so hard walk on the main net of pure a network and also the common chestnut is affected so if we decide to go with Peters suggestion meat really do you have an idea how that would affect you just to make to make it clear is he suggesting to make two separate pork blocks so my suggestion is that we

define two hard Forks one of them is Constantinople as it is currently and the second one is Constantinople fix up that just disables this feature and on main that these two two forks would trigger on the same block on all the tests that works these could be scheduled after the water after we actually believe in you what is the difference then if it's happening on one block it's like just one mean that there's absolutely no difference the problem is that if we just removed from Constantinople then we instantly killed every single test not every single private network that

upgraded or attitude wasn't doable and by having two forks those who already upgraded we can they can do a second fork to actually downgrade serve the same yeah so it could save some time for actual preparing a lot of work because then we can get the often live quicker for this change right so it's understand tests will look exactly the same like Constantinople hard work and the test having AP design this we had some feedback from clients were actually

using Robson in a semi productive manner already for applications where they aren't required that much of security and then so I would be very careful with new king knobs and not underestimate the time actually needed to then start verifying if everything works again based off of an empty test network so from parities perspective Peters so Jetson makes perfect sense and we should have this Konstantin of the fix art for

transition at some point so we can also fix the Qi networks and koban so I would [Music] approach so the issue here is that it doesn't matter how we go forward in with may not if we want to keep rinkeby Robson and the other networks alive then parity and guests needs to implement the second heart for anyway so if they're going to be nicer to make it clean and not hack it in so if Constantinople fixed block number is exactly the same as Constantinople hard

work number then 4-minute it doesn't make any difference I'll just change the test but for definite you could use different work number and that's how you transition investment yes that's what you mean yeah exactly okay but there's I mean from a testing perspective there is no real need if we're tied for time to actually have the test cases for each 1283 we have to make the tests for not including the AP into

Constantinople I think what Martin is saying is that it can be as simple as just disabling the EEP and then generating your tests so yes there is no need to actually like test that you know I just know updates the test instructions yeah well it could be still Constantinople I see two different names so the the problem is that we so Constantinople was defined

with these features that's and if we create a new fork that just disables this then if we retain the name as Constantinople for Manor at least forget we have named Forks which means that for Inca be all of a sudden Constantinople name would mean something different so that's again you have these clashes that we could hack around somehow but it gets messy well it will stay in Genesis configuration file by Constantinople one and two ideally constantinople and something something something i know i'm open to suggestions i don't really care yeah we can we could call it constantine nope

[Music] yeah sounds good let's just call right yep ideally it should be a name that so on main that it should make sense so ideally let's use something meaningful considered how the public sees that a little bit which they are kind of waiting for the delayed constantinople fork so i think it's probably good to keep calling it this way i was just gonna ask where did the names tangerine whistlin spurious dragon come from i think Martin was came up with

those right I think we were goofing off if I recall yeah just some random words so what what we call it and what goes into the code doesn't necessarily need to line up exactly with what you know the public refers to it as so in the case of spurious dragon and tangerine whistle they were just called like Dawson mitigation the hard forks so just making that point like we could come up with a creative name I think and still call it Constantinople yeah that's not focus on the naming I already promised to each trade our communities that they can choose the future hard for names to be more inclusive but let's just go on the meeting oh that's a good idea cool so I like Peters idea who doesn't

like Peters idea okay let's do Peters idea yeah that's cool if Peters working yeah maybe so are we good there does anyone else have any other comments on that or any major objections or anything because I think that's a good idea and it happened on the same block and we can still do it in a timeframe of six weeks or whatever I think we also too sited on six weeks right was there anyone who thinks we should have more time I'm just actually can we calculate right now except what block number six weeks would be in a actually hold on what's the block number literally right

now I'm pulling it out go eight seven six six okay so 13,000 and then divide by 5500 so that number then one hundred one hundred thousand good way we have we have a difficulty poem coming up already I know I know we have a difficulty boss and I'm just figure out what that would actually look like in practice and so like let's see it would six weeks is 42 days so that seems to be very close to what we would get if we have put the

block number to be 7.3 million and I feel like going later than 7.3 million would definitely make the block time be a B to in mmm okay I'll rerun the simulation code and check when that block should arrive with the difficulty bomb factored in okay so what's the calculation for Vitalik the calculation was just to check what the was to check what the block number would be at that's it at the roughly six weeks from now on timeframe because right now block times are already am increased by about

something like nine percent from the ice age and so saying six weeks would say that we're willing to take two more steps of the Ice Age which would possibly push four times up to maybe playing in 21 seconds if we were to be more aggressive and say something like three weeks instead then we could then we can avoid a big step of that but then I think the rue-ing's is too aggressive hmm even given that people are all expecting it and that this is well I guess if it's not just removing code and

we're actually gonna be creating a creating an extra hard work that it's a bit more complicated yeah we're having to create new tests and we're having to do more client coding instead of just removing code I think Dimitri said he only needed if I remember correctly a week to two weeks for testing three might be aggressive could be target for maybe and presumably already need to deploy not Anton opal to one or two of the test nuts before being that this many fork needs to be deployed mm-hmm yeah okay so I guess either 7.25 million

or 7.3 million okay other comments on that I I still like six weeks personally because that sounds like enough time to get Rob stand updated anyone very opposed to the six-week timeline well just a quick memo about what you said previously Rob stone is kind of independent of this so if we go down with this to fork approach then we can update Rob's turn and the test nets

whatever so those are completely unlinked from a nuttin okay got it I mean I'm not saying that we should not update the test net first and then mean that's just that it's separate sure but this is a hard fork and the precedent is to update okay well we can decide the name on chat we can also decide the block number on chat because we'll say where I play six weeks from now and try to keep with the block number conventions of was it triple or quad quad zeroes okay cool try to want to be more aggressive just boy

well the chatbox has never programmed before then I guess oh snap and upper Taylor in there oh yeah you're right let's see so what's anyone else have any comments before we move on okay so post mortem how did this happen how do we prevent it from happening again I'd like to bring in Charles st. Louis to talk a little bit about the post mortem that's being created Charles's with the etherium cat herders and he was around the entire time the incident was happening this week so he kind of got he took some good notes and

the cat herders are kind of working on a post mortem along with a few other people Hudson we haven't ever shared the cat herders with this group do you want to just quickly tell them what that isn't working from I almost want to be a surprise or a secret but no yeah we should we should explain and I I kind of mentioned this like three meetings ago but we have a group set up now of about maybe twelve people total that go around and help take notes take surveys for the core devs eventually do some project management tasks around the ecosystem late how else would you describe that you kind of pin the blog post so you probably have better wording yeah I mean it's it's an initiative basically to

improve project management across the ecosystem and improve like inter team communication and so the only thing I would add to what you said Hudson is that these are all people with like many years of real-world project management experience which i think is something that we as a community have been somewhat lacking in and they're volunteering so yeah I think we'll see exciting things come out of the initiatives and as part of that offeree is going to be kind of hard work release coordinator and then taking some of the cat herders and having them help him organize for stuff so that's part of it and yeah that's pretty much what that is

so Charles do you want to do if you have any update on that I think we basically just have a document but was there anything else you wanted to add yes so there was a document that was just kind of highlighting the decision process for the postponement kind of walked through why we all chat about on the or getter and on the emergency call and it's just a document I could link it in the chat but mainly the kind of steps were identified that second factors involved in deciding to postpone or not hopping on emergency reticle then kind of deciding the decision window for boarding the network upgrade the emergency security testing analysis

scanning by gene security and then proactive in a retroactive action postponed and what we can do before it can happen and what we can do after that did we feel confident that we could get every stakeholder notified in time and then we made the decision it was mostly over the call if I recall then lastly it was how do we communicate the decisions to everyone so that being calms blogs social that kind of emergency comms and then we're at the process where we're deciding to remove the EIP on this call and then the last one would be rescheduling the hard fork I'm gonna paste echad in there if you guys wanted to know or comment on it yeah because it's open edit don't paste it to YouTube

or anywhere else everybody because otherwise it'll get vandalized okay so yeah and if you're interested in contributing to that Charles is gonna paste the link right now if you're a core dev or someone who was involved in this who wants to help with the post-mortem feel free to reach out to Charles Charles can you put your email in the chat as well yeah sure thank you so much great so that's what that is does anyone else have comments on a post mortem or was anyone else working on one on one I don't have a comment although I wanted to bring up something that we've discussed after Byzantium so it probably a lot of you remember that we had a

similar mess up during Byzantium where we had to do many many last-minute hotfix releases due to the basically we had the fuzzer which found a lot of bugs and we the problem there was that we were an apparently released two or three releases we also did one release days or hours before the hard fork so it was really crazy and back then we talked about that maybe it would be nice to have an untrained Oracle to pull the plug on on a hard fork and I guess this kind of it's not really something that people like to talk about because it's obviously a pain point which we got to centralization

that's why I myself never really brought it up because it doesn't really feel too right but it was up again on reddit so I I thought that it's worthwhile to mention it that not it's not really relevant for the upcoming Hartford but maybe for the one in October we could think about how to how to handle these scenarios well where something really bad happens and we need to pull the plug and we don't have 36 hours we have maybe only three hours left it's I don't know we I know whether this whole on chinoe Rock is a good idea bad idea from centralization perspectives

about a bad idea from a practicality perspective for graphs anyway I just wanted to bring this up that it's it's something that was mentioned quite a lot of times you know previously so it might be worthwhile to either say that yes we want it and this is how we can achieve it without people freaking out or be say it that no we don't want it and these are the reasons so that at least next time something goes bad and people ask us why it's not there we can point them to some rationale I think what instead of a centralized Killswitch each client maintained their own and had made their own decision coordinated but they respect only their own Killswitch contract Wow so that's

that would be even messier because then you have this client so in in practice whether clients maintain their own or separate ones that's not really a difference from a centralization perspective because it's still one team deciding and so the original idea was that if you have a contract where every client has so the sailboat and if I don't if if we have three five-minute clients everyone can vote anything the majority vote can actually postpone the fork that is actually the cleanest from the network's perspective because it doesn't happen and I don't know get Forks and parity doesn't fork and then we have a really nasty situation so gone sorry I was gonna say parity already has

an auto upgrade feature and obviously it's opt-in so I don't see any issue with this if it's as long as it's an opt-in thing that a node operator can turn on it doesn't change any of those centralization decentralization of the network I think it's important goal behind a mechanism like this to kind of state the intent which would be to make the decision whether or not to go along with a hard fork a conscious decision in the knowledge of you know security for our exploit like this happened the Sun run so if it was more of an automated switch some people might be more acceptable so the problem is that for

example gate also had upgrade Oracle's where it we bumped some numbers in a smart contract and then get started logging messages to the console that there's a new version or something the issue is that realistically not many people look at the logs so it's just boring set of August on you don't get up every morning and see that who did my node lock something interesting and I guess most people run these a theorem nose in headless modes on some server so it's I don't think many people have a UI on top of or directly on top of it so it's a it would be I don't think it will reach many people if we start messaging I guess the clients were implementing a

configuration option whatever makes it the clients are still watching consciously I think just the point I'm trying to get across is it's not really a centralization mechanism if there's some conscious decision person willing to go along no I agree that that would be a the best scenario for example if the client would signal to the user that hey there's this decision do you want to opt out that would be a real nice thing to do just I don't really see that viable for example if in Fuhrer has 45 nodes and then how do those 45 nodes

signal that hey I would like to opt out it Sam from that perspective it's a bit messy but yeah anyway I don't want to hijack this discussion the reason I wanted to bring it up specifically because it's not a simple task to solve and if we can solve it well then I think it would be a welcome thing from the community if we can solve it well then it will be just a horrible I think so it's long term it probably something to discuss to clarify we're saying it's just I'm thinking 99.999 opt in to what this groups consensus is if I'm running a node so

I'd be happy to flip that flag in my configuration ahead of time and then in an exceptional case be willing to have to be diligent so the degree to which I care about being decentralized yes that's kind of a I also agree on that if if it is something often I can imagine that many people would prefer to opt in rather than to have to watch their computers and install updates at the last moment okay cool thanks all right awesome yeah we should we should

definitely be kind of iterating on those ideas a little bit let's and I just reran the simulation with the latest numbers can we just really quickly go back to blogger and block time again cool so with all the latest numbers including the current hash rate it looks like we had 32nd blocks at the end of April April 27 which is between April 17 and 27 so that's kind of what I said earlier so that's good and then we talked about six weeks from now batalik suggested blocks seven point two five or seven point three million seven point two five million looks like it would happen on February 19 and seven point three million looks like March second so if we want six weeks from now

today's January 18 we want the end of February so that puts us around seven point three million is that that is what the Telex said so that's March second seems like it's a bit more than six weeks so we could always do something in the middle like seven points Unitas it was seven points you eight or whatever yeah that puts us at based on the simulation February 26 or 28 okay cool so we've narrowed it down to like a day I'll figure out the block number sounds good it's it's gonna be a little harder to pick a specific day given the bomb

because as the network hash rate changes the speed of the bomb changes but we'll do our best well yeah but I guess that's kind of the point of picking Wednesday so that even if you have a two day drift it's still in the middle of the or I mean it's still on work day all right that's good great is there anything else that we have left to talk about with regards to the Constantinople upgrade again we're gonna be naming the second one in the core def chat and then or we're I think a free mention maybe earth trader deciding I kind of like that idea personally and then what else was gonna say Oh Oh free for you and for your planning of

the road map and stuff like that were there any other questions you had or things you wanted to say for Constantinople specifically no okay sounds good the next item is Prague town and we actually have I think we have if death and else in here so that's really awesome before we go into whether or not we are doing a Prague PAL hard fork week we tentatively decided that was it last meeting last meeting feels like forever ago I think we decided at last meeting but since then there's been some community feedback about it so I wanted to make sure that if death and else were

able to respond to that community feedback if they had any updates or commentary and then also just Reedus cus Prague pal within the group so um welcome if death and else and feel free to start out with any commentary or updates you have so in the past two weeks since you guys can hear me I'd correct okay yeah in the last two weeks since there was tentatively decided to go ahead obviously there's been a lot of community feedback and also a lot more testing the the Gangnam a testing that has quite a few clients on it now that

are getting some pretty good hash rates one interesting development that came up was we've discovered a what appears to be an AMD compiler bug so absolutely once in a while as we generate these random programs the ambi compiler just completely missed compile with it and so AMD hardware will give bogus answers for an entire period the next period when you get a new random program it compiles it correctly were actively engaged both our team and also some of the east minor developers with some AMD engineers trying to root cause this and see how we can mitigate

this issue to go ahead some other feedback that we've gotten is that the the there's a number of parameters that thun talked how how much compute how much memory it uses and the tunings that we've set turned out to be a little bit too harsh for AMD a little bit to compute heavy for some AMD hardware so we have a recommendation to tune it down a little bit we move about 10% of the compute workload that has no effect on some AMD hardware it has no effect on any of them video hardware we've tried but it does help some of the ambi

hardware that's out there in the ecosystem to keep the playing field fairly level I think that's the only major updates we have ok does anyone have any comments or questions outside of if death else for them or about this what's the preferred channel to give these feedback is it the disc or is there some other github we should be talking to what's the preferred um the east minor dev channel has turned into a somewhat unofficial Channel we could also start a our own getter

channel actually that's probably the best wolf start our own getter channel their words the authoritative specification locations because there's one an EIP there's one on if that else the test case on the lawn if else is actually out of date the test case honest FL should be up to date last three days it's not oh I will make sure that we get that fixed so I have many questions like this so I get her or a formal channel would be something that I would be their agency yeah let's let's say

a getter with 4f Steph house that will be the best place I'll start that right now wonderful any other comments questions stuff like that I think the biggest community feedback that I've been seeing lately is that that this decision was potentially rushed a little bit not enough time given for discussion but even the bigger argument than that was that AMD's video cards are affected so I'm glad that you all are looking into that and fixing it with AMD and yeah good good work there but yeah I don't

think does anyone has anyone have any proposals to change the decision it was tentative so we still can but as of right now we're still going ahead with an eventual prog how hard fork yeah anybody have comments or anything yeah okay I'll just go ahead so there's been some discussion about you know proper claims sort of features such as a certain level of let's call it a secure systems and question if it upholds those claims which is very technical discussion but then there is the other

discussion because these claims or features the acid resistance relies on the kind of assumption that we don't want asacs on the network and that a level of asset assistance is something worth striving for I personally kind of assume that naturally that's what we should aim for because that's what one of the early goes with eta each hash but it appears that there's been well it appears that this is not well this is not a technical issue is more of a

political issue and that's been there's been lovin this Russians about this should we strive for a secure assistance and it should how much pain are we willing to go through and is another right way to reach that I believe so but yeah I'd be willing to hear other viewpoints on this can I jump in you guys hear me yes we can hear you so I'm coming from the perspective but we eventually want to end up off of proof-of-work entirely and that's one of the motivations for developing this

could you get a little closer to your microphone mr. death yeah I'm coming from the perspective that we eventually want to move off of proof-of-work entirely sorry with the understanding not not and I'm trying to support that decision if that's not the direction that we're going in I think some of this discussion becomes less interesting assuming that that we're trying to move to a system that we're not going to be doing proof-of-work I think the most imperiled system that has been the status quo that you can

observe from the last two weeks after the initial announcement of a tentative consideration for the progressive proof-of-work what it motivates those possessing Hardware on either side on either the existing status quo with GPU mining Accor with those who are making or have made Asics how that motivates the conversation to kind of take non-productive angles if

you will I think that's just the exact type of negativity that we're trying to avoid eventually I think the problem that we would like to try to help with is to minimize the economic incentive alignment of particular hardware holders or of any particular hardware ecosystem to the development of the network as a whole I think it's super important to preserve the independence and the

ability for aetherium core developers to continue making progress in technology and enhancements to the network and it's very unfortunate if the network hash and the neck network security model becomes unaligned to a particular type of system or a particular specific set of owners or miners or something like that now that said I mean even there's there are even problems with the status quo right I think it's been correctly remarked that that AMD and NVIDIA and

there are not enough particular independent brands or makers of the existing GPU a64 for the network and and thus may have some a lot of economic alignment issues there I think that's a valid argument to make taking that same line of reasoning I think the existing status quo also already has the best let the least evil if you will because it is the most

distributed hardware compared to any other ASIC that's available or even FFP J's or at what what have you right in terms of the economies of scale that people have pointed out in the ASIC economy and make terms of the distribution and they can economy of scale being aligned to a wide and massive distribution base and a very good availability in terms of fairness and availability fairness of distribution fairness of market price the status quo already has the least evil of all the evils and so that was kind of the the starting point for for

our development and our rationality working on this um beyond that I don't think the goal is to necessarily try to win for one particular hardware or another because I don't think necessarily that Hardware any particular hardware maker or owner should necessarily win in the end but I can understand that that might be very unpopular a very unpopular or very negative thing for existing miners and existing hardware ecosystems I just very much hope that we can contribute a

little bit to be continued independence of aetherium development okay thanks for that does anyone else have comments questions comment is that I would like I mean I don't how people perceive this meetings in terms of major decisions but I would like to say that I'm abstaining from making a decision and so my silence should not be counted as a for or against something because I personally believe that this particular call is not the right place to do to make this decision in the end and I will just

explain my perspective is that I'm not aligned with any of the kind of basic or not ASIC sides as some people might have suggested because of my activity in terms of discussing it my only sort of point of view is that I have taken on the task of kind of developing and sort of designing the one of the parts of this theorem one point X which is the state rent and I do understand that the more hard Forks we do have planned the harder it is going to be for us or to me personally to do this job that I've taken on so that's my main viewpoint and therefore I that's

that's the explains my sort of interest in the issue otherwise I'm not really interested in kind of arguing with with minors or with ASIC manufacturers or whoever that that be and I also wanted to point something out is that although some people say you know if you don't like the hard work you just you know for it off and then you do your own fork I I would also say that this is not the correct advice because it actually depends on the entities that fund the further development let's say that the whoever does the fork you know the theorem foundation for example possesses the ether on both

sides of the fork and whatever they choose to do with that then it's it's actually determines the the chances of any of the forks winning so that's why I think the you know that that's why people kind of appealing to this forum for particular for a decision because everybody know it's not formalized but people informally know this is why we're actually making these decisions here so that's that's it for me I'd like to jump in and also pack that up and I in principle also agree with less Forks just an observation I I think more forts is not just hard for

developers but it causes discussion and and it causes charity anyway so so to the extent that that there's an many much earlier thread saying that if a proof of stake could just be implemented in the short-term we should go directly to that and I wholly agree I mean there's if if basically progresses proof of work is only going to be in effect for a month or two before everything else is ready then there's kind of no point and an extra fork is not a good thing that said if the development team of the folks meeting here believe that

there is a longer a more arbitrary amount of time needed to get a proof of stake working correctly then I think one of the mechanisms that is built into progressive proof of work is in effect it's basically a bunch of microscopic forts that are not hard forced right it's actually the evolution of the algorithm or the changing of the random Mac and the recompilation is basically changing the mining algorithm in currently a 50 block step but maybe we change it to a shorter time what what people do to do basic resistant Forks I

mean that that is the mechanism that that underlies the core of progressive terrific work so it helps eliminate but the need for at least algorithmic to look for King for the algorithm or the mining algorithm so it maintains a basin and then you're just doing a bunch of continuous Forks all the time in a predictable and and well-understood manner um and actually with regards to that the next thing if we have time was probably gonna be the POS finality gadget on the pouch Ain but Danny or metallic do you all have any kind of words on how fast things are coming along not like

necessarily like oh it's gonna happen on this date but anything like that so I think that's relevant here is that we're designing the protocols so that the be the beacon chain will be and of usable as a finality gadget for the proof-of-work chain if people wants to so that well that would basically give the the same security property is that the original kind of pre beacon chain dat hybrid Kaspar if she was going to go and that's something that'll be out and not focusing on timelines before sharding and before and ever before

state executions though so that would basically mean that if that if that happens that if everyone is listening to the approve of state system Pro finality and if enough people are participating that it's actually secure then a 51% attack on the proof of work will basically be able to censor but it will not be able to revert anything finalized yeah no realistic way don't expect this within six months and adding the

finality gadget from the beacon chain is probably not it wouldn't happen at initial launch we'd want to see stability on the beacon chain and kind of an increased security over there before we would be part of the bijon chain code immediately it's just no one would necessarily we'll listen to it immediately correct but the follow distance at the beginning would also be really long and we would want to choose yeah that's true Vitalik I'd like to ask your opinion in terms of the sensor and not reversal comment the if you have a persistent censorship for some

percentage of the blocks being censored censoring a certain type of operation the chain have to basically be be less effective at that point and cause basically a crisis anyway if if there's a if there is a censorship 51% attack and if the attacker is persistent so the attacker doesn't just go go away on their own after at one or two days or whatever then basically if we the only thing that we can really do is well if we know the attacker has a sixth and we can change the proof work algorithm to cancel DeRay six and but if

it's a 51% attack that's run based on basically GPU hardware then we would really have no choice but enough scramble as quickly as possible to my greatest some kind of primitive stake or just chain don't algorithm entirely attackers using GPUs that we know there's another avenue actually so I've been thinking about and researching the ways to way to avoid this kind of situations regardless of what kind of miners we have like a signal ASIC so and I thought about there was a proposal on the BTC

read it a bit from this guy who wrote the mining farm in the US so he essentially proposes to modify the the fork choice rule in in that case in a Bitcoin cache but in the in the in our case could be in the theorem 1.0 so that in the long term it converges to the same fork choice true but you know short term it could favor the blocks which are not censoring for or the blocks are which are not trying to revert so essentially even if the attacker has a six and so it would still be beatable if the the network agrees that actually yeah that's that attacker is actually censoring because they can compare the transaction pool with the

blocks and they can figure out whether the censorship is really going on so while it works that works okay if your goal is to prevent a short-term 51 percent it's a short-range 51 percent of text but if you try to use like like if you try to turn kind of banning censorship into a floor into a four choice rule components then that's our that starts to become scary because an attacker can do a head of network splitting attacks where they can kind of sensor just enough so that half the network thinks it's fine half the network thinks it's not fine and at that point the attacker can just start reaching a huge amount of havoc and so I

would probably recommend of not trying to go in that direction at least like the only version of that sort of thing that I would find secure is probably something based on combining my and the 99% fault tolerant consensus approach whichever which requires a basically clients and like all the nodes in the network to be online with proof of work in some way which could be possible like properly researching inspecting you know it would take a huge amount of time so I want to jump back to an earlier point about GPU versus ASIC 51% attack its theorem currently is is resistant by the

virtue of it being the biggest coin biggest work consumer on the GPU type of ASIC right in any case in any sort of hardware specific algorithm or an algorithm what more correctly said an algorithm that can be made optimized for a specific type of hardware yeah only the only the biggest work consumer that consumes the most amount of that hardware is ever protected so so by changing the algorithm to some other algorithm what whatever Hardware and affinity it has the that that algorithm

selection would only be protected from a 51% attack if the algorithm selected was the biggest work consumer on that type of new new type of hardware and I forked to a new an algorithm that requires a new hardware to be made well first of all that algorithm initially would probably most likely be best mined on either something programmable right either CPU or GPU or something like that perhaps FFF PGA's but so so it would still be you know attackable if it was originally attackable it would be still

attackable and on programmable hardware if it was forking to a some sort of optimized ASIC algorithm then you immediately run into a distribution problem where the first to produce gains economies of scale and gains leverage and also limits you run into a limited abilities a scaling hardware is always hard right it's not like software you can send it all around the world and any any piece of soft hardware that can run that software immediately gets it just distributing hardware means shipping something somewhere and some manufacturing lines spinning out so there's always going to be a narrowing or or basically you end up putting

yourself on a narrow bridge or a narrow path that that becomes very dangerous all of a sudden if you remember would switch over to some ASIC friendly target and then for example an elegant solution would be to announce it that one year from now or two year from now we're going to use this ASIC from the algorithm and that kind of gives everybody ample time to use all these problems out yeah I'd like to speak about that a little bit I think another person in the community has already

talked about proofs of scale sorry economies of scale and I think that's a very important point that we all understand so first of all there is economy of scale and then the same person referred to manipulation in terms of partnerships in hardware manufacturing in China and both of these are very very real so economies of scale obvious term first in names you have the advantage and you can leverage additional profits from the initial sale whoever is most efficient to basically have a pricing advantage and a manufacturing advantage for whatever initial partnerships they've

started a first mover advantage I mean everyone should be familiar with that and in terms of production in in the Asia and eco system once you've established a money-making path it these relationships become very well cemented so equal technology even if people have an equally efficient to to competitors have an equally efficient basic the natural evolution of the production economy is that you have one dominant

producer a second competitor and everyone else being terribly far behind study any sort of stable production ecosystem I mean look at a beer look at paper look at any any physical good look at its it's very obvious that the consolidation happens very early on and especially for narrow things with narrow demand and specific very specific purpose special purpose to me then you end up with very tight alignment of economic incentives to preserve one particular path furthermore you have manufacturers that end up say

it there's been an argument that says well some it's it's either bad where you have too much complexity and and only people that are well-funded can can make progress or too little complexity where well if only economies of scale dominates well actually it's it's not either or both of them will be true right you're always going to have someone who has a technological advantage either in the ability to optimize for complexity or a technological advantage in being able to drive either to a lower process node faster or an economy scale advantage it's always going to be the case that

there's in a hardware ecosystem you can't pick your poison all three of them are poisoned we're having to wrap up the call here in just a minute or two but feel free to just wrap up your final thought there okay so that's that's why I'm more pushing for this to thatis quo if you have an ecosystem that you already know is distributed it's the enemy you know and you given its it's already stabilized in kind of trading off all of the benefits or sorry dealing with all these damages or difficulties of a hardware ecosystem and ameliorating that because those incentives aren't aligned to trying to manipulate the

etherium chain right there already aligned to going to win a different market cool thanks for your comment there so something that I just want to bring up before we sign off alexei mentioned earlier that this isn't the right forum for or this is a bad form for a decision for prog pal and I actually agree with that I don't know of a better forum but that is something that the cat herders said they want to try to look at and just evaluate and see if there a better form or decision making process for that if anyone else has ideas feel free to shoot them in the awkward devs chat because that that'll be very helpful and it's something else that was

brought up to was that the people who aren't commenting on the call about the proc Pao decision or tentative decision is because the they haven't formed an opinion yet or it's kind of out of their wheelhouse as far as this hardware stuff goes so I think that's kind of an important thing to keep in mind I would say that we will need to continue this discussion in the future I don't know if it'll fit into the next cordon of call or not we'll we'll try but I do want to thank if deafening on and providing their perspective and answering questions and things like that do you have any final comments to just wrap things up we're a little bit over time but if anyone had anything they really

wanted to say sorry had some I'm jumping above a Canora again there right now wouldn't it be nice if we can agree on a block number for Constantinople today yeah and Lane actually put in the all core dev chats yeah yeah I'm proposing seven to eight million the simulation changes slightly depending on like two variables which are the network hash power right which could change between now and then as well as the current block time but we did some sensitivity analysis and it looks like 7.28 million gets us pretty close to the target and and as someone else proposed I think we can maybe go with that if people are okay with it for now as a tentative

number and then once all the clients are updated reevaluate in like two weeks or something but why not why not do finally do that thing that was suggested a long time ago and based a fork off of the block timestamp because you know now that would be even more helpful I can tell you because it's quite an and what changed and the clients and it's nothing we can probably do within a couple of weeks there are also some really weird corner cases where an uncle block mind after the fourth good action so you have the problem with that at post fork block might have some weird uncle blocks with beers time stamps so validation gets really really messy okay I'm good with

the block that Lane just suggested anybody else anybody opposed can we also figure out the block for UPS tandem made me a couple weeks before that it would probably have not to delay two more weeks I mean picking the block yeah let's do that in the court of chat unless you have numbers ready or a suggestion nope okay great well we're definitely over time so I want to make sure we respect everyone's time and wrap this up thanks everybody and we will talk to all of you and about Oh actually are we talking in two weeks or is there gonna be that in-person thing when is that oh that's just the first okay never mind we're good okay

thanks everybody bye [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music]