This post outlines a GPU-friendly PoW mechanism that mimics the security of ASICs.
tl;dr
-
Miner required to perform one-time heavy PoW in order to join the mining set, in other words, it acquires a permissionless license to mine by burning electricity
-
This upfront PoW serves as its investment or stake in the system, providing a long-term security similar to those of ASICs
-
The difficulty of the upfront PoW investment is proportional to the amount of hashrate the miner wants to mine with
-
The protocol makes sure that the mining rate of the miner does not exceed its upfront PoW investment both on a short-term and on a long-term basis (both needed due to stochasticity)
Motivation
The debate around ASICs can be summarized by: ASIC-friendly PoW systems are more secure, since miners have a stake in the system and this aligns their long-term incentives with the healthiness of the system, whereas ASIC-resistant PoW systems are more decentralized, since mining can be done with commodity hardware available to anyone.
I suggest below a PoW system which gets the best of both worlds. In general, mining involves Capital Expenses (acquiring hardware) and Operational Expenses (running the mining operation). The CapEx investment that ASIC miners put into acquiring the machines represents their stake in the system. I propose a replacement of this CapEx with an OpEx scheme; this is crucial for the pre–ASIC stage of any new cryptocurrency with small hashrate, see below. According to this scheme, in order to enter the consensus set, a miner is required to perform a one-time heavy PoW, which we call the “upfront PoW investment”, and this essentially mimics the CapEx investment that ASIC miners have. This initial investment provides more security than a regular GPU-based PoW system, as it sets a higher barrier-to-entry to mining.
It is easy to show that the security of Bitcoin, for instance, stems from its CapEx and not from its OpEx: Measuring the OpEx cost of attack would put Bitcoin in the security of a few millions of dollars per hour, which is arguably really insufficient compared to the potential gains from such an attack (e.g., by shorting the currency beforehand), whereas the CapEx cost of an attack are in the order of magnitude of billions of dollars.
Mechanism
The mechanism considers a new miner M that acquired GPUs with total hashrate H_M. In order to start mining, M must publish a PoW that is proportional to H_M, i.e., a preimage of the form \langle M,H_M,\text{nonce}\rangle such that \text{HASH}(\langle M,H_M,\text{nonce}\rangle)<\frac{C}{H_M}, where C is some constant to be discussed later. We will refer to this preimage below as the “upfront token”.
The mining rate of M is enforced in the sense that M is not allowed to mine more than H_M blocks per second, on average. A naive enforcement scheme wouldn’t work, due to the inherent stochasticity of PoW mining (i.e., deviations from average are natural), and so we use a more sophisticated one:
Let h_M be the chain height at which M published the upfront token \langle M,H_M,\text{nonce}\rangle. For a block B, H(B) is the average number of hashes needed to produce it, as implied by the difficulty requirement encoded in its header. We denote by H_M^{[h_1,h_2]} the cumulative hashrate of blocks (i.e., the sum of H(B)'s) mined by M, between chain-heights h_1 and h_2. Finally, let \lambda be the network’s target block rate (# blocks per sec) as defined by the difficulty adjustment algorithm.
Then, if B was mined by M at chain height h, B is valid only if H_M^{[h-j,h]} \leq g\cdot \frac{j}{\lambda}\cdot H_M AND H_M^{[h_M,h]} \leq \frac{h-h_M}{\lambda} \cdot H_M + \mathcal{O}((h-h_M)^{-\beta}), where g>1, j\in \mathbb{N}, and \beta>0 are some constants (think \beta\approx1 and j\approx100\cdot\lambda). In words, the first term imposes a short term constraint on the miner: it is not allowed to mine at a rate higher than g times its declared hashrate H_M, which guarantees that the miner put a stake in the system before mining (this is where the added security comes from). Due to the stochasticity of mining, g must be greater than 1, thereby allowing the miner to deviate from its declared hashrate during short time spans. However, in order to ensure that the miner’s long term rate is indeed H_M, the second condition imposes a constraint that explicitly requires that the miner’s long term hashrate does not exceed the declared one [by more than a vanishing amount].
Challenges
The first and immediate drawback is that this scheme compromises miner privacy, as it forces the miner to reference their upfront token with each block they mine, linking all of their blocks to the same identity. Of course, a miner can mitigate this by fragmenting her mining machines into different upfront tokens. Alternatively, the reader are welcome to suggest an efficient zkp scheme to recover miner privacy.
Secondly, while this mechanism conceptually simulates ASICs, in practice, it creates a much more liquid market than the one created by actual physical machines. And so the security benefits are limited.
Finally, some argue that there do not exist GPU-optimized ASIC-resistant PoW algorithms, and that therefore for any widely adopted system ASICs are inevitable. Nonetheless, this mechanism is still beneficial for systems using new PoW algorithms for which ASICs haven’t been manufactured yet, and provides enhanced security for the early days of such a cryptocurrency—a period in which it is actually the most vulnerable.
Appendix
Choosing the constant C
Recall the requirement \text{HASH}(\langle M,H_M,\text{nonce}\rangle)<\frac{C}{H_M}. In order to define the security parameters of the mechanism, and in particular the constant C, we must define the USD (or Kaspa…) cost, D_0, required to acquire a licence to mine with a hashrate of H_0 hash/sec. Then, we set C=\frac{H_0}{D_0}.