Algorithmic ASIC Mimicking

This post outlines a GPU-friendly PoW mechanism that mimics the security of ASICs.


  • 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)


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.


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].


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.


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}.

  • Nifty idea! Several thoughts:
    • A nice property is that this mechanism is (or at least seems to be) truthful, .i.e., no one has the incentive to declare either a higher or smaller hash rate than the actual average the hash rate.
    • Using a zkp can be applied here (by e.g., commiting to some hash rate when entering when entering and then using some range proof to show that the value that is being committed to is indeed in that range). Note that in this “trivial” scheme there’s an information leakage as anyone who verifies the proof knows some upper bound of the hash rate. Therefore, a commitment to the address (e.g., HMAC) of the miner should also be used (as used in zcash). This comes with a price of an increased the computational time.
    • Regarding mimicing the ASIC, it seems that if one had an ASIC, then it will always has the incentive to run it in its full power. In order to mimic the ASIC well, shouldn’t it has another enforcing mechanism to make sure the miner has some average minimal hash rate?
  1. The ZKP should make private the linking between the blocks of the same miner (and not necessarily the amount of hashrate committed)
  2. It seems that under this system GPU miners will mine in full force anyways (or at least that this mechanism won’t change the behaviour)

Yes, zcash did similar thing with individual transactions where the linking between different TX of the same input is private

The problem that is being discussed here is indeed important.
I’d like to point out some thoughts regarding the suggested solution.

1. Goal Price

When choosing the license cost (in USD/Kaspa/Gold/whatever), what is to be considered?
The actual cost might change from almost nothing for those who pay very little for electricity to those that buy it in very high cost. In addition, it might also raise the cost of later ASIC devices, assuming that each and every miner must provide this license as well (either by the need to work on the license or due to possible additional circuits logic).

According to the motivation section, the cost of CapEx is ~1000 times higher than the OpEx. Does that mean that mining the license should be equivalent to 1000 (or maybe a few thousands) of blocks?

2. License Mining

This might result in a secondary market of “license mining”, where people with very cheap computing expenses (or maybe, later, special ASICs) might create mining licenses and sell them directly to those that would like to enter the mining business. Not that this is necessarily bad – it serves the original goal of “having a stake” by having CapEx. But then again, it might set the bar too high for most possible miners, leaving the network too centralized.

3. Getting to Business

How much time it might/should take for a miner to achieve the license and start the actual mining?
If it takes a lot of time to get into business, it might be a barrier for new miners. If it isn’t, then maybe the security achieved by that is not enough. Therefore it should be carefully chosen.
The possibility of a secondary “licenses market” might solve that problem, but it might as well suffer of raising the bar, as discussed above.

4. Possible Mitigation

The proposed “ASIC Mimicking” therefore might mimic the ASIC too closely - including the problems of less decentralizing ASIC brings. I think of a direction that adopts the idea presented here but might mitigated it to get the good of both approaches. Again - what appears in the motivation part is:

  • security achieved by high CapEx; relying on ASICs only takes to that direction
  • decentralizing is achieved by low CapEx; relying on GPU only takes to that direction

What if, instead of a single, high barrier (in time or price) such as a license, there will be a progressive increase in the mining power of each new miner?

For example, say that a new miner gets only 1/16 of the mining power, then 1/8 power, 1/4 power, and 1/2 power, until it gets a full miner power. Specifying the portion of power might be done by various ways, for example:

  • requiring a higher “difficulty” from new miners’ hash - if a “full miner” has to provide k leading zeros, then a “half power miner” is required to provide k + 1 zeros
  • not accepting some of their blocks, e.g., the first block a “half power miner” creates is not acceptable, but the next one is - provided that it includes a proof that there is a former unaccepted block

and maybe other.

This way, it might be easier to achieve both security (as the cost of changing the network is high - the “CapEx” is just spread over some period) and decentralizing (as it is very easy to start mining - it just that at the beginning, the mining rate is low and only later it increases).

Of course, this is just a general direction, but I thing it might take the “ASIC mimicking” idea to even better results.