监听器认证
监听器（NelfeMemoryListener）是在内存中测量分数的闭源组件。它的可信度并非来自（保密的）
代码，而是来自其认证-如同计量仪器的闭源固件（技术类比，而非监管主张）。
术语（精确）
- NelfePlay 认证：每个官方构建都由发行者签名并背书。
- 已审计：仅当独立的外部审计确实发生时才使用。
- 已认证：保留给真正的正式认证计划（获授权机构）。在这样的计划存在之前我们不使用它。
构建的公开信息表
每个监听器版本发布：
{
"listener_build": "4.2.0",
"sha256": "…",
"publisher_signature": "…",
"released_at": "…",
"supported_protocol": 1,
"homologation_suite": "listener-tests-2026.1",
"audit_report": "…",
"status": "authorized"
}
allowed_listener_sha256）。护照携带监听器的哈希
之前 / 加载 / 之后-由开放组件独立测量（而非监听器自身，以避免自我背书）。
发布即认证
在平台知道之前，构建信息表毫无用处。当认证还是手工动作时，监听器每出一个新版本，整个机群就 失效一次，直到有人想起去登记为止：越是保持更新的机台，越会因为「未知构建」而被拒绝成绩， 这与本意恰恰相反。
因此清单文件与二进制一起发布并带有签名，由平台主动去读取：
{
"built_at": "2026-09-05T21:13:53Z",
"sha256": "1bd08a9d5d9aaac16692eab6f52278b3f072a143c20436271883d28025034e75",
"signature": "MEUCIQD5QTn8FMBbiLBZKXLL9P_-1_f6cQAtiLFv9vphxYmqtQIgGdTPvOkMoF5EbwCiSCsBNu_IMJY94d6vGr_Fl60WPRI",
"subject": "CN=nelfeTech",
"version": "0.334.0.0"
}
签名是对规范化正文（RFC 8785）所做的 ECDSA P-256 / SHA-256，以 base64url 传输。平台使用 固化在自身代码中的公钥来验证，绝不使用清单自带的密钥：没有这个锚点，任何人只要发布一个 格式正确的文件，就能让自己的二进制通过认证。
这一设计有三点值得说明：
- 清单是被拉取的，不是被推送的。 平台定期读取一个公开 URL。任何人都可以读取同一个文件并 重做同样的验证，因此认证从外部即可观察。
- 构建不会自行消失。 自动化只做添加，不做移除。
- 撤销仍然是一个刻意的动作（见下文），并且优先于发布：已撤下的构建不会因为文件仍在线上 而被重新认证。
由于这个文件是整个机群的锚点，它必须由签名链本身生成，绝不能手写：一份声称的版本与已签名 二进制不一致的清单，会认证一个并不存在的哈希，所有保持更新的机台将同时失效。
认证套件（黑盒，公开）
可以在不泄露算法的前提下证明行为：
ROM X + 场景 Y → 屏幕上的分数是 12,500 → 官方监听器必须产出 12,500。
结果公开；内存地址与读取方式不公开。
撤销
某个构建有缺陷？我们对新对局撤销该构建（status: revoked），同时不使旧分数无法解读：它们
仍可用历史配置与构建验证。
为闭源组件增信
签名二进制 · 每个构建的公开 SHA-256 · NDA 下的外部审计并附无代码的公开报告 · 公开 SBOM · 可选的源码托管 · 公开的行为测试 · 撤销政策 · 版本历史 · 漏洞披露计划。
再谈边界
以上都不能在数学上证明监听器读取了正确地址。它们确立的是：一个已认证、未修改的构建 绑定到正确进程，并应用了公开规则。对测量的信任建立在认证之上-这是可辩护的基础，与 现实世界的计量仪器相同。