How proof of work creates scarcity
The Premise
Recently, I tried adding [proof of work with dynamic pricing] to a web service.
The web service, PixivFE is an unofficial frontend like Invidious, but for Pixiv.
It has the following resource constraints:
- original service’s request limit
- cpu time
- network bandwidth
The hypothetical use case is to prevent mass scraping. Like Anubis.
Initially, my idea is to introduce a one-sided market for the service, weighing the cost of requests and let user agents pay according to demand. However, I found that the three type of resources (list above) cannot be made one. They are three constaints. Furthermore, it is difficult to ascertain how much cpu time and bandwidth is used. Does the service really need access to OS kernel’s knowledge about itself in order to function?
The Hypothesis
Since the market way didn’t go as planned, I thought of the following ways to prevent resource depletion on our service:
- figure out who we serve and actively verify their identity (in the cryptographic sense)
- diplomacy: work with the original service provider to use their resources more efficiently
- change user behavior through UI and culture; let them not waste our resources
- get more resources
My hypothesis is that a combination of these will prevent resource depletion for at least two months.
Outcome
(2025-11-11) I have not found evidence of actual scarcity. I can only hypothesize that the offenders are web scrapers brought by the LLM boom.
Pixiv’s response: Standard “don’t abuse our service” reply.
Epilogue
If you want to defend against web crawlers, Anubis is fine. I also have the idea of turning web crawling activities into a curiousity for humans to toy with. But pitching humans against humans, I hope that both sides will learn to sit down and negotiate.
I also want to know: is it possible to live in a market society without experiencing scarcity? I think I will answer that myself in the future.