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
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