我也做过类似尝试。PoC 确实可行，但无状态性确实成为了一大障碍。

它强制要求客户端在每次请求时都执行工作量证明。

我们在PoC中发现的其他困难包括：

并非所有客户端都是平等的：这会让老旧的手机或树莓派比运行在配备GPU的强大服务器上的客户端，或运行在受损硬件上的客户端受到更严厉的惩罚。——即真实用户很可能受到惩罚，而非法用户往往受到的惩罚最轻。

并非所有端点都相同：我们尝试了对POST/PUT/PATCH/DELETE等操作设置更高的难度，而对GET操作则设置较低的难度。同时，我们对不同端点设置了不同的难度级别，试图匹配这些操作对我们而言的成本差异。这需要通过多次往返来交换难度设置。

这会阻碍正确的HATEOAS或REST设计，因为客户端本应通过跟随链接浏览API，却鼓励了“在单次查询中包含尽可能多内容”的调用方式。这削弱了我们的缓存能力、灵活性，并阻碍了良好HTTP实践的运用。

基于流行的流量峰值通常非常短暂，小型网站无需过多关注。

我正在开发一个公共服务，并计划在其中使用一个简单的工作量证明实现，该实现可通过单次调用完成，无需每次请求都与服务器进行往返通信。

我的例子有些肤浅，但你不应专注于这个用例。小型网站并不总是意味着“可忽略的信息”，而爬虫程序始终在窃取CPU时间。

Zip炸弹会占用一些内存。我对向明确无视“禁止进入”标识的客户端（更具体地说，是故意进入的客户端）提供Zip炸弹没有任何问题。（此外：这本质上是一种蜜罐设置，这种概念并不新鲜；人们也会在SSH和其他场景中使用类似方法。）