CometBFT 证据系统如何把双签与轻客户端攻击写进链上？

共识安全与证据系统的分工

在 CometBFT 这类按轮次投票的共识里（CometBFT 是原 Tendermint Core 共识引擎的延续实现，被众多 Cosmos 生态链使用），协议本身有一个明确的前提：只要作恶验证者的合计投票权少于三分之一，状态机复制就是安全的。证据（Evidence）系统处理的是另一侧的问题——当合计投票权达到甚至超过三分之一的验证者联合作恶时，链怎么发现、传播并落地处置。官方规范把它的职责限定得很清楚：负责检测拜占庭行为、在全网 gossip、把它写进区块，并告知运行在 CometBFT 之上的应用；至于罚没多少、要不要把验证者关进监狱（jail），是应用层模块的决定，共识层不越权。

双签：最基础的罪状

equivocation，即”双重签名”是最典型的拜占庭行为：同一个验证者在同一个高度、同一个轮次、同一个步骤里签了两份内容不同的投票——比如在同一轮先投给区块 A 又投给区块 B。这类证据的形状非常直白——DuplicateVoteEvidence 结构里就装着 VoteA 和 VoteB 两份原始投票，任何人拿两份签名一对就能定罪。检测也不复杂：投票本来就在全网广播，节点只要从同一个 peer 手里收到两份冲突投票，就把它们拼成证据开始转发。规范要求节点验证证据后持续向所有 peer 广播，大约每十秒重发一次，直到证据上链或过期。

轻客户端攻击与”疯子攻击”

第二类证据针对轻客户端：三分之一以上的验证者可以联合签一份轻客户端会认为合法的替代区块（light block），也就是给不同观察者看不同的链。规范里的形状是 LightClientAttackEvidence，包含冲突区块 ConflictingBlock 和公共高度 CommonHeight。检测依赖轻客户端同时向多个节点求证：只要有一个诚实节点交出挑战区块，客户端就能把”伪造的轻区块”发回网络。规范还把攻击细分成几类：同类冲突是双签型；验证者集合对不上是另一种；还有一种被称作 forward lunatic attack——作恶者伪造一个未来高度的区块，节点只需拿自己已知的更新区块时间戳一比，就能识破这种时间不一致。

过期窗口：证据必须赶在解绑之前

证据不是永久有效的。EvidenceParams 用 MaxAgeNumBlocks 和 MaxAgeDuration 两个参数划定有效期：当前高度差与时间差都越界，证据就被当作过期忽略。规范特别强调一条实践约束：在质押型链上，证据有效期应当短于解绑期（unbonding period），否则作恶者已经提现离场，链上处罚落空。同时证据具有唯一性要求——同一份罪状只应被提交上链一次。区块打包时证据优先于普通交易：一个区块先装满证据，剩余空间才给交易。

谁执行惩罚，以及能力的边界

CometBFT 把证据提交上链后，惩罚由应用层落地。在 Cosmos SDK 生态里，这通常由 x/slashing 类模块承担：确认签名者身份、按链上参数扣减质押、把验证者置为入狱状态；具体比例与时长是各链自己的参数，需要查该链文档。规范的职责表里还有一条常被忽略的细节：证据系统只管”报告罪行”，连”是否确有其事”的最终裁决都交给验证函数加应用逻辑的组合——共识层不维护独立的罪名清单。还要说清一个容易被忽略的边界：规范明确承认，如果三分之一以上的投票权持续作恶，证据本身也可能被这些力量审查掉——它们可以选择不把证据包进区块，或者干脆只在自己的分区里传播。所以官方把证据系统描述为尽力而为（best effort）的附加安全，而不是无条件保证：它把”攻击必然悄悄成功”改成”攻击大概率留下公开罪证”，但不能承诺一定定罪。对普通观察者来说，这套机制最常见的可见痕迹，就是区块浏览器上某个验证者因同一高度双签被记录、随状态变化被停止奖励的事件本身；观察这些公开记录时，以链上交易与该链文档写明的参数为准，而不是依赖第三方仪表盘的历史结论。