All Core Devs - Execution #57

Transcript

[Music] Happ

[Music] J [Music] hey

everybody hey Peter all right let's go ahead and get started welcome to the EOS Tron fan club where we discuss all things EOS and Tron this is meeting number 57 and let's start with the Istanbul hard Fork Road map um so there were when Offrey was release manager he came up with a road map um and that had uh starting in May the cuto off date for eips and then I think sometime around October the actual hard Fork so people are liking that model so far that I've

heard um however um yeah I don't know if it had been completely agreed upon but it's sounding more and more like there's consensus around it so I don't see why we shouldn't go with that

Hudson Jameson: um what we're doing is um getting a group of release managers together um Boris I think you recently said that you have been taking some steps to kind of um uh get some release manager organization organizational stuff together

right yeah I think more uh I just considered that the af's plan was a good one starting to communicate that and

starting to ask questions about what we need to get done for that um the Joseph Delong who's been working with ethereum cat herters has kind of stuck up his hand and said that from an ethereum cat Herter's perspective he can be a point of contact UM to help whatever needs doing and using the ethereum wiki to uh you know flesh things out and have a a spot to work on and I also volunteered to work with uh Alex um on updating e233 uh so that we can uh keep the Eeps proposed in uh the Eeps repo uh up to date

Hudson Jameson: great which

Alex

axic axic okay all right that sounds good so um what that's that sounds like a good plan to me and what I'll do Boris is if we start a chat room with some of the people who are like Joseph and others who are wanting to organize More release manager stuff I'll get a chat room going uh on getter and Telegram and we'll get everyone involved uh cat H herters have one set up already oh cool um um I think it's private for now but uh um I think you may already have access but I'll check on that

Hudson Jameson: cool are you in it

Boris Mann: I am

oh perfect okay I not been keeping up then I will I will look at

that um cool so that's kind of

Hudson Jameson: the latest on the road map all that being said um let's uh start getting some eips together to propose before may we only have about a month and a half until we close down the proposal period um and start making decisions on which eips are going in um so anyone who has eips that they really wanted to you know go into the last Fork this is a great opportunity to get them into this Fork so uh start uh the way to start discussing those is to put them on the court have meeting agendas and then I will add them to the agenda and bring

them up during

meetings um Hudson will you somewhere be keeping track of uh the uh Su the suggested Eeps for the next hardwork and then event follow up them with the status of when we discuss them yes I'll get a doc together these are two discussed these are decided these are rejected kind of so

Boris Mann: this is already on the ethereum wiki and the change that Alex and I have suggested is that we actually make them as pull requests into the hard Fork meta uh e 1679 so this is really just

following the suggest questions and process that uh afre had started um with the tweak that hey let's use PRS so that we can actively track things and then uh Hudson and others don't have to manually maintain

a dock okay that's so you will create a a new meta and the process to get get something discussed basically just to make a PR against that meta linking your e into it exactly just in a in a proposed section and then it can move through um again still suggest it for cev's call to actually bring it up for discussion but in terms of tracking um

EP 1679 is the existing Istanbul hardfork meta perfect we need to clarify anything about like um these Eeps that people are should propose need to be hard for work related Eeps because the majority of them are not and even in this list that you posted in chat like 778 as far as I know doesn't require a hard that doesn't really need to be on this road map so that's the exact kind of things

Boris Mann: that we need to do with the formality of actually adding it to um 1679 uh obviously the the wiki is editable right now um and the 1679 I'm

proposing is should be canonical if it's not on there it's not going to be considered um I'll and I'll track down I think the author of 778 might be on the call today

so yeah is that Felix or uh yeah Felix I don't know I don't know if he's on the call oh no he's here cool we'll talk about that more then and good point Fred we'll we'll watch out for ones that only require a that do require hard Fork rather than something that can go in educational and like get getting the word out that that people should propose thece that it's something that requires a hard Fork

right like they can propose non hard Fork EFS anytime they want then they might get implemented any other time yep sounds good can everyone hear me my my computer freaked out for a second yeah okay perfect all right so next up uh progpow update um so uh just a second sorry I had to cough as I discussed last time there are two components of the progpow audit there's benchmarking and then there's looking at um the how like basically how efficient a Prague po Asic would be compared to a

graphics card and what the efficiency gains would be and let me pull up the proposal there's a proposal that's been submitted and I'm pulling it up here just a second and there's going to be another one submitted hopefully today from another group and what we're doing uh the cat herters are looking at both proposals and we are um basically going to evaluate them and then make a decision next week which one we want to um basically uh try to get funding for so uh if I so if I understand correctly there has been none work done yet on this there's been

Hudson Jameson: no work done on this

yes or I should say well I should say there's no there's been no work done on the audit itself now let's see so yeah the and um something you asked Martin I think in the uh comments has been um if the the overview and claim so basically here's what the questions that the second audit would answer um and then I'll approach the first benchmarking audit because I have new developments on that too so the questions the deliverables I should say are um a constraint analysis on progpow uh to look over the overview and claims of how um efficient the a progpow Asic would be

compared to a graphics card because there are claims that you wouldn't get that much of an increase and so that would deter people from building a prag Asic in the first place uh so basically a hardware constraint analysis then there would be um an analysis on the proposed Asic architecture um a manufacturing assessment with that includes expert interviews um that's something else that is in the deliverables for the first proposal we received and then potentially an economic analysis um on the uh impact that progpow would have on economics of the ethereum uh protocol so that is kind of what we're looking for not there's a potential that

because of budget restraints we might not be able to do all of that but we're going to try to do as much as that as we can so I think what some people have been asking about is um number one the benchmarking how's that going and I've talked to white block and they are on the fence about um uh what the next steps are because they haven't secured funding for the audit there's also been a lot of community participants who have sent in their benchmarking which although not as I guess scientific as white block would do in their analysis it's still um is something that we can look at and

evaluate uh since a variety of people have been doing it in particular um one person uh actually live streamed the audits over a series of graphics cards and for proof that they're actually using the graphics cards and then ran the numbers um over like a twitch stream or something which I thought was really impressive so what might happen is we may not do the benchmarking part at all because that is the Lesser uh less important part of the two pieces of the audit and we may only try to pursue funding for the second piece so um big question is even if the audit doesn't get funded are we still going

forward with progpow and I think the answer to that is I'm not positive but it looks like more and more consensus is going toward putting progpow into the next hard fork in my opinion um that is something that we will need to discuss on here um between now and May and because the audit might not be done by then but I think a path we could go down is if we decide to put progpow in as one of the eips that would go into Istanbul we can say by May yeah it's going in and then when the audit is done we can choose to throw it out if anything major is found in the audit like any problems or something that would um eliminate the initial reasons why we chose to put prg

poow in the first place um put pgp in the first place so I think that's a good path to go down but I want to hear people's opinion on a path forward um since this is still a political topic and um being debated and things like that I I kind of want some insight from uh anybody here about what they feel like the um consensus is going toward and what we should do

so

Danno Ferrin: I was surprised how uniform the uh Co coin vote and extra data vote was in favor of it that was a bit of a surprise so I think that does change some of the

um the calculus as far as what the audits have to deliver um one thing that I heard that was wasn't listed that I think should be part of the audit or at least some Community contribution for it would be an analysis of the security if because there are some changes to um the hash kitak is going to a 32-bit version instead of a 64-bit version and someone with real cryptography training and experience might be useful for them to go over make sure that it's been done right um to my look it is but I'm not a trained cryptographer

and you shouldn't trust me so okay that's something we can definitely consider um other comments um yeah I

Tim Beiko: I spent some time uh with the cat hurters over the past

couple weeks trying to understand like the progpow community like where they're at um and one thing that they seemed frustrated about was the lack of clarity about like the next steps um just came up in a couple forums um and I think this idea conditional acceptance is something that would at least help sort of them like people interested in proile gain clarity about like okay this is really the only missing piece it's like if the audit is only green flags then uh it's going in uh because I think there's a fear that because the work on the audit

is not started then if it starts too late uh then it won't make it a day stand bu and then that's another six to nine months for the next hard Fork yeah yeah

like yeah so my thoughts on matter are that I mean any e that we accept for hard Fork if it later turns out that there's something horribly wrong yes we're going to pull it so it's always going to be conditional acceptance and we have actually made it was my understanding that we at one point did make a conditional uh acceptance of this a and now that I mean on the court of quot now now we see signals from miners we see signals from coin holders and coin vote uh about accepting progp so I think I don't know if we should um yeah kind of uh consider progp to be

accepted and then obviously if the audit turns out there's something horribly wrong we're g we can remove it and I think progpow is going to be the historically simplest thing to pull out of a hard Fork because it's unrelated to everything else and we're not going to have to rewrite consensus test cases just because we remove it um yeah that was about it okay so

Hudson Jameson: the one question I have related to that is when we say something goes horribly wrong are we talking about like figuring out that it has something like the hash function is just fundamentally broken or something like

that or would it be something like oh it turns out an Asic manufacturer could make this thing in a month and it would have a 20 times or 20x um like increase in efficiency so really it wouldn't make a difference in the first place

I mean either of those but it's hard to say how we could um we would have to discuss it when we get the audit results but if it turns out uh across all kind of sense that it's Tri easy to make an assd for then why would we do it I mean why would we uh switch Pro work if there's no

improvement yeah that's that's kind of the feeling I'm getting from others too um can I get some comment as well um so it's so I just wanted to remind somebody who people don't remember what we did actually in January when there was a tentative agreement about the the progpow I mean I don't know if we agree on this specific thing but I was suggesting at least that that the progpow should be activated in a separate hard fork and then but now now we seem to kind of um default it back to the old ways that basically bundling things out and also it seems that in the first uh part of this call we again I

mean it seems to me that I suggested in the last call that we should think about restructuring the sort of delivery uh the changes so that we don't we at least explore the the of possibility of not making a huge changes every nine months but potentially spread it out and also appointing the the the reviewers for the changes but it seems like we kind of sort of by default went back to the the old ways of doing things I totally agree Alexi yeah I'm also more in favor actually of rolling out progpow and potentially other things more peace wise okay uh what are other people

think it does have a like a lot of advantages because that means that like both there's fewer things to worry about but also like there could be two different pie like different strands of work could um happen in in parallel where basically finalizing and rolling in rolling out procow would happen at the same time as implementing the other hard works that might require different kinds of test cases and so forth hello and also oh sorry yes go Greg um how long does it take an ASI manufacturer to deliver on some promise

like 20 is ridiculous but two three four whatever if if we got evidence that an Asic manufacturer could actually beat Prague W how long does it take them to to actually roll out a chip does anyone know well it's been discussed on if def El is they could do it between six to nine months but that opens up another question of is it economically viable if they need to use um hbm or whatever it is it's some really expensive memory and they can do do in six months and it costs you know 10 times as much to make the minor as it

would an E minor even though they get the same improvements um that that adjusts the economic impact of it okay I mean this would seem

Greg Colvin: to be irrelevant to the consensus we already made

wait you're saying

Hudson Jameson: what would be irrelevant to the consensus

your question or

Greg Colvin: we already decided REM moving un Le there's technical issues so being told by someone that oh we can do an asick after all but it will take months and months I kind of shrug and go well put put your money where your mouth is

and that's what the audit's for the

audit is to actually basically go through the exploration process of creating that Asic without making the Asic so they can know what the efficiency gains would be and a and without actually building it

Greg Colvin: this is a separate audit from the

the security audit so the so to find the security audit I'm not sure we made a

Greg Colvin: consensus to move forward unless technical issues arose um so I'm I'm rolling all of that into security um for us if if there's something wrong technically it's going to affect the

security of our system if if an Asic manufacturer claims that they can beat it that's not a security issue

well

Martin Holst Swende: for proof of work system I would argue that it is

yeah so these are two different issues so one issue is is procow a a good proof of work algorithm in general so that is maybe what the security audit that you would be referring to would actually determine is whether it's a suitable proof of work algorithm at all but I think we're reasonably sure about that by now so and then the other thing that has to be determined is like is it economically sensible to you know for for the goals that

we yeah well no we're we're

Greg Colvin: going back to stuff we were tired of talking about months ago we decided that's the only issue is whether there were errors in the algorithm back doors in the algorithm anything like that not arguments about whether not arguments between the GPU people and

the ASI people that'll that will unroll over time yeah that's not well it's not about the arguments between

Hudson Jameson: the GPU and Asic people it's about the reason we would put this in is to prevent or dis or

highly discourage Asic from entering the ecosystem and additionally to make sure that as6 that would enter the ecosystem would not have more than a you know whatever X um Improvement upon previous as6 or comparatively to gpus is was my understanding

so that does have pieces that require we already had this discussion and I'm not going to believe any such numbers until the a sick chips actually hit the market

Hudson Jameson: even if there's an audit that would determine that

Greg Colvin: yes

Boris Mann: Hudson I think I think from what I've seen and what Tim

said this is the all of the pain and suffering from the people who on the mining side has been there's like three audits what's the point of them which of them need to get done and I don't think we're testing whether or not an Asic might be created that's up to the market and we we can't know that ahead of time um can we meet reasonable security guarantees ahead of time is I believe the point of it and if this isn't written down let's just table this and say where is the single written down thing of what the purpose of the audit is

Hudson Jameson: okay I think that's fair and we should get that organized

because it sounds like we don't have that right

now

Boris Mann: are you the point person on this Hudson

I would say the cat H herters are and within that there was a group of about five of us in a chat room who were organizing this and so yeah so so

Boris Mann: let me be very direct and I've said this before to the cat herters already um regardless of decentralized from a responsibility and planning perspective there needs to be at least one human who whose responsibility it is so maybe that's the other action as well of figuring out who that is

Hudson Jameson: I agree I think that that is a good step forward and I will see who can take that up and announce it um on I

guess the magician's form would be best uh to clear up both issues that you just brought up which is point person who can make these announcements and uh what the audit is actually covering

and another comment I wanted to make following what Greg just said that I don't think we could be sort of pedantic about things so in a way that oh yes we have uh said or maybe sort of decided that this is what we're going to do and then we discover some information which means that what we were going to do is going to be useless but we have to still do it because we decided I don't think we could do this we're not uh because otherwise it will look like a like all these brexit negotiations

everybody understand it hurts but but we're still going to do it so I don't think we should do it like this so if we to we should totally go back if we discover that the change is going to be useless we should totally go back and cancel it yeah

Hudson Jameson: I agree with that personally and to discover if the change is going to be useless is under what conditions because that'll help write down the deliverables for the audit

well

Alexey Akhunov: this is what I complained about last time is we were discussing it again is that it this was very difficult for me to pin down when I was trying to actually figure it out like what is the goal what is the what are the criteria for success and so far I have not not

been able to to extract this from from from uh people who are suggesting the profile so I don't know so it's basically making a different difficult to write it down so I don't know I mean it's kind of vague if it's vague on one side it's also vague on the other side

so I my understanding of the goal was to discourage or entirely prevent as6 from joining the network um and kick off the current as6 on the network in order to prevent a centralization risk and um also to in a way and this isn't like maybe something that's like super

official but in my mind it's to also appease the current miners who have overwhelmingly said they want this

Alexey Akhunov: well this is basically what I call call the very vague and loose description of it and if we go if you start working from this then I wouldn't be surprised if the if the the the the what you expect from audit will also be vague and loose and uh so so basically uh demanding that the the audit should deliver very factual and the results is actually unfair because before you can do that you also have to Define what the goal of the actual change is like in the numbers if you want to put the if you want to have a numbers on one side you have to have a numbers on the other

so

that's to the critique of what Boris said or Tim yeah I would

Martin Holst Swende: I would say that it's people who are currently uh against progpow are the ones that should Define what

do we what questions that we want answered uh or yeah yeah I think

Boris Mann: I think what you're trying to say is basically this is going in unless there's security issues or number X or number y um and frame it as such that the the the the audit must

prove uh those things is that the right way of saying it

so

Danno Ferrin: maybe those who don't want it in the burden of proof is on them

is it why why is that is because because basically two people in January said on the call and actually one one I was one of these people I remember how this what we call consensus has been made because basically I said that we need to just stop procrastinating this was my exact words and we should make some decision and Hudson said yes okay let's make decision and that's it that was your consensus and then after that I added that oh sorry I needed to also to add that the the change has to be stand on its own so it has to be separate hard

Fork so if you call this this this is a consensus made by me and Hudson then I I I don't know it's like now the burden of proof is again on on you know if that is enough to basically to shift the B burden of proof on the other side I don't know what is it like it's it's we also had the coing vote and the exra data vote and a lot of um marshalling of support from the pro prod community on a lot of the forums so I think that consensus alone was not what pushing the burden of proof on the detractors um the miners have a large stake in mining and they've spoken fairly uniformally which honestly surprised me

Greg Colvin: the consensus was not just two people

it was everybody on the call and it was it was months of discussion leading into it so that anyone who really cared should have been on the call um and you know if you don't object to a consensus that's that's part of the consensus nobody objected many agreed nobody blocked it we had a consensus that it was moving forward unless there were technical issues um not whether GPU miners liked it not whether some ASI people came up and said they hated it

not whether some Asic people came up and said well we can beat it we really can um none of that I am fine with saying it doesn't have to go into a particular hard fork and I remember Martin in a previous round saying we really should have a separate hard Fork just for it and that's a good idea I think because it takes the pressure off um it takes the pressure off finding the technical issues um but I just object a lot to bringing back up you know any of these non-technical issues I don't I don't particularly believe anything you know

the miners have to say about it until they actually deliver um especially because if they really can they would keep their mouth shut and just make some money otherwise um otherwise it just doesn't mean a damn thing

to me okay so just I just want going to comment on the very first thing that you said which is I think is not was not common understanding so you said that if somebody is on a call and doesn't say anything which mean that means that they agree with the decision I actually probed this guys just to interrupt I'm in the interest of progress can we agree on say a timeout of five minutes from

now for PR discussion

Alexey Akhunov: okay I understand so basically I just want to say that it's against my understanding that everybody who's joining the call and then not doesn't say anything agrees with what been said because in this case a lot of people would just refuse to join the

calls so that's what I wanted to say con consensus is not a

Greg Colvin: consensus is not about everybody agrees it's it's about nobody is blocking the consensus

um so let's let's move on to the next thing and good idea of italic we'll put a we'll put us like a pause on that and come back to it either late like Pro hopefully later in the call um so the

Hudson Jameson: next thing is Felix's EIP 778

for

ethereum node records Felix if you can give us a couple sentences on what that is and um what your proposal is to see what everyone feels about it um and just to also clarify that it doesn't involve the hard Fork yes all right so so um yeah so the story behind the etherum note records has been that I submitted the e in late 2017 I guess so it's more than year ago and um it was kind of the first e to to be submited in this like in this like series of you s like General peer Discovery improvements uh but the the my problem is so first of all so what is it

so it's it's a it's a definition of a data structure that is that can be put in like any network protocol but the specific intention is to put it in the current node Discovery protocol and in the next version of that but um the intention behind making it a separate e is because this data structure is kind of universal and it's actually very useful to to agree on a common format for note information regardless of the system that it's being relayed in and I hope that some people have actually read the E because it tries to explain that in a bit more detail and it gives some more examples and um yeah so that that's what it is so uh to answer the second question no it doesn't require a hard

for because it's basically a data structure that isn't involved with ethereum consensus in any way so and um the other e that I'm not bringing up for discussion today but that would kind of be sensible to include at the same time is the enr V4 extension sorry I don't have the number handy just yet just now because I'm on my phone but basically uh that one would kind of like Matt help suggested that it makes it would make a lot of sense to um activate that at the same time just to have a use for this format because just having the format alone it doesn't actually buy you much you kind of have to you know like relay it over the network for it to be useful so it would be good to just have at

least one use of it in the sort of agreed upon set of protocols but um so I think this answers both of your questions and the way I would like this discussion to goal is to just you know if anyone has any questions I'm happy to answer them just now so okay Felix I have read yourp and I think it's long overdue uh this this CIP and it's pretty looks pretty simple to me my only question is that what is the upgrade path that you're thinking about like how how can we actually get into is does it require everybody to upgrade simultaneously or can it be kind of done over some period of time no so there is no um so with this with the

Felix Lange: just with

this e there's actually because it's just the data format the way that the like implementation consensus would be achieved is that people would just implement it and then we'd kind of you know be able to compare you know the records generated by one implementation to the other and say I don't know a unit test or something and we basically yeah know that both imp like all implementations can generate these records correctly and they are actually sort of valid and then when it comes to integrating it into the the discovery this is something again that doesn't require any specific like cut over date or anything because we can make this change in a backwards compatible way such that notes that do support it will use it or can use it and notes that

don't support it will just ignore

the feature so it's there's really it's really like so I would recommend to include this this comment that just made like with the uh the actual upgrade pass into maybe to to so that it will be easier to it is kind of

Felix Lange: in the other e that actually uses the format so but this again the 778 is just about the format so the thing that I kind of wanted to get for a long time was to was for someone to just kind of look at it and sort of like sign off on it like saying okay I'm a client implementer I've read this E I think this is a good way to represent arbitrary node information like this is really all I wanted so um I I like in the meantime

implementing a wise so I've integrated in go eum so it's pretty core to the go eum networking stack now because basically at any time any code deals with like any kind of node it's represented internally as one of these things so it's kind of like I can attest that basically it's a good way to represent node information because we're using itum but um yeah but like I said yeah there's like we we don't actually use it over the network just now so the upgrade path would be to implement the the other e that actually uses it in the existing protocol or to implement the DNS Discovery e which also I don't have the number right now which also uses the format so these will be the two upgrade parts and both of these

can be done without a specific cut over

dat

Jacek Sieka: in terms of implementation effort how would you score

it like I don't know hours days weeks so for the basic format is really simple so it like in go so actually there's a I have a python implementation and the python implementation is like 80 lines or something or 100 maybe uh including some like convenience code and um the hard part about this format is that actually like just the format itself is really simple I mean it's it's an it's an rlp list of list of variable length containing you know alternating

key value Pairs and there's some crypto involved for you know verifying the signature and everything but that's it so it's a really really simple format it's literally just an RO list containing key value pairs like that's that's all there is but um the um the hard part about uh enr is actually generating it properly and this is something that took a bit more code in in go theum because uh one of the key changes with the enr is that node information is signed and uh it kind of means that in in the client what kind of have to do is for example anytime you want to tell someone else about say your IP address you have to give them like a signed representation of that IP address

so you better be pretty sure about your own IP address for example so the way we handle that in go theem is to we have a prediction mechanism that continuously monitors the UDP traffic and then detects when our local I when when our local internet facing IP changes and then it generates a new version of the node record signs it and makes it available but this kind of code is this is something that is not in the E because the E is just a format but you know just you know like creating signed records of information about yourself can be a bit more than just you know encoding it in this way well you don't have to go through like you know these lengths you can you can totally Implement in a simple way but if you want to do it really well you probably

have to add like a couple hundred more lines just to you know add the infrastructure to figure out when you should actually make a new record because it's kind of implied in the E it says okay whatever your local node information changes you should generate a new record and sign it what that actually means is that you have to have an internal mechanism to detect when your local node information changes and that can be you know a bit more involved did that answer your question it's exactly the kind of nuance that that I was looking for thanks and I actually just after what you said is that I think you're mentioning there are some other eips which kind of logically follow from this and I think it would be useful uh to actually have the a little bigger

picture because I understand your desire to sort of feed them one by one and it looks like the good way to proceed but maybe it's also good to to show like what is the big picture like what are we getting out of this yeah absolutely I can do this so the big picture is basically that you know in terms of peer Discovery we had this problem for a long time where um just from the information that's available in the current protocol you don't actually know much about the node so all you pretty much know is the IP address and and and the port to connect on and the and like the sep 256 K1 public key and uh from from that information you know you know the system is reasonably secure I think at the moment but one downside of it is obviously that it's an index of all the

nodes that you know that exist including you know any swarm nodes nodes on other blockchains you know at any time go ethereum is Fork to create to create a a spin-off of ethereum we add you know a couple participants to the DHD that don't actually belong to any blockchain that we you know want to connect to or something uh so there's basically the current Discovery system is you know an index of all the nodes but it's really like you know every node ever so uh the thing that we wanted for a long time was to just be able to distinguish nodes before we even connect to them so we kind of wanted to have um a way to just you know filter out um notes that aren't particularly interesting to us so that's one use case for it and then the other use case for it is uh to allow client

implementers to go forward with say alternate transports and stuff like that so the the big topic for a long time has been that people have been pushing for say lip P2P integration so they what they would like to do is you know maybe remove their RPX implementation and just you know use lip P2P throughout even for eum one and uh the way forward for that I think in a backwards compatible way would be to you know have a way to actually announce that you support like an alternate transport or say I don't know a very special feature that is you know only really only related to your implementation or your blockchain or whatever and you kind of want to be able to announce that before um others connect to you so they can all or or

like connect to you already with this knowledge that you know you're going to support the thing that that they want and this is like the big picture of it and uh this is kind of how the E came to be like as a format to be able to announce these things and then the um the big question has been you know like how to integrate that with the various mechanisms that we have in place for the discovery and the the the road map there is to kind of sneak it into the uh existing Discovery protocol as an extension so you can use it if you want but uh most of the notes aren't going to use it uh the upcoming version five of the DHT is actually going to support it natively so it's a good first step in

that direction implementation wise because if you're going to be on board with like the next version of the DHT you're definitely going to need this format because it's core to the whole thing so that's all this new thing talks about really is is note records and um yeah other than that I mean the other e that's out there that hasn't received any any comments so far except from someone from status is the uh DNS Discovery e so that's just like a totally different Discovery mechanism that doesn't rely on the DHT so it might actually be very very useful for people using doing private networks and stuff like that and we do kind of need sign note records for that because the um the DNS Discovery system is uh has a

goal of being sort of like because it's a um it's not a system that's like you you can freely participate in you kind of have to get your Noe listed if you know what I mean and the my my problem with these kinds of schemes that has always been that of course you know as soon as you have a setup like that there is someone who has the authority over like which notes you can see and I wanted that to be as transparent as possible so with the DNS Discovery a good thing there is that the no list themselves are signed but also the entries in them the the the the entity that is publishing this this node list for others to to to discover PE from um cannot actually change the information about the participants

inside of the list because they're all signed by the participants themselves and then you know others can actually audit the whole list and see okay so are they including like shitty notes or like I don't know notes that Behaving Badly or something and they can hold them accountable because the whole list is also signed by the provider and stuff like that so there's a lot of um there's a lot of things we can do once we have this like shared form at in place I think because it it means that different Discovery systems going to be interoperable we can you know start trying out new transports even on the main net I don't know there are couple of people who have been bugging me for like months about you know different sort of Transport ideas and they want to like you know I don't know explore

totally different mechanisms of relaying blocks and stuff that and I think all of that can happen if we have the basic infrastructure in place to actually negotiate these extensions to the regular protocol so does that answer anyone's everyone's question about the future yeah I mean overall I'm in favor of enr I think the the one thing I would add is that you know integration into you know V4 with the backwards compatibility um you know some of the methods are there are more of you know one-off exchanges between peers uh do Envision adding some sort of propagation and query mechanisms um to get you know enr records so for example can I go to a peer and say hey can you give me all of the peers you know of that have um this

um you know in their um enr records you know so on so forth yeah I'm not I'm not super sure because it it means we like so the problem is that with the current V4 index I I don't want to like get too deep into this discussion because I think we're not quite ready for that yet we should have this discussion on the V4 extension but I can just quickly say that one problem with adding too much into the existing system is that there's always going to be a lot of participants that um will not support the E because they're just old software or something and uh we don't want to fragment the DHT too much because to be honest it's kind of nice that we have like a a reasonably sized DHD it makes the whole thing just

a lot more secure even if the participants themselves aren't participating in main net the security of the overall DHT is higher the more participants we have and we don't want to actually lose anyone there so if we're going to start you know preferring certain nodes because because they support the extension or something that's just going to reduce the security so this something to keep in mind right but at the same time I mean it's really more of keeping the existing DHT with augmenting it with some additional metadata for some subset of the peers that would be in the HT um and then also preference for peers that are supporting this you know also incentivizes um upgrades and people to keep their uh software up to date but

yeah we should have this discussion offline yeah so let's let's have this discussion on so by the way in case you guys are interested in this kind of stuff so the way I've always been doing is kind of like I've just submitted the e to the networking category which is reasonably sized so there aren't too many proposals in there actually and all of the proposals have a discussions link that leads to the de PDP repo so you can just um at any time come to the Deo and if you have questions or suggestions for the future or something just open an issue there it's like totally open for that and um um yeah so yeah we I'd be happy to discuss like any any ideas about the future of networking in that rort to be honest sounds great Felix thank you is

there

Hudson Jameson: anyone opposed to this otherwise I think sounds like it'll go forward

Boris Mann: from a process perspective and maybe this also solves the problem for Felix of not people not looking at it um is there something we want to do about uh last call signaling

I think that's a separate conversation of overhauling EIP 1 personally but um yeah I'll take it there because we're going to do some work on that with 233 probably as well yes absolutely personally I looked at this yeah sometime early next year uh next year last year and um I think the part of the problem is it's it's um too

granular so yeah this is an e for data record looks like a fine data record like it's without the greater context of with it we can do all of these things and this is how to integrate it and this is sort of the implementation and path forward you know it's just another data structure that looks as good as any any other data structure um so I think U you know getting the context in is necessary to actually make a decision on this and moving it Forward I would also suggest that actually just implementing it in one client and then going to the other client hey we have this please do it as well okay so

Felix Lange: is there anything I could

do to make it easier for you

is it is there anything I no at this

Fredrik Harrysson: at this point I understand it and agree with it completely

sorry I think we should just do it okay all right so because I kind of want to do this right you know with the whole E I have a related thing by the way so I'm not sure is is there anyone else who has an objection okay take I'll take this as no so I have a very very quick related question I'm sorry I didn't put it on the agenda so um um we've over the past uh weeks what we've done is actually we've revamped the um networking specifications one more time so I think they're really

really complete now I'm actually happy to say that we have a like fully specified Network St now like from the ground app so there's like the specs are really comprehensive now and should be sufficient to implement from the specs alone that wasn't actually the case previously and one of the things I've done is I've um copied over the specification of the of the E ethereum wire protocol from the ethereum wiki to the repo and actually uh made it a tiny bit nicer so and I just added basically like I I've kept all the content but um I've just you know added some more explanations about certain Concepts and stuff and I added a description of fasting and a description of of fing that actually matches the current protocol and stuff like that so um what I would like to request is that I'd be

allowed to um replace the spec on the wiki with a link to that you know actual specification in the Rayo and then you know from now on you know if anyone has anything to add to the spec they kind of have to open a pool request would that be okay for everyone or is that like too much Authority on my side I don't I don't know no I think I think it's a great idea so we do need this uh more spec if you think that you're done you've improved the specification I think we definitely need this more of this stuff right so you know just yeah so I mean the same thing has happened the Json RPC spec just got merged into an EP but a bunch of interested people have tuned into into a separate repo I think this

also nicely falls out into working groups of certain areas of the stack um so having it essentially have a an EP that points to the repo and knowing who's responsible super useful yeah okay I agree so the other thing that we've done is we've also moved the light client uh specification there so it's just alongside the E specification now and they're like actually similarly good so it it might actually be super interesting for people because I think most most people actually had a hard time finding the the like CLI specification so far because it's been you know on on uh on someone's private uh repo wiki page so there's now actually an official place for it also I had a discussion with afy uh late last

year about uh copying the parody specific uh protocol specs into the rapo but maybe not making it the official source for them I still think that you know this is something I can just do because there there are no like legal restri on these specs but would still be nice to get like a positive uh feedback from from parody about you know moving or at least copying those specs into that prle also so yeah for sure sounds good okay so I can we can just do we're just going to do this next week then we're basically just going to copy your markdown content and just you know insert it in the in the rle and then I'm not sure how I'll let you know if someone if someone wants to we could

we could

Alexey Akhunov: uh we could make a follow up on the next call and just see how it went you can just come and tell us how it went

all this specification things right yeah so I just think that you know it's kind of

Felix Lange: time for us to have you know like an official source of the spec that isn't the wiki because with the wiki it's been I just you know keep seeing people like edit like random parts of it all the time and it's I think it's it's actually much better to have a

a decent record for yeah can we add Discovery version five to the wish list to the which wish list of moving stuff to EIP specification well yeah so the the we've

actually taken a bit of a different route with the dis 5 because it's kind of large so

Felix Lange: the original plan was to submit it as like two different e but it's kind of weird actually now it turns out it's kind of weird to actually have this like super large e specifying the entire protocol because there are just too many things there that you know we need to come so I think the the process for the whole Discovery protocol has been so far that we've just committed a the draft to the defp repo now so there is a draft now for the wire protocol but um the way we want to uh move ahead with this is we're just going to keep editing that draft until it's it's until it's fine and if anyone wants to participate in the development process you're free to come over to the rippo and you know

add your suggestions open issues whatever but um we're just going to basic I think at some point we're going to do is maybe we're just going to write an e that says this is a new protocol here's the link and do do we want to schedule it for because it doesn't really make sense to copy the entire spec into an e it's just too big and you know adding rational content for like every single thing we have like yeah it's better to do that

work

Boris Mann: pointers that's that's the thing describe it briefly and then a pointer to where the uh spec is maintained maybe an additional thing again in The Who are the the humans where if the EP can get updated for who's the point of contact that would be really useful

yeah so but

Felix Lange: it's too early for the E now because we haven't actually fully finished I mean there are there are so many uh interested parties in the scar V V5 I mean we're also discussing it separately in the in the in the etherum 2 discussions and and and and with ipfs people who are also like sort of interested in in it so it's just there are too many people interested in it right now to just you know make the E now and sort of finalize it we just have to like yeah finish it first

so yeah

Hudson Jameson: sounds good

I just also wanted to add that if we include a link to any sort of repos we should include the commit that's being referenced too

Hudson Jameson: all right okay cool thanks so much for all that Felix I think that's going to be very

helpful

right um so next up we have the working group updates

Hudson Jameson: um so let's start with Alexi um what's the latest on the uh we're calling it State fees

right

Alexey Akhunov: yes we still we still call it State fees because it it's still um I mean it now kind of moving maybe in a hybrid Territory between State fees and something stateless so last um last meeting I mentioned that I started to do some data analysis on on the viability of the um of the stateless clients and so what I did since then I have uh coded up the Prototype which is essentially uh producing the block proofs in some

serialized format and also on the other side it actually parses these block proofs and tries to execute the blocks using those block proofs and so verifying all the hashes so this way I I kind of I'm sure that the number that I'm getting is pretty accurate so of like how many uh bytes do I need so so far I've been able to run this through to the block about 4 million and there are some issues on the way but I solved them but there's still more so I could give you some preliminary uh data but it doesn't mean a lot because the interesting things are actually starting after the block for for million so let's give you quick overview of what I found

so essentially uh first of all the the block proofs in this stateless client idea comprises of uh several things so first of all it's the the the the hashes which are basically the the the the components of the proofs of the miracle proofs so then there are the um the keys and values and so essentially these are the leaps of the state to try so uh so the keys are essentially like hashes of the accounts and values are the calization of accounts so these need to be present for for for for the for the cases where for example the transaction reads out of an account so then there is codes of the contract so if the if the transaction accesses a certain contract

and need to run something the block proof has to provide the code of the contract otherwise and there's no way to execute it and then um finally there's also something I call masks in this uh way because so essentially this is the way to uh to describe the structure of the proof because the proof is essentially uh is kind of the the portion of the tree starting from the root and you have to describe the structure somehow to be able to to to recompose Recon reconstitute this little subtree from all the hashes and all the shorts keys and keys and values and I also split split the analysis in two parts so uh I do separate analysis for the main try which is the which contains

all the accounts and also separate analysis for the for the contracts so in in the reason why I do it is because we want to to evaluate whether we want to do stateless clients for everything or we just want to do stateless clients for for contract storage and do the the the state fees for everything else for the for the actual accounts and so far up to the block 4,000 the rough numbers are um so let's say that first for the uh for the hashes okay so so the masks for that describe the structure are pretty insignificant compared to the hashes and let's say that the block for about block 4 million the the the size of the hash hashes in the proof are

about 100 than 30 kilobytes per block but I expect this number to rise so this is only for the for the non-contract storage so only for the accounts so for the contract storage the number is about uh 60 kilobytes so in total it's going to be uh let's say 40 + 60 will be 200 kilobytes this is only for uh a proofs the the hashes which constitute the proofs and as I said the structure is is insignificant and then for the keys and values so keys and values which are not in contract they are about 6 kilobytes per block and the keys and actually no not not six kilobytes 12 kilobytes per

block and the the the contract keys and values are about four five kilobytes per block so as you and then the codes of the contract are about 50 60 kilobytes per block so as you can see that the biggest part of this whole thing is so far the the proofs the hashes but as I said that the the activity of the with the contract will increase uh and uh so we will probably see a big explosion of this so I will keep the the running the analysis and I hope for uh as as soon as I get some interesting numbers like for Block five five million six million I will publish it on a blog post but that's basically update and I hope to

include this uh into the next uh version of the state fee proposal

Hudson Jameson: okay sounds good thanks for the update um the other piece we have for the I I guess we're still calling them working group updates um FV 64 call for proposals and stop gaps that was um Matthew Halper and Jason Carver so uh Matt uh uh if you could explain what that is and any updates on that

yeah absolutely so I think the motivation is that there hasn't been um any sort of upgrade to um

eth you know the eth line of um some protocols for some time I think even so far back as 2015 so the idea was just um to open a ring on eth magicians to see you know what ideas were out there what were people thinking that sort of thing and um I'll post the link in Zoom but uh there's uh actually been a lot of good um discussion going on there we've had good proposals uh spanning multiple client implementers uh the changes have ranged uh from simple things like adding some fields to more complex things like uh supporting client side client side flow control uh from less uh to some things that are a little more middle grounded

like consolidating less and eth and then also um adding better uh fast sync support Primitives so at this stage I think I'll leave the call open for another week but then starting to get uh key stakeholders or people that are interested and moving forward with their proposals uh getting them into Eeps and then starting to I guess um prod the client developers to see who would actually be interested in um supporting that and then of course getting reference implementations I would um want to say that like for I think what you're talking about is slightly broader but um when it comes to

syncing algorithms both gu and parody are working on one uh and they're like both gu has and parody has Pro concept implementation and I would rather that we focus on those and try to say okay this is not good about this algorithm or this is good about it but like let's change or evolve it in some way rather than go back to the drawing board and say okay now we're doing a call for proposal and we get you know 500 proposals that are all equally good because this is a problem space where there are liter literally thousands of different solutions and they're all equally good um so we just need one and like considering we already have

implementation of one let's try to make like iterate on that one um yeah absolutely do a bunch of more proposals that then delay everything again right so so I I don't think we have to go through you know the formalities too much especially for you know fast sync and and things like that um I I assume that you know everyone working on this you know Jason Alexi and you are are all talking and agreeing on you know what Primitives you feel like need to be there um I I don't imagine that too many external parties will be trying to interfere uh with what you have in mind there especially if you have you know something working and performant right but I'll let Jason also speak to that a little bit too uh yeah so

Jason Carver: I guess that's a good segue

so in addition to the the prototypes from the GU and parody team there's some some other teams that uh that I've been talking to um you know turbo gu paa talk to swarm about some of the things they might be able to support here and uh you know our own Trinity perspective um so I've I've been trying to write up the uh working on writing up the draft proposal for um that tries to incorporate uh some of the things I've found I'm still um uh you know it's still early on so for anyone else who wants to get involved that now's a a great time to do that uh there's still more to do on uh syncing up with uh with parody more so we're

gonna keep talking offline but uh yeah now you know feel free to reach out if you're another client or just have other uh ideas about um where fast things should go

I'm on

Fredrik Harrysson: when it comes to syncing specifically there is also a getter channel that you could join

might be good to have everyone there yeah absolutely so feel free to uh reach out to me on getter um Carver um and and I'll sync you up with sync whoever up with with this group so that's that's uh that's it for now right Ju Just for my understanding how disjoint are the efforts for uh the

next fasting proposal are there multiple independent groups working on this or is everyone collaborating together

Jason Carver: there's conversations but there's still fairly uh disparate ideas right now about how it should go so yeah it's it hasn't coalesced yet

so I would get into a

Fredrik Harrysson: bike shedding territory here where we just will never reach any sort of consensus because everyone is married to their particular solution

sure yeah

Tim Beiko: I would say for sure like implementations win over ideas right so so that's that's like a a quick way to to whittle down from ideas to to the final solution but uh but I do think it

is important to talk to different groups and you know figure out what concerns they have just like you mentioned we just but we should iterate on on the ideas that are implemented for sure

yeah so

Alexey Akhunov: I wanted to add to this yes the reason why there there is no uh kind of it looks like there is no convergence so far on these ideas is because as far as I know that most of the groups are trying to actually Pro uh make uh some kind of implementation or modeling because the subject itself is not uh so simple is that you can just figure it out in your head you actually have to do some coding and modeling and stuff like that so once we've done it we've done we going a bit F further on that we can actually see the ideas converge that's

what I would expect so it's a bit too early so that's why I would suggest not not to so I was going to kind of suggest that we should not in this situation where there's a lot of activities on some topic we should not try to constraint ourself with some sort of deadlines like okay by may we have to do everything because that kind of makes us cut the corners we only need to to have a deadlines when we actually when there's not much activity going on and just uh but if there if the people are genuinely like writing code and trying to make things work then I think we we have to give them the the runway

sure so we can see if there are any e you know v64 um enhancements that can be separated and don't interfere

with the the syn work that seems perfectly fine

Hudson Jameson: okay cool um that all sounds good

is there anyone here who wants to talk about ewm or simulation okay um actually I was just looking for the for the mic um yeah I mean we've been uh we've been working so the we met in Paris and then the guys met in goodest but I wasn't part of that uh so there's been some uh conversations and some work on uh on the what's it called the benchmarks um I'm told they should arrive around next

week and when it comes to to um yeah to the is one X um I've got I've got a prototype that runs uh ahead of ahead of time population so we take was a wasn't file we compile it to x86 and uh and we just run it uh like we just run the contracts this way so that's uh that's up and coming but it's still uh yeah it needs to be stabilized let's say and yeah that's roughly U it wasn't update as I have it awesome thank you

Hudson Jameson: so the next thing um Boris has organized um an uh Istanbul and f1x road map

planning meeting in Berlin April 17th and 18th Boris if you want to go over that quickly

Boris Mann: sure uh once again apologies that it's uh somewhat tight timing um I decided to just go ahead and and and plan it uh Alexi uh is available and is going to be there and we've got a number of other people who committed to being there um and uh uh basically the point is uh to sit down and actually look ahead of both Istanbul review the Eeps have anybody who's proposing Eeps go over those um essentially very similar to the Stanford meeting um and ideally we can get some more work done in person

uh around even looking out further ahead I mean it's come up on this call around uh Discovery already um I think Alexi's done a great job of having um uh areas or related Eeps and What U multi- hardfork planning looks like um so the goal is just to go over that and in general see where e1x is heading uh and work together with uh implementation teams and get feedback on that and really just uh get our get our act together for for this hard Fork uh so it's roughly uh it's almost exactly a month before the hard deadline to accept proposals um and uh um and ideally we know we will then know uh exactly which

Eeps are most likely to be proposed um and client teams can make plans and or give feedback on what resources they have available uh to actually get this done um eth magicians has uh a uh um a post with all of the details um uh I'm pasting it in here uh if you can let us know if you are coming um there's a link in there just to a little Google form um or just contact me directly um and uh we'll be working on agenda and presenters and and other things like that uh likely likely at full note in Berlin because I know some people have

started asking me um where they should book uh hotels and so just the nosis team uh volunteered uh full node uh so likely that end of the city

Vitalik Buterin: um I probably won't be able to to show up but I know that there's interest in EIP 1559 which is the which is the fee Market change so like if people wants to discuss that would there be room to um appear remotely

Boris Mann: uh absolutely um um ideally you know lots of value to meet in person and doing whiteboards but we absolutely want to support

uh dialing especially for uh EP uh

proposers MH yeah and iners there's also the various edcon and hack and hackathons that are happening around the time so won't cover everyone but it'll be a good place to time to chat with a lot of people

Hudson Jameson: yeah that sounds good I won't be able to make it either because I'm going to um a giant Star Wars event uh but um yeah I'm I'm looking forward to the remote connection so I can tune in uh let's see was that it Boris

Boris Mann: yeah uh links are in the chat here uh and I'll uh I'll tweet about it again so it's on top of everyone's

feeds

Hudson Jameson: okay thanks uh okay we're making good time actually

um let's go to testing updates with Dimitri hello guys hello so uh Rec update with a Constantinople changed um CPP client and I now see that not all of my state test are passing through the RPC

Dimitry Khokhlov: the main uh agenda for me right now is to make all of the state test that we currently have to be able to run through retested via RPC

protocol and also some python team also working on the same kind of thing and we think to develop um generic Genesis file format mandatory for every client to implement actually suggest to open an EAP proposal for every client to um implement this protocol for Genesis file course this Genesis airp initialization method is crucial to run State tests or other tests through RPC and overall um I think we still need to support test Leed in CDP client because it's it is stable and it works really

really fast compared to RPC protocol but it uses CPP client um how you think about this um generic Genesis format for every clients any comments from other client developers

Felix Lange: I think this be great this would be really great we we we we've kind of wanted this for a long time

actually actually yeah

Dimitry Khokhlov: one year already um what is the proper way to open an a for that

so

Felix Lange: the usual way would be you write like a draft and you just copy one of the

existing e and like fill out the sections and then bring it up I guess bring it up here is that the current process just bring it up on this

call uh bring it up

Hudson Jameson: on this call and also um it'd be a good idea to make an ethereum magicians form post um and then link that in the EIP as uh there's a section called discussion um discussion site or whatever and uh you can put The ethereum Magicians Link in there and and then yeah let's bring it up let's do a followup on this call to see after people look at the EP uh what their thoughts are on it

okay so

Dimitry Khokhlov: let me prepare this EIP for the next cor developer call we could discuss it I I will send you the

link

before okay

Hudson Jameson: thank you very much um any other testing updates

uh fuzzing or otherwise no we're progressing on the fussing regarding Hive we're adding new tests and doing some general changes to the framework now we have some time between before the next hard work so it's going through some changes

Hudson Jameson: great um let's run through client updates real quick

uh G I think that'd be Peter yep so yes uh can you hear me yes any uh so U as

Péter Szilágyi: as for the client

update um one interesting thing that's um that Gary's been working on for about one month are Level DB optimizations and um actually over the past month he kind of managed to speed up level DB by for huge databases meaning archive node the big scary ones by about a factor of seven which means that uh well we haven't really Lear run two conclusive tests but it kind of seems that uh compared to to our current stable release which does an archive sync in I don't know many weeks six weeks or somebody I haven't actually ever did one of those but based on our

latest benchmarks we can more or less do that in 7 to 10 days currently with the latest g code so that's um I'm really really happy about that and apart from that uh currently we're working a lot on slimming down G memory consumption wise plus doing some um some final Works around the data storage um so perhaps we can uh move more data out of ssds and move them onto hdds yeah that's about it

Hudson Jameson: wow so that's eight weeks to seven to 10 days you said

you said yeah I think six weeks to 7 to 10 days yes wow cool

okay did that improve fast sync at all no this is archiv not for sync well it probably improves fast sync uh quite a bit as well

Hudson Jameson: cool

all right parody no significant update we're also working on some database improvements and other things but U nothing shipped yet okay alth all right uh oh actually gam do you

have anything for that I don't know I was just going to say I think pav is traveling today oh that's right

Hudson Jameson: okay uh Trinity

Jason Carver: I don't think anyone's here last time we had an alpha release before the last allord devs with Constantinople support and as well as performance and stability um but uh Master Masters continuing to improve pretty quickly so look out for our next update in probably about a week

that'll continue to get much better sync support

Hudson Jameson: great uh anyone from ethereum JS here

okay

Hudson Jameson: um so Harmony couldn't make it

but they said that they uh demonstrated 1.5 months worth of stable runtime with no consensus breaks memory leaks dis space issues or performance degreg detected during that period so the version they have right now looks pretty reliable that's exciting uh Pantheon

Tim Beiko: uh no major updates on our end

okay turbo gu um yeah no no updates for me apart from fact that I started to do this prototype of status Lin which is just for the date analysis okay nimus uh yeah well we've gotten past the homestead um flock which is pretty

cool uh syncing it like you know

Jacek Sieka: running a full sync all the way through so we're going to take a moment and celebrate that by uh doing some refactoring on on on some of the issues that

with it so far A little bit in the little bit s results but pretty cool cool congrats woohoo um web 3j hey uh so we drafted the release of 4.2 this morning uh 4.2 web3j um I think the most interesting thing in there is the we have a erc20

interface baked in so that'll allow you to write erc20 tokens in Java using solidity DSL that we've put in with 3j um and after this 4.2 release is finalized then um basically unless people's computers blow up uh web3j will be on the back burner for us so we'll only be doing like critical updates um and our Focus right now is jbm implementation of Li PTP cool um Mana okay neum okay is there any other clients I

missed all right um let's see we already or no have we talked about ewm yeah gam gave an update um research updates uh Danny or vitalic

Danny Ryan: um we just released v05 of the uh primarily the phase zero B chain protocol but this includes some stuff for phase one um the major thing here was that we um made the entire spec executable and have a series of State tests which is a big uh big win um so now that clients can use those to come to contest each other um in Sydney we were going to be doing some of like 20 Workshop before

edcon uh and we're looking into setting up remote participation so I'll uh be sharing information on that if you're not going to be there

um vitalic anything else um and I mentioned in in the call yesterday that we and I made a lot of progress on the like client protocol so that's uh starting to like like it's it's potent it's at the point where you can like start at least looking at it and and seeing whether whether and how it makes it makes sense to start implementing um aside from that I would guess the main thing is probably phase zero like

nearing complet uh stabilizing and the the phase one pro of custody game improving quite a bit and there's Al I'm also probably just want to repeat my my usual kind of f for more feedback on uh phase two stuff in general right and I think there was a MAG

Danny Ryan: magicians link recently where you kind of dumped the things yeah I just CED the GitHub issue more visible there cool and um I know a number of you have already checked this out at least some of the networking people uh but there is a um basic networking protocol up for review in the be in this e go spec repo um so

if you haven't taken a look and you have some interest in uh digging into the networking protocol and helping out there please do

I'll drop a link in a second okay

Hudson Jameson: any other researchers have any updates I think there's a few others in here if you have anything

Danny Ryan: oh um I don't think there's an EIP written yet uh but something that we want to write up soon and push for in the next hard work is a BLS 12 381 pre-compile in the evm um that would open up possibilities of utilizing um the two things from 20 inside the context

of one um FAL more on that yeah I opened up a magician thread where I got linked to

one of the the like materials that I mentioned that like an E2 an E2 like inside one would require els2 3d1 precompile and it would it would very significantly benefit from a call data gas cost reduction and that's probably also something that we should consider because it is a oneliner that seems to be in line with the um at least what we know about what about what things are under and overpriced

Boris Mann: I think one thing to bring up on the topic of pre-compile so there's another pre-compile proposal by MCO uh who'd like to see it in

Istanbul um so I suggest one of the things to go over in person is uh if there's an opportunity to work together on pre-compiled rather than the every client implements their own so not for discussion just right now but just bringing it up and uh to put it in people's minds

I

Vitalik Buterin: I also saw the generic elliptic curve pre precompile idea which is like interesting the one thing to point out is that that doesn't Sol like that does that's not a replacement for BL the BLS 12 3d1 pre-compiled because you can't do pairings over a generic tic curve Rec

compiles and we do needs2 3d1 pairing support

Boris Mann: yeah I think all of these obviously we don't want to do infinite infinite pre-compiled but uh get help from Remco and yourself and other cryptographers and see what are The Logical ones to get into the eth1 X line

agree

Vitalik Buterin: and it's also not just a question of cryptography it's also a question of like what our priority um our priorities are so like for example like BLS 12 3d1 is nice because it improves interoperability interoperability with like zcash and all the other blockchains but additionally

does this like extra big thing of making it viable to have to have an e two white client whereas um and whereas for like other hash functions might have like different value and it's not about kind of cryptographic viability as it is about what concrete things do we goals do we want to achieve

Alexey Akhunov: yeah I definitely agree that the the the the link between 1.0 1.x and 1 2.0 should be one of the uh the priority uh because we do want to do do this uh potentially we want to do this finality Gadget at some point

okay

Hudson Jameson: uh anything else all right awesome um we have one minute left and I think we'll wrap it up um we didn't come back to Prague pal but so I guess we'll have to do that next week um do we have Boris do we have a discussion on magicians about prag poow that's like a central one

Boris Mann: uh Lane cross posted that yes um action items that and I think Tim's on the call taking notes as well is mainly just point of contact and uh audit details um I don't think we

need to discuss it again like if we want to have a call right now is there anyone who's saying you know Prague poow Over My Dead Body otherwise it's over to audit and we only need to bring it up again if there's an update from essentially the audit working group does that make sense

that's sounds good to me thanks so much Borris you have closed the issue all right Hudson yes

Tim Beiko: one thing we started talking about but didn't quite wrap up was the idea of smaller hard Forks versus larger hard Forks I'm not

sure if we want to do that async or bring that up on the next call let's think about it and bring it up on the next call

cool can

Danno Ferrin: we put time box on some of these requests for the next call

too uh requests for the night oh

Hudson Jameson: just like things on the agenda in general

Danno Ferrin: yeah time box them because um apart from prodcast some of the other issues that have been spoken for the next meeting also could turn into um alcohol consuming discussions

Hudson Jameson: okay good idea let's time box I'll uh try to estimate how much time each should get I guess or people can give suggestions

Danno Ferrin: yeah we can hash it out in the thread

all right

Hudson Jameson: sounds great all right thanks everybody have a great

day

thanks bye happy Friday happy Friday bye bye happy weekend [Music] [Music]

J [Music] [Music]

for for [Music] [Music]

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

he [Music] for

[Music] [Music] [Music]

[Music] [Music] e [Music] [Music]

he Jesus [Music]

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