All Core Devs - Execution #52
All Core Devs - Execution · 4 Jan 2019 · 1:41:48
Ethereum core developers cover testing, client and research updates, working group updates on state rent, Ewasm, pruning and sync and simulation, a Constantinople hard fork evaluation, ProgPoW hard fork decisions, the Istanbul roadmap and a Gitcoin bounty for note taking.
Speakers
- Hudson Jameson
- Alexey Akhunov
- Martin Holst Swende
- Afri Schoedon
- Alex Beregszaszi
- Paweł Bylica
- Jacek Sieka
- Péter Szilágyi
- Lane Rettig
- Danno Ferrin
- Dimitry Khokhlov
- Greg Colvin
Topics
From All Core Devs - Execution, hosted by Ethereum Foundation.
Transcript
[Music] [Music]
[Music] [Music] [Music]
[Music] [Music] [Music] [Music]
t-minus 20 and Counting I'm just gonna start now actually sorry Greg just give skip to one anyways
Hudson Jameson: hello everyone and welcome to episode 52 of the core developer meetings I'm Hudson and let's get to the agenda first we're gonna have a quick announcement about note-taking and a git coin in bounty associated with it so I'll have Lane go over that
Lane Rettig: awesome Thank You Hudson can you hear me clearly
Hudson Jameson: yes cool
Lane Rettig: welcome everybody happy new year super excited to kick off this year yeah and find health so I'd like to introduce everyone to Anna who's on the call Hudson mentioned I I think our last meeting about a month ago that we were kicking off an initiative to help to have some bring in some sort of external project management talent to help us just sort of run these meetings and just coordinate hard Forks and things I'll freeze also kindly volunteered to help out with that process and one of the things as you guys know I've been taking notes for these calls for most of 2018 so we're gonna so we're gonna sort of experiment a bit going forward with that so Anna has kindly offered to take notes for the meeting today and the other
piece of this is that we also set up a git coin fund as a massive thank you to get coin for helping us out with this and for funding the first bounty and so there's actually gonna be a bounty for note-taking this is something that we hope to keep doing for all of these calls basically so we may have some other fresh faces joining us to take notes going forward thank you
Hudson Jameson: yep exactly and we also have maratton here he is also part of the group of people who are it's kind of right now called like a project management group for the core devs which is a group of about how many people something around seven or eight people who want to kind of learn how to navigate around either the e.i peas or the court dev meetings or note
take or help out in some way or another may be hard for coordination stuff like that and offeree is going to be leading the heart for coordination paths between now and the next part or after Constantinople but also I guess leading up to Constantinople usually that role was taken by either no.1 or kind of taken by me for previous hard Forks but he's stepped up to take that so thank you so much offeree and during calls for hard fork related stuff I'll probably have offeree cover a lot of that so just a heads up to everybody I think that's about it on that topic let's go ahead
and start with testing updates is Demetri in here yeah Dimitri's in here and let me meet my phone Dmitri if you want to go ahead take it away
okay hello everybody welcome you're in 2019 so tests focus on tests now more to validating the clients how they pass existing tests generated by cpp client in a block sheen test form and now we test those tests on hi basically it means we need to test your client quality client and any other hive compatible clients so far I see only
goal client is working on hi I've been on a maintenance in the beginning of December and I see now it worked go client files only 90 tests out of all of our test pool and most of the failures are insignificant is it because of configuration errors or maybe high script errors and rest of the tests I will look the spoilers and investigate why and and I need to contact is the developers cause to be nice to her like all passing without any issues well interesting enough that a left
client actually doesn't work on hive also a left plant did generate the test for high it is being done with testing and I left client work I've finally mostly all of the tests because configuration issues parity still being integrated into the hive oh I would like yeah so I fixed the parity errors last night and wait now so if you look at it suffering during this morning or afternoon the latest results popped up for parity it's a twenty three so to me 23 just failing on parity yeah and at
least a couple of weeks ago it was due to a crash in a theoretical case which cannot happen a minute and I believe parity guys had fixed it but I'm not sure if it's been merged okay so basically we need at least two clients work working on those death so we could compare results on the same test one what are the different clients and if you have no issues no serious issues I think we okay could say that we pass the test so yes that this is what we are going to work on and I next week making sure that we issue BC we have is not a major issue
is the test what wasn't just configuration high schools for some Muslim person okay is there any other testing updates from anybody okay we can move on the client updates let's start with death I think Peters off right now so maybe maybe Martin or someone else on the guest team yeah Peter would yeah I'll ping him and see if you can okay
sounds great no problem parody I think we have aa free or Fred no just offer you today so I'll just pecked on vacation so I'm not intelligible up to date everything but I can summarize some things we are working on right now of course yeah we are working on cow
Afri Schoedon: I think we are up to date with the current spec and we are all ready for the proctologist net we also started working in addition to P wasn't on he wasn't was a goal eventually to join the emotion chestnut yeah we all start
working on implementing fast synchronization we discussed those previous meetings that we want to have something like hybrid fast walk synchronization and future and implementing fast sink is one of the first steps process and last but not least we start looking into removing counts from parity in general account management of transaction signing should not be part of world line of soup we noted in attachment he has is something we're trying to figure out how to transition
best to I guess that's it so far okay thank you great unless I don't have any updates related to
Constantinople so yeah nothing to report okay Pantheon I think that be Danna or Meredith yeah not much to update here as people have been out for the holidays okay as mana here okay what about wait I'm Oh turbo gas hello so I was mostly working last for last couple of weeks I was mostly working on these the database that I mentioned in on DEFCON 4 which I call Morris which actually is a Latin name for Marbury um
I didn't explain it very well okay but essentially again working on the most most complex part of my proof of concept which is the reverse kind of reverse this for therefore the footage for the history and I sort of made it work so far so the reason why I'm doing this now is because it's going to be quite important for the to baguettes to support things like light clients and snapshot things and it's also gonna be part of things like either mint and things like this and yeah so that was my main focus on for last week's okay swarm with Adam yes so we were working on including the ability we
found the skeleton in the cupboard like the oldest part which caused some stability problems and we are working on fixing it so we are expecting a stable swarms that's okay II was um I think that's Lane maybe hello Oh Oh Alex you're here nevermind it's Alex hey Hudson hello we have a couple things to report on first of all we focused quite a bit on
the so called eat 1x
Alex Beregszaszi: working group which proposes to introduce P compiles using he was a man to the main net and that proposal which was made public like you were able to go mmm he proposed a couple of new pre compiles and the good thing I can report is most of those we have you implemented in rest of the new proposed become PI's and the reason we implemented them to have them benchmarked and to also run metering different metering strategies on them and to come up with a good solution so after we implemented them we also focused on creating a benchmarking framework to benchmark all these pecan
pies we have been done benchmarking every single one yet but at least we have a framework which should allow benchmarking different implementations the one we focused on is benchmarking different implementations of share to 5/6 and running different and metering strategies on them so all of this can be found on the ewaso morgue on github under the benchmarking repo and the second focus area was the test net the public tested we have we've worked quite a bit to improve the documentation and the documentation covers things like had to use the tested and had to compile
and deploy contracts and the second part is where we did a lot of improvements and we should have much better description had to work with C or rust contracts we also have decider tool called wasn't chisel which can which can basically fix any kind of wasn't binary to be compatible with T wasn't and that's coming to release soon and that should enable different languages to be used on the tests now last note on the tests net itself so far the test net was running with Kuwait here um and this is c plus plus VM called Hera but in the last couple of
weeks we also deployed a purely go implementation called the Bergen on the test that so we have two implementations of webassembly VMs running on the test net the last couple of weeks and it was running without any issues so I think that shows that it should be possible whatever you mentioned to you to have parity also join the test net without any issues sometime in the future the next thing I wanted to mention is we working on on surveys regarding blockchain platforms using web assembly and this will reveal look at how to use web assembly well not only platforms which used web assembly would also address which use other VM similar or
dissimilar to you to have assembly but of course main main focus is on assembly itself and we intend to include you know best practices we have found and history should be published I think that's it
okay thank you ethereal J no features or something like that we are working to pass all github tests that's why edges by Dimitri and other contributors for Constantinople and we did it we have not found almost any bug just one we compile it mod X all asses other heroes were
only associated with tests like one with empty storage this empty account with storage so we are passing all github tests and we are ready for head fork but we are not running on hive we had issues with it and looks like they are not fix it need to check and that's all I think ok etherium j/s I can't give a tiny update because Holger is not on the call but I keep a close eye on it yes and what an important thing to note is a
DEFCON there was some discussion and that maybe some hearts should be written in typescript and that work has come to fruition
Alex Beregszaszi: the first part is they are LP library which has been written to tie script that has been published and before Christmas and now work is being done on rewriting other libraries to typescript
the main benefit of that is it's gonna be made more safer than what we had which I'll skip and I think that's the main update cool Trinity are you here ok and we'll go on did I miss any clients I felt like I missed one but I can't
remember all right we can go back to it if I did research hey from our side the es research team we've primarily been focusing on refining this phase zero spec for serenity where phase zero is the core proved mistake chain that is the backbone for the all the shard chain we are moving into a relatively stable place we're still refining things making optimizations etc but I will say if you have not been following the progress on this side due to not having the the time
to dive into the weeds and things are constantly changing sometime during January might be a good time to open up the spec and to provide insight into you know the things that you have expertise in we're targeting something that looked is relatively complete in production ready in terms of the spec by the end of January obviously as we do implementation things might change bugs we fix error but again if you haven't opened that up some time over the next two or three weeks would be a good time to open it up and review and see what's going on over there
that's the main main stuff from our side okay great and II was them or do we already do that yep we already went through that whoops okay cool I think that might be it for clients and research do we have any working group updates as far as white block I'm not sure is accur or someone who can speak on that or any of the other ones I guess state rent if there's anything on that
Alexie's here yeah so I haven't written down the second version yet of the proposal and I currently think that it will be in a very different format that the first one was so essentially the way I'm wanting to do this is the some kind of so split it up into much smaller pieces which I probably would call cards so like you can describe one of them in one one slide and then instead of creating like Winchell steps like once one two three four five six essentially there would be some dependencies and the reason I'm I want to do this first of all these cards will more or less correspond to the
Future II IPs and the reason I want to do it is that I started to discover research the be like the different alternative approaches alternative proposals abut or some kind of shorter term shorter term measures that we can deploy to to set of stem the the state growth and for example one of them I've been researching is D is the stem the the the state growth while increasing the block size limit so I've written Li small post about it on the theory magician essentially the problem that I see is that if we are ready to raise the gas law gas limit and problem with that
would be that we would unleash more rapid increase in the state size unless we simultaneously somehow restricted but they're restricting it simply by making it more expensive as some some some side effects so essentially in this post kind of goes over that we could in a short term decouple the blow gas limit increase from the state rent but it's not trivial it requires some changes for example one of them would be something that metallic proposed to change the fee market anyway so this is the my current thinking and so I probably gonna do this about and around the next week and I know it's a
bit short before the before our meeting in January but yeah that's my update and there's another post about about the dark rent which is an italic suggested solution to which is also necessary magician so I think you can go to the the keyword 2d to the tags on the pseudo magician about the ECM 1x to find all this post they don't actually many of them basically that yeah that's it for the statement and for the other working group which is Peter Lee Peter I'm sure he's gonna join but so for the cleaning up the sorry pruning the the other types of information like
blocks and receipts so I also wrote up the proposal for the backwards forward sink which is which came out of assembly different but essentially the idea is that you would as a lot of clients do right now you would do some sort of snapshot sink by the para para to work sink or fasting and then you instead of instead of basically a trying to reconstruct the the prior history from the execution transactions you simply download the prior history from the from the pier nodes as a reverse yes so essentially that if you kind of continue
this you probably would arrive to the situation where you don't actually need to store prior blocks that's all but yeah so I probably will write a bit more about it but maybe like in February or something but it's that's more for me thank you great and you mentioned the meeting later this month there is an very optional in-person meeting January 26 through 28th and in the San Francisco like Bay Area of the United States it was discussed on a previous call and also some people are on a an email list for that if you're not on the email list reach out to me on getter and give me
your email and I will add you to the list if you're interested in possibly attending we're also gonna try to have remote options for parts of it or if not as much of it as we can I'm not primarily in charge of that I that's pretty much something that consensus has graciously volunteered to kind of take on and the stemmed from the ad hoc meetings at Def Con I believe so again just reach out to me and we don't have a specific venue yet as far as I can but that'll be coming up pretty soon we'll have information on that and send me your email if you're interested
it looks like a Peter or actually is was there any questions about that before I start or get throat to Peter Oh actually you can just a very quick another update I forgot to say sure I have found another person to help me with the with this kind of with these tasks and so he's gonna join me in the end of January and he's also gonna be coming to that to that meeting as well to get to get introduced to other people so I've been working with this person for a long time since my three previous jobs so I am I'm pretty kind of sort of relieved that there would be somebody helping me with
that so kind of full-time see ya that was another awesome Peter do you wanna give an update on gasps yes my vacation was great so not really I mean I don't have any particular updates regarding Forks or what not one nice update is that about half a year ago we were working on pruning and we found there was some fault and it took us an eternity to find it and it turned out that it simply was not a fault and it was everything is
actually working so now we have a fresh energy to actually do pruning properly again so that's like that's good news but that's about okay great and good we're on track here let's go ahead and go to the Constantinople hard fork that is currently offering do you have the latest figures on when that's supposed to happen I know you've been keeping up with that yes so let me check I have a small script calculating and we are off by 10 minutes and 23 seconds after 12:00 p.m. UTC on
wednesday 16th that's very close to very cool
Hudson Jameson: so one potential concern is that according to a website and I guess back in script running the Peter Prechter set up from one of the major mining pools only around eleven percent of the nodes are on the latest versions of Gaither parity that are able that are compatible with Constantinople
is that a concern and is that something that we should be proactive about as far as trying to get
the messaging further technical reasoning behind that I'm not smart enough I don't know oh yeah I usually do that and I forgot I do that so I'll do that yeah maybe this will help us like spreading the word and the other thing we already discussed this on Peter I think there are a lot of clients tracked by this fault monitor that are not on issue room because a lot of old versions
that are not even updated to bits and Hulme yet and I expect them to run on this room mainly so I personally don't think this major issue but yeah spreading the word but was something we should do the next two weeks any other comments so I thought something else is dead so I know that
Alexey Akhunov: parity for example supports usually a kind of two versions one of the stable ones and one of the like the beach' ones and both of them are now concerns enough already as far as I understand but is the other clients I guess as far as understand it only has one version which
sort of supports the Constantinople I wonder if this is the might be the reason why you could you see that a slower adoption rate
slower upgrade rate for her guests because people are usually very sort of reluctance to to go to the beach a straightaway so I just that was my thought when I looked at the stats mmm
Péter Szilágyi: we don't have so in gas we kind of have two versions one of them are stable releases which we kind of release every two weeks and the other one is likely so to say unstable but but that is pretty much stable too but both of them are and have been on
Constantinople for a very long time
okay okay any other comments okay and the next item or actually I don't yeah I don't think there's any other stuff on Constantinople we may have oh the next meeting we're gonna have it's gonna be post Constantinople so we'll just go through what we usually do and talk in the Chordettes chat if there's gonna be any problems or anything we need to do Oh actually Hudson maybe it makes sense to you to have a to have like some kind
of around the fork time maybe to make sense together some like look like exceptional meeting or something we're completely optional but just to talk through the what's going on if we if if people want to do this sort of to monitor the transition or I don't know if it's helpful because that actually kind of reaction time might be I don't know does it make sense Jenny but yeah that makes sense to me yeah I can set up the call and have people who want to join who are up at that time can definitely join and it'll be a party so we'll do that that's what I was gonna say basically the best case
was no news and then we just celebrated yep totally I don't know it in a quarter called but there's this for cmon not east devops good io where we can watch the for captain okay actually it would be it would also be useful for people who are like for people to join like run some important services to just get them real-time updates with some interpretation rather they're just sitting and watching it like a fourth monitor because people have a different sources of information so if we can just throw it in and sort of explain everything as it happens okay I can see
if in fira and my crypto and others want to join the people who run a lot of nodes that could be cool and if you have ideas for other groups Aleksey just let me know and I can reach out to them by doing Martin regarding the fork monitor could you also add the pre Constantinople note to it'd be nice to see that thank you okay let's see what is next I think we're gonna just have a overview
from offeree on the Istanbul hard fork that's going to be coming up after Constantinople including a rough proposed roadmap and just some other things about that so offeree if you want to go over that yeah sure I was thinking about the stuff we had in mind for quite a while now as far as I remember we started thinking about this around with an tiem hard fork to have a fixed hot fox schedule protocol upgrades deployed on maintenance on a fixed schedule like every nine months or something like that and I was running some numbers and proposing something I would just go
through now if we agree on on this we would have the next main that hard fork in October just would be nine months I already saw some discussion to have it shorter maybe eight months or six months or someone in proposed three months cycle I don't think it should be too short but yeah we should discuss what a reasonable cycle would be I was running numbers against the nine months cycle and this would mean we have the next hard fork I caught at Easter move next next hot pot on 16th of October 2019 it's a Wednesday this means we should
have the test at half work on Rob's nor any other suitable test net around mid-august that you want to follow this I put dates on the agenda and in the comment and most importantly we should have a deadline to accept proposals that go into this hard fork around mid-may so we have around five miles to probably implement and test or the protocol upgrades that's it so far as a roadmap action items so we should have
decide now do we want this we should decide what's the reasonable timeline I I'm personally in favor of having nine months and yes any comments so far and that time I asked for which part yeah that timeline was for the whole the amount of length between today and the next heart Fork right exactly except there's time from Constantinople to Istanbul is exactly nine months I see you in before that possible so yeah I guess we haven't
really decided about how and that's so I mean tentatively I kind of agree that it's sensible to past scheduled work every nine months but yeah I'm also I also believe that we should roll out and I kinda feel that that's we should have a discussion about that yeah I'm seeing yeah that was actually the next item but we can kind of start talking about that a little bit and I'm kind of hearing two sides one of them is that we should have the Prague PAL fork if we're going to have it at all before nine months maybe
sometime in between there the other the other point of view is that we should have it at nine months and bundle it with a bunch of other updates so I'm starting to read your notes on the agenda offeree was that was the Prague pal mentioned on there if we were to do it or is that just kind of being discussed now what I'm doing is proposing how to manage protocol upgrades on the main that I'm not suggesting that we force our set to fit the schedule I mean I would recommend that we stick to a plan in generally but if the group of quarter limited sites we want to have an
additional hard-fought in between then why not I mean but that's not relevant for my again that item right now so that we want to move to power first let's just talk about yeah let's do Prague now first and then we'll go back to the proposed rough timeline for Istanbul and some of the other EPS and stuff that you've been working on for the formal process for hard Forks so we have miss if and mister else from the Prague POW team thanks for coming back you all and they can along with Martin and a few others probably give some updates on Prague tau or actually missive do you do
you'll have any particular updates for the specification that hasn't already been you know covered by any of the Deb's here yeah the changes that we published in early December there were two small changes one late November and one early December to try to the first one made it a little bit harder for specialized days at ASIC to be made the second one stabilised hash waves those are the only two small changes we've had
we don't see any changes going forward from there okay now let's talk about implementation of the gangnam tests net first just a quick overview as my understanding correct that the gangnam test net is just a test net running client implementations of prague pal it started off with efashion then switched to Prague now after 3,000 blocks cool and how's that going I think Martin you posted something about it the other day in chat what's
what's the latest on all that yeah it's kept track of it but it
Martin Holst Swende: had some problems during the first epoch transition where one of the miners fell off and yeah yeah and that's I'm not sure about the specifics of whatever it was it's been fixed I've heard this I don't know more details about
that um the the original miner the original GPU miner had about that when you transition the epochs it would crash it was just a tutor programming bug that's been fixed
and so were up to a hundred fifty thousand blocks now so I've done multiple epoch transitions with no problems that's five epochs and we kind of from that from the outset we knew that the things that we needed to tests are basically the epoch transitions because yeah those are the parts where where you can trip and fall and from my perspective yeah is that's basically the big thing that needs to be testing and regarding this should we bundle it with other updates that's my take is that the the transition from hush mode it's broad
does not involve the EBM or state transition mechanics at all it's only the envelope of the blocks and the current test the the extensive test that we need to write to all be due to the normal current works we don't have to do those tests there are the kinds of tests they mainly really the main thing to test is you know can
Martin Holst Swende: we switch to a new dag at a certain epoch does it work or not and then of course you know if clients can verify it but they pretty straightforward tests and that's why I believe there's
no real point in bundling it with
other um updates and yeah okay great so I guess what we want to decide today is not necessarily when it would happen but if it
Hudson Jameson: would happen and then we can start to kind of formulate what that entails if we decide it's gonna happen I haven't heard much dissent as far as people saying they don't want it to happen very very few just a couple of people actually so what are some opinions on whether or not this should go forward is there anyone who doesn't I
want this to go forward or
Martin
Martin Holst Swende: no other just thought I'd some well opinion some facts about why I want it yeah great for some facts we know for a fact that there exists basic minors so it's obviously profitable to manufacture and/or buy and use acid miners there is some the III as I understand it is the first generation assic miners but there was a second generation asag miners one from bit Maine which I'm not sure if it's even publicly released yet and there's also some other companies produced some acid mining for thorium there's also a fact that there are FPGA
based GPU accelerators I mean my new mini aura t-cells them which evidently you can make a profit if you put them on your GPU and they can accelerate and we believe that power is more elastic resistance and also more resistant to those kinds of accelerators for the GPUs and yeah there's grounds to believe but switching to power would postpone or yeah because postpone the acid level of asacs in our network for at least a year
probably a lot more than that yeah so we know today that ETA hash hash moto has flaws which are actively being targeted that's that's my that's why I would like to switch as soon as possible to give us more time to move
the proof of stake okay do we have other opinions
Alexey Akhunov: well I just wanted to remember Martin you also said in any previous or something that the other the other side of this of course is that when if the such time
comes we would postpone it for one year but after that year because the profile is a bit more sophisticated then you see hash then obviously making Isaac is much more difficult but if somebody does manage to make it then they will have a very good advantage so that is kind of the coin so is that is that you just to your you know you
used to
Martin Holst Swende: believe that I believe that about a year after we switch to power we hear new rumors about Essex being manufactured and some
central really large player has monopoly of the ethereum Essex then yes we should probably consider switching to something which is trivially trivial to implement in hardware
so I would I would interject a bit that the etherium Asics that exists today are only marginally better kirsta watts than commodity GPUs and the way that hog power has been designed yes of course somebody can always may ASIC I'm a GPU is an ASIC but the amount of benefit they'll be able to get is vastly reduced so even after a year if
they spent millions of dollars designing an ASIC it might only be 10% faster maybe 20% more efficient it's such a small defense that it won't be effectively the difference between one generation and the next of an AMD GPU or an NVIDIA GPU it's not going to be the way that we've seen with other basics or with the ease hash Asics where you can get a 2x benefit right
Martin Holst Swende: that's the case then it might not be worth switching again but in the event that that is not the case then yes I would I would
probably prefer switching to something which anyone can
mister
Alexey Akhunov: else you said that the the ice except currently are marginally better like how marginally because isn't doesn't this defeat the purpose of the switch is there marginal better
so a nice hash ASIC can be about 2x better the the ones that are on the market right now that use ddr4 so only a little bit better they're not much better than a GPU we know that DDR six based these hash Asics are on are coming soon and those will be about 2x better than any existing GPU ok so that's this
what do you mean by marginally ok yeah some talk powd takes that 2x down to 1.1 X 1 point 2 X so I would at worst will be in a slow-motion arms race exactly and the GPU companies are also won't be sitting still so the state of the art for what a commodity consumer can buy off-the-shelf will be in a slow motion arms race with what they the mining ASIC manufacturers are doing making
Alexey Akhunov: so I'm not generally
opposed to this change might mean kind of what I would like to find to find out before we make a decision is that whether we underestimated the the actual efforts to be switches switch on it because we know that there is algorithm that we know we can do verification but essentially what are the things we need to do and is there any other catches that we haven't looked at like certain elements of the infrastructure ecosystem like light clients or or whatever the mining protocols or anything which we haven't even looked at and then we kind of assume that it's going to be done very quickly but might be not so do we
have any blind spots you know should we look at any blind spots that we might have missed
yeah I think
Hudson Jameson: that's a good idea oh go ahead Martin
now it's gonna
Martin Holst Swende: say that that was one of the reasons to spin up to test that to see that we could get more clients on board we could do CPU mining we could do a few mining we can have fast syncing I don't know if we have any light clients on it but like time verification is the same as normal verification
okay should just metric also has what's wrong said okay and they
were really abated they've
Alexey Akhunov: already upgraded these things like what is he the protocol they call using
the Frank gown on the call the works on a minor software I'm there alone Frankie oh you said Andrea Andrea yeah
Hudson Jameson: I believe he is on here or she's on or someone's on here are you on
here wonderful well and actually I worked a lot to integrate project into F minor
so the normal eighty ash and profile can live together actually they share the same that memory area which is generated by the classic 80s caramel and things are going pretty well minor is working the test net is working but actually is a too small test net we have a few notes the hashing power is very low there are not particular problems I want just to add a few notes about the addition of POW what does it mean for minors while it's pretty easy
for AMD users to switch to the new algorithm it's a bit a little bit trickier for NVIDIA users because the run time compilation of the kernels requires that the Nvidia toolkit is on board so this means a little more space needed on rigs which are driven by USB sticks or whatever and a little bit more of computing power just for the needs of the compiler to switch very rapidly on profile periods changes under it all
I'll chat with you offline you don't actually need a full toolkit to do the Tudor compilation yeah I know I'm trying to reduce it the most the elements of the toolkit needed for the for the compilation but I will clearly chat with you to do to get the smaller size puzzle actually all the implementations have a little hole that is in during the PAL period switches all the miners stay silent for say half a second at least
for the time needed to compile the kernel I think we can easily implement an async precompilation of the kernels so we can give continuity to the mining activity on the the devices and one last thing I think it might be related even if it's not directly related to theorem itself I think is the adoption of the theorem stratum 2.0 for to communicator among miners and poles we have reduced significantly the bandwidth use it to
signal all the words and might also if needed in the future integrate the revisions of the programmable protocol so if it will ever happen that we start with the revision of profile which is actually the all point nine point two to get to 1.0 we can easily implement the switches without changing the structure of the miner itself that's my notes about the matter
Martin Holst Swende: so when talking about those
silence half a second was that during a period or epoch change
during a period change epoch changer actually cannot be prefect unless you have a lot of very consistent space on the GPU which is actually possible for 6 GB gigabyte GPUs and but it's half a second in period changes so 50 bucks every 50 blocks yeah but as I said it's quite trivial to pre-compile the the kernel the new kernel while the old one so see running
of the GPU because at least for NVIDIA the the compilation as far as I understand is completely host process it's not on TPU
Alexey Akhunov: and so Andrea de would did you say that the stratum is already supporting this this new whole grid the
new etherium 2.0 stratum proposal yes does supported actually is not effective in user even if I worked with Peter Peter Pratt sir which have implemented it in for their pool and we have a couple of tests and points which are
working very well just yesterday with a collaborator of Peter we have tested and aetherium stratum 2.0 all in bundle with profile which is working quite fine
Alexey Akhunov: I mean so my question to basically everybody is that how much work do we have left for the core developers how much work do we have for the mining pools like if there is no much left work to do be done by core developers then I'm pretty happy to just sort of like wait to add or other people just finish their work and tell us when they're ready of course they might need to have some certainty whether this change is going
through but we can at least sort of goji how much of our involvement is actually left in the process what do you think
well you asked me not
Alexey Akhunov: not just you but everybody so my main question is that because this is the court of calls is that how much in more more time and efforts or the core developers need to be spent on this change and like it said minimal is it like medium is it large because I'm pretty happy if the rest of the work is proceeding somewhere else and then we can just make decision on that basis
I can't give you my personal opinion about that the work on the
mining side is pretty much done what we are lacking now is a serious test actually the the Gangnam Network is mining a bunch of block of empty blocks we have no transactions I don't have a clear idea which is the impact of a slightly longer or live a verification of the transactions what is working now is a test matter which is doing basically nothing is only producing a
bunch of empty blocks it works the stop it happened it was only due to the fact that there was practically only a might of keeping keeping the chain running we have a very few very low heart rate at this very moment there are less than 40 mega hashes and my rate my test rig alone is producing 36 so actually no one is participating actively in the testing of the network there are no transactions and I do not
have a clear idea of what might be the impact for large pools to implement all the stock needed for prop out I can tell on the f minor side that 95% of the work has been done it's working and we need only to go to through the optimization phase if there are any optimizations left to be done for the rest the protocol is here Peter is providing a very useful and valuable support to integrate pro power in my nipples maybe
an extensive test on a real crowded chain is needed before we take any decision about the schedule of the adoption
Martin Holst Swende: well since I mean the only such test that we have is is basically rob stone so that would mean we would switch Rob's them to prague power and then decide if we are going with proto which is a little bit not how you should do it
well
Péter Szilágyi: one thing that we can do is to create a shadow work of Robson basically just launched a few notes that switch over to prop power and have the two
chains coexist and everybody can still use the original Robson the original Robster will still have the exact same transactions but we'll just
piggyback on it and try mean replay the related transaction questions yeah
Alexey Akhunov: okay well eventually this will diverge but for some time for some time it will work
well yeah
Péter Szilágyi: so it first it won't function properly forever but still I mean it would be so if there if our only goal is to test how things perform on a used chain then I think it would be more or less useful maybe 10% of transactions will fail but who cares
and the
Hudson Jameson: decide today is more do we want to go forward with prog Pao and not develop a timeline quiet yeah but I do understand Alexi that your concern is the amount of effort involved across teams and if that amount of effort is going to be longer than the effects of you know putting it in in the first place or what it's trying to prevent no no it's mine basically like the the the I just want to understand what is the so if we if some of the work has already been done from the core developer side like how much more do we need to do or not
yeah
Paweł Bylica: I can try answering this so
firstly I would suggest to those I try to answer like what would for the clients the developers what is the work left so I would suggest a small change to our PC endpoint I think it's called get work to also include mining algorithm there it's it's rather trivial we recently added block number to the to the respawns and so because this is kind of the connection between mining pools and so I'm not sure like every mining pool is using that maybe they have
modified clients but anyway this is kind of the connection and the second and the second bigger part would be considering block verification so what clients need to implement protocol block proof-of-work verification
because
Alexey Akhunov: isn't it already implemented and a couple of
the points
Paweł Bylica: yes we have have free implementations right it's C++ rust and go so this can be exposed as a library whatever but if you want like pure Python and something like that it's it's not done and so this is
what you could considering as something we want to have or like it's optional and I also I also proposed to to add other language bindings to my library I promise to this sharp sometime ago it's not going very well because some problems with figure out how to do it exactly what it's doable if that's acceptable solution so I can I expose Python and maybe take JavaScript and something like that maybe javascript will be more problematic because it might be useful to have JavaScript only
implementation to be to be able to be run in in browsers but I'm not sure if we have if hash implementation of that anyway so but that I think that's the biggest and like something this weekend considering not to be mandatory to have for every implementation we currently considering as a as a Chilean client
okay
Alexey Akhunov: so what you're saying is that there some worth left for the kind of non major clients to do
Paweł Bylica: yes yes and like at
least we should like having that into consideration right to either support their teams on like figure out approach to it these like probably all the teams should somehow response to that and say what do they need what they think should be day way of implementing blog verification and then we can suggest some solutions or work on my like on some common solutions to that there's multiple approaches to it but it's it's I think at this point
it's some kind of open question so maybe that well we could collect some answers during next two weeks
Hudson Jameson: yeah and we can make I mean I guess if the major clients if it's possible for the major clients to code that in I mean sorry the non major clients to code it between now and the time that we would potentially launch it which would be what's the what is theoretically the soonest that we would want to do this has anyone kind of thought about that Martin I thought you might have been
throwing around numbers but that might have been someone else for like three or five months
okay
Hudson Jameson: that sounds like two to three months or well really three to four but most if it's this quarter so let's actually I have a question for Dimitri from the harmony team have you all looked at anna grading prog Pao and or can you estimate or give us an idea
of the amount of work to be done because that would also help us understand where Pantheon might be at and I can also ask the Pantheon team as well
I'm not sure but I think it should take like two three weeks okay
Hudson Jameson: pantheon what about you all do you do you have any idea
we haven't started implementing prog power really looked at it a whole lot I've looked over it briefly it doesn't seem like a massive amount of work but again we haven't invested much time in it yet okay
Hudson Jameson: thank you I guess I couldn't talk to the other ones sir
the other clients to nimbus have you all looked at this oh I think you're still muted sorry is it third Oh yep that's on now
Jacek Sieka: all right cool no we haven't really looked at this we're not that far okay no problem
and just a quick question are there any test Suites that we would be able to run against as we implement
Martin Holst Swende: yes so there are yeah there are test cases or everything from smaller functions the math and the random stuff up to full
blocks
and yeah obviously the constant as well these test leads include the epoch transitions issues that you could you minor yes so there are tests that that block one block 29,000 999 and transitions as well
Dimitry Khokhlov: there are also difficulty tests designed specifically for difficulty formula check so it basically just file describing what was
the previous block number what is the next block number so I think you could extend that to also check
the
Martin Holst Swende: the formula for calculating what difficulties required from a block doesn't change
yes
Dimitry Khokhlov: we could extend those tests to check also proof of work somehow I mean you mean in the same format we could generate a lot of cases for proof of work if you really need
okay
Hudson Jameson: so Alexi does that help a little bit
Alexey Akhunov: yeah and I have a suggestion I think so it
looks to me that we want to hear back from the non major client but at the same time we kind of leave we don't want to procrastinate too much and just leave the decision hanging in the air so I would say that we might just do the we might decide kind of the conditional decision kind of thing this might decide to do to go ahead unless we you know there's like some major problem found with a non major client or something like that I don't know because it seems to me that there is no big reason why not you know why don't we just go ahead and give people some certainty about why they because I guess the the mining
pools and other people will just need this go-ahead to start working on their stuff right
Hudson Jameson: yeah I think it'd be good if we didn't procrastinate anymore I think you have it right you'd hit the nail right on the head as there are other technical questions about prog pal that we can ask Missa for mister else while they're on here
Jacek Sieka: one thing that we've learned from ET hash which is that the verification time for ET hash so that sort of causes us to have to resort to other solutions less satisfactory one
thing that I'd be looking at is is like when evaluating program later would be whether we can actually verify blocks on on devices which are not as powerful as as computer right so calculating in normal hash is fine
so prog how is very much based on each hash it adds a little bit more math in the main loop and the oldest amount of memory memory that's consumed from the dag so if it has is to
swell prog power will also definitely be to swell
Péter Szilágyi: I think last time I saw benchmarks compared the verification I think the best numbers were that Prop POW is about twice as slow so nothing too insane but
I want some that I thought were about 1.5 X depending on some variables and compilation but yes then in the range of 1.5 to 2 X
Alexey Akhunov: and Jacek what is that what are the other techniques do you need to use to we gonna go around the problem there's this technique gonna work do this technique work would they work in a proc power not
Jacek Sieka: basically it means going over to different trust models okay you know ultralight clients with some sort of staking or whatever like VIP no those kind of solutions which are like on a powerful device like an iPhone you get away with it but on say emerging markets typical device is not at all
Alexey Akhunov: and then you what you need to what you need to verify essentially you verify the hash chain from the beginning read from
well
Jacek Sieka: let's say something like a light sink right you need to verify it to just keep up with with with blocks it becomes
okay just keep verifying the blocks okay but
but jessic
Martin Holst Swende: in your in your model do you what would you like to verify each and every block okay into option istic book verification once in a while
Jacek Sieka: you could consider opportunistic verification we haven't really doubt that far into it and the one thing I know is that verifying every block was simply too slow too heavy and too draining on the battery and and a bunch of other things I guess you could explore models where you verify blocks when you're sha sha verification that that it prevents normal operation so to
speak the kind of operation that you seen yes and and if ET hash adds threat well obviously we have to look at these alternative models
Alexey Akhunov: this is actually quite interesting because the since we are changing the proof-of-work algorithm it's not only like the burden but it's also an opportunity because if there isn't a solution to that which we can incorporate so we basically will not simply make it slower but we might actually solve this problem on somehow it's a kind of the craziest thought but for example can we like sort of do the double prophet work like you could put eg like profile plus sha free or both of
them have to be valid and then the glide clannish can simply check one of them does it work
does it work
Jacek Sieka: that's actually an idea that I thought about exploring but I haven't really looked at the logic of it together but if you could include an extra hash that
Alexey Akhunov: well what I'm thinking is about is that you basically need to provide two proofs of work one is the basement rock pile and another one based on let's say shot 2 or shot 3 whatever and which is much slower lower difficulty but still it will be it's booby kind of hard to produce not as hard as the both PUFA works but still hard
um so if half actually has that
built in today and how retains that where the way each hash works is there's a tech AK of the header and a nonce then the East has loop runs or plug power runs and then there's a keck AK of the result so a light client could just check the CAC acts and verify those some clients use those for denial of service checks that you can check the CAC if that's wrong then you don't bother calculating the heath hash so a light client could decide to just check the CAC and not the
proof-of-work not interact with a dag at all it's it's not a good verification but it's better than nothing
Alexey Akhunov: could it be could be could it be somehow strengthened we're like
Paweł Bylica: well it's secure secure hash function so I don't think it's something trivial that you can replace that with something else if you don't want to read for memory that's that's you can replace that with other hash function but doesn't change their the scheme of it
Jacek Sieka: that's an interesting observation
Hudson Jameson: Thanks okay cool
so that's get too much in the weeds it sounds like what we've come to is that we are going to tentatively go ahead with prog pal and by tentatively what we mean is we're going ahead with it unless there's a major problem found within the testing or things of that nature is anyone feeling like that's not the case or there's different feelings okay great then we will be going forward with
prog pal
Alexey Akhunov: and just when will command sorry sure just just so I think we have to make it clear and kind of documented
that we're not gonna include any anymore changes into the Hartford because otherwise it will increase the complexity fight a lot
Hudson Jameson: yes I think that's a good move does anyone have any comments on that statement that we would not be including any more changes into a prog how hard fork that would happen before nine months and sustainable hard
fork
Afri Schoedon: no but I'm saying that we should not go down down the rabbit hole whenever anything comes up to try to squeeze it and I totally agree with Alexa here
Hudson Jameson: great do we have any other comments on this
Afri Schoedon: yeah maybe it wants more comment I would like
yeah I'm I'm that guy again let's not rush it I mean when we are ready that's forth but I personally sink two to three months was very ambitious especially if you have to consider that we needed six weeks between all client releases and people having time for our creditors then we maybe need to test my heart for I think two two bounces if possible and three months ambitious
Alexey Akhunov: I think now what we can do now is that we're not going to decide at the timeframe but we sort of decided we are going to go and then we request the comments from all the people that still need you to work on this
about how long is this going to take and then just based on that information we can decide because we do want everybody to be sufficiently prepared right
yeah make sense yeah
Hudson Jameson: I think that's a logical next step
Martin Holst Swende: but if we if we today have agreed that the goalie profile with some caveats then we yeah let's people do some homework until the next court of call and see if and how they can implement this and there frameworks and maybe we can talk about timing and two weeks that some feasible
Hudson Jameson: yeah that sounds good we can clear data
between now and then okay do we have any other comments
the
Greg Colvin: speaks to the general issue of you know whether we want to do this rigid corporate thing of you know rigid scheduling or do the continuous integration of when we get a decent set of features that need to get out we get them out
Oh Greg I think you cut off I'm still here
Oh perfect okay that was just the end of your sense okay
Hudson Jameson: yeah I agree I think that's something we need to look at over time is the magicians form a good place to discuss that do you think or is there a better
place oh it's a coordinate issue
Hudson Jameson: oh I meant like the for like the so just discussed it in the calls or do you have a suggestion on where where to
discuss a on the chord AB channel Decatur okay that makes sense
Greg Colvin: some extent here and now because the Prague P of W is already a case of oh we have a nine month one but oh we're gonna break the rule for this important feature
Hudson Jameson: I
see we only have a few minutes so we can't do it today but I agree that's something we need to come up with
yeah for the next meeting okay
Hudson Jameson: sounds good to me thanks Greg okay so we only have a few minutes left and I wanted to make sure offer you got some time in so thank you miss if and mister else for attending and answering some of these questions and I look forward to further collaboration between you and the other core dev teams as we try to implement this okay let's see offer if you wanted to go back and just do a quick summary of kind of what you've been working on as far as hard
for coordination and what you were discussing earlier
Afri Schoedon: yeah sure so I was proposing to have scheduled for protocol upgrades and basically releasing all accepted proposals as honest schedule and yeah now I'm requesting comments
Hudson Jameson: and should those comments be in the Gator channel is there an EP that you have that like can people can comment on or what's the best Avenue for that
Afri Schoedon: no there's no EEP you know yeah I'd be but
this would be a outcome of discussing this I just want to have like I mean you have only like five minutes left but I would last want to have any comments here from the core developers if this is actually desired or we want to go in our that fast because based on this decision I will continue my work on very specific kinds specifying some documents like that
Martin Holst Swende: yeah I'll go I think it's great if we can have scheduled horrible hard Forks with the longer term view as to what's what kind of protocol no place we want to do it well and it's about time we actually start rolling and with that model I mean we
discussed it in Mexico it was quite a while ago
Hudson Jameson: oh yeah good times anybody else have comments
Danno Ferrin: I support the general idea of a regular I start Forks and also I think what I think is better than just a regular hard Forks is the rigor we're putting into the milestones such as making sure and releases her six weeks before the any hard work would happen having a time frame before that six week reminder clients and other people come in and commit not commit you know just the milestones of what we need make sure that we have our ducks in a row before we basically reboot the network so those are the things that I find most exciting about a regular heart Fork and regular times give us a forest and functions to make sure that we're
doing these things at a particular time on a particular schedule
yeah
Lane Rettig: just adding my voice of support as well I support this I think in particular having a regular testing schedule and right making sure we get ample testing in and no changes or landing you know kind of just before any sort of a may not hard for captain's I think this is a great idea and a great step towards more maturity project management
Hudson Jameson: any other comments
Péter Szilágyi: so from my perspective at least from the
for the gas team doing regular releases scheduled releases worked out really nice a lot better than trying to cram in features and then eventually we do big major releases so I think it's a from a community perspective to it's much it's much better to be deterministic rather than having to wait half year and wonder whether bit shifting will arrive or not so I'm all for regular releases
Hudson Jameson: ok anybody else
Danno Ferrin: me again one thing we might want to add in light a product how is maybe since
we're consideration for earlier than scheduled Forks such things as limiting the scope and the time frame for those I think those would be valuable to add into the process
definitely y-yeah sure
Péter Szilágyi: I don't think it's a it's an issue to have unique Forks if need be or do roll out certain upgrades if need be I think it's more about the general releasing of new features
yeah so what happened was constantly knowbut took like 1.5 years I don't have to exact you know but having like a strictly defined schedule for heart Fox tries to shoot this goal to
have these upgrades deployed regularly to may not that's not opposed having other heart faults like power out of it makes sense you know okay any other comments I think we're actually over time so any last comment all right thanks so much for putting that together off free sounds like we're making good progress there and we're looking forward to what we talk about more in the next meeting thanks everybody for attending made some great progress today and I'll try to post the
next agenda soon so we can add items to it and I'll be posting that in the core dev skitter chat again send me an email if you're interested in the J and the January in person meeting in San Francisco and everybody have a great day or night bye [Music] [Music]
[Music] [Music] [Music]
[Music] [Music] [Music]
Speaker names adapted from ethereum/pm, CC BY-SA 3.0.