我一直在为 Linux 内核开发一个补丁，以通过 binfmt_misc 中的 bpf 支持解释器 (PT_INTERP) 的 $ORIGIN [线程]。当然，我借助 LLM 来帮助我完成这个任务！为了预先提供 LLM 的背景，我让它阅读了 https://lore.kernel.org/ 的线程。哎呀，看来他们采用了阿努比斯，这是一种 HTTP 代理，它要求在访问资源之前进行工作量证明。这真的有效吗？不幸的是，没有。我的 AI 勤奋地提出了 anubis-fetch ，你可以在 https://github.com/fzakaria/anubis-fetch 找到这个工具。该工具试图原生解决工作量证明，或者作为最后的手段，将启动 Chromium 来访问 URL。这个工具还通过请求原生模拟了真实的 Chrome TLS/JA3 指纹，因此也可以清除被动的 Cloudflare 阻止。☝️ # HTML 输出到 stdout $ anubis-fetch https://lore.kernel.org/linux-mm/some-thread/T/ # 可读的纯文本 $ anubis-fetch --text https://lore.kernel.org/linux-mm/some-thread/T/ 那么我们到底阻止了谁？阿努比斯所针对的确切对手轻松绕过了它。使用阿努比斯的整个过程显得退步，并且边缘化了那些无法访问“好” AI 的人。对于爬虫来说，解决阿努比斯挑战是一种一次性的成本，费用摊销为零，因为 cookie 可以被缓存和重用。对于人类来说，每次新访问时，都是数秒的等待和电池消耗。他们无法在彼此之间摊销任何成本。这种“倒退税”对那些设备较弱或通过手机访问内容的人来说，付出更多。部署阿努比斯是否阻止了上述的机器人农场，还是他们在需要暂时增强自己的机器人以支持新的工作量证明解决方案时受到了一些轻微的不便？讽刺的是，阿努比斯的目标是阻止 AI，但 AI 绕过它非常简单，而对人类和开放网络的成本依然存在。在假设阿努比斯现在是一个倒退税的前提下，成本是多少？这里的每一个数字都是粗略估计。这根本不是一个环境论证，因为机器人农场和 AI 工具本身使用的能量是数量级地更高。然而，看到我们花费多少时间在工作量证明挑战上以边缘化人们也很有趣。困难 d 是哈希必须具有的前导零的十六进制字符数，因此每次求解的预期工作量为 W = 16^d 个哈希。困难 哈希数量 / 求解 原生 浏览器 JS 感觉的实际时间 4 65,536 ~1.3 毫秒 ~130 毫秒 ~1-5 秒 5 1,048,576 ~20 毫秒 ~2 秒 ~5-15 秒 难度 4 是常见的默认设置。假设的速率：原生（Go）约 50 MH/s，浏览器 JS 中约 0.5 MH/s；“感觉”的实际时间包括页面加载、工人和重载。设 C 为全球每天的阿努比斯挑战求解数量。假设感觉时间 t = 2 秒，每次求解的设备能量 E = 20 焦耳（屏幕 + CPU）。人类的时间 / 年 = C × t × 365 / 3.15×10⁷ 每年能量 (kWh) = C × E × 365 / 3.6×10⁶ C (求解/天) 每年浪费的人类时间 每年能量 1 M ~23 人年 ~2 MWh 10 M ~230 人年 ~20 MWh 100 M ~2,300 人年 ~200 MWh 集体而言，我们在等待访问网站上浪费了令人印象深刻的时间；在 AI 时代之前我们并没有花费这么多时间。对于人类来说，时间是珍贵而有限的，而对机器人来说则不是。