fe52c47570
This: * Re-organizes the docs into sections that align with what docs.filecoin.io becoming: * An installation section * A "getting started" section (lotus client focused) * A "storing" section (lotus client focused) * A "mining" section (miner focused) * A "build" section (developer focused) * An legacy "architecture" section is left in the last place. A few high-value documentation pages have been reviewed and updated with the latest recommendations: * Installation section and lotus setup * Miner setup * etc. ... Other pages have been correctly merged into the new relevant sections. Some pages have not been touched. The filesystem layout of the documentation has been changed into folders corresponding to the sections (as requested by @cw). Some pages that were not linked at all and/or where hidden, have been moved to "unclassified". This should make the porting of the Lotus documentation to docs.filecoin.io much easier, while ensuring it is more up to date than it was before. For the moment, this breaks most links as link-aliasing is not supported in lotus-docs.
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.
|
||
|
||
|
||
|