Link to the beginning of the ProgPOW discussion: http://www.youtube.com/watch?v=z2mefVnZHpw&t=48m46s
-----
I pulled the below quotes that spoke to the not-too-technical aspects of ProgPOW that were discussed in the Ethereum Core Dev Meeting #47.
-----
Implementing ProgPOW
Timestamped Link: http://www.youtube.com/watch?v=z2mefVnZHpw&t=63m43s
Martin "I really think this change could be implemented in parallel with Constantinople. From a technical perspective they have nothing to do with each other. From a political point of view, yes, they might be very related...I can add also that if the technical underpinnings are there and Pawel things this is good and that people whoare in the know deem this to be ASIC resistant then I think it's a very good change and I'm for including it as soon as possible"
---
What is the algorithm doing & how is it ASIC-resistant
Timestamped Link: http://www.youtube.com/watch?v=z2mefVnZHpw&t=72m50s
Alexey Akhunov "I think that we need a bit more exposition about why...we kind of believe that this...from the description of the algorithm that it's supposed to be doing what it's doing, making it harder to implement ASICS and I get the general idea. But I do believe that if people do really know what the reasons (are) that they can actually explain it in some simple way. Maybe not in a very simple way but at the moment I feel like a lot of people including me --either I'm really kind of dumb or-- I don't really know what (it's) doing. I'm just trusting that someone else who is cleverer than me understands this and I don't. I also got (the idea) that some people are talking to each other or (having conversations) that they cannot disclose and it just doesn't really have a good feeling. So maybe somebody can write down...some exposition about why exactly the current technology of ASICs will not be able to do ProgPOW efficiently in a more detailed way so that people can apply critical thinking rather than just trusting that somebody...says that they have experience and (saying) "okay that will be fine."
-
Mr. Def "Hey Alexey I think that's totally fair. It would be helpful to get specific questions on areas where you want more information and I think we have been very bad about handling the Ethereum Magician's discussion and so we will improve that in the future and be a little bit more responsive.
In terms of why this algorithm is ASIC resistant:I think that we should all start from the point that...the algorithm's goal is not exactly to be ASIC resistant...we started (with) the this effort from the perspective that GPUs are ASICS and we're actually designing from a perspective not to be ASIC resistant but actually be friendly or to be very much tied to a single type of ASIC which is a GPU.
-
And so that's the perspective that we started with and so in optimizing for a specific type of hardware the goal is to maximally utilize all the functions of that hardware---a large register space (that's expensive) and of course not to forget the starting point of why Ethash is strong which is it's still memory bound. So the algorithm starts from a place where it's memory bound and its still going to be predominately memory bound. In addition, it also has to use the additional registry space that GPUs are able to provide and are needed for additional math calculations. And, on top of that, adds the programability aspect or the programmatic aspect (where) the exact series of math operations that you're running is changing in every epoch or, actually, as proposed with the stratum implementations, would change every 25 or 50 blocks or something like that --to change even faster.
-
Now, when you do something like that the problem with implementing an ASIC for something like that or a different ASIC or a more custom ASIC is you would have to design the ASIC to either be flexible enough to capture all the possible variations or evolutions of the algorithm or you'd actually have an ASIC that pre-designs for every variation or every math ordering in the evolving algorithm. So, if you pre-design for every possible variations well you're ASIC just explodes. You're just burning silicon area that's mostly unused. If you try to design for the programmability and the register file size that you would need then you basically have something that is a very big ASIC that is also applicable to many other general math problems. Which is fine because if you're gonna design a general math processor, I think that's the goal of this project. I think having more general math processors in the world is a good thing and having these more flexible computation units is a good thing at least until we have POS. So leveraging off the existing install-base of more general math units was the goal of the project.
-
So we're basically trying to force a custom design to be not-that-custom because you have to flexible to varying and changing math and a very rapid pace and you have enough variation that you can't pre-design for all of it and you have to pay additional silicon to be able to even execute the math.
-
If you have specific implementation questions in terms of why ASICs can't keep up with it or can't design for these math variations, we can certainly do a deep dive on this and I think for our responses it would be best to put it on some public forum like Ethereum Magicians so that once you ask a question everyone can see the response and we can just point people to that forum if other people have similar questions"
-
---
Economics and can you build an ASIC for ProgPOW
Timestamped Link: http://www.youtube.com/watch?v=z2mefVnZHpw&t=79m43s
Hudson Jameson "I know... you all are doing a Medium post that might answer some more of these questions and make sure that people understand why it's certain types of ASIC resistant"
-
Mr. Def "Right. To be clear on another point, we tried to make the algorithm as optimized as we could for the GPU but it is true that it is not the most optimized piece of hardware simply because things like GPUs have floating point paths that's not really appropriate for cryptography but that's only a small part of the silicon that's unused. There's other parts of the silicon including display outputs and things like that that, of course, are also unused.
-
In working and having the GPU-makers assess and review this algorithm the conclusion was that it's roughly 20% of the (GPU) area that would be unused (with ProgPOW) and it would not be a 20% power penalty but simply a 20% area penalty. Or, basically, an area savings that you could have if you stripped out all of the unnecessary bits of the GPU.
-
And then we also asked them to do an economic analysis of what that savings would be in terms of having an ASIC be more economically efficient (by) saving that silicon area. Online, you can look at die-area estimates and how much it would cost and if you look at GPUs that are most popular in the mining world today --i guess that's the 480/580 and the 106--then it's roughly $50-$60 for a piece of silicon and you save roughly 20% of that which is ~$10 and (then) the total manufacturing cost of the board, that's roughly $200, (so) you're really saving an insignificant amount of the total cost of the board.
-
So, yes, you can have a more custom hardware design for ProgPOW than GPUs and save some silicon-area but economically speaking it's not a significant impact to the economics where it would cause someone to go do a custom design especially given the amount of volume that GPU manufacturers have access to versus someone who would be doing custom design. The economic structure of doing an ASIC just would not be worth it.
-
There's also been other comments that we've seen where GPUs are moving further away from doing simple math and that might be true but at least in this generation, until we get to PoS, I think (progPOW) is a reasonable interim (solution) until PoS comes in."-
---
Providing proof and benchmarks
Timestamped Link: http://www.youtube.com/watch?v=z2mefVnZHpw&t=83m40s
Alexey Akhunov "Now I kind of understand that you're doing two things. You're optimizing for the GPU and you're doing some things that are harder for the ASICs. So what I would like--when you said you talked to the GPU manufacturer and asked them to do this or that-- is this information available...or were these just some chats you had with some people?"
-
Mr. Def "We reached out to some connections that we had. I don't think this information is public information however they advised that there are some very good reverse engineering analyses--already existing technical analyses--of this generation of silicon. Let me go and try to dig that up and see if I can point those out. I think, in general, I would expect that GPU manufacturers would not be that excited about doing detailed area analyses because they have competitive concerns about doing exact breakdowns which is why we ended up with a hand-wavey rough estimate."
-
Alexey Akhunov "What I would suggest if it's possible. I've done some GPU programming myself years ago, I know when you run some algorithms you can actually profile it and it shows you how much of the bandwidth you've consumed and how much of the registry you've consumed and how much of these operations and those operations--it would be nice if you could run that (so that we can have) have some data to demonstrate that this algorithm is actually utilizing these resources in a GPU. Like let's say "it's utilizing 90% of bandwidth". Is it possible?
-
Mr. Def "Yes. It's possible. I think that's a wonderful suggestion. Let me get on that and we'll have someone put that together."
---
Conversations with GPU manufacturers and confirming Mr. Def's assertions
Timestamped Link: http://www.youtube.com/watch?v=z2mefVnZHpw&t=86m38s
Lane Rettig "I know that you said that you (Hudson) and Pawel have been in touch with some GPU manufacturers did I understand that correctly?"
-
Hudson Jameson "Yes. So right now we're keeping these conversations private because we want to respect the privacy of the manufacturers we're talking to but yes."
-
Lane Rettig "I was just wondering...if this has been part of that converation already but just getting some confirmation on the ideas that mrdef has shared with us here would be helfpul."
-
Hudson Jameson "Absolutely. That's exactly why we're talking with them so that we can come on one of the next calls and say "we've confirmed what they're saying with the manufacturers".
-
------
I'll try to update this post with links for the below items they promised to follow up with (all help appreciated!)
Items promised in the meeting
- Benchmarks of ProgPOW's GPU utilization (Mr. Def)
- Medium post about how ProgPOW worked (not totally clear this was promised but it was mentioned) (Mr. Def)
- Answers to specific questions about why ASICs cannot keep up with ProgPOW answered in a public place (probably the Ethereum Magician forum) (Mr. Def)
- Technical analyses of the current generation of silicon (Mr. Def)
- Confirmation from GPU manufacturer that confirm Mr. Def's statement (Hudson Jameson)
Edit: formatting
![Livestream [Day 1] - Ethfinex Governance Summit](https://b.thumbs.redditmedia.com/Q8I5kw8kBWwfAPMg85R_3MHagp_0xAWmwp_AMddaFlw.jpg "Livestream [Day 1] - Ethfinex Governance Summit")
No comments:
Post a Comment