How proof of work creates scarcity; how not to do it

The Premise

Recently, I tried adding [proof of work with dynamic pricing] to a web service.

The web service 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

TK: We will see. Hasn’t happened yet.

Epilogue

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.