This post outlines a GPUfriendly PoW mechanism that mimics the security of ASICs.
tl;dr

Miner required to perform onetime 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 longterm 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 shortterm and on a longterm basis (both needed due to stochasticity)
Motivation
The debate around ASICs can be summarized by: ASICfriendly PoW systems are more secure, since miners have a stake in the system and this aligns their longterm incentives with the healthiness of the system, whereas ASICresistant 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 onetime 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 GPUbased PoW system, as it sets a higher barriertoentry 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 chainheights 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^{[hj,h]} \leq g\cdot \frac{j}{\lambda}\cdot H_M AND H_M^{[h_M,h]} \leq \frac{hh_M}{\lambda} \cdot H_M + \mathcal{O}((hh_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 GPUoptimized ASICresistant 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}.