All Core Devs - Execution #56

All Core Devs - Execution · 1 Mar 2019 · 1:31:10

Ethereum core developers note the successful activation of Constantinople the day before and cover the ProgPoW audit, the Istanbul roadmap, a change to the hard fork coordinator role, a heads-up on subroutines and static jumps for the EVM and the rejection of EIP-1355.

Speakers

Topics

From All Core Devs - Execution, hosted by Ethereum Foundation.

Transcript

[Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] you [Music] all right everyone welcome to meeting 56

of the theory and core developer meetings most of us are awake I think we'll start with the first item which is some roadmap items Constantinople activated successfully yesterday so yay it was fun hey we all take like 10 seconds to like celebrate it was fun in the all core devs chat we had some popcorn emojis and no no shots unfortunately no shots yeah we were all very professionally sober well that I

know of actually if someone did I was I was unaware so that's great I don't think we are having any problems with it yet so that's good next item Prague how odd it gonna give a quick update on that let me just pull up my update real quick so we're gonna publish a more the cat herders are gonna publish a more official like blog post that gives more details on it but I wanted to clear up some things about the Prague Pal audit from the perspective of the etherium cat herders who were designated to try to organize one and

also get signals from the community on what was going on with the audit so first of all there's two components to the audit the first one is the benchmarking which is the less important one in my opinion because the community has been benchmarking lately but that one looks to see by running graphics cards if nvidia versus AMD if either one of them is more than the other in an unfair way white bloc has a bounty out right now on both bounties Network and get coin to perform

that work that's to try to raise funding to do benchmarking on prog pal the other component of the audit is to see how long it would take an ASIC company to actually build a prog pal ASIC and how perform it it would be compared to a GPU by a factor of like 1x or 2x or 10x so we can see if it's even going to be worth it to implement or if someone is just gonna make another ASIC in three months and all our work will be for nothing since the work isn't entirely done yet and so that I feel like would be a more major factor and contributing

whether or not to go forward with prog pal as far as signals from the community we have a what I'm calling a hash vote but I think there's a better name for it if someone has a better name for it let me know and that's where miners are signalling on the etherium network using the extra data field whether or not they support prog pal and so far all the miners who participated support it there's a page on either chain that shows that I can try to dig up the URL later but there's also a there's also a coin vote that is also overwhelmingly

yes however I want to stress these signals and and also a third thing I guess would be the an official Twitter poll that the cat herders ran all of those things are just signals they're not anything that's gonna be like a deciding factor Oh Lane posted the link thanks Lane none of those are going to be a like truly deciding factor it's more just figuring out like from which types of folks like that which stakeholders think of certain things so we know that the current miner on the network overwhelmingly support Prague pal which was kind of already known to the for the most part but this kind of cements it and so we have a interested party who is going to send me

a proposal for the second part of the audit the one where it looks at how long it would take to actually build an ASIC and it looks like oh cool there's some stats fifty-five percent voter turnout for minors signaling which is really high and a hundred percent in favor I was surprised by that that over half of the miners and the ecosystem voted really I guess that's happened more than half of the hash power so I don't I don't know how it's calculated I don't know if that's heard like number of blocks or if it's hot I guess it equates the same thing if you take a large enough sample then then it's hash power

is the same as number of blocks so yeah that sounds accurate I think it's 50 percent of hash power yep that makes sense so yeah that other company they're gonna get back to me hopefully by early next week and then we would start either getting a get coin grant together start looking for funding like we did for white block and see what that's all about so that's the update Charles pooja joseph is there anything I missed so

Alexey Akhunov: I just wanted to say that I've seen it somewhere so the there is another

interpretation which was potentially can be useful of this 55% number which is the turnout for the miners signalling somebody said it but I think it's a good where essentially if those 55% that turned out and they all voted in favor that gives you essentially a lower bound on how many GPUs are currently mining

and network if you think it's that make sense yeah actually that's that's

Hudson Jameson: that is an interesting things to think about

potentially right unless there's some sort of like misdirect effort where someone trying to split the network or something but I agree generally it seems like a lower bail

Lane Rettig: also most of the votes we have we know

which pools they came

from if you look at that ether chain-link I posted its nano pool it's either mine it's the folks you'd expect f2 pool there's a few here that are unidentified so yeah yeah and then spark pool

Hudson Jameson: was going to vote yes is what I heard I don't know if they ever got around to doing there extra data but that would also represent an even bigger amount of hash power

if they're not already represented they are they are not voting yes oh all right

Hudson Jameson: well that makes a big difference

to them yeah

Lane Rettig: it might be worth asking them wire maybe not

Hudson Jameson: the last I heard they were just trying to figure out how to do it at scale for their setup or something like that

listen I was gonna ask if you wouldn't mind talking a tiny bit more

about the funding question I know there's been some question about this like I know there was at least one application I believe aundrea submitted to EF and I just I'm a little unclear on this myself like what was submitted is is the official statement on the part of the foundation that they won't be financing any part of this and if so like what's the plan anything you could say about funding would be helpful

Hudson Jameson: yeah absolutely so it's very important that Andreea get his funding for prog Powe if we decide to go forward with it or in my opinion even if we don't just because it's starting to trend in a way where we would go forward with it I think it's important that he continue to work because he's been working without pay on prog Powe and I don't think that's sustainable in fact I think he stopped

working because it was not sustainable as far as funding sources from the etherium foundation the I was not involved in those conversations and I don't know about any kind of official viewpoint or anything like that I heard that there was a grant application submitted that got rejected I don't know if people know more about

that oh great Pawel know there was yes grant application that actually suggested to do and participate in the process as applicant but I apply for any funding for myself yeah but it was that was rejected following

the standard def grant process okay so it

Hudson Jameson: sounds like we have an answer there from the etherium Foundation perspective for the grant

and

Lane Rettig: I guess I was just wondering if there's any color there on whether that was more of a political decision or a technical decision like if it's technical decision fine you know that happens all the time that's the grants process but you know if it were the case hypothetically again I don't have any inside information either but like EF is saying we don't want to fund this we don't want to fund things like this because we don't want to take a stance I think that would be helpful for the community to know

so I don't know maybe Hudson Park the grant Havel could you explain with the great ones

yeah the grant was for to developers to to work on propel implementation and Eve miner and also to work on instruction protocol new version of it that will help with switching to any other I need to make a proof-of-work switch and and there was some I think two more tiny items that were also included are related to mining infrastructure Linda no I wouldn't read it as political I wasn't involved with this but I I know

there in the past 3-4 months have been kind of like going back to the drawing board and making sure that they have the priorities straight and really trying to ensure that they're giving grants to things that are providing distinct value if they did not and I think maybe in my my interpretation would be maybe there's a there's a lot of prog power work going on and maybe the assumption is that it would be going on with without the grant well the official statement is is just like those number of applications for grants and tested they selected some number based on well I think we cannot expect any

other statement other than that so that was presented to us and I think that was accepted by a way to achieve I was gonna just

Alexey Akhunov: to make a comment about the grant first of all I do know of other grants had been rejected so I wouldn't like read it as this is the only thing that has been rejected because I I know of other applicants that have applied and reject got rejected so I don't think it's political at all and the second thing I wanted to point out is that if you think about what the Assyrian foundation should actually be finding and I think it should be finding the things that otherwise cannot be commercialized or made you used in a profitable way so essentially public

goods so if you think about it you might kind of conclude that some of this work could actually be profitable for some people so therefore they might try to find funding elsewhere but this is my personal opinion

Lane Rettig: thanks Alex hey that's helpful yeah I agree let's not read too much into the EF gray I guess then the question on my mind is just what are the other options on the table I know that we have there's at least two

funding kind of requests open I think they're both on get coin right one is for ondrea's work and the other one I believe is for white block oh that's correct yeah so

Lane Rettig: just making

people aware of

those would be good I think and the other thing is I know that consensus has a 500k 500k I guess grant thing either doing I don't know much about it though it's this is the last thing I'll say on this topic and then we should move on

Lane Rettig: it's not like officially up to the core devs to like you know worry about funding or get people money but like I do think that we need to have an honest conversation about it in this context as well as in a broader context so yeah I'm just curious if anyone else has any other thoughts like I think that some of this work is probably pretty essential to the ecosystem and it's pretty important that without picking sides or having favourites right that in general

that there be funds available for this

sort of work in and I would say the last thing about my thought about I did read the magician thread about listen about the funding it was a cause - for the serum foundation funded and but there was other ways to think about it is that if you look at the carbon vote I did actually look through the carbon vote where the people were voting with the ether and you could see that the number of ether which voted for what part was about 3 3 million ether and I looked at where did it come from it so it basically very large amounts like up to half a million 200,000 ether so essentially there was about 20 different

votes which probably came up from about three entities and so surely this this basically reflects that this huge entities actually have interest in this project so maybe we should ask them to fund this yeah that's not a bad idea but I don't know if we should be the ones asking but individually maybe not as a collective but yeah individually I completely agree anybody else have comment on this before we move on

Greg Colvin: the best thing they can do is just speed up their process honestly I've had a grant almost two months there and they can't just let us know yes or no so we can

move on knowing we have funding or not not everybody can hang out for months waiting weatr to know to go get a job rather

than help aetherium okay good good good feedback

Paweł Bylica: I have one one more comment about the proc PO outed so I think I tried to make a note in some of the text discussions but well to clarify Proctor never claimed it's it's it's Isaac resistant and like there's no way to make Nasik but what proc brow claims to provide is that the difference in performance

between GPUs and Asics to simplify will be much less than if harsh so I don't think it's really important and that should be part of the audits to figure out how much time will it take to make enough and basic for it for profile because it's somehow it's not really relevant the question should be like if it's really true that the maximal difference will be 20% in

favor of Isaac's yeah but I agree the real oddity is to verify that those bounds

have solid reasoning well well the I remember like like some time ago

Alexey Akhunov: when we had this really huge discussions on on a guitar channel I have been asking the question what is the success criteria for for the broke pal and I've never got the answer and actually what pyro is saying is probably would potentially be the answer because whenever you try to pin it down there's always things like oh but the GPUs are also a 6 or but you know they probably can be created but in three years and this kind of thing so unless we pin down what is the success criteria then they old it's probably not going to deliver much kind of

satisfaction

Hudson Jameson: that's interesting

fighting

Greg Colvin: anybody who knows the answer has damn good business reasons to keep their mouth shut and make the assets

yeah that's actually why a few different ASIC manufacturers have declined to do the audit in the first place why would you its competition

Hudson Jameson: luckily the person that is offering to do that that's going to be sending me a proposal is independent of ASIC manufacturers and seems pretty excited to potentially do this and has the

background as far as I can tell to complete something like this and

the team behind it I'm still confused well why were doing this but what part of our consensus wasn't clear that we're revisiting these issues

Hudson Jameson: that's a good question

Greg Colvin: it's my only question

I'm

Hudson Jameson: trying to remember the meeting where we decided to do the audit and what the what we came to

Greg Colvin: we were looking only for for technical problems like holes in the algorithm not not whether the algorithm

was going to have a certain percentage of effect I think we knew we're in an arms race with the a6 and at some point we'll either decide to maintain the racer decide the a6 win but for the next nine months we decided we're going to do this unless there's a technical problem with the algorithm not whether somebody thinks that maybe the a6 can win the battle over some period of time

Danno Ferrin: the argument about the a6 in the margin of efficiency is one of the claims in the EIP so I think that's within bounds of a technical problem because they claimed it in the EIP

ok yeah any other

Hudson Jameson: any

other people have comments on that

yeah good I also would say the comment that I also read recently is that so the question I also been asking in like were the whether we we would like to to kind of keep fighting basics or we just do one attempt and then we stop at this because I heard sort of somewhere renew sort of call ok because we have the knobs so the profile has lots of knobs like six different parameters that we can change but then my question is that are we actually going to do this are we going to keep tuning it to the basically do it hard for it every six months and because the this is not defined you know

the the conversation they just go all over the place when whenever we start discussing this because it has never been decided like how you know what we're going to do after that and my concern mostly comes from the from my appreciation that the bandwidth of the change in the Syrian protocol is actually limited so like something can dominate this whole agenda for four months for gender this meaning and so that makes really hard to actually do the other improvements that we will really need as well

Greg Colvin: that's when you form a working group and tell them to go away and come back with information

Alexey Akhunov: I completely agree with that great and that's why I think the working

group should take over and then we remove it from the agenda and you don't talk about every single time

Greg Colvin: we don't have to decide through this hard for what we're going to do for the next

five

Hudson Jameson: yeah that's a good point and also the people so when you say working group that's kind of what the cat herders are doing so we don't have to have it on future agendas until we have the audit done it was more community requested that we have it on the agenda so I decide to put it on there cuz it's something that people want to hear about that it's on a technical level at some that's in some ways so that's the reason it's on the agenda but I I agree it shouldn't be on the agenda every time

because we'll just rehash the same arguments and it's pretty clear what we're doing even if it's not clear why all the time it what's clear what we're doing yep cuz I I agree Greg your question was really good okay so we can anyone else have any

prog pal comments cool so the next item is the Istanbul hard fork roadmap and I forgot to add something else in there the hard fork coordinator role so off Rees no longer the hard fork coordinator and a very good question came up actually how he became hard for

coordinator and it was discovered that I thought that I talked about it in a meeting but I hadn't and so technically I just like decided he was hard for coordinator along with the rest of the cat herders like we all just were like oh after he wants to do it that's great but but then we didn't really talk about it in here so we should probably talk about that now dude does anyone want to or what do we think about having a heart fork release coordinator it seems like from previous discussions everybody wants it but is there anyone who's against it does anybody want to do it there are some people who've come forward yeah

Lane Rettig: before we get to that Greg I I agree with

Hudson's question it would be helpful to talk about what the role is and whether we all think it's worth having I'll just whatever I'll just share one quick thought like I think there's value in this and the reason is because the number of teams and the number of individuals working on even just the etherium one work stream not even to mention the youth to stuff but of course that as well has grown quite a bit right the size of these calls have grown the complexity the coordination work required in getting everyone on the same page and getting these hard Forks to happen has grown as well I do think and hope that I am expressing you know the consensus of this group when I say that like we'd like to do hard Forks more

often or upgrades I should say more often and I do think that the coordinator role can help a lot with that so I see value in it but I'm curious as well if anyone disagrees

so my

Alexey Akhunov: my question to the sort of hard for a coordinator role is whether this person or a group of people going to be only concerned with the actual card fork meaning like something which sort of starts let's say one month before the the block of the heart fork and then end of the day on the day of the heart fork or is it more like loosely defined spills over to VIPs and all sorts of stuff so where does the barrier between kind of yappy coordinator and hard for

coordinator stands but I do agree with Lane that if we do want to sort of reflect on like why we are doing things with the way we're doing and maybe we should do better and maybe we should do quick for more hard Forex Foss sort of more frequency then yes I think that might be important

Hudson Jameson: yeah and just to answer your question they would not be an EIP editor they would obviously have to Reedy I peas and coordinates some of the quarry IPS that are going into like the meta EIP for upcoming hard Forks but in general a hard fort coordinator in my mind would be someone who between now and the next hard fork decides hard dates for deadlines of submitting e IPS for

consideration deciding on those AI P's implementation and testing and then finally what day the hard fork would be of course they wouldn't be a dictator in this regard but they would come up with they would be the one to come up with suggestions or different options to bring to the table because no one really has time to do that so far also if there's any kind of disorganization with it like confusion over a IPS or like confusion over what people want they can kind of sift through like core dev meetings and online discussions and kind of filter through that stuff so that's my idea but it could definitely expand

to other things depending on what the release coordinator feels like they need to do so in general a few people have come to me and said they want to help so I'm gonna collect a group of those people and maybe do some people a lot of people actually suggested that we do a community vote on who should do it I don't know if that's the best route or not I wanted to hear opinions on that if it should be the core devs deciding who the core dev release manager is or the community deciding who the release manager is

Joseph Delong: um is it also possible that we might split the role among the you know two to three people

as well

Hudson Jameson: yeah

that's absolutely possible

Greg Colvin: who actually wants to do it

josephs come

Hudson Jameson: forward and said he would do it

my volunteering yeah there's some other people I want to definitely give a chance to say they're their parts since they've come forward but I haven't had a chance to talk with them deeply I haven't even had a chance to talk with Joseph deeply about it but he's come forward that's it sorry

Greg Colvin: is there any objection to this person it's not you know it's not like we have so many people who just want to go through that abuse

Hudson Jameson: oh yeah no there's not it's more like people understanding like if there's gonna be more than one

person and then really I mean if the core devs don't really care then they can delegate it to the cat herders and the cat herders can pick some people okay I either split the role or to have one single person do

it if the cat herders volunteer is a group oh that was gonna

Lane Rettig: be my question do we see this as something that falls under the purview of the cat herders

you just it's still not clear I mean I'm sure it will be clearly as it goes on that what are they what is the the actual so so what are the decisions that these these people

are gonna make because what we do want them to do is essentially to aggregate some information and make decisions or though we don't want to make them to make any decisions or they're just going to be information aggregators um we have a blog out that we released do we release that yesterday everyone who's a cat herder in this room when did we release that blog that explained when that what the cat herders are yeah that sounds right pooja do you know I think he might be on mute oh thank you if you could post that link that'd be great

that should answer your question Alexi about the scope of the cat herders this is about release manager if we we decided that it's gonna be the same thing or yeah that's that's the that's a good question

Hudson Jameson: I think people don't really care they just want one that's kind of what I'm hearing because I'm only I'm not hearing a lot of comments on so we can do this let's have the cat herders figure out who wants to and get them all in the same chat room and see if they want to split the role I think that sounds good to me anybody else have any ideas okay the cat

herders can do that then Alexi did you you didn't get your question answered

though could you rien no no that's okay I think it's too I don't expect this all these questions to be answered straightaway because it requires a bit of figuring out try yeah so I just wanted to just for example more concrete question you probably saw it and you know the github issue that I was proposing couple of things a couple of changes into the actual process and I wonder what this is gonna be purview of the cord release manager for example I suggest you to appoint dedicated reviewers for the change rather than to wait for somebody to look at the changes because as far as I can remember like a

lot of times especially if the hard work is not ready near it it takes quite a long time for somebody actually to pick up the change and look at it and that because there's no dedicated reviewers and I think that's a shame because we waste a lot of time waiting for things to happen and that we have a very really small limited number of people who are expected to look at the changes so I would rather have to you know get some appointed potentially people who are not even on the calls but they want to review the changes they just can review them in the common code to explain what they found and so we can iterate quicker over all these things rather than having things lying down

Hudson Jameson: hopefully we can find that role and if we can't then we can

have the release manager poke at people who would review that such as the EIP authors to do more review

reviewer I mean that it's like for each change you basically somehow pick the reviewers who probably want to do the review and those reviewers are not necessarily like the core devs who are kind of in initiated I would say in this call but somebody else who actually really wants to do it and and then the second thing I wanted to propose is something I already said before is that we need to revisit the assumption that we have to kind of bundle a lots of updates into one big release I heard before that it's really really hard to

coordinate your release but actually I'm keep questioning this is it really and so I hopefully but this new rollover this manager or Google people helped us to really understand if it's really difficult or not

Hudson Jameson: yeah I I agree I think those are good I think those are good ideas and I'm sure the release manager will take them into account

so one of the things I'd like to point out is the for a free left if it's a schedule that you're going to have this done by that we're expecting this to be done by this point this will be done by that point I think some of those road back dates roadmap dates are gonna help us you know get them to the point where get these things review to get these days in at a time and make a decision to put it in or

pull it out so I think you know there's some changes that are ready coming that are gonna help address some of these issues if we actually follow the dates and you know if the roadmap is still valid but as far as my opinion on even multiple smaller releases it's gonna make things take even longer because there's a lot of lead-up and preparation that goes towards getting me to releases out that I've seen that if we do have multiple times of smaller things it's gonna be a lot more inefficient they're gonna come still about every six to nine months with smaller releases so I think it's more efficient it's a bundle multiple in but you know that's something for the release manager discussion I mean I think

Alexey Akhunov: thank you for this comment but I think this is made

and this is based on the assumption that we continue do things as we did before and this is why I put another two or one or comment on my so we so what I also propose is we first of all we introduced high standards on the IPS that we really need to require some kind of proof of concept that probably pre generated test cases so we don't leave it to the later and also the my proposal about the the pointing the reviewers might help as well so because I think a lot of people assume that you know we have to sit on a change for months before it actually gets in but as we we did a bit of introspect with respective on this during the workshop that we don't

actually have to sit on this for a month if you find the reviewers quickly to rate implementation doesn't actually take that long the test generating test cases probably takes that long because there's only one person or two people doing it but if we make it a burden on to the EIP whatever author to actually do that to help the testing team that I think we can move much quicker than before

I agree yeah you should come with test vectors yeah that's a great idea okay I want to move on from this item because I think we've figured out what we're gonna do so let's go ahead and go to subroutines and static jumps for the EVM there's a link to the magician's thread and to the EIP

Hudson Jameson: this is something

Greg just wanted to bring up

because I believe it's going to last call soon so Greg you can take it away yeah I didn't want to discuss it in any detail

Greg Colvin: I just wanted a heads up that it's coming because there's people on this call who I'd love to have some review and they might not hear about it otherwise

okay

Hudson Jameson: great thank you for that

and let's see the next item reject VIP 1355 that's Paul's item if you want to go ahead yeah mostly I think most of people that were involved in it and so it was originally

proposed as a kind of counter argument for propo but in the end we realize it's it's not very effective and considering how much time does it take to this castle pro proof-of-work changes and related issues with that I don't think it'sit's really possible to have done it and it anytime so yeah to clear it up I would like to mark that as a reject it so

Hudson Jameson: I think according to the EIP process and someone correct me if I'm wrong you can withdraw any IP if

you're the author of it and it basically has roughly the same meaning as rejected because rejected would be the core developers deciding it's rejected like because of a technical issue more more so but you can change the status to withdrawn and then it's withdrawn

okay yeah

Paweł Bylica: I didn't realize that so yeah I think that's might be better

approach to it okay sounds good next up working group updates I think the main people who are here for that there's he was ohms here and state fees are here I believe and then maybe if

Peter has any update on on the state pruning I don't know if there'd be an update on that but let's start with state fees that would be Alexi who just released part six of his really cool in-depth articles on reflections from the Stanford working group so Alexi if you want to give an update on that and then I had some comments okay so I'm just gonna post the link again to so the the part the book posted Hudson just referenced is the sixth part has linked to all the the first parts as well so it I wrote it through after the event and I added more data analysis and more

thoughts on this and so I reflected on this human workshop and I've realized that there were some blind spots so which I will talk in a bit later but essentially the main thing we that I carried out or we carried out of the OD workshop is that there were four main problems there are performance problems that are coming from their large State and a growing state and the first problem is the failure of the snapshot saying second problem is the duration of the snapshot sync the third problem is the slowing down of the block ceiling and the fourth problem is the slowing down transaction processing due to the

state state size and so the the block describes in detail like what are these problems and what how we're planning to but some of them how we're planning to to address them and for example the first problem which we deem the or I deem the most critical one can actually be solved by introducing a better Sync protocol and I know that already some work going on about it in the parody and go cerium they have different names for this also andrew is not working with me on here 1x he's also working on the modeling and documenting the sort of other work our version of this protocol he came up with a cool name for it it's

called the Red Queen which is not be confused car over reference it's not to be confused with the Queen of Hearts actually they're two different things but the Red Queen is the one which basically says that in order to even stay on the same place you have to keep running and this is where so the idea is that you have to keep following that so when you think you actually try to chase the chase the the head of the chain while you're thinking so but this is this hopefully these all efforts for hopefully converge when we start once we start having some specification and I don't think we need the hard work for that but we will need to get some coordination in terms of the purity protocol then the blind spot that I

talked about is that I want to come back to the idea of stateless clients and this is not the same as the stateless contract that I was was describing my in the state fees proposal the state of clients is actually the idea that that the blocks that we are propagating through the network they are they basically augmented by some more information which provides you the sort of the state subtree like with all the hashes that essentially provide the proof that the data that the transactions are reading are indeed belong to the state and and then the the they are Bates the transactions are

performing result in the new state fruit so essentially by having simply the blocks and the state fruits of the Endo's argumented data which is like we call them block proofs then we will be able to execute transactions without even having access to the state and this has previously been researched a little bit but not so much so I also wanted like one year ago to do some data analysis on how big this book troops would be I know that vitalik has has done some analysis miss a she also did that but this time I wanted to do kind of more seriously meaning that I almost been doing the proof of concept for this so to make sure that my estimates are

correct and so I will publish the details about how big these things are and we will see if this is something which we could combine with with the state fees the reason for that is because one of the so after the workshop enough to be in writing all this these blog posts I realized some did some project planning and I realized the most expensive and most laborious part of this project would be what I call the ecosystem research which is basically analyzing like all possible contracts that exist currently very popular ones and figuring out how they can change and how can adapt today to the state fees and that

potentially could take months and costs a lot of money so I'm trying to see if we if it's truly necessary so I'm mildly kind of I'm not optimistic or pessimistic I'm saying a probe posted possibly blissed ik on this third regard so I would not say many much more because I don't want to hog all the time in the meeting but yes any comments on that I would say that you say and we talked we had talked about this

Vitalik Buterin: privately but the idea of using X Dallas clients for contract storage definitely

AG has a lot of advantages to it especially since it would and as I mean I mean that III search post where I compared the two but it seems like it would break a lot existing stuff which is a a nice benefit and like doing it just ad contract level and not at kind of the level of the whole system would definitely have to remove a lot of the biggest risks that I see him I guess the mean challenge in all of this is definitely going to be like basically whether or not the date whether or not the costs of like having potentially

much higher bandwidth are worth it and as part of that I guess a couple of questions one of them is how would we actually do gas costs for the bandwidth so it would we have would we still have a fixed gas costs practices like a storage salat would we try to do gas costs based on the length or the moral branches to try to incentivize having smaller trees and incentivize reusing access would we try to do something else and otherwise like if it becomes too big what actually is the cost of DNA ugh do we you know I know we decided at the workshop

but called data is like probably a very over a kind of overpriced by now but like what would

the new illicit price would be is that a number that we're okay was okay

Alexey Akhunov: thank you for that so to answer the question about the cost so yes definitely these proofs that are well according to the current idea that these these extra proofs they will have to be paid for by the transaction center and in this case the payment would go to the miner rather than being burned because essentially introduction of this system relieves everybody all the nodes apart from the miner from actually having a state so everybody else that don't doesn't even need to have a let's say that the cash you try in the

memory because they can simply verify the proofs and that they update their database even if they have the entire state in the database they don't actually have to cash it in and so in the memory so that means that we we get like everybody apart from the miners we'll get much huge boost in terms of performance in terms of the resource consumption so and I would charge the note in terms of the length of the branch is that but basically per byte of the proof so currently as I'm working on this sort of little proof of concept I'm actually going to calculate the two parts of disprove the actual crashes that are accompanying the thing then and the data so the data is essentially what

are you have you read during a transaction assuming my charge for it differently and also if the proofs turned out to be super big what we could also do we could use something like Stark Bruce or snart proofs to actually to compress them in such a way that there will be a fixed size per block for all the proofs but you will not be able to compress the data this way so I'm want to explore explore this maybe within the next week or two and publish some data so we could have a discussion about it it's not sort of decided yet that this is the pivot we're going to take but

it is potential pivot okay no that makes it definitely makes a lot of

sense to try to and have a look at both of those paths in parallel and seeing how viable both of them ends up being I guess just what kind of is zooming you know more more broadly has there been progress on like figuring out what the costs of like bandwidth data are is a I guess like proof data of this kind I seems like it would have the exact same cost sounds like transaction data so do we have good like better ideas on how much that and if theoretically should be charged for

Alexey Akhunov: no I I'm not I'm not aware of such analysis but it's definitely

important so I don't in my plan that's so what very good point thank you

mm-hmm and I guess like final point replaced the hexer eatery with like basically any by a kind of binary tree so is like we were you know so it should tree replacements like be part of this and like if so for very big contracts like has there been thought of how to do that instantaneously I have thought about it but not for very long time so as far as I as I can tell now

it's very challenging to try to swap the the the healthy tree binary tree that's why I hope that if we get something if we have some sort of star core snark roofs we might create this altogether but yeah so I haven't figured out yeah but like instinctively start birthstone and started

Vitalik Buterin: don't seem like the sort of thing that would be viable within the next

like even one one one and a half yeah I'm a bit more optimistic on that I guess like my main concern aside from like

Vitalik Buterin: all of these technical issues is that there's the zero knowledge proving

things in general like you know each general purpose has an overhead of a factor of like anywhere between like 100 and 100 thousand depending on how ugly the computation is and a hash functions that we use today it's tend to be on the very ugly side and given what we what I what what I know about the efficiency of roll-up which seems to be a very similar case optimistic and it seems like that would like basically require block producers to have like a whole other layer of a whole other GPU dedicated to proof generation

which me I mean I explore in this with so I

we'll start exploring this with with the guys from Stark where once I've got the data side so maybe they will give me some hints okay then we majendie have just as a kind of by the way the end of 2.0 it's evil probably be having those same conversations what both star is probably various people

Alexey Akhunov: absolutely yes

yeah Alexey thanks for the update a lot of the kind of stuff you just shared I don't recall seeing that in the latest kind of fellowship of a theory or magicians post thread and the latest thing you posted on kind of storage management state fees just wondering if

there's like a more recent thread or I have a lot of questions and ideas as well but rather than take up a lot of time on this call I was thinking that'd be a good forum so where should we have that conversation yeah so I haven't so I only started working on this like three days ago so I haven't had the time to publish anything yet and but I will hopefully publish something in within like next few days and so because I really want to have a finish this coding first and then I will just write something up so I brought up in this code because it's important to know about the potential upcoming pivot but I simply didn't have time to put it down in writing yet I'll

Lane Rettig: keep my eyes I'll keep my eyes peeled for that and look

forward to digging into it thank you

Danno Ferrin: so you mentioned the parity guess hybrid work whatever sync is there any place for those prototypes are available that we could play with and try

on for example so

Alexey Akhunov: this is the the the the the challenge at the moment and I think if somebody from parity and go cerium or Nicole they could correct me but at the moment there are some prototypes in the code but there is it's not like written down as a spec or a model so that's why we be so one of the things we're gonna do with the this Red Queen we will actually try to do the spec as well as the modeling so at the moment it's a bit too early to say and I would like to also have some to encourage other people

to write the write up suspects as well but it's a bit early

stages yes okay yes at least the girl code is there's a pool request I'm not sure whether there's

Péter Szilágyi: a pull request or just my branch but I can shared link the code itself I mean it's fairly simple I guess it's more or less the idea you get the idea but there are still a few few corner cases I haven't solved completely and I had honestly I haven't I wrote that code a year ago and I haven't touched it since because something always came up

Hudson Jameson: one other thing that you talked about Alexi was figuring out the

p2p protocol are you talking about like if we're using like let p2p or something new or which protocol

no I was talking about the so we have this thing called East 63 which currently is used to essentially shuffle the data around this year network by the data I mean the headers blocks transactions so for each of these types of data there is a normally pair of what I call operative it's like get block get block header yet this and then they also announced thing so what I mean by changing peer-to-peer protocol it's actually adding more operatives to that for example to get me like a range of leaves or something like that so adding some

operatives to that which means that we will need to sort of upgrade the protocol so that the clients can all understand each other and these operatives will be dedicated to supporting this new advanced protocol which pretty much never fails hopefully got it okay anybody else have comments on Alexie's update ok we can move on

Hudson Jameson: there was an e wasum working group I don't know if that's still a working group or not Lane do you have any updates or

comment on that yeah I'm not there's a little confusion here because I think the e azam working group

is sort of like the e azam team and unfortunately like neither case you know alex is on the call I don't know Pavel do you have anything to say I don't know if I have any update on that I don't have anything in particular except we preparing for if you see great sorry

Alexey Akhunov: if I may I wanted to throw something in for the awasum as well

Hudson Jameson: sure

so

Alexey Akhunov: what I've been thinking about in terms of Eva's and I didn't after the workshop and and then before that is also if some some of you might remember in the first proposal of the state feast or stay granted was cold I was actually suggesting linear

storage which is like a new type of storage it doesn't exist yet in etherium and one of the reasons why I really liked that was that II wasn't is essentially kind of operates on a linear memory an idea was that you can map do the memory mapping from the storage into the memory in a very straightforward way I still think it's a good idea and I'm currently like trying to research this as well and maybe I will propose as part of the whole state management thing maybe I will propose this linear storage again but in a different guise maybe more integrated with the u.s. so I just wanted to throw this in

Vitalik Buterin: just to be clear linear storage like does that just mean

storage is a byte array

or so

Alexey Akhunov: yes so the current idea that for example if we introduced a new type of contract for example that will have you as encode instead of the idiom code or something like that and storage which is like a mapping to have essentially an array of bytes word and say you do some sort of merkel mountain ranges on the miracle trees which is friendly to the expansion so that basically means that whenever we execute it was and we just map the map is there part of the storage into the memory and then you can have this really great benefit because then you can use all sorts of libraries from the let's say the red black trees are sort of some

sort of sort of structures whatever whatever have you so because they would be the all these libraries are written in the assumption that you have a linear memory instead of like kind of the lithium storage so I see it as a potential for code

reuse would these we

Vitalik Buterin: would you be expecting the storage size to be like something fixed I know of one size so like possibly capped by a 24k or some similar number

or is that arbitrarily expandable

Alexey Akhunov: I thought about this because you I remember you were suggesting this idea somewhere I still thinking about it it might be a good idea but at the moment I'm thinking about expandable

storage so but I remember your

Vitalik Buterin: so you would still be able

to I go in just a store like byte number 547 gazillion

right it wasn't

Alexey Akhunov: kind of but it will cost you astronomically

a much OSE so in that case it is kind of de facto capped right as you like basically whatever coordinate would I was at all the comments another thing I'm a quick thing on he was especially rigor like this is also enough slightly

during in season two territory but I made up comments I thank you very on github yesterday or day before well basically like asking what does the e was I'm team Guyana think should be the kind of interface of you want some with respect with respect to the rest of the system so this would basically be like calls for a foreign function interface as how environment variables and storage would be accessed and things like that so I guess I was wondering Nick are there it would it would be nice to hear like in case the team had any thoughts like what kind of what would an ideal and of wish list for an interface look

like like is it basically the same as what we have now but simpler would there what do we want to adding any new kinds of features else so how it looks now it's like we have versions from simple as EVM up to the new ideas how to do it but definitely we need how to take some kind of iteration over it with other teams to figure out what the requirements on the other side mostly in the design repo he wasn't but some proposes how to make it

either more generic or more related to to episome li and yeah we have to precede that in some some way to we've probably other teams have said have a lot of

Lane Rettig: question for you do you think this would look anything like EC I like the work that you've done on that or would this be a very different type of interface

so yeah that's one of the this away so I figured that two aspects like

Paweł Bylica: how much compatibility we we need with EVM and have we learned from from EVM all the good parts of it and like bad

parts of it so this is how you actually want to access data from etherium environment let's call it this way they will probably look acts as as imported functions in new APIs MB but the other aspect of it is how actually you want to interact between contracts because both of them are written in in in in the end in in webassembly and the possibly provides some more efficient or more direct ways of calling one model from from the other so so this opens are not

another set of possibilities I'm trying to keep it on its high level

what yeah so

Lane Rettig: Alex also mentioned in the same thread I just posted the link that were investigating different ways of doing contract linking as well so I think that that time you were just talking about

okay great then I'll probably like poke into the you was InDesign repo at some point and I guess I'll wait for a key he wasn't be able to come up with more things yeah I'll

Lane Rettig: take a look as well the design repo vitalik and I'll try to map some of the open issues there to some of the questions and topics that you raised in this

thread as well and if you want to poke through there and I give me

whatever the guy no pointers to things you think will be more valuable to read it would be good to great will do okay cool I'll see was there anything else on that I don't think so anyone from pruning sync or simulation here okay and I don't know if those would have much of an update anyway for testing updates which is the next item oh I think it said something about is their appetite for a future okay right yeah

Hudson Jameson: we talked about that last time

anyone have any comments on that I kept it on because there weren't any comments last time but there's a different group of people on this time

so are there so I go ahead yes

Alexey Akhunov: I would say that the the person meetings a word but I wouldn't do it in like very often because there is a certain amount of work you know so you know there's all this traveling fatigue people have and some people feel that it's actually not very inclusive when people gather around in the I almost say that for example we did workshop that we did in Stanford I was a skeptical before I came but after afterwards it turned out to be a very very useful thing to do I know that is a

a lot of people couldn't make it but I say that it is he's definitely useful but we shouldn't try to do them too often I don't know when when we think that we have enough kind of divergence in our mental

models and we we kind of come together in terms of like making them more in course a more inclusive if they have to happen like bouncing them between continents is also helpful so I think like the last one the last one was in San Francisco and there'll be a kind of some people descending on Australia both of which are not very convenient for people from Europe but then at least like in our 2.0 calls we've been getting someone kind of constantly yeah so Jim

badgering us about having one in Barcelona so it it might make sense to do something in Barcelona at some point and then I I'm sure lots of people that were that will just found a way to inconvenience it come to like or just would end up coming to that one I know a lot of you folks are planning to meet in Sydney around I'm just wondering if any one is going to be there as well maybe we could take advantage of if people will be there or maybe not

Hudson Jameson: that sounds like a good idea as long as people will be there

yeah and I definitely don't want stagnate no cajole people in

fatiguing twenty eight hour flights but I mean if anyone is if anyone is coming then you know we'll be happy to chat there's a the commuting plans are doing a con already just enough warning international flights get more and more expensive as the date approaches so often there's so little warning it's just not possible when Zed Khan I'm a parole h14 yeah that's pretty simplistic yeah

okay so

Hudson Jameson: it sounds like there is an appetite for future meetings but we may need to have them with enough lead time so anyone who wants to take initiative on planning those meetings can go ahead and do it even if it's more I guess ad hoc and not like a really really big one they can at least give the opportunity and then people can attend and I know ed Kahn's pretty well attended so that might be a good one for someone to take up the torch on I can't because I won't be going but someone else could

yeah but I would say that for specifically for this here one X I think it might be for my point of view it might be too early because we haven't I mean I haven't even

digested Li the previous workshop I mean I've been digesting it for like

Hudson Jameson: yeah and figuring out the specs a little more clearly that's a good point

Lane Rettig: it sounds like maybe Barcelona maybe sometime in the summer maybe it's too soon to pick a date but yeah just back of the mind that's helpful

all right

Hudson Jameson: cool I think for we can get off

that topic for testing updates I don't think Demetri and Martin are here is anyone else have testing updates well yeah there was those

Paweł Bylica: small change to blockchain tests recently which which

aligned the configuration for for what actually happened on the Maenads yesterday which is Constantinople and the Constantinople fix were activated on the same block so frivolously the blockchain the block train test for this case what's what was a bit different and we changed that so some set of tests are different now and they were uploaded I believe yesterday so yeah that surfing client teams can take

Hudson Jameson: okay thank you very much for that

next

up we have client updates so we'll just run through that and then we'll be good to go guess he'll so

Péter Szilágyi: update wise I think two more interesting updates are that we managed finally to merge in all the changes that Slim's down the databases and cut out a lot of redundant data so we're kind of down by about 16 gigs compared to our previous one which kind of puts us in the same ballpark as parity so I'm really happy about that one and apart from that we kind of recently also found some bug within level DB which we fixed and this seems

to have sped up our archives things quite a bit but where they were still not quite happy so we're still looking into it but yeah apparently we managed to shave off quite a bit from the sync times and yeah I guess that's that's mostly what success stories and apart from that we're mostly working on the networking voice and discovery protocol and nightlife client and essentially trying to pull off the whole historical state Kooning but that seems to be a bit tough debug and that's about it

Hudson Jameson: ok anyone from parity here

ok unless

Paweł Bylica: no real update except the information that

we haven't done the stable release off of Constantinople fix yet we are a bit behind the schedule for that

ok Trinity okay theory MJS harmony not special from harmony except leaves a bust hot wok well that's it all right pantheon yes so big news this week is we released

pantheon 1.0 the big improvement there is cutting our archive sync time down we cut it about in half which brings us to about half the speed of death on rough stone more to come in future releases but that was a pretty big one for us we'll be continuing to work on performance reliability and fast sink and we also want to get involved with the work on the fast warp POCs we actually haven't found any of the details on that yet so if you are working on that and wouldn't mind reaching out to us or pointing us in the

right direction that would be much appreciated

Lane Rettig: Congrats on the 1.0 milestone

that's uh that's exciting yeah Congrats Eric did you have anything else or is that it Thanks wonderful okay turbo gasps oh

Alexey Akhunov: hi it's me again so I haven't yet so - oh yes is progressing but not I mean I haven't rebased for the Constantinople upgrade so it hasn't actually sinking fast Constance Nobu yet but something that I have fixed recently while I was doing this these the

stateless client thing is that I have this double GB I recently introduced the memory only mode where you don't actually have put anything on disk and then it was surprisingly slow but then I found why it was slow so now I'm hoping that I will have an option to to basically have the entire current state in memory but not in the form of the tribe but in the format of actual b-tree which is much more compact and it takes let's say 10 gigabytes if you have that sort of memory but that would result in ultra sync file sorry ultra fast archive sync so I haven't tested it yet but I would do it afterwards but yes at the moment I'm mostly using turbo jet

this is basically a working horse for all the data analysis which is pretty awesome but yeah I haven't caught up with the other things yet

Hudson Jameson: ok Nimbus

[Music] congratulations all the big boys and

Jacek Sieka: the Pope will release on the Nimbus side we're making slow progress and we're almost almost there for the first for the homestead fork so we've been able to think like a million blocks now running all of them and through the EVM and so on which is which is pretty cool so yeah so steady progress

Hudson Jameson: great

mana or

exterior ok mantas I still need

Hudson Jameson: to get those devs in here but I keep not getting in touch with the right people

nathie reom ok I think we have someone from web 3j here do you got any cool updates about your project ok and research will have Dani go first and

then metallic I think we're focused highly on these two aspects the phase zero which is the core kind of surface takes and stuff is relatively stable a lot of people are moving towards simulations and testing phase one which is consensus on data of the star chain the bones of which exist in a spec document but we expect this to go through kind of a highly iterative design phase similar to the phase zero stuff but if you're interested in checking out the grip of custody games and stuff and providing feedback now it's probably a good time to take a look and the phase two which is States data

execution on charge across our transaction this is something that we want to see and it's beginning to ramp up the efforts in parallel there's a Vitalik add as an issue in the specs repo I think actually laying Rd close to that oil go where we're beginning to discuss this is just kind of a large design space and a good time to start narrowing down that's generally what's going on on the research side check out each research if you want to see more of the stuff that's more outside of the spectrum but more in just the research area okay

Hudson Jameson: thank you I think that's all of the groups and the

agenda does anyone else have any final thoughts or anything else agenda items that weren't on there

Lane Rettig: I think there was a little bit of debate on the on the issue about specifically IP use that were proposed for Istanbul so Alex put put three of them forward but then Alexei had also said before we do that why don't we talk about some of the higher-level questions that he brought up earlier so I just wanted to acknowledge that that there was the IPS were there I don't know that we need to talk about them necessarily today

Alexey Akhunov: yes so there was a question number four in my comments about a deluge do we want to create a deluge over IP and sort through

them or do we first kind of want to figure out if we want to do things in a different way this time that's my question

Hudson Jameson: do you have an idea for an alternative way to do it

Alexey Akhunov: well this comes back to my two suggestions is about the sort of processing actually yep it's quicker by appointing the reviewers and essentially by but potentially making the releases shorter and therefore we don't really make kind of everybody is is a hostage of everybody else like so that's my my basically two suggestions and I I think

generally we might also do more reflection on the past me retrospective whether like what would you know whether we we did the best we could in the previous two releases

okay

Hudson Jameson: we might discuss that more in the next meeting but for the moment everybody be thinking maybe not putting down like on that meta EIP but thinking about the different IPS that you would want to go into Istanbul and we can talk about those feel free to put them on the agenda that

I'll be putting up pretty soon and yeah I think that's that's all good I think is there

anything else anybody had okay cool one quick thing can real quick let me get the list here can Anton Danno and Alexei stay on after the call ends I had a couple of things that were just outside of core dev stuff okay thanks alright bye everybody thank you [Music]

[Music] [Music]

[Music] [Music]

[Music] [Music] [Music] [Music]

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