All Core Devs - Execution #46

Transcript

[Music] [Music]

you [Music] okay hello everybody I think we're ready to go I think we have a good representation here or the only person we're really missing is Dimitri but if he comes in later we can go to back to testing so let's go ahead and go to the agenda okay so we'll skip testing for now and then go into client updates we will start with parity and this is not

necessarily Constantinople updates will probably go through that separately but if you want to go through that now either way I guess yes thanks Hudson actually Constantinople is first on my list I just go through it because parity client is ready implementing all the IPS we merged everything we have tests at least let's let's talk test later so for now we can basically switch the flip in parity and start testing it so that's what's new regarding Constantinople what it's we have like some stretchy

discussions for parity we consider replacing WAP sync with some hybrid client mode instead we are considering two or three stage clients so imagine you start the parity serum node and you it will instead of starting to shrink from Genesis it will pop up a light client so you have sensitive workers when you started immediately and it will do a full second background we also consider maybe not replacing warp sync with so hybrid client but having like a Swiss stage client that starts up a slight client table swing in background and then a fourth one swaps with Gaston

but that's all just ideas the backwaters that we need to think about alternatives because the state is so big that even warps in takes like two hours now and that's quite loses the point of being war PA at all you know and another problem we want to address this is actually removing our ancient block synchronization which is not not a fully verifying block synchronization but just checking the proof of work and I personally would like to see this replaced was a fully very fine synchronization mode but that's just or ideas we have no concrete plans to implement this yet main problem is that

we need to stabilize lightly at first you know what is we have a light wallet it's called feather it's the lightest um wallet to do basic stuff like easier transactions or tokenization it's an early iPad for everyone interested I would say let's check it out yeah still we need to stabilize so light friend yeah okay cool thank you um real quick question about the feather wallet I thought that I saw a blog post about two or three months ago saying that you guys were dropping the wallet in favor of only doing production-ready

CLI clients for people like exchanges is this kind of a different path now or is this separate yeah that's quite a smart project it's a very light electron app that allows sending easier and tough moments that's it it's it's like a very small utility you can put whatever it's IC just just sometimes you want to have a quick way to send tokens oh okay cool thanks for the update

and then let's see what do we got next Oh Demetri showed up Demetri we're gonna go through testing after we go through client update and let's go ahead and also talk about our constantinople progress with the client update it'll be better to just combine the two I've decided so next we'll go with death I think that would be Martin I'm sure by the way that work may vitalik welcome was hoping you would make it I don't know really if we had anything you need to mention here except for yeah we're lacking to two things for Constantinople it's a minor word

reduction and it's a four changes I'm hoping we'll get it in within the next couple of days yeah other than that it's ready in as far as it can get can be configured in Constantinople mode and run this day first and stuff for Constantinople so we can get casting on okay awesome next we'll go with Trinity I think we are in roughly the same boat as gift we've got to get we got two more issues for Constantinople issue its reduction and the changes to storage costs I expect those will get spun up you soon

we're kind of in the middle of a larger internal refactor to speed up our our sink processes which I think we're looking at some notable improvements but I don't really have numbers right now for how big those are getting but chipping away at the performance numbers to get towards a client that sinks in a reasonable time so I think that's what we got okay thanks so much and you sorry did you give a Constantinople update - you said you had a few more to go yes we've got two outstanding issues issuance reduction and I can't remember the number but the changes to storage costs okay great thank you

Aleph hi so we also finished all the peas and Clemente ssin for Constantinople now so and it is ready now for Dmitri to generate the tests for any ap yeah we also fix the issue reported by Martin last week about the case with address collision when the account is considered empty by the protocol there is it has zero knowns it doesn't have the code but still has non-empty storage which is very theoretical case but we have some

tests affected by it so I left behaved a little incorrectly in that case and with extent and the tests were generated okay atheria me J we've been working on Constantinople and we have a store gas price reduction so far it's been merged and we also have implemented skinny create too but there is one test failure so working on that it's not yet merged and one thing that is left is difficult to bomb delay I guess it's pretty

straightforward so I guess we will have it by the next week and the next step is to work in testing to make sure that theorem J is hard for compatible I guess yep the next week or the next two weeks we'll be ready for for the fork that's it okay thank you Nimbus so we enabled general state tests in Nimbus and we are now passing more than 500 but we noticed that several are assuming that gas is

you int two five six even vogue F and PI VMI using in 64 so we'll be looking for some feedback later we also started working on some pre compilers and for cryptography we are looking into more tests vectors for the alt BN 128 curve because it's a kind of harder to to find regarding p2p we now have better block downloads and can request a range of

blocks and regarding the research on the earth 2.0 and we've implemented as for choice rules old one and we're looking into integrating it into the become chain 2.1 cool that sounds good thank you turbo gas hello so yeah I have a I'm not working on Constantinople here but there's one thing which I kind of I think I've combined some of the earlier pull requests for the net cast metering

into turbo gift and for the reason I'm gonna explain now is that I've changed the database layout again to support pruning you know kind of trivial way and you know I also when I was testing RPC I've noticed that I've been writing the some records in history with duplication so this actually the net gas metering implementation helped me to figure out the duplicates and when I remove the duplicates I've seen another really big reduction in a storage space so probably gonna be about hundred gigabytes less they for the archive node so and the I also changed the the records so that they reversed ifs rather than forward

ifs which means that I can very easily implement pruning we just throw in a way that the the old history without any other changes so and also I was actually starting to look at that that there may be supporting some kind of work sink and I'm gonna be very interested talking to priority guys about this maybe make it sort of compatible or something like that and so yes I fixed most of the RPC api's like the transaction tracing storage introspection ballot balances and generally I can see a very big performance difference I like for example the the transaction tracing is

about 10 times faster than a gas and storage introspection is about 100 times faster but some of the other things that I haven't measured yet the interesting thing is that I also try to remove the the storage receipts to not store them at all to reclaim another maybe 40 gigabytes and at the moment it's works on the same level of order of magnitude as the guest running kind of restoring that the receipts from the storage but I also noticed that a lot of time is actually spent on recovering the sender from the signature so that is a well there was another interesting investigation that I did here so very

soon so basically to be guess is pretty much ready but it needs to be a bit polishing so and I was going to be the point until within fewer than maybe in a week or two to start the first kind of real life testing so that's my big awesome thanks for the update so next up before I go into II wasman research is there are there any other clients that I missed I as aetherium J s here okay yeah are there any other clients I missed otherwise we'll just continue on to he was them and that'll be I guess x ik

yeah so we have a Wabble VM which you're working on it is called Hera and runs through the e BMC interface that means it works with Aleph but we have a fork of goethe room to use it in go atrium as well and we made a significant progress in discussing that change with the GUI theorem team and hopefully it's going to be integrated into Goethe Liam soon in a matter of weeks second to that we and in this VM actually we support multiple engines for executing wasn't itself and so far we have three engines two interpreters and

one jet and having this in place enables us to focus a bit more on benchmarking and that is our next next big focus to benchmark pecan pies so basically all the main a tree comprised implemented in wasn't benchmarked those between these three big engines and the main results we expect to have is have an understanding of the performance between a jet and the non jet was mentioned so that was most of the work we have done in the last two weeks okay cool let's do research next so that would be Vitalik

and then Danny sure do you guys hear me yes we can so on the research side I think there's just been slow progress on kind of polishing and refining the Kaspar 2.1 spec so and there's also been a lot of progress on getting that implemented there's been and I know there's been considerable progress on the plasma side

but that's kind of less directly related it's a core client development so I guess all in all it's been relatively cool relatively quiet this week okay Danny I've if you have any other further updates that'd be cool but also at the same time can you kind of go into what the ëthe implementers 2.0 call is because I've been seeing that pop up and I'm kind of curious what gets covered in there and if people need to contribute or tune in right right so we I think we've done for these two implementers calls we do them every two weeks we're doing every other week out of the core desk calls but then the core death call

had two in a row so we have it on Thursdays we got it yesterday any of the people on this call are certainly welcome to join I know after he was came yesterday is kind of first representation for parody it's an effort to begin implementing the v2 one spec which is the beacon chain which is going to be kind of a new component of the protocol developed in parallel to each one o for the time being definitely the spec is the bones of the spec are really solidifying and we're kind of just doing minor refinements and additions at this point rather than kind of quarry right so if your team hasn't

taken a look it's probably a good time to at least familiarize yourself with the spec at least what's going on with that and make a make an informed decision whether it's time for your team to maybe start looking at it and if you want to hop on a call with me to discuss the architecture and kind of the design decisions anything like that I'm very happy to take that offline as well okay thanks so much Danny and if you could in the all core devs chat at yeah exactly post the spec to Casper that'd be great so the next thing let's go back to testing so what we're trying to

accomplish today hopefully is to get a block number for Rob stone or basically a rough time like number of weeks or so that we can actually for crop Stan to start testing constantinople but that's gonna be very dependent on testing it was dependent on client implementations but it sounds like by the end of next week everyone's gonna pretty much be done so I think that when I say everyone I mean the major clients who like death parity and harmony should be done and the less so what we should probably do is the I try to decide a block number but let's get a testing update from Demetri and

Martin first Dimitri you can go ahead guys I posted earlier today and post which test cases we still missing it's about more coverage around store changes it is about X code hash which hasn't been updated by Jared for a long time and I think I will and of those myself and we don't have transitioned tests in the form of block chain test and difficulty test was a bomb delay it's not done in a block in this form and then just formula check and I heard about fastest been converted into state

test this is a really good idea if we could do this it would be really nice what else I finished creating create do tests it's now in a repository and action executed in hive they found a couple issues with Martin and discuss those what actually every client could now pass the current create two tests that we have also if you have an idea please add a new test cases this is still open although I can't received any updates from you what I hope maybe when you start implementing those you will

add some what else I'm ready to start to review all of the existing tests and regenerate them with a constantinople version this is a process i do before every hard work released all of the contests are being regenerated my tests eat the current Aleph version and if needed constantinople version is added and if there are some issues i will be fixing those issues so i not really know how much time it will take i think this is all of the testing that we need for now ok and martin did you

have anything because i know you've been dealing with height lately yes so as far as i know i mean hive is running on there are quite a lot of failures I know I think it's emmerich and peroxide is looking into it to their failures and I'm looking into white and guess it's failing a lot of creative stuff I was not sure if they if the tests were generated correctly but as far as you know to make sure they are now correct right all the tests in May that's triple all the create two tests you mean yes

and we just have you see about hypothetical scenario is all create collision and yeah there's just there are a lot of things of 52 failures forget which I don't think everything comes from that so I'll have to dive in a bit more about that regarding first testing yes so we have a large corpus of data from their foster which have been now converted into state tests and we will try to execute those against clients that can do state tests and I'll probably check them into repo somewhere not marching today asking a question at this point sure those state tests that I'm generated from corpus

well as those in a feeler format or is just state test format they are in the ready to run formats what Foreman well they're ready to be executed on the client they are not in generalized form not oh not only fielder foreman right no cause if it's possible please now create a killer format yeah week afterwards cuz I yeah hospital what exactly do you mean other than that we also have a we don't have the Lib fossa running but we have

the EDM lab-based posture running get the parity then there it is not switched over to Constantinople yet but it's that's another to do and I'm hoping to have all the fussing properly roaming oh let's say are the next week okay awesome so all things considered I guess let me see here so what we were trying to do is trying to launch Constantinople before Devcon I don't know if that's still possible I can see a timeline where that is possible but I don't want to make it

so that this is unsafe or that the pushes people too hard to get certain things done so as far as Dimitri in your opinion how much longer do you think if you have a number at all if you don't that's okay but do you have an estimate on amount of time testing should continue before we potentially fork on to rob stone I think a couple of months at least and we have upcoming Def Con conference or is that my delay the progress okay that sounds good in that case right sorry Dimitri you said a

couple of months so was that a couple of months before we do the Robson Fork yeah I would I think it sounds a bit overly cautious because I mean Rob's them it's a test and oh I prefer we run it longer on Rob's them yeah I still have a lot of tests to implement in my list that's why this date okay yep does anyone here really care if we don't really I'm not judging I just missed curious I'd argue

that there is that consensus issues on raphson happening from time to time is good because it rains I'm ecosystem participants on how to react to them okay so we could technically for crop stand before DEFCON but then not release Constantinople until after DEFCON that sounds like a good and between but what if some like that developers are testing on Rob stand when we just break order workflow just before death Khan I think most people trying to demonstrate stuff for Def Con I suspect

they won't be using Roxton but either semi private network or that they will be using a colon or ring to be because Roxton has issues and I've had them for a long time I may be wrong though it's correct me if I am i find people use rob stand less and less personally that I've seen yeah it's all about ring Fiat kovin okay so in that case is that he want to post the idea of forking Rob stand before DEFCON and then figuring out after DEFCON went to watch launch Constantinople hopefully before the end

of the year I don't know if this is what you meant Hudson but I'm curious if we've retired what was it that came before rots Robson whatever it was I bought it at you so like we retired Morden at some point and Robson feels like it could be retired I'm curious if we launched a new test network sometime soon and then did the fork on that one with the plan to just completely retire rinkeby some benefits that I see from that are it being a younger Network makes it easier for clients to reset

catch-up and run through the fork whenever we do actually have the fork scheduled is there a benefit and having a very mature blockchain as far as amount of blocks that have been produced when doing these test cases on something like Rob stone so I mean there pros and cons I know that when Peter has experimented a lot with sinking protocols and yeah in that those cases Robson can I mean it has data so it's possible to simulate how sink there's

also benefits to testing on each team that has lots of stuff happening on it because the the gist creatives that wanna watch something could you repeat that last part Metallica you cut out I was just saying that there are benefits to uh testing on each chain that has a lots of activity happening on it because it's often the activity itself that this discover we kind of lost you there again but I think I heard what you said

basically there's benefits to having tests done on a chain that has a lot of activity on it because more things could trigger a consensus issue yeah okay hmm this is interesting anybody else have opinions on this so what's the what's the major Pro of starting fresh is it more to have it sink more quickly or oh yes yeah Piper you had given another Pro I just forgot

it um I mean that was the primary one was basically that Robson's been allowed round for a long time and and we have retired a test Network before I've always kind of assumed that we would retire Rob Stan at some point and and kick off a new one so it seemed like a pretty good time for that but they tell it does have a point anyways yeah that was my my intent was was something that was easier to pick up from the beginning and sink through where the fork is I think it's it's a kind of a balancing act because as you say that if you if you have a users on your test net and they're kind of happy then they create a lot of activities as

Vitalik said but if you make it too unstable they will go away and then you won't get that benefit so you have to kind of keep the balance somehow not not to do too early but again so that it will definitely break but not too late so that you do lose advantages and if we were to do a new test that right now all the clients would need to update to support that new test net and then everybody who wants to use it would have to update their clients so that's not a bad thing but that's just something where I don't anticipate that everyone's gonna update their clients so Rob stone for the time being even though we're not

really supporting it anymore I should say so yeah well there would there be I guess there's there's income there's issues with adoption is what I'm kind of seeing well if we're looking at multiple months before we think that we're ready for the test net hard work according to testing then rolling out a new test net sometime in the next two to three weeks gives us an extra month and a half or more for that new network kind of spin up and populate and like you said it doesn't eliminate robson from from the table so it would mean that we could work on our

new test network and then potentially even work on robson if we felt like there was a benefit from doing it on a network that had more activity yeah that makes sense so how much work is involved in starting up a new test net um I know I think Casey did a lot of that last time but I think he's real busy with he was on and then something else what else has to happen I guess we just set do we just set new parameters and then just go get miners to mine on it I may I leave a comment here do you think having to proof-of-work

chestnuts was beneficial for the ecosystem because maintaining one proof-of-work test net is already like hard to incentivize - to mine non-bio bearing shane and now we be proposed to have a second one I don't know if this is something we really want to do yeah the idea isn't that we would support both of them the idea is that we would tell the miners who were mining on rinkeby or sorry on Rob stone to move to the new tests net would be the idea we're just saying that as far as adoption goes miners might not do that immediately so Rob stone will upon I think we should test the heart for con

Robson III see the benefits from having a new tested but it also has a benefits to happen Shane that already has something in the stage you know yeah that makes sense any other comments I agree with our free and I do not feel strong enough that we should have a new one to push for it so I'm fine with that as well okay then we'll be forking Rob stone so what we can do is we can for crop stand I guess whenever we get get it ready even if the test cases aren't done I guess the only thing we'd be committing to if we were

to you know do that is we would have to let me think we would have to have people kind of on the ready if there is a consensus issue which isn't a bad thing I guess because we want to practice that anyway like the talaq mentioned so to be a little bit more precise are we talking about something like roughly one month or so from now maybe a little bit more forking Robson and kind of dealing with whatever fallout comes from that

then yes pretty much I think that's pretty much what we would be doing so I think forking Rob Stan sometime in early October would be fine personally but this is it's kind of up to you guys who are implementing this I guess it's really it's just flipping a switch in the client and then releasing a new client right is there anything else that goes into it maybe instead of us just needing to make a decision now let's a freak do you think you guys and guess could get together and give us a

date for this or a proposed date for this since really that we're talking about y'all's clients supporting the network I'm happy to decide on the block number now but if other clients need more time I'm happy to wait it doesn't really matter we could set a date I think yeah I think I think we could today hmm so when is a good date I don't I guess it doesn't really matter as long as we give enough time to have a release ready

looking at my calendar people are going to be kind of busy with different stuff um there's like FSF there's web three summits and then there's Def Con so doing it like the second week of October I don't think anything's going on the second week of October that I know of so that might be a good good range we target for something like that Tuesday whatever the Tuesday's of that week that'd be the ninth as I say it's hard to target a specific day right now the average time on Rob's penis 10 seconds or nine seconds I think it's a bit instead so that would be good to

target Tuesday then because if it's a little early that it's Monday if it's a little late than it's Wednesday all right or do you think the deviation would be much bigger every yeah that's what I'm suggesting it might be plus minus seven days or something depending on how fast - hop on or drop off can we if we today just aside today aim for the 9th and then at later stage we set the actual block number when we need to release the new clients about that seconded yeah that sounds good to me so I

actually I didn't catch the end of that Martin what what which date would that be so today really decided upon maybe aiming for the 9th October and in two weeks we set the block number okay that sounds good to me cool so we kind of have a decision there and then we'll also kind of be monitoring as we go along how close we are for test cases for Constantinople can someone do a calculation about block times in November and December name net because we don't want to release

Constantinople so late that the block times are crazy but I think they're not gonna get crazy till 2019 is that accurate so hard times like still around 15 seconds right now because if so they're definitely not gonna get crazy within two months let me check you know check myself but like in general right you are the the general pattern is like a doubling in start at the beginning I think every yeah well 17 days so two and a half weeks all done average block time chart oh look at this okay I see it

being about 15 seconds consistent yeah yeah it seems like completely as stables - so far so like we could probably we would probably have one three months of safety and like we even more like if you notice what happened before Byzantium right like the amount of time it took before it started even showing up on the charts and then Simon got to 30 is half a year and right now it's like not really even showing up on the charts so oh no although the one thing that we that that we had then was kind of a

backdrop of a rapidly increasing youth price that hash rate whereas now we don't so this time could take on a new look four to five months instead of six well given still it's like totally not urgent okay hmm okay that sounds good to me so it sounds like we don't need to make any decisions on main net stuff today and we're safe to say that if it doesn't happen until December even then that would be okay and right now it's September so I mean it could happen as early as November but as late as December and still be okay that's great so I think we can move on to other agenda items unless there's anything

else here and then I'm also seeing kind of in some emails and chats that people kind of want to join to champion semi IPs and I don't really want to bring anyone else into chat today until the developers had more time to look at some of the last-minute agenda items for next time we might go over them briefly today to kind of just go over what they are but we wouldn't be making any decisions today for sure and we wouldn't be having that in depth of discussion so let's do let's prepare a little bit more before we have people come into champions certainly IPS and I assume that those will be on the agenda for the next call yes they would be on the agenda for the

next call they're on the agenda for this call to an extent it's mostly people are willing to talk about Prague POW and 1108 but neither of those would go into Constantinople so there's no rush on it so let's see can we do it before Def Con we're saying no so that's the end of agenda item four so now that we have just a little bit of time let's go ahead and run through five six and seven but we're not gonna go into much depth on them until we've had more time to look them over so one of them has reduced gas cost on the call for to self

this was acts ik talking about reducing the gas cost for the call instruction so Alex can you go over kind of what the CIP is and what you're recommending yeah actually it was a collaboration between and maybe I'm pronouncing his name wrong word Shack from Viper and me and it's it's it's been initiated by the fact that Viper currently uses coal to sell for internal methods but that currently

is a bit more costly than just doing jumps and therefore a lot of people suggested to Viper that it would switch over to jumps and this is kind of this has been created kind as a as a can counter action to death because if think the way Viper does it currently is is actually beneficial because with jumps there is no or at least regarding memory safety it puts a lot of the work on the compiler and with calls there is no issue regarding memory safety so the proposal is that for any kind of call so not just call but then I get phone

instead of coal if it goes to the very same contract it originates from and then we charge less and now there's a lot of motivation described there but the main question at least from our side from is what would be a rational gas cost so the proposal right now suggests just to go back to whatever it was before spurious Dragon which I think what's 40 and keep 700 for any other case but that assumes that the spurious dragon increase was really attributed to the IO cost and what we're saving here is the IO

cost but we still and the client once still needs to create a new context but the IO cost is saved so that's in short cool does anyone have any comments on that about it being a good idea or that idea or anything in between intuitively it definitely seems a kind of more fine idea than it was before especially because the spurious dragon kind of de-facto reduced to the maximum staff depth stack depth from 1024 so like around 300 or so and I so I personally would buy the adjust incidentally favor

Viper not doing luck not switching to junks regardless of whether or not this gets implemented because like I feel there's value in having a language which kind of value simplicity even at the cost of optimality in some cases but like in general like it does like it does seem to me like having like the whole idea that you have languages that means we're kind of calling yourself and calling like we're basically who needs to kind of code up two ways of calling contracts one for yourself and one for others definitely seems and it fairly some optimal and this does seem like a

fine approach for end of mitigating it it also feels somewhat in line with the current EEP for chaining storage costs in sort of addressing the the nuances of the actual costs and by the way it was there any for reducing gas the gas cost of coal specifically doing the preaching files is that part of Constantinople or not because I know we talks about it there are two separate the IPS for that but I don't think it has been an agenda for like the last three or four calls because person for simplicity it might make sense to just like merge those two

and have them at the same time as I feel like their benefits are like not the same but still one is in a similar category so actually there is a matter proposal yet to be written up which resulted from this proposal have we had a discussion within the solid is the team and it was suggested by Chris that eventually we could propose a way similar to the and that s door metering and that there would be a map of loaded contracts originating from a single contract and we there wouldn't be an extra charge for for loading an already

loaded contract and the context this would be beneficial is doing a lot of library calls to the same library and by library I mean a solid library which is a contract to be called the delegate call but this this proposal is yet to be written and you have to be designed I just wanted to put it onto the table because it's kind of like the same same direction that's interesting hmm yeah I can see a lot of value engineer sizing and because it addresses a wider thing which is right like our you know libraries the concept of solidity libraries are pretty nice for certain

things and but yet they do incur higher gas costs so allowing that pattern to be we feel like this could this could be genericized even further are going all the way to is saying something like the gas cost for accessing in accounts that has already been accessed in the same block goes down from like 700 to 40 that's more of a long-term potential thing okay so we're not putting any more AIPS into Constantinople so it sounds like these changes would have to go into the

next fork afterwards called Istanbul so I I guess yeah so when we're talking about it right now it's more I guess talking about much in the future implementing this kind of stuff okay yeah which is disappointing but we you know have to do kind of a freeze on the IPS eventually so we're not stressing out Dimitri and others too much for implementing test cases and other stuff so the next item or were there any other comments on that so yeah I was curious did you ever consider having an annual

code called like self call instead and why how come you choose to go with this this would make existing contracts be able to use the effects rather than just future contracts Martin who was that question for praxic but I guess it got answered by Danny fine okay sounds good any other comments okay just to comment I think it is

healthy to like have at this point in this process have new ID IPS that might go into the future fork just start starting to be discussed so that we even have a little bit of momentum and can really get excited about a fork in eight months so I'm I'm you know it's disappointing that we have cool a IPS that we can't include right now but I think it's a positive thing to be considering that at this point yeah that's a good point the next one is e IP 1108 reduce all be in 128 pre-compile gas cost so that would actually I believe Martin responded to this in a threat I saw but

basically this would because the go reference implementation had significant performance gains for EC and EC mole and paring check precompiled contracts on that elliptic curve that should be reflected in reduced gas prices but I think there was like some issue where those performance gains were not for other clients yeah so what they wrote to me was we strongly feel that continue to keep gas prices high for these operations it's going to jeopardize the whole host of privacy related solutions from being able to get going so there are a lot of people who wants these

precomposed to have lower gas costs and as it is right now we could lower it a bit but I yeah we didn't I think we've kind of dropped the ball on that we might have been able to make it small reduction for Constantinople but I think that we can do a larger reduction the next hard fork with some more work on the other clients well on parity it is possible to find a good rough slip with which has all the optimization stuff

it would be nice mm-hmm-hmm-hmm okay that sounds good any other comments on that okay and the last thing on the agenda is a IP 10:57 and e IP 1355 10:57 is prague pal and 1355 is ET hash one a there's some comments in the agenda that kind of argue that we need to implement ET hash one a which is just a slight tweak to ET hash in order to take more time to evaluate prog pal just to give you an update me and powell

have been looking at prague pal and and we are getting some feedback on that from different engineers from different companies and seeing the viability of it to see if it really does make Asics obsolete and this is not because we've decided to actually implement prague pow at all this is just to make sure we have all the information we need if we decide to do that and this was kind of part of the I guess part of the package deal in my opinion with lowering the issuance because miners cared more about taking Asics off the network so for us to

consider that and then have to have the issuance reduction I think was a good combination so the biggest the number one thing I can see with this you know whether or not to implement something that makes Asics obsolete on the network that the biggest thing I think would be is there actually a threat to the network having Asics on there I know it does affect GPU miners and do we you know even care about that so can I hear any opinions if anyone has it on what because we we had the miners on a few meetings ago but we didn't really go into much detail about whether or not it's an actual threat to the

security of the network to have a six on there or if there's centralization risk in that stuff so anyone who has an opinion that'd be great okay so it sounds like we're not getting any opinions really on whether or not it's a centralization risk or anything like that this is kind of a contentious issue more or less because miners you know are pretty passionate about this but I

haven't seen many other stakeholders really care you know such as just average users DAP users developers other people like that so we might just have to continue this conversation just to make it clear prog POW or any other change to the proof-of-work algorithm would not take place until after Constantinople so likely eight months from then and then it's arguable if that would even have a major effect on the centralization of the network until then I know people have said other opinions in the past about how it's not a centralization risk but I think that's still up in the air to be discussed

given what I just said does anyone have any comment I think a six the discussion or a six if we were not intending to decrypt mistake I think he'd probably be argued as a centralization risk if it went the way of the nameless Bitcoin and other kind of networks but this conversation is always in the context of moving to proof of stake and I'm hoping by the by the time we're discussing next work we have some exciting developments on the side of the deccan chain of proof mistake and I can maybe put the conversation in contact a little more in

context okay that sounds good so it sounds like there's no reason to commit to anything especially today but you know until after Constantinople and even then this will be in the context of how fast proof of State can get there because if it's gonna happen shortly after a stand bull or not even shortly but just in enough time where we would only be obsoleting the Asics for a few months or half a year or something then that would definitely be a different story right cool many other comments on that Oh also we

coined a new term while me and Lane and a few other people were at F / Len during a governance panel there's something called consensus by Hudson now where when no one gives a comment I start rattling off and basically I hopefully don't steer the network in the wrong direction but I just start giving my opinion so I feel like that's what just happened and I find that hilarious so thanks vitalik I guess I'll take that from you now what do you say when I said Hudson you did a great job of steering us towards a good dinner in Berlin using consensus by Hudson so I'm all for it

great alright anyways that's the last item on the agenda does anyone have anything else to discuss I'm looking forward to these meetings being shorter and shorter as we go on and we're just doing mostly client updates and some VIP discussions so we don't have to go an hour and a half each time so this time we only want an hour which I'm excited about and we will see you all in two weeks for the next meeting bye everybody [Music]

[Music] [Music]

[Music]