ECIP-1093[Discussion]: If GPU-friendly Ethash is Removed then Change the ETC Proof of Work Algorithm to CPU-friendly RandomX

[gitr0n1n]

---

lang: en
ecip: 1093
title: If GPU-friendly Ethash is Removed, Change the ETC Proof of Work Algorithm to CPU-friendly RandomX
status: Withdrawn
type: Standards Track
category: Core
discussions-to: #329
author: r0n1n (@gitr0n1n)
created: 2020-09-05

Abstract

A proposal to replace Ethereum Classic proof of work algorithm with CPU-friendly RandomX should GPU-friendly Ethash be rejected from the network.

Motivation

I am concerned with the centralized pro-ASIC movement in ECIP-1049 (and ECIP-1095) from a centralized body in ETC (ETC Coop, Commonwealth.gg, and EPIC Blockchain). I believe the self named SHA3 Coalition is not fully addressing the many concerns of miners/developers/end users regarding miner centralization, inflation capture, supply chain bottle necks, network security, interoperability with other EVMs, and a deviation from the core principles of Ethereum Classic network.

To date there are 27 meaningful unanswered comments written from high profile ETC network developers, large mining pools, small independent miners and independent end users. The champions of ECIP-1049 and ECIP-1095 proposals are not engaging these comments in their ECIP discussion threads. Due to the uncertainty of these unaddressed questions, a material opposition to ECIP-1049 has formed in the Ethereum Classic community.

It is my opinion that ECIP-1049, will not achieve the Rough Consensus requirement to push SHA3 ASIC on the network and Ethash GPU will likely prevail in that conversation. As an auxiliary path, this ECIP is being proposed to offer an alternative route to consumer product, decentralized mining via a CPU route.

Related ECIPs to the discussion:

• Do nothing. Stay on Ethash.
• ECIP-1043 Ethash GPU. ECIP-1043: Fixed DAG limit restriction #11
• ECIP-1049 SHA3 ASIC. ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak-256 #13 , ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak256 #8
• ECIP-1095 SHA3 ASIC. ECIP-1095: Change ETC PoW to "vanilla" Sha-3 Discussion #342
• ECIP-1099 Ethash GPU. ECIP-1099 Calibrate Epoch Duration #368

Withdrawn Status Update and Explanation

This topic has evolved rapidly since the date I originally submitted this proposal. As the author of ECIP-1093, I believe this ECIP is unnecessary at this point in time and request that it be moved to Withdrawn status. This ECIP became obsolete due to the materialization of a vocal opposition to changing the Ethereum Classic mining algorithm. Dexaran of Ethereum Commonwealth has committed development resources to the GPU-friendly Ethash chain should the ETC mining community chose to continue to mine Ethash ( #13 (comment) ). That means that any proposal to change the mining algorithm will likely end up in contention, which is against the goals of the ECIP process.

A non-exhaustive list of comments from a notable opposition to changing the Ethereum Classic mining algorithm from Ethash:

Sourced from ECIP-1095 Thread

• ECIP-1095: Change ETC PoW to "vanilla" Sha-3 Discussion #342 (comment)
• ECIP-1095: Change ETC PoW to "vanilla" Sha-3 Discussion #342 (comment)
• ECIP-1095: Change ETC PoW to "vanilla" Sha-3 Discussion #342 (comment)
• ECIP-1095: Change ETC PoW to "vanilla" Sha-3 Discussion #342 (comment)
• ECIP-1095: Change ETC PoW to "vanilla" Sha-3 Discussion #342 (comment)
• ECIP-1095: Change ETC PoW to "vanilla" Sha-3 Discussion #342 (comment)

Sourced from ECIP-1049 Threads

• ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak256 #8 (comment)
• ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak256 #8 (comment)
• ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak256 #8 (comment)
• ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak-256 #13 (comment)
• ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak-256 #13 (comment)
• ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak-256 #13 (comment)
• ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak-256 #13 (comment)
• ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak-256 #13 (comment)
• ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak-256 #13 (comment)
• ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak-256 #13 (comment)
• ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak-256 #13 (comment)

Specification

The proposed solution refers to RandomX. This spec was sourced from the Monero Community. Thank you to all the wonderful researchers contributing to the goal of ASIC resistant algorithms.

RandomX

RandomX is a proof-of-work (PoW) algorithm that is optimized for general-purpose CPUs. RandomX uses random code execution (hence the name) together with several memory-hard techniques to minimize the efficiency advantage of specialized hardware.

Overview

RandomX utilizes a virtual machine that executes programs in a special instruction set that consists of integer math, floating point math and branches. These programs can be translated into the CPU's native machine code on the fly (example: program.asm). At the end, the outputs of the executed programs are consolidated into a 256-bit result using a cryptographic hashing function (Blake2b).

RandomX can operate in two main modes with different memory requirements:

• Fast mode - requires 2080 MiB of shared memory.
• Light mode - requires only 256 MiB of shared memory, but runs significantly slower

Both modes are interchangeable as they give the same results. The fast mode is suitable for "mining", while the light mode is expected to be used only for proof verification.

Documentation

Full specification is available in specs.md.

Design description and analysis is available in design.md.

Audits

Between May and August 2019, RandomX was audited by 4 independent security research teams:

• Trail of Bits (28 000 USD)
• X41 D-SEC (42 000 EUR)
• Kudelski Security (18 250 CHF)
• QuarksLab (52 800 USD)

The first audit was generously funded by Arweave, one of the early adopters of RandomX. The remaining three audits were funded by donations from the Monero community. All four audits were coordinated by OSTIF.

Final reports from all four audits are available in the audits directory. None of the audits found any critical vulnerabilities, but several changes in the algorithm and the code were made as a direct result of the audits. More details can be found in the final report by OSTIF.

Build

RandomX is written in C++11 and builds a static library with a C API provided by header file randomx.h. Minimal API usage example is provided in api-example1.c. The reference code includes a randomx-benchmark and randomx-tests executables for testing.

Linux

Build dependencies: cmake (minimum 2.8.7) and gcc (minimum version 4.8, but version 7+ is recommended).

To build optimized binaries for your machine, run:

git clone https://github.com/tevador/RandomX.git
cd RandomX
mkdir build && cd build
cmake -DARCH=native ..
make

To build portable binaries, omit the ARCH option when executing cmake.

Windows

On Windows, it is possible to build using MinGW (same procedure as on Linux) or using Visual Studio (solution file is provided).

Precompiled binaries

Precompiled randomx-benchmark binaries are available on the Releases page.

Proof of work

RandomX was primarily designed as a PoW algorithm for Monero. The recommended usage is following:

• The key K is selected to be the hash of a block in the blockchain - this block is called the 'key block'. For optimal mining and verification performance, the key should change every 2048 blocks (~2.8 days) and there should be a delay of 64 blocks (~2 hours) between the key block and the change of the key K. This can be achieved by changing the key when blockHeight % 2048 == 64 and selecting key block such that keyBlockHeight % 2048 == 0.
• The input H is the standard hashing blob with a selected nonce value.

RandomX was successfully activated on the Monero network on the 30th November 2019.

If you wish to use RandomX as a PoW algorithm for your cryptocurrency, please follow the configuration guidelines.

Note: To achieve ASIC resistance, the key K must change and must not be miner-selectable. We recommend to use blockchain data as the key in a similar way to the Monero example above. If blockchain data cannot be used for some reason, use a predefined sequence of keys.

CPU performance

The table below lists the performance of selected CPUs using the optimal number of threads (T) and large pages (if possible), in hashes per second (H/s). "CNv4" refers to the CryptoNight variant 4 (CN/R) hashrate measured using XMRig v2.14.1. "Fast mode" and "Light mode" are the two modes of RandomX.

CPU	RAM	OS	AES	CNv4	Fast mode	Light mode
Intel Core i9-9900K	32G DDR4-3200	Windows 10	hw	660 (8T)	5770 (8T)	1160 (16T)
AMD Ryzen 7 1700	16G DDR4-2666	Ubuntu 16.04	hw	520 (8T)	4100 (8T)	620 (16T)
Intel Core i7-8550U	16G DDR4-2400	Windows 10	hw	200 (4T)	1700 (4T)	350 (8T)
Intel Core i3-3220	4G DDR3-1333	Ubuntu 16.04	soft	42 (4T)	510 (4T)	150 (4T)
Raspberry Pi 3	1G LPDDR2	Ubuntu 16.04	soft	3.5 (4T)	-	20 (4T)

Note that RandomX currently includes a JIT compiler for x86-64 and ARM64. Other architectures have to use the portable interpreter, which is much slower.

GPU performance

SChernykh is developing GPU mining code for RandomX. Benchmarks are included in the following repositories:

• CUDA miner - NVIDIA GPUs.
• OpenCL miner - only for AMD Vega and AMD Polaris GPUs (uses GCN machine code).

The code from the above repositories is included in the open source miner XMRig.

Note that GPUs are at a disadvantage when running RandomX since the algorithm was designed to be efficient on CPUs.

FAQ

Which CPU is best for mining RandomX?

Most Intel and AMD CPUs made since 2011 should be fairly efficient at RandomX. More specifically, efficient mining requires:

• 64-bit architecture
• IEEE 754 compliant floating point unit
• Hardware AES support (AES-NI extension for x86, Cryptography extensions for ARMv8)
• 16 KiB of L1 cache, 256 KiB of L2 cache and 2 MiB of L3 cache per mining thread
• Support for large memory pages
• At least 2.5 GiB of free RAM per NUMA node
• Multiple memory channels may be required:
  • DDR3 memory is limited to about 1500-2000 H/s per channel (depending on frequency and timings)
  • DDR4 memory is limited to about 4000-6000 H/s per channel (depending on frequency and timings)

Does RandomX facilitate botnets/malware mining or web mining?

Due to the way the algorithm works, mining malware is much easier to detect. RandomX Sniffer is a proof of concept tool that can detect illicit mining activity on Windows.

Efficient mining requires more than 2 GiB of memory, which also disqualifies many low-end machines such as IoT devices, which are often parts of large botnets.

Web mining is infeasible due to the large memory requirement and the lack of directed rounding support for floating point operations in both Javascript and WebAssembly.

Since RandomX uses floating point math, does it give reproducible results on different platforms?

RandomX uses only operations that are guaranteed to give correctly rounded results by the IEEE 754 standard: addition, subtraction, multiplication, division and square root. Special care is taken to avoid corner cases such as NaN values or denormals.

The reference implementation has been validated on the following platforms:

• x86 (32-bit, little-endian)
• x86-64 (64-bit, little-endian)
• ARMv7+VFPv3 (32-bit, little-endian)
• ARMv8 (64-bit, little-endian)
• PPC64 (64-bit, big-endian)

Can FPGAs mine RandomX?

RandomX generates multiple unique programs for every hash, so FPGAs cannot dynamically reconfigure their circuitry because typical FPGA takes tens of seconds to load a bitstream. It is also not possible to generate bitstreams for RandomX programs in advance due to the sheer number of combinations (there are 2⁵¹² unique programs).

Sufficiently large FPGAs can mine RandomX in a soft microprocessor configuration by emulating a CPU. Under these circumstances, an FPGA will be much less efficient than a CPU or a specialized chip (ASIC).

Acknowledgements

• tevador - author
• SChernykh - contributed significantly to the design of RandomX
• hyc - original idea of using random code execution for PoW
• Other contributors

RandomX uses some source code from the following 3rd party repositories:

• Argon2d, Blake2b hashing functions: https://github.com/P-H-C/phc-winner-argon2

The author of RandomX declares no competing financial interest.

Donations

If you'd like to use RandomX, please consider donating to help cover the development cost of the algorithm.

Author's XMR address:

845xHUh5GvfHwc2R8DVJCE7BT2sd4YEcmjG8GNSdmeNsP5DTEjXd1CNgxTcjHjiFuthRHAoVEJjM7GyKzQKLJtbd56xbh7V

Total donations received: ~3.86 XMR (as of 30th August 2019). Thanks to all contributors.

[workvint]

@gitr0n1n Are you joking? Have you seen the increased difficulty after switching Monero to RandomX?

[Dexaran]

@gitr0n1n it seems that changing the mining algo is not a solution to 51% attacks. Instead of being 51%-overwhelmed with Ethash we will get 51%-overwhelmed with RandomX which is essentially the same problem.

[BaikalMine]

RandomX is CPU mining, so botnets will take over the network, do you want that?

[gitr0n1n]

Charles at IOG commentary on RandomX / SHA3 philosphical debate and considerations. This is the spirit of conversation this proposal is meant to stimulate. I'm glad he understood why I submitted this proposal.

https://youtu.be/F0lR_u7BVho?t=490

[gitr0n1n]

RandomX is CPU mining, so botnets will take over the network, do you want that?

Does RandomX facilitate botnets/malware mining or web mining?
Due to the way the algorithm works, mining malware is much easier to detect. RandomX Sniffer is a proof of concept tool that can detect illicit mining activity on Windows.

Efficient mining requires more than 2 GiB of memory, which also disqualifies many low-end machines such as IoT devices, which are often parts of large botnets.

Web mining is infeasible due to the large memory requirement and the lack of directed rounding support for floating point operations in both Javascript and WebAssembly.`

Linking a section of the proposal that references this botnets concern for RandomX.

[gitr0n1n]

@gitr0n1n Are you joking? Have you seen the increased difficulty after switching Monero to RandomX?

Doesn't an increased difficulty help secure the Ethereum Classic network? Currently Ethash is at a very low difficultly and we have experienced three 51% attacks in one month.

My opinon is that an ASIC-friendly option (SHA3) will result in less hashrate than Ethash (GPU) and more centralization. And, far less hashrate than CPU algos like RandomX.

Risk: With more available hashrate comes the more opportunity for malicious rental hashrate market which is currently crippling the network under the Ethash algo. Would available CPU hash be as hostile as Ethash hash? I'm not sure.

This proposal was opened for public discussion to act as a compliment to the ECIP-1049 discussion which only discussed GPU (Ethash) and ASIC (SHA3) options. This puts a CPU option on the table.

[gitr0n1n]

@gitr0n1n it seems that changing the mining algo is not a solution to 51% attacks. Instead of being 51%-overwhelmed with Ethash we will get 51%-overwhelmed with RandomX which is essentially the same problem.

I agree that changing an algo does not fix 51% attacks and adjusted my proposal given that feedback. This proposal is a compliment to the current, very narrow, algorithm discussion that is being push on ETC via ECIP-1049.

I believe we should be discussing the deeper topic of "Who we want to be miners?": CPU (RandomX), GPU (Ethash), ASIC (SHA3).

[gitr0n1n]

For this proposal, we have the benefit of observing the Monero networks adoption to this alogrithm. Below is a list of helpful videos that document how the transition from CryptoNight to RandomX worked out:

• A recap right after the hard fork by Red Panda Mining: https://www.youtube.com/watch?v=LjgD6GZpXeQ

Notes:

• Hashrate immeditely TRIPLED with the change to CPU from CryptoNight (ASIC exploited). That's a positive for network security.
• Mining profitiability dropped with the increase in hashrate. This appears to have normalized over time, but that was the immediate effect due to the sharp rise in hashrate.
• Supply chain: CPUs are readily available on the market. There is a well established supply chin for this algorithm. This is a big differentiator from the ECIP-1049 proposal. Where the supply chain is very small and CENTRALIZED. Think: ASIC front running via manufactures like Bitmain!
• Many miners already have CPUs sitting around, so its a low investment costs to onboard more miners to support the ETC network under RandomX. This is a positive for network security.
• Software available to dual mine RandomX and Ethash. Our current GPU miners can migrate to CPU while still utilizing their current GPUs. This is a win/win and could set that stage for a gradual transition from Ethash to RandomX opposed to the immediate algo change that Monero did.

This algo will allow anyone to participate in the Ethereum Classic mining ecosystem and is in the spirit of a DECENTRALIZED mining ecosystem. No one in the SHA3 camp is acknowleding how the move to ECIP-1049 will highly CENTRALIZE ETC mining. This gives those actors far too much power and we will eventually have a BTC/BCH contentious fork down the road with that centralized mining entity as it tries to retain its monopoly on the ETC inflation.

Scroll youtube for RandomX material, there are so many videos out there now that it's been about a year since Monero switched to this algo.
Here is an example of a RandomX home build:
https://youtu.be/ARJlaWAZjcw

June 2020 RandomX Results:
https://youtu.be/Z_CxGoEt1_o

[OmniEdge]

iirc sha3 additionally makes a flyclient possible. Is it depended on that algo or will this flyclient also work with RandomX?

[gitr0n1n]

@OmniEdge Great question. But do you centralize the whole networks security to an unknown, small, infant supply chain for fly clients? While I dig deeper into RandomX I'll note to look into flyclient implementation.

[wahaobi]

支持RandomX

[gitr0n1n]

Withdrawing this proposal based on this PR #376

It is apparent from the end of the CDC #13 the SHA3 ECIP-1049/1095 and accompanied mining algo change discussions are eating up too much bandwidth. The focus needs to remain on 51% attack solutions to stablize this network. So, I request to move ECIP-1093 to Withdrawn status to clear it from discussion.

Withdrawn - ECIP authors may decide to change the status between Draft, Deferred, or Withdrawn. The ECIP editor may also change the status to Deferred if no progress is being made on the ECIP. Source: https://github.com/ethereumclassic/ECIPs

Due to the observation that there is already a vocal opposition to changing the mining algorithm away from GPU-friendly Ethash. I believe any proposal suggesting a mining algo change would be contenious (ECIP-1049, ECIP-1093, ECIP-1095) and is against the ECIP process goals of avoiding network splits.

Thanks,
r0n1n

[gitr0n1n]

#376 (comment)