ASIC Resistance

[timolson]

I couldn't find a better issue to discuss this. RandomJS is not ASIC-resistent. An ASIC designer may simply design a chip to do compilation. In effect, your PoW is a compiler, which is definitely implementable in hardware.

[timolson]

I’m discussing this on IRC in the Monero research channel if anyone is interested.
I’ll close the ticket because it doesn’t seem like anyone wants to discuss here.
I maintain that an ASIC which is more efficient than a CPU can be developed for this PoW.

[tevador]

RandomJS is not ASIC-resistent.

It depends on what you mean by "ASIC-resistant". For me, it doesn't mean that a custom hardware cannot be developed or cannot be faster. That would be "ASIC-immune".

The typical CPU development cycle is ~5 years. The picoJava processor took about 3 years of development before being scrapped. Javascript is an even more complex language. A lot can change in crypto in 3 years. The length of development and the required investment can mean that no ASIC will be developed simply for economic reasons.

[timolson]

A full JavaScript implementation is not necessary. See the "easy nonce" problem thread.

Let's even suppose that a full processor is necessary (I don't think it is, but for the purposes of discussion...). Your generator is not really that random, and tends to create programs of characteristic size, with a characteristic number of expressions, and a fixed distribution of functions to variables, etc. We may simply do statistical analysis on the generated programs; Suppose we find that on average, programs generated by RandomJS require 3MB of memory. We may quickly build a chip which outperforms consumer CPU's by licensing an ARM core and giving it exactly 3MB of SRAM. All the Intel chips which have 8MB of L3 cache per core are now inefficient compared to our chip, and we've done very little hardware design. Importantly, it is not the absolute size of the cache that matters, only the ratio of cache-to-core. If you make programs require 10MB the problem is even worse. Our ARM with 10MB L3 will blow away the Intel with 8MB cache because the Intel is waiting on cache stalls. So maybe then you design for a specific cache-to-core ratio. Now you have the problem that any CPU's which are not in the exact family you design for are slow. Even people with Intel's... if they do not have the chip with 8MB cache they are at a disadvantage to people with the 8MB Intel.

This idea may be extended well beyond caches to ALU's and other circuitry. For example, if you generate, on average, one integer variable for every two float variables, an ASIC design will have two int units and one float unit, whereas the Intel has one of each. ASIC wins.

ASIC exploitable:

    <item type="Add" weight="4" />      <!-- OPERATOR += -->
    <item type="Sub" weight="1" />      <!-- OPERATOR -= -->
    <item type="Mul" weight="1" />      <!-- OPERATOR *= -->  
    <item type="Div" weight="1" />      <!-- OPERATOR /= -->

Also, the idea that 5 years is required is not true. A chip doing PoW does not have to be perfect. It only has to be good enough to find some solutions some of the time. A proper CPU or JavaScript chip must be 100% perfect 100% of the time. Most of the development for these projects is not design of the chip but validation. ASIC miners may get away with lots less validation. So what if the float unit gives wrong results 1% of the time if the chip is 10% faster? You just gained about 9% in a PoW context. In a general CPU context, Photoshop just crashed.

[tevador]

ASIC exploitable:

   <item type="Add" weight="4" />      <!-- OPERATOR += -->
   <item type="Sub" weight="1" />      <!-- OPERATOR -= -->
   <item type="Mul" weight="1" />      <!-- OPERATOR *= -->  
   <item type="Div" weight="1" />      <!-- OPERATOR /= -->

Here the situation is not as simple because the function of the + operator depends on the type of operands. It can mean integer addition for integers, floating point addition for FP numbers and string concatenation (with some additional function calls) for everything else.

Most of what you wrote applies to any PoW algorithm.

The programs have to be limited to keep the verification time under control. Nothing can be done about that.

The custom ARM chip is probably the most realistic threat (we have already confirmed that even Raspberry Pi 3 is one of the most efficient devices at running RandomJS).

I will try to do more research about the possibility of generating random x86 code. If we couple that with a memory access pattern tuned for CPUs, it could be more ASIC resistant than the current approach.

[hyc]

ISA licensing issues aside, I don't believe it's a good idea to generate X86 or any other existing ISA. There's no good reason to benefit X86 and penalize other architectures (ARM, MIPS, SPARC, POWER, RISC-V, etc) at this point in history. ARM servers are about to become mainstream, and they already dominate the portable/handheld market. MIPS still dominates consumer routers. SPARC and POWER both still have significant data center presence. Supporting all of these aids decentralization.

[hyc]

Note: we've created the #monero-pow channel on IRC to avoid these conversations getting lost amid the rest of the MRL message traffic. Feel free to join us there.

[timolson]

#3 (comment)

The fact that ARM cores are competitive should be a major concern. It is likely that an even smaller, simpler implementation will outperform, i.e. ASIC.

[timolson]

I must withdraw my recommendation for x86 and agree with @hyc. It is critical for mining fairness that we have many manufacturers. Using x86 basically grants the ASIC monopoly to Intel and AMD and excludes new competitors from competing. What happens when Intel decides to make miners and produce a RandomX86 ASIC? Binding to x86 would create a true monopoly because of the insurmountable barrier to entry for new competition. SHA-2 is wayyyy easier to implement and we still see significant variances in the performance of different designs.

[hyc]

More on ARM - hardware support for SHA-3 https://twitter.com/thecomp1ler/status/989530582513168385
Hardware support for float-to-fixedpoint conversion with Javascript semantics https://twitter.com/gparker/status/1047246359261106176

AFAICS these just keep ARM competitive with pure ASICs.

[timolson]

Keep in mind that the ARM will have one SHA-3 datapath per core. That datapath is tiny, so a dedicated SHA-3 ASIC might have thousands or tens of thousands of them. Not really competitive.