71 lines
4.1 KiB
Markdown
71 lines
4.1 KiB
Markdown
# Why does Filecoin mining work best on AMD?
|
||
Currently, Filecoin's Proof of Replication (PoRep) prefers to be run on AMD
|
||
processors. More accurately, it runs much much slower on Intel CPUs (it runs
|
||
competitively fast on some ARM processors, like the ones in newer Samsung
|
||
phones, but they lack the RAM to seal the larger sector sizes). The main reason
|
||
that we see this benefit on AMD processors is due to their implementation of
|
||
the SHA hardware instructions. Now, why do we use the SHA instruction?
|
||
|
||
## PoRep security assumptions
|
||
Our research team has two different models for the security of Proofs of
|
||
Replication. These are the Latency Assumption, and the Cost Assumption. These
|
||
assumptions are arguments for why an attacker cannot pull off a 'regeneration
|
||
attack'. That is, the attacker cannot seal and commit random data (generated by
|
||
a function), delete it, and then reseal it on the fly to respond to PoSt
|
||
challenges, without actually storing the data for that time period.
|
||
|
||
### Cost Assumptions
|
||
The cost assumption states that the real money cost (hardware, electricity,
|
||
etc) of generating a sector is higher than the real money cost of simply
|
||
storing it on disks. NSE is a new PoRep our research team is working on that is
|
||
based on the cost assumption, and is thus able to be very parallelizable (In
|
||
comparison to schemes based on a latency assumption, as will be explained
|
||
next). However, cost assumptions vary greatly with available and hypothetical
|
||
hardware. For example, someone making an ASIC for NSE could break the cost
|
||
assumption by lowering the cost of sealing too much. This is one of our main
|
||
hesitations around shipping NSE.
|
||
|
||
### Latency Assumptions
|
||
A Proof of Replication that is secure under a latency assumption is secure
|
||
because an attacker cannot regenerate the data in time. We use this assumption
|
||
for SDR, where we assume that an attacker cannot regenerate enough of a sector
|
||
fast enough to respond to a PoSt. The way we achieve this is through the use
|
||
of depth-robust graphs. Without going into too much detail, depth-robust
|
||
graphs guarantee a minimum number of serial operations to compute an encoding
|
||
based on the graph. Each edge in the graph represents an operation we need to
|
||
perform. We thus have a guarantee that someone has to perform some operation
|
||
N times in a row in order to compute the encoding. That means that the
|
||
computation of the encoding must take at least as long as N times the fastest
|
||
someone can do that operation.
|
||
|
||
Now, to make this secure, we need to choose an operation that can't be made
|
||
much faster. There are many potential candidates here, depending on what
|
||
hardware you want to require. We opted not to require ASICs in order to mine
|
||
Filecoin, so that limits our choices severely. We have to look at what
|
||
operations CPUs are really good at. One candidate was AES encryption, which
|
||
also has hardware instructions. However, the difference between the performance
|
||
of CPU AES instructions, and the hypothetical 'best' performance you get was
|
||
still too great. This gap is generally called 'Amax', an attacker’s maximum
|
||
advantage. The higher the Amax of an algorithm we choose, the more expensive
|
||
the overall process has to become in order to bound how fast the attacker could
|
||
do it.
|
||
As we were doing our research, we noticed that AMD shipped their new processors
|
||
with a builtin SHA function, and we looked into how fast someone could possibly
|
||
compute a SHA hash. We found that AMD’s implementation is only around 3 times
|
||
slower than anyone could reasonably do (given estimates by the hardware
|
||
engineers at [Supranational](https://www.supranational.net/) ). This is
|
||
incredibly impressive for something you can get in consumer hardware. With
|
||
this, we were able to make SDR sealing reasonably performant for people with
|
||
off-the-shelf hardware.
|
||
|
||
## Super Optimized CPUs
|
||
|
||
Given all of the above, with a latency assumption that we're basing our proofs
|
||
on right now, you need a processor that can do iterated SHA hashes really fast.
|
||
As mentioned earlier, this isn’t just AMD processors, but many ARM processors
|
||
also have support for this. Hopefully, new Intel processors also follow suit.
|
||
But for now, Filecoin works best on AMD processors.
|
||
|
||
|
||
|