Instrumentation 质询

Instrumentation（浏览器环境检测）质询是 Cap 的第二层验证，与核心的工作量证明系统一起静默运行，并已内置于 Cap Standalone。

它们在每次请求时生成一段独一无二的 JavaScript 程序，在访问者的浏览器中执行。执行结果由服务端校验，Cap 借此在接受令牌前确认对方处于真实的浏览器环境。

工作原理

签发质询时，服务端会生成一个自包含的 JavaScript 包，先运行若干浏览器 API 探测，再执行一条主计算链：多个整数变量以随机种子值初始化，然后经过一系列随机化操作不断变换，包括按位 AND/OR/XOR/NAND、原型链技巧，以及基于 DOM 的运算（向页面追加一棵元素树，沿树回溯累加数值，最后把树移除）。

服务端会并行跟踪每一步操作的预期结果，因此它知道最终四个值必须是什么。

所有这些检查都在一个 iframe 内运行，并通过 postMessage 把答案发回父页面。

为什么要用 DOM 操作

纯算术运算在非浏览器环境中只需直接运行这段 JavaScript 就能复现。DOM 操作做不到，至少无法低成本地做到。构建真实的元素树、通过浏览器排版引擎读取数值、再把它们拆除，这些会触及浏览器中那些非浏览器运行时常常只做桩实现、实现得不正确、或出于性能考虑干脆跳过的部分。质询因此很难在真实渲染引擎之外被重放。

Instrumentation 质询通常还会把这些与一组预设检查混合使用。

自动化浏览器检测

Instrumentation 质询还可以选择性地尝试拦截自动化 webdriver。虽然我们为此做了大量检查，但它们并非万无一失。即使是 Turnstile 这样的商业闭源 CAPTCHA，攻击者也能通过打过补丁的隐身浏览器绕过。

与工作量证明的关系

Instrumentation 质询与工作量证明是互补的，而非冗余。工作量证明证明的是付出：客户端必须消耗 CPU 周期来寻找哈希。Instrumentation 证明的是环境：计算发生在浏览器里，而不是脚本里。二者结合，在两个独立维度上抬高了滥用成本。面对有决心的攻击者，单独任何一个都不够，但要同时攻破两者就难得多。

Instrumentation 并非万无一失。虽然 YouTube 和 Twitter 等平台已在超大规模上部署了类似的质询，但我不建议用它替代工作量证明。在没有 PoW 的情况下，攻击者用真实浏览器就能低成本地批量通过这些质询。