在 Anubis 中发布 WebAssembly 花了一年时间

原文 ↗ Hacker News 讨论 ↗

像 Anubis 这样的工作量证明挑战，正作为 CAPTCHA 的替代方案出现，用于限制滥用性的网页抓取和机器人流量；它现在使用 WebAssembly 和内存硬函数（Argon2），以更好地适配现代浏览器和硬件。评论者争论这种做法究竟能否真正阻挡大型、资金雄厚的抓取器，还是主要惩罚普通用户——尤其是使用旧设备、禁用 JavaScript/WASM，或采用严格隐私设置的人。讨论还凸显了更广泛的担忧：这种“浪费”算力带来的生态与经济成本、跨浏览器和设备的兼容性权衡，以及在住宅代理网络和激进的 AI 驱动抓取时代，IP 封禁和 robots.txt 等传统工具的局限性。

工作量证明的角色与经济性

  • PoW 被描述为一种经济节流阀：不是为了消除抓取，而是让滥用流量变得过于昂贵。
  • 有些人认为这些计算周期是浪费的，尤其是在气候担忧之下；也有人说，如果它能遏制类似 denial‑of‑wallet 的抓取，这个成本就是值得的。
  • 争论焦点在于内存硬函数（argon2id）是否真的能限制资金充足的 AI 抓取器，还是主要伤害小型“skiddy”机器人和普通用户。

对用户、设备和隐私的影响

  • 用户反馈称，移动设备在解决挑战时会发热，或者需要明显时间；桌面和 VPS 则能很快处理。
  • 配置很重要：低难度和 Cookie 复用可以让 PoW 在正常浏览中几乎不可见，但激进设置会让老旧或低端设备失效。
  • 出于隐私原因而禁用 JS、WASM 或 cookies 的人，常常发现 Anubis 无法使用；也有人认为，破坏“正常”的网页假设就会带来这种摩擦。
  • 有人担心，service worker 预计算和 IP 绑定会与隐私工具、动态 IP 和网络变化发生冲突。

对机器人和抓取器的效果

  • 支持者说，真实部署显示滥用机器人流量大幅减少，尤其是那些使用轮换 IP、猛攻搜索或 git Web UI 的抓取器。
  • 怀疑者认为，每个挑战的计算成本对真正的抓取器来说微不足道，而且它们可以适应（复用会话、改变策略）。
  • PoW 被视为纵深防御中的一层，在 IP 封禁因庞大的代理网络而失效时，它可以补充传统技术。

robots.txt、“好机器人”和静态内容

  • 有人问为什么不依赖 robots.txt；另一些人回应说，只有“好”机器人才会遵守它，因此限制性策略几乎没有保护作用。
  • 看似静态的页面仍可能带来真实的 CPU 和带宽成本，而且由于政策原因，许多部署无法使用外部 CDN。
  • 人们在想阻止“不诚实”的机器人、又不想过度伤害合法的归档或研究爬虫之间存在张力。

实现细节：WASM、JS 和 Rust 工具链

  • Anubis 使用高度优化的 WASM，并在不支持 WASM 的环境中提供 wasm-to-JS 回退方案，为兼容旧版 Chrome、Firefox ESR、智能电视等投入了大量精力。
  • 已经存在可通过 WASM 或 WebGPU 加速求解的扩展；argon2 本身也可以被 GPU 加速，这让“GPU-proof”之类的说法变得复杂。
  • 讨论还涉及 Rust 工具链在 wasm32-unknown-unknown、MVP 与非 MVP 特性，以及 build-std 方面的问题；有人建议采用如 wasm32v1-none 之类的替代目标。

“有用”或可变现工作的想法

  • 多位评论者建议用以下方式替代纯浪费：
    • 微支付或代币系统，让网站从 PoW 中获利。
    • 在网站之间交换 PoW 积分（半开玩笑地说是“重造 crypto”）。
    • 将 PoW 转向社会有用的任务（例如科学计算、分布式 fuzzing），不过任务粒度让这很难实现。