早上在 Babylon 治理论坛上刷到一条讨论：有人提议把 unbonding 期从 7 天缩短到 3 天。
回帖里最有价值的信息不是"赞成还是反对"——是一段技术 explainer 解释了 7 天的来源：unbonding 期必须 ≥ 挑战窗口期。挑战窗口是给 vigilante 提交 slashing 证据的时间。如果 unbonding 更短，FP 在挑战期内被 slash、但 BTC 已经提走了——slashing 变成一纸空文。
7 天不是拍脑袋定的。它来自一个密码学约束的连锁反应：EOTS 证据的提交和验证时间决定挑战窗口长度，挑战窗口长度决定 unbonding 期下限。
所以讨论缩短 unbonding，实际是在讨论能不能缩短挑战窗口。缩短挑战窗口意味着 vigilante 的响应窗口变窄——对监控网络的覆盖率和速度要求更高。
那条提案最终没有进入投票。但让我停下来的不是提案本身——是"一个看起来像产品体验的参数，链式地绑着协议安全层的核心设计"。
你在 UI 上看到的每个数字，后面可能都拴着一根看不见的绳子。
@BabylonLabs_io $BABY #baby
回帖里最有价值的信息不是"赞成还是反对"——是一段技术 explainer 解释了 7 天的来源：unbonding 期必须 ≥ 挑战窗口期。挑战窗口是给 vigilante 提交 slashing 证据的时间。如果 unbonding 更短，FP 在挑战期内被 slash、但 BTC 已经提走了——slashing 变成一纸空文。
7 天不是拍脑袋定的。它来自一个密码学约束的连锁反应：EOTS 证据的提交和验证时间决定挑战窗口长度，挑战窗口长度决定 unbonding 期下限。
所以讨论缩短 unbonding，实际是在讨论能不能缩短挑战窗口。缩短挑战窗口意味着 vigilante 的响应窗口变窄——对监控网络的覆盖率和速度要求更高。
那条提案最终没有进入投票。但让我停下来的不是提案本身——是"一个看起来像产品体验的参数，链式地绑着协议安全层的核心设计"。
你在 UI 上看到的每个数字，后面可能都拴着一根看不见的绳子。
@BabylonLabs_io $BABY #baby