用 Proof of Work 击退 Bot 的机制：守护提问箱的计算谜题技术

Bot 垃圾信息攻击的实际情况

匿名提问服务，是 Bot 的绝佳目标。不用注册账号就能发帖，匿名性又有保证，所以对攻击者来说风险极低。只要写个自动化脚本，1 秒钟就能发送几十条不正当的帖子。

Bot 垃圾信息攻击的目的多种多样。有针对特定用户的骚扰（用大量攻击性留言塞满管理页面）、广告垃圾信息（大量发送含有通往交友网站或诈骗网站链接的提问）、妨碍服务（给服务器施加过大负荷，让服务停止）等。

作为过去广泛使用的 Bot 对策，有 CAPTCHA（图片验证）。这种机制会让人辨认扭曲的文字，或要求“选出所有包含红绿灯的图片”。但是，CAPTCHA 有严重损害用户体验这一致命缺点。如果每次想发提问都被要求做图片验证，很多用户会嫌麻烦而离开。CAPTCHA 会破坏匿名提问服务“可以轻松发提问”的价值。

Proof of Work 这一思路的转变

Proof of Work（PoW，工作量证明）用和 CAPTCHA 完全不同的方法排除 Bot。它不是给人布置任务，而是给电脑布置计算任务。

机制很简单。发送提问时，浏览器（客户端）会从服务器收到一个叫“挑战”的随机字符串。浏览器针对这个挑战进行计算，寻找一个满足特定条件、叫作“随机数（nonce）”的值。具体来说，就是穷举搜索这样一个随机数：把挑战和随机数拼接起来的字符串，其 SHA-256 哈希值开头带有一定数量的零比特。

找到满足条件的随机数后，就和提问的正文一起发送到服务器。服务器端只用 1 次哈希计算就能完成对随机数的验证（验证只需一瞬间）。如果不满足条件，这条帖子就会被拒绝。

这个机制的核心，在于“计算的不对称性”。要找到正确的随机数需要大量的尝试，但验证找到的随机数是否正确只需要 1 次计算。这种不对称性，大幅提高了 Bot 的成本。

为什么能不影响人类，只排除 Bot

PoW 的难度（开头零比特的数量），通常设定在普通智能手机 0.5-2 秒左右就能解开的水平。输入提问、按下发送按钮后，计算在后台运行，一完成就发送到服务器。用户感受到的延迟几乎为零，即使有，也只是“发送中……”的提示显示 1-2 秒的程度。

人发 1 条提问所花的时间，算上构思和输入提问的时间，最少也要 30 秒到几分钟。在这期间跑 0.5-2 秒的计算，对体验几乎没有影响。

另一方面，如果 Bot 想在 1 秒内发送 100 条提问，就需要 100 条份的 PoW 计算。假设每条要花 1 秒的计算成本，发送 100 条就要 100 秒。Bot 的发帖速度降到 100 分之 1，垃圾信息的成本效益会显著变差。攻击者投入更高性能的硬件，计算速度会提高，但其成本（电费、服务器费用）会与攻击规模成比例地增加。

也就是说，PoW 是一种把“对人来说可以忽略的成本”转换成“对 Bot 来说无法忽略的成本”的机制。可以说，这是一种利用人和 Bot 行为模式差异（人是低频率，Bot 是高频率）的优雅防御策略。

Proof of Work 的历史和应用

PoW 的概念，起源于 1993 年辛西娅·德沃克（Cynthia Dwork）和莫尼·瑙尔（Moni Naor）作为垃圾邮件对策提出的方案。其想法是：在发送邮件时附加计算成本，让大量发送在经济上得不偿失。

让这个概念广为人知的，是 2008 年中本聪（Satoshi Nakamoto）发表的 Bitcoin。在 Bitcoin 中，PoW 被用作区块链的共识机制。矿工进行海量计算来生成区块，这种计算成本保障了网络的安全性。不过，Bitcoin 的 PoW 和提问箱的 PoW，在目的和规模上都完全不同。Bitcoin 要求几分钟到几十分钟的计算，而提问箱只需要 1-2 秒。

提问箱中的 PoW，与其说接近 Bitcoin，不如说更接近最初的垃圾邮件对策的思路。“通过提高大量发送的成本，让垃圾信息在经济上得不偿失”这一原理，在邮件和提问箱中是一样的。

亚当·巴克（Adam Back）在 1997 年提出的 Hashcash，也是属于同一谱系的技术，它通过在邮件的头部附上 PoW 的证明来排除垃圾邮件。提问箱的 PoW 实现，可以说是把这种 Hashcash 的思路应用到了 Web 应用程序上。

仅靠 PoW 防不住的攻击和多层防御

PoW 是强有力的 Bot 对策，但单独使用并不能防住所有攻击。

第一，它对人手动进行的骚扰没有效果。PoW 是防止“大量自动发帖”的机制，防不住人一条一条手动发送不当提问的行为。应对这类行为，是过滤功能和用提问者 ID 识别等其他机制的职责。

第二，使用高性能的 GPU，可以加快 PoW 的计算。普通智能手机要花 1 秒的计算，用最新的 GPU 可能几毫秒就能完成。对此，可以组合使用对同一发送来源的发帖频率设置上限的速率限制，这样无论计算速度多快，都能压低发帖频率。

第三，同时使用蜜罐字段（人看不见、但 Bot 会自动填写的假输入栏）检测 Bot 的结构也是常规做法。即使突破了 PoW，只要掉进蜜罐，帖子就会被拒绝。

安全的基本原则是“多层防御（Defense in Depth）”。不依赖单一的措施，而是叠加多种措施，即使 1 层被突破，也能在下一层挡住。叠加 PoW、速率限制、蜜罐和过滤的结构，作为守护提问箱的防线被广泛使用。