ProgPoW - A Programmatic Proof of Work by Kristy-Leigh Minehan (Devcon4)

so there's been a lot of excitement about Prague pal and what is Prague pow well it's a programmatic proof of work and we're going to be tackling all your questions and answers today this will be sort of a medium level expertise presentation so not too technical but not too generic and if you really want to go in a deeper dive I figure you should check out the official github repo with the official code and the white paper as well as our medium accounts but first a little bit about the team so too many people put an emphasis on the people behind algorithms or work which is highly amusing to me especially considering that you know cryptocurrency is all about no trust but hey I learned from the first time when we were released Prague pal that you've actually have to do these disclaimers so I figure we have to do a disclosure on who we are so it Pro POW is made by three people if def else I am miss if I am currently chief technology officer of course scientific course scientific is an artificial intelligence and blockchain infrastructure and hosting company I'm also the founder of the minority group who is responsible for our fantastic graphics today and I'm also extraneous mining the world's leading hashing power provider and then we also have mr. def mr. def is an experienced systems engineer he's a blockchain enthusiast and I like to call him a professional cat herder because that's pretty much what 24 24 hours of his job consists of and then we have mr. mr. elfs so mr.

else is quite an experienced semiconductor engineer he has over 10 years of experience working in this space and he is also an experienced GPU architect and he loves Prague pal but not the pro pal we're all familiar with he loves this program and together we are if def else so what is prog pal well as I said before it's a programmable a programmatic proof-of-work or as we like to say a GP you tuned extension of it hash it's also sometimes called portal or pongy well after this little guy our little hero from Star Wars lost Jedi and it also takes its roots from the word programmatic now I quite like programmatic because it's a great way to explain algorithms algorithms are actually very musical I'm you know every algorithm has a beat and optimization when we talk about optimization of software or hardware it's all about matching the beat of an algorithm to the beat of a hardware so at hash I like to say is a little like trap core Manero is like dubstep z cache is a little like rock and these beats like I said they need to synchronize with the hardware itself so let's do a big deep dive right now why was prog pal created well today there's kind of a problem with algorithms you see traditionally algorithms are designed by software engineers now you might be asking what's wrong with that well would you want your hardware designed by a software engineer the answer is no because that's actually how you end up with things like these the windows phone so we we always talk about how you need to have people who are experts left to do the things that they're an expert in how do our engineers so it should tune for hardware soft engine software engineers should tune for application layers that's the crux of the problem today and how we get fixed function hardware or in this case Asics and proof-of-work has traditionally taken an algorithm that's fixed and tried to shoehorn in the hardware to make it efficient at executing it but that leaves many unused parts of the hardware that you can just shave off or you can get rid of instead Pro pal flips this paradigm we take the hardware already-existing and we modify an algorithm to match it because an efficient algorithm for proof of work means hardware needs to match s match access patterns and available space of that hardware now I know what everyone right now is waiting for me to say given how vocal I am about ASIC resistance but I hate to say it ASIC resistance is a fallacy there's no such thing C prog how is mistakenly trumpeted as an ASIC resistant algorithm but quite frankly that's proof of work requires some form of an ASIC to do work be it be it a CPU a GPU and FPGA or mining ASIC and guess what oops they're all Asics they're all built using the exact same fabs the exact same technologies the exact same materials the difference however in the in this hardware is the class of algorithms they're designed to execute efficiently and that they're optimized for so generally when people say when they say ASIC resistance what their meaning is centralization resistance and we can dive into why that's important in the breakout session but there's my statement on ASIC resistance it doesn't actually exist so why does hardware actually matter why do we care about hardware with aetherium well for the time being hardware actually defines your user base and note blockchain is suited for all user bases just like no application is suited for all customers GPUs therefore the common folk you know they're readily available they're flexible they're adaptable they're quite cheap and pretty much everyone has one today look at your phones you will have a GPU in there every single laptop you have has a GPU every console app video game console out there has a GPU FPGA is there for enthusiasts really rich enthusiasts they're high cost my expertise they run hot the definitely not plug and play and I should know the minority group hosts around 5,000 of these things so and then we whoops and then we have of course Asics these are really for enterprise minors so they're relatively simple they're plug-and-play they're consumable goods and they kind of have short lifespans and they generate a lot of heat and consume a lot of power but the density of an ASIC lends itself really well to professional farms so what user base do we actually want for aetherium well if aetherium is a decentralized application blockchain that means we kind of want as many participants and as many players as possible application user basis usually need to be as decentralized and distributed as possible to prevent malicious actors and if you want an enterprise-level blockchain you also want to make sure as many participants as possible are active to ensure your application your code is executed on as many diverse nodes as possible a GPU card is naturally decentralized there's widespread adoption it's in every device and you have multiple manufacturers and a healthy ecosystem outside of the blockchain now that point is really important because when you only have one line of business you are naturally incentivized to protect it at all costs that's an important statement but wait what about CPUs well there's a problem with CPUs see they're naturally exploited for cryptocurrency mining they're really great with botnets and you should probably trust me on that because I might have written a few back in the day CPU implementations are also the easiest execute on fixed function Hardware because of their very single-threaded nature that lends themself really well to fix silicon implementations on top of that CPU implementations are also hard to tune for each architecture shift or each revision has some tricks of trade to get the optimizations or you know in order to perfectly saturate the hardware and of course they're not that great at you know math compared to an FPGA or a GPU they're kind of slow not as dense you can't really pack a mining machine full of CPUs you can pack a rack full of Asics or GPUs density is really really important to mining enthusiasts and also remember GPU was a GPU based algorithm from the start that's what memory hardness means it means that you need a GPU we simply tuned it for GPUs now a warning this is gonna get a bit technical from this point on this is our at hash spaghetti and logo Lego rather and hash itself is relatively simple it requires a semi constant scratch pad file we call it the dag and then all instances reuse that same dag for the next 100 hours mining it hash really just involves grabbing random slices of the data set and hashing them together and then the DRAM peak bandwidth up there which we can see it's easy to calculate it's 64 iterations each reading 128 sequential bytes so at hash is really just a memory hard proof of work algorithm that means it just requires two major things a relatively large frame buffer and as much memory bandwidth as possible both of these things that GPU has great but guess what an ASIC can have that too so can an FPGA so it can a beat PCB with just a ton of DRAM in a little compute core because that's all you need memory DRAM chips and hashes only tuned to memory but not the rest of the hardware and so again how you make an ASIC you just remove all the other parts that are currently unused or rather all the wasted space and you get a nice increase that's ASIC creation in a nutshell guys just remove all the unwanted or wasted parts be it silicon or compute cycles voila so the inefficiencies in add hash become more obvious when you profile a graphics card with if minor so this is the top picture there is taken from insight profiler that's new videos new performance profiler pretty sexy bottom one is AMD's so you see SM up there s M stands for streaming multi presser multi processor those are kind of the computational cores of NVIDIA GPUs which you know create manage schedule execute instructions for many threads in parallel and they consume most of the GPUs die area so when we talk about a GPU ASIC we're referring to the GPU core as we can see they run up less than 30% utilization right now and all the bottom code Excel AMD's performance profiler we don't have as many details but you can see there v al you busy that stands for vector al use vector al use are the digital circuits that perform arithmetic and bitwise operations for the AMG AMD GPU cards and it's kind of the same thing as math core for NVIDIA GPUs both of these things are the building blocks of a GPU ASIC so that means today at hash only consumes 30% less than 30% of a GPU core so that's one of the major deficiencies with it hash today and the reason you can get a large ASIC performance gained because really all it does is a small 128 byte read from the main memory that small access size is a reason that GPUs that utilize gddr5 X or GD DDR 6 memory were so inefficient at executing at hash some of you may be familiar with our tool f largeman it got kind of viral on the internet watchmen abused this so we matched access patterns of 5x and g 6 memory to it hash to enable 128 byte loads to run at full speed we have a public version of that tool for 5x we have a private version of that tool for G 6 we made a lot of money off that just because an algorithm wasn't effectively tuned to the hardware we see up there the tide and X pass it's similar to a 1080 TI and it's pretty awful where you can see up there it has less than 20% core utilization and less than 60% memory utilization which is on the bottom there's also another issue cat jack that's the hash function that stuff at the start and end of it hash and that can be executed much more efficiently on an FPGA or an ASIC in fact that's actually what the acorn line of FPGAs are designed to do offload catch hack computations to save system power and increase performance you shouldn't be forced into buying extensions to your hardware just to compete with other hardware but hey guess what Asics can do that too profiling at hash with catch Accra moved shows us that the compute cause of a car to really only utilize 20% of the time allowing for 10% efficiency gain right off the bat simile our personal / sauce line profiling up there shows us that more than 20% of the all instructions are catch shock which can all be offloaded that's a 30% performance gain folks 30% okay so I've talked a little bit about the deficiencies about hash so what the hell did we do about it we're just gonna sit up here in trash at hash no we went and kind of fixed it so that's a pro growl spaghetti and Lego this was made on a plane while I was slightly drunk so excuse the mess there are five major changes here see we changed cat jack from F 1600 to f800 I'll go into why that was really important in a moment we increased the mix state we added a random sequence of math in the main loop we added reads from a small low latency cache that supports random addresses and we increased the DRM read from 128 bytes to 256 bytes and this is what it all became see the most efficient and effective algorithms are the simplest and any ASIC designer will tell you that complexity leads to weakness in proof-of-work okay so why these changes well let's stop with cat check and dear M read catch hack hashes used at the start and end of it hash get reduced from F 1600 with a ward size of 64 f 800 with a word size of 32 why well GPUs actually have 32-bit data pods and F 1600 requires twice as many instructions to execute on a graphic card it's it's wasted cycles yet hash does not use the extra data processed by F 1600 so reducing this amount of data has no effect on the security of the algorithm but what it does do is reduces any possible efficiency gains from offloading the kept track computations from the GPU that eliminates your a 6 speed up that eliminates your your FPGA speed up and I should have just put that out there oops so by by 30% performance again we leave the number of accesses to the dag which is also the number of the loop iterations unchanged from at hashes 64 we don't need to touch that don't need to dick around with it but the dag reads size we increase from 128 bytes to 256 bytes this allows prog cow to be efficiently executed on all current and hopefully near future DRAM technologies without requiring overclocking that means there's no more no more system tuning it just works off the bat fully tuned fully optimized now for this part see as I said GPU cores are most efficient when they're doing 16 byte or forward loads and in order to have our 256 byte loads we have to do 256 bytes by 16 bytes per Lane which ends up with 16 lanes working together in parallel yeah if I'm getting too technical let me know when we work back from the frame buffer interface GPUs have an l2 cache an l1 cache and a texture cache we use these things for graphics and virtualization we haven't discovered a way or a method of making use of these cases that's both efficient and portable across GPU architectures so we leave those alone that does allow for a potential efficiency gain in a fixed function ASIC where you could shave those off and we'll touch in that on the breakout session so propel doesn't target those cases it simply passes through the dag load but next to the cases we have something that I love which is called scratchpad memory so let me tell you a little bit about scratchpad memory it's this high speed internal memory used for temporary storage of calculations data other works in progress think of it like your brain Nvidia and q2 referred to this as shared memory and AMD and OpenCL refer to this as local memory the defining feature of this memory compared to DRAM is that it's highly banked with a large crossbar that means it allows accesses to random addresses to be processed really quickly something that fixed function Hardware it doesn't do too well with Nvidia is Pascal outline supports a scratch pad of up to 96 kilobytes AMD's Polaris and Vega line supports up to 64 kilobytes and the AMD OpenCL kernel currently required additional scratch pad space in order to exchange data between lanes so in order to effectively execute on all existing architectures and not limit our occupancy the case portion of the dag our cash bytes up there is set to 16 kilobytes now the compute core of a GPU card the ASIC itself is really just a large number of registers that feed high-throughput programmable math units the inner loop of Eid hash just uses the dag load and then the FNV to merge the data into a small mixed state Prague as a sequence of random math instructions and random cache reads that get merged into a much larger mixed state why is this important the bigger the mixed state and the more random the bigger the die size gets on fixed functional hardware reeking of FNV I wanted to touch on it for a moment because I did promise some folks that I would so there's this rumor a myth going around about FPGAs with some killer performance on it hash even when they're just bound to ddr4 memory F&V fuller Nova vole is not a secure hash function there is a possible attack where if you know iteration I is accessing dag X then only a small number of next possible dag Y will be accessed and technically you can do a pre calculation attack where you pre compute dag X with enough SRAM or be ram followed by all combinations of dag Y and you completely skip off the memory accesses what that means is that you violate the memory bandwidth Evette hash most of these FPGA rumors seem to be require 64 gigabyte which suggests pre-computation combining DAGs doesn't actually work but in case there is an F&V attack well there's kind of good news see prog pal doesn't have this problem and hash is dag to F and V to dag but prog pal its dag with a bunch of random math which with dag with a bunch of random masks repeat repeat repeat until dag now multiple people have claimed to attack this weakness and F and V to date and who knows maybe I might have to so let's move on to the random math function and why that matters so much randomness and fixed function Hardware do not mix random math helps to match the GPUs program ability and integer math that they normally excel at fixed function Hardware like I said doesn't like randomness FPGAs don't really like it much either they require reprogram ability via JTAG USB or some other metric to employ randomness some people think that the random math and probe pal is a bit naive they assume it's cheap to implement on a 6 because we use bit operations our implementation uses rotates which require a full barrel shifter that's pretty expensive on fixed function hardware and sure if you're the bitstream on an FPGA could be updated every 12 minutes it could definitely implement the random math portion of prog pal at a lower power than GPU by creating a fixed pipeline but there's a problem with that the cache accesses however all of that all so since you're gonna need a high throughput throughput crossbar you know the things GPUs naturally have it's gonna cause a problem and we use KISS 99 for our random random math and that's that's kind of important for you number geeks out there like me we don't use Mersenne twister because it's efficiently implemented on the specialized ASIC actually we don't use a lot of the random number generators out there because we need something that posts the test you owe one statistical test suite why well test you oh one actually performs checks to determine whether a random number generator produces well truly random numbers for some reason most of them fail horribly so yeah Zor shifts they're not your friend folks they're not your friend so by now you're getting kind of bored and you're thinking okay okay great you talked a little bit about Asics what are the actual results well boom baby look at that look at that almost 90% utilization in both the core and the memory and on top of that we can also see our scratchpad memory up there the second screen is also completely saturated and then look at the 5 85 80 has 88.8% occupancy and saturation up there on a video eighty eight point four percent now in at hash we all know that NVIDIA GPUs and AMD GPUs are not equal they're not matched they're not balanced prog power fixes that a proper proof-of-work algorithm is all about balance and yeah while our cat check calculation is halved frog power does add that series of KISS 99 calculations as part of our mixed stage remember we talked about why mixing is important well the filmic stage has too much data to offload to an external FPGA now it could be implemented on a really small chip within an ASIC using a small accelerator but that's only 7% of our compute utilization so we see up there ninety one point nine percent of the instructions are executed within the dag access random math and random cache accesses things we can't move off the GPU can't check and fill mix only account for about seven percent that's only a seven percent speed speed gain so what does that actually mean well in layman's terms it means that an ASIC for at hash looks just like this high bandwidth memory interface kept track engine usually on an FPGA and a small compute core to do FNV loop and modulo operations but a pro palcic well it's gonna have the high bandwidth memory interface it's going to have a compute core with a large register file compute core with high throughput integer math high throughput highly banked cache small cap check and kiss 99 engines wait I think that's also known as a GPU and probe has also tunable so that's a really important feature of your proof of work algorithm so what happens if in the future if def else isn't around to keep tuning profile for the next generation of GPUs when they come out in six years well any GPU architect and their there are thousands of them can go and open up the videos profile or AMD's codec cell and simply tune these parameters to make sure that the GPU is completely saturated and quite frankly we shouldn't be on proof of work for aetherium in six years otherwise I'll be very disappointed and really that's that's it that's the technical walkthrough of Prague pal it doesn't have to be that complex proof-of-work like I said it's just about matching the algorithm to the hardware just through some minor chains changes and so that's it thank you very much so I imagine there's going to be tons of questions and I'm petrified and so shoot great talk thank you I want to play devil's advocate and challenged the premise that utilization and saturation is actually a valid metric and the reason is as a GPU designer you're not looking to solely optimize energy expenditure per unit of proof of work what you're trying to do is you're designing for gamers where performance is a key thing and also you have constraints in terms of diarrhea so you want to optimize for power so basically what you do is that you will design your ASIC to have a reasonable trade-off between performance power and diarrhea but as as a miner the only thing you care about is power energy spent units of proof of work so you could build something that is functionally equivalent to an ASIC but might have you know a larger area or might have a higher latency but consume I'd say ten times less energy per unit of work and utilization which would be a hundred percent but you know from your perspective that it's not a good metric so there are three things to address there one is a philosophical thing where we talk about what proof of work actually meant when it was a created you know proof-of-work kind of means work AKA energy expended but that's really a philosophical debate from a minders stand for miners standpoint miners really care about balance now prog pal it does consume more more power simply because it uses the core which was not used before but the important thing with that is that you take an ASIC that also has the core also has the memory take a GPU same it will match your other point was that miners only care about power but I'd I'd really contest that miners really really just care about fairness that's that's the crux of it we care about being able to all be on the same playing field in the same level field and then you touched on the fact that GPUs are just naturally tuned for video games that's not true at all see GPUs are tuned for maths geforce cards and AMD's gaming line sure it's tuned for FPS but by modifying the firmware you can also just tune it for math that's the great thing about GPUs they're tunable and programmable and customizable what was what was the other parts of your question you can try and minimize latency you can try and minimize area or you can try and minimize power you could find a reasonable trade-off if I was to go ahead and build an ASIC for pro power what I would do is I would make it energy efficient first so I would choose my cells extremely carefully so that you know I don't care if the 10x the latency or if the 3x the die area all I care about because the revenue as a minor is basically going to be proportional to the the amount of work that you can get done drool can burn only when it's compared to other miners of course that's that's the difference yes so the other miners will use GPUs and I will use something that is functionally equivalent to GPU but is potentially has a much larger diarrhea and runs but when you when you go and build a propel ASIC you're only going to be able to shave off I get your question now you're talking about the fact that you're going to shave off although you know the GPU pipelines the extra Katia's all the things we've left to optimize it for power it's not about shaving of things is about fundamentally designing the circuit optimized for power as opposed to optimizing you can't really optimize for power when you just have a bunch of random math churning through there that's that's going to consume a lot of power and no matter what the only way you can get the power savings in that circuit would be to probably shave off a few transistors let me give you let's say you want to build a 256 bit multiplier mm-hmm you have two options one is that you can build a massively parallel multiplier where basically you'll have 256 by 256 array and then you'll have a massive reduction trees with lots of compressors and that's going to use a lot of dynamic power mm-hmm the other option is to have a much smaller circuit which does less things in parallel like much more much more sequential work and that is going to consume less energy 256-bit multiplication now it's possible and it's likely that GPU designers did not build their circuits to minimize for for low power for low energy expenditure per unit of work I wouldn't say that I'd go and look at the GPUs design again the most the ones we target here are G Falls but if you actually go and look at AMD or nvidia gpus that do target low power for every energy of work it's their new tesla lines specifically for g6 that consume about 55 watts per card for about I think it's 9.6 teraflops that's a great example of optimizing for power it's just about which line of GPUs you're going to target so they do build some things like that high so there is a speculation that this algorithm was developed by AMD and in media in order to protect GPU money and interests so and you did obfuscated people who worked who is behind it but if then else why does it matter who created it did you so two parts to that first the amount of work and research that goes into designing an algorithm both AMD and NVIDIA have way better things to do for a start cryptocurrency mining and I'm really really really knowledgeable on this considering I contributed to most of it only made about 384 million dollars last year for them and then it made a tiny amount of money this year and you can publicly track that because it's all in their financial reports perks of a publicly traded company now their actual revenue per four GPUs or per quarter I should say is somewhere in the five plus billion which is a lot it's a lot see they don't care about GPU mining they're fighting the battle in the AI space in the TPU space in the CPU space and in the FPGA space the other thing is that if AMD had designed this they would probably have done a better job at fixing their shitty OpenCL implementation and they wouldn't have given me so much hell in trying to get fixes and the other thing is again the whole point of prog Pao is to protect at hash wallet transitions to proof of stake we do not let me make this very clear if def else does not want proof of work to exist when proof of stake is ready the main reason for this is to make sure that proof of stake has a fighting chance and etherium doesn't get destroyed by centralized entities while it's going into its transition phase I just think that there is a conflict of interest for you to pour that prop pal right now why I can make an ASIC I'm like let's be very very public prog pal destroys every single optimization then I get pocket money for this destroys a lodgment this destroys all my private optimizations this destroys the acorn line of FPGAs which I think some of you are familiar with the minority group is selling and we do very much support this destroys a lot of things that we very much like hey I just curious about the statistics and security of the random masts how do you prove that it can be performed much better than FME because I checked this back it's just some random mathematics calculation based on the ha pill is calculated value if my understand is correct a previous previous block block header not the previous value that's a that's a mistake so specifically the random math function takes a few few parts it takes kiss nines random math generator it takes the random block header that changes a random block hash sorry and it also changes the input changes every 50 blocks now it's tweakable where you can adjust it to change every 25 blocks instead or every 5 blocks if you really want to be painful it's FN v1a that we use not FNV itself like I said it takes C dag which is a combination of your case your block header and some random math mixes up with more random math keeps doing that for about I think we're doing it 64 64 cycles then spits it out the code the code is the proof mm-hmm yeah you can go and grab the code today and you can profile it yourself usually through synopsis or another simulator again all in the white paper yes everything's completely public with that we actually did a huge ride up on medium that we published two days ago about this about the security of the FN v1 a function yep just to the point you made earlier so this is purely an altruistic effort by FFLs to transition safely to proof estate god yes i'm of course course scientific love's a six please we want a six to be around because they consume more power it's better for me and deaf and else couldn't really care less right now they're GPU enthusiasts we think it's really cool we like algorithms a lot we like proof-of-work a lot it's kind of fun I noticed that someone on Bitcoin talk claimed that they found a way to represent the food Wawa yes the food Aggie yeah several megabytes so what that well if he is not lying what the protocol I will again we pointed that out it's the FN v1a attack it does or F and V attack it doesn't affect prog pal but yes so Wawa is on to something and he will be a very rich man is there any like economic analysis on how that well first of all how the hardware that you can currently buy improves current GPUs performance versus basic miners and how would that like how would that change in like in the world of proc Val so the biggest thing is when we do our analysis we compare silicone costs to silicone cost so I never play in the realm of like what what MSRP is for GPU cards because there is there are ways around that the I'm guessing you're talking about like the cost of an ASIC versus a cost of a GPU in the world of prog pal yeah well I know so that comparing to the cost of ASIC versus the cost of GPU plus acorn plus all the other stuff oh yeah so let's so the cost of a GPU card will talk roughly about that today it's around it's around $100 for the memory on its own for 8 gigabytes of gddr5 g6 is around 150 the GPU ASIC itself is around $40 or $50 depending on it whether it's Nvidia or AMD and the PCB is 25 bucks and the heatsink admin miscellaneous it's around $15 now an ASIC an ASIC is really cheap so we talked a little bit about the e3 because it's the one I have the most experience with I haven't analyzed ed Lindsay's at hashe 6 but the e3 chips the DRAM chips were brought for $3 50 each that's actually public on if you if you check their l PETA's Oh Peters filings you can see how much was brought in that certain period then the PCB is only around 20 to 25 dollars the heatsink the sheet metal everything else assumed $30 so there is quite a large gap and then you have to factor in the MSRP as well now in a probe pal world they're going to actually match on a silicon and a heatsink cost and the only savings as I as I said before you're going to get is by shaving off those unused dye cases that we can't really find it use for and that's gonna save you around two to three dollars per GPU card so there's also the basic design costs right and any and ASIC design R&D I mean I'm not sure how public some people's costs are but like for for a sia ASIC or for even a sha-256 ASIC you can get them as cheap as 10k R&D cost and a pro growl a sick it's pretty simple to make since all the code is open source and he'll maybe when we have some spare time we can just make open source schematics of a probe pal basic why the hell not a better way to prove our point thank you yeah I just want to make a guess a quick point for people in the audience from this coming from miner miners mostly just care about the profit that they're making correct so it the revenue is gonna be you know how much coin you're mining times its value you can sell it in to you know all the miners have real-world Fiat costs they have to pay the power companies in fiat so they have to convert the cryptography so at the end of the day they just care about their profit margin and so you know Minh wants to develop a ASIC for Prague cow and there's only a 20 or 30 percent speed-up just the development costs for rolling out the silicon and you know building all that which costs millions and millions of dollars won't actually make up for the gap so it's not like you guys have to be like just as fast as ASIC even if a six or ten or twenty percent faster it's just not economical for them to even go out and deploy all that NRI cost to actually build it so I don't think it's like you guys need to even make it so that there's no efficiency speed up but it just needs to be that there's you know even if there's a 10 and 20 percent speed-up it's good enough so I mean right now there's a there's like a 7 percent to 12 percent speed up but we also just like to make it so that there's no major speed-up because a it's fun sure yeah the fits with the chaotic theme just a follow-on question for that is that presumably prop power works on standard commodity GPOs which can be redeployed on other uses like artificial intelligence even after a theorem goes to proof of stake that's another very big factor if you're considering deploying tens or hundreds of millions of dollars on an ASIC which has only got one purpose where as a GPU farm can be reused is that the case that is very much the case I can talk a little bit about how awesome GPUs are they're repurpose 'fl I love that you can play a game on it though most miners won't be playing games with their mining farms but you can use alternate you know alternate proofs now a golem is probably the one you're most familiar with you can sell your GPU cycles now for rendering so that gives mining farms a little bit more of a profitability and that contributes to a pretty cool world proof of useful work is something that's being explored as well trying to find a use case for all these proof-of-work machines out there there are some interesting things with computational fluid dynamic annex there's some interesting stuff in the medical space nothing is being fleshed out to date simply because people haven't solved the liability problem that comes with having a very decentralized system but golems on the right track which is great and that's taken what just a year of development imagine what we're gonna see next year so yeah GPUs are pretty awesome because they're repurposed and on that note FPGAs are as well but they do have a much higher skill level you do need to go and rewrite the bit streams you need to reconfigure them tune them and the amount of GPU compute architects out there significantly Dwarfs the amount of VHDL and Verilog architects hi great talk I'm just wondering you have tunable parameters these are integers yep how about tuning which app codes we use there I think there was like a list of 11 app codes that we choose randomly and maybe tuning also the hashing algorithm maybe something that you know you say that some version of ketchup is is better for some GPUs how about some different algorithm altogether or maybe two different algorithms one different one at the beginning at the end just someone that's naive that says why this why that poking holes you know at every part of your diagram can we do something different here we can the biggest thing you don't want to do though is one we wanted to make Prague towers simple at today to slot into the existing at hash implementation so we didn't want to get dick around too much because that would have required way more test analysis it dicks around with the CPU verification as well which we know is very very important to the etherium eco eco system and quite frankly as long as you have enough random math in there it's going to it's going to make it impossible to offload we could replace ket Jack with another hash function I haven't really thought too much about it we also had a really cool idea of merge mining as well which would be a great way where you know other proof-of-work algorithms could use probe pal in tandem to compute their final cycles to get a bit more ASIC resistance that would actually defeat the nice hash problem that we all have in mining but that's a lot of development work as well and these just to be clear these tunable parameters are just for future revisions of GPUs so today all of these are completely tuned for NVIDIA z-- latest line of GPUs which is the RT X to 2000 a.m. DS latest line which is their Vega version 3 I guess they're on now and also we did have an Intel GPU sample but I don't think that those will be massively used by miners unless you're very very rich so a great talk thank you even though I think I probably only get 10% of it I wonder from integration standpoint like how feasible of our long hour because I remember I'm seeing that the time to verify the proof work increased by a margin that might make it infeasible to actually use it yeah so that let let's make that very public that is simply because of my terrible go skills we are we we are really great on the GPU side not so great on you know standard client code we fix that with an optimized implementation had some great help from Paraty devs from earth minor developers for the hope from the whole ethereum community really there is going to be a - it's going to take two times as longer to do a verification simply because two times the data is consumed that's the 128 bytes increase to 256 bytes but as long as everyone's verifying proof of work the same it evens out and it levels out and a 2x a 2x slowdown is much more palatable than what it originally was which was a 9x slowdown so that's what happens when you don't optimize your code guys hello me again on the legal front someone might say some things are copyrighted some code is sort of you know intellectual property and your other people are running this code would there be any barrier does someone own this intellectual property does anyone own the copyrights to Prague POW would would there be someone that could later on say okay you're using my code you're running it now you know I mean it's open source so if you want to go patent the open source code licensed under the MIT license go for it guys no there is no copyright again this has been public fully public fully open source since I think we released it in April oh god it's GPL infected well there we go I have several questions regarding the specs other official specs now because in the beginning it was a bit janky I realized that there is a still some use of FN v in hey no no the normal Wow oh yeah yeah because I've I've seen the the primes used by the normal one why is that simply because we didn't want to mess around with the original proof of algorithm too much because it affects that you it affects the balance of the compute core of the GPU if it's in the is it in the dead duck generation yes it is okay then the question is if we shouldn't just change this if we change prop oh we should maybe just change this if this we can buy from we can we can definitely take FNV out altogether we'd need to find another really light verification fast hash that would just require some sort of research maybe we should just change it to FN v f11 a yeah we can do that maybe yeah ok then the cache the small cache in shared memory why is it felt that way it's felt like at first 128 bytes from from the deck or something or the first elements from the deck why that why not some randomness or something simply because that would so if you were going to make a probe pal ASIC because it doesn't saturate all of it completely in theory in theory you could go and create a sort of a compute core that takes takes all this randomness and does a pre-compute with an FPGA it would only have to do it every 12 minutes you could have a very dedicated bitstream developer and you wouldn't always get that balance between this is the important part you wouldn't get the balance between a NVIDIA GPU and an AMD GPU sometimes if there was too much randomness you'd end up going way over the the case case availability for an AMD GPU the AMD GPU here is the big bottleneck and I think both both architectures have to save the same amount of data in correct but if you have the ran randomness changing the bytes that screws with the saturation and then that would cause the AMD GPUs to underperform we did try that early on it didn't work out too well the updates so we have an update every 25 I don't know every 50 or 60 yeah we put it at 50 blocks I think we were we finalized on 50 bucks you could change it to 25 blocks but there's really no point 50 blocks is pretty good but I guess if you want to be super hardcore changing 25 blocks what's the overhead of this update do you have some what do you mean by overhead like do you have to pre-compute the kernel do on a GPU it's it's really fast it's we publish it publicly it should be like 0.

2 or 0.3 seconds 25 blocks gets a little a little painful on an FPGA you're still gonna have to go and we push out the bit stream every every few blocks which will be painful that will be a three to three to seven minute overhead do you know how much CPU that computing the kernel code I don't actually I should I should measure that I know that some of the mining rigs are running on almost full capacity on this like really small intercourse most of them have a Core 2 Duo which should be okay with it quite frankly and all of our computation as well takes place on the GPU and we can actually make sure that oh the CPU is just doing a very slight amount of verification so we could actually tune that that's more of a that's not on the proof-of-work side though that's more in the application or like the current the client side so definitely we need to work with the etherium developers for that again the clients are not our strong suite as as is proven by the cpu verification will you update the DEP to have the new spec yes that has been on my list of things to do I did get the medium article out I did update the I did get hub yes I need to update the EIP will you develop some test cases for other clients to use yes I need help with those quite frankly I think that would be amazing I do not have enough spare cycles to date to be able to do all of these things okay thank you about five minutes left could you speak a little more about whether this changes to bandwidth consumption on the bus on the other GPU because of the increased cache size yeah that's that's the whole point it actually does change the bandwidth consumption again generically it's only 60% consumed which is a problem we do 90 percent you can never get 100% bandwidth consumption in real world applications it's just it's impossible it's one of the things GPU architects struggle with so that's the best we're able to do to date in theory you could I'm sure there's like a trick and I'll go noodle on this because if probe power does get adopted naturally I'll want to go and break it again I'm sure there's a 1% speed-up you could get with some clever tricks on the minor side but other than that yes it changes your bandwidth consumption consumes 90% of the bandwidth that's basically what we mean by bandwidth utilization that's how much bandwidth is consumed hi I'm still thinking about how to break your scheme that's okay man that's okay I wish I was deaf and elsewhere here even if they were wearing masks they love you so I mean even though you let's say assume you're using a hundred percent of the GPU you still eighty percent you still not using the full flexibility of the of the GPU so for example well why you're not using the full flexibility of the GPU so for example you know there will be a circuit that does addition and then a second as multiplication and then you call them one after the other and the reason why these two circuits would be separated in the GPU is so that you can you can mix and match but because you're calling them in a specific order as an ASIC designer what I could do is I could build a clever circuit that does a and B at the same time and uses less energy than would be if you first use the a circuit and then the B circuit yes actually that was something I was going to put in my slides we use a again I mentioned we use a barrel rotate shift our implementation of rotate is more GPU implementations I said I should say it's more efficient than any existing ASIC to date and any existing fixed function hardware again GPUs are I think most people forget GPUs are really just Asics for meth that is what a GPU is so what you're specifically referring to is a barrel shift rotator and the GPU right to date is the most efficient efficient implementation of it that's why when I say that you know if we want to go and make a probe by a sikh it just ends up mimicking making a GPU because you just mimic that i'd love to touch more you after this on that actually because I have a write-up on that because we got that question asked a lot from an FPGA developer who was who was talking about putting in square roots and other things into propel so I'm done you're releasing me from my prison you