Fuzz、Property、Differential Test 与安全事件响应¶
要点卡¶
30 秒回答
安全测试围绕不变量分层：fuzz 探索输入，property/stateful test 验证大量输入和操作序列， differential test 比较实现前先定义合法差异与 oracle，fault injection 验证超时、分区、 崩溃和恢复。任何一层通过都不等于无漏洞；还要把检测、精确遏制、可信证据恢复和改进做成 可演练 runbook。当前 NIST SP 800-61r3 已把事件响应融入 CSF 2.0，而不是只背旧版四阶段。
3 分钟展开
- 先从威胁模型提取资金守恒、request-to-intent 不变义、旧 leader 不可签、finalized 历史不可静默改写等 oracle。
- Differential 先 canonicalize 版本、fork height、字段和允许差异；两个实现一致也可能共享同一 bug。
- 故障矩阵覆盖“持久化后响应前断线”、unknown broadcast、WAL torn tail、reorg 和升级 decoder。
- 事故响应先定级和保全证据，再按 key/tenant/asset 精确停用、撤销身份、可信重建、shadow 放量和对账。
| 记忆槽 | 内容 |
|---|---|
| 三个不变量 | 测试先定义 oracle；一致不等于正确；恢复以可信证据和对账完成为准 |
| 手画图 | threat model → tests → fault injection → signals → runbook → exercise → improve |
| 项目落点 | 用 signer fence、交易生命周期、WAL replay 或四链 adapter 的实际测试证据，不虚构生产演练 |
| 一个取舍 | 越接近生产越真实也越危险；按 model/localnet/staging/shadow/受控 game day 逐级扩大 |
错误表达
- ❌ “fuzz 没崩就说明安全；两个 SDK 输出一致就是协议正确；事故先重启恢复流量。”
- ✅ “测试只能增加证据；事故先控制授权与资金风险、保全证据，再从可信状态恢复。”
自测追问：signer 已持久化签名但响应丢失时，故障注入应验证哪些状态和审计不变量？
10 分钟版（测试与响应闭环）¶
flowchart LR
Threat["威胁模型 / 不变量"] --> Tests["fuzz + property + differential"]
Tests --> Fault["fault injection / chaos"]
Fault --> Signals["可观测与检测规则"]
Signals --> Runbook["contain / eradicate / recover"]
Runbook --> Exercise["tabletop / game day"]
Exercise --> Learn["修复、门禁、风险模型更新"]
Learn --> Threat先定义 oracle¶
Differential test 不是“两个输出不一样就一定有 bug”。不同 client/provider 可能在 trace 字段、错误文本、排序和 pruning 能力上合法不同。比较前应规范化：
- 共识/协议字段必须一致的集合；
- client-specific 字段允许差异的集合；
- 数字、地址、事件顺序和缺失值的 canonicalization；
- 版本、fork height、tracer/config 与历史状态可用性；
- 若两个实现共享同一依赖或 spec 误解，它们一致也可能一起错，仍需第三方 oracle/golden vector。
高价值状态不变量¶
signed request ID -> exactly one intent digest；更高 epoch 后旧 owner 不能签。- 正常自动处理路径不得改写 canonical finalized watermark 及以下的历史；若发生严重 共识故障、客户端 bug 或社会协调恢复等超出正常假设的事件，应先冻结并进入人工 incident/fork 决策，以新证据保留 lineage，不能静默覆盖旧 canonical/orphan 记录。
- 提交超时和
not found不得直接触发新 nonce/sequence/blockhash 的重签。 - 每个 asset 的 ledger entries 平衡；修账只能新增 reversal/adjustment。
- 跨链 message identity 绑定双域、emitter、payload、nonce，replay record 不因完成而删除。
- 撮合成交量、订单剩余量、账户/手续费守恒，STP 不产生虚假成交。
这些 property 应在单线程模型、并发实现、WAL replay 和故障恢复后分别验证。
故障注入矩阵¶
| 注入点 | 预期安全行为 |
|---|---|
| signer 持久化后、响应前断线 | 同 request 返回原 receipt，不产生不同签名语义 |
| broadcast 超时 | 状态 UNKNOWN，查多个来源或重播同一 bytes |
| backfill/realtime 分歧 | 保留双份 evidence，按 hash lineage 判 canonical，不按高度覆盖 |
| RPC 返回成功/失败冲突 | manual hold + 原始证据，不多数票猜资金状态 |
| WAL 尾部 torn write | 截断未完整 frame；中间 checksum 损坏 fail closed |
| decoder 升级 | raw 不变，shadow decode 比较，projection 可按版本重建 |
事件响应：安全优先而非“尽快恢复流量”¶
NIST SP 800-61r3 强调 incident response 是整体风险管理的一部分。Web3 事件中先确认决策权和安全边界：
- 检测与定级：区分可用性事故、数据完整性、授权滥用、密钥材料泄露和链协议事件；保存时间线与原始证据。
- 遏制：按 key/asset/route/tenant 精确暂停，提升确认或限额；必要时全局停签。暂停本身也可能导致清算和用户损失，要预先定义权限。
- 根除：撤销 workload/human credentials、修复漏洞、轮换 key/策略、隔离 builder/provider；私钥泄露还要迁移链上权限/资产。
- 恢复：从可信 checkpoint/provenance 重建，shadow read、限流放量、连续对账；不能因 API 200 就宣布资金安全。
- 改进：更新 threat model、检测、门禁、runbook 和 owner；复盘聚焦系统条件，不停留在“操作失误”。
不可逆链上动作¶
链上交易通常不能从数据库删除。响应方案要提前包含：合约 pause/role rotation 是否存在、timelock 延迟、multisig/MPC quorum 是否可用、桥/issuer/custodian 的外部协调、资产迁移和用户沟通。紧急权限本身是高价值攻击面，必须限权、演练和监控。
生产场景¶
- 疑似 signer credential 泄露：立即 fence principal/epoch、限制 key policy、核对最近 intent-to-signature lineage；若 key material 可能泄露，执行链上迁移而非只换 API token。
- Indexer 投毒：停止基于受影响 projection 的入账/清算，从 raw canonical evidence 重建，比较独立节点。
- 供应链事件：按运行 digest 盘点，不按服务名猜；验证 provenance，替换 builder 信任根并重建。
- 深 reorg/链 halt：按链 runbook 调整 finality 和业务可用性，不能统一“多等 N 块”。
排查与工具¶
演练指标包括 MTTD、决策/遏制时间、受影响资金上限、证据完整率、恢复对账时间和 runbook deviation。不要以“告警触发了”作为演练成功的唯一标准。
架构取舍¶
故障注入生产流量的真实性最高但风险也高。可按 deterministic model → localnet/staging → shadow → 小范围生产 game day 逐级推进，每级声明未覆盖的假设。主网资产操作应有硬额度和人工止损边界。
深挖问答¶
- Fuzz 与 property test 区别？ → fuzz 是输入生成/探索机制；property 定义跨大量输入必须成立的语义，可组合使用。
- 两个 client 输出一致就正确吗？ → 不一定，可能共享 bug；需要 spec/golden model 和独立实现。
- 发现私钥疑似泄露先重启服务吗？ → 先遏制授权与资产风险、保全证据；重启可能破坏证据且不撤销 key。
- pause 越快越好吗？ → 需预定义风险分级；过度暂停也会造成清算、可用性和治理风险。
- 事故恢复完成标准？ → 控制已恢复、受影响范围清楚、状态从可信证据重建且资金/链/外部三方对账通过。
反模式与事故¶
- 只 fuzz 单个 parser，却从未生成状态序列或注入崩溃恢复。
- differential test 直接比较整段 JSON，合法字段差异导致大量噪声后被关闭。
- runbook 写“轮换密钥”，但没有链上角色/资产迁移、MPC participant 和审批步骤。
- 为快速恢复清空 replay/idempotency/slashing 数据。
- 继续把已被 r3 取代的 SP 800-61r2 四阶段当作当前完整框架。