工程不幸路径：理解 BitVM2 架构 第一部分：安全性存在于争议路径中 一个 Bitcoin L2 的生死取决于它的不幸路径。 在 Bitcoin 上，你不能“在链上运行验证器然后继续”。你得到的是一个受限的执行环境、预签名的交易图和定义每个参与方何时可以行动的时间锁。 BitVM2 是 Bitcoin 的一种乐观执行模式：在链外执行，然后通过基于预签名交易的链上争议协议使正确性可执行。 这导致了一个简单的工程规则：如果争议成本高或可能因费用而被延迟，安全模型就根本无法工作。 基于 BitVM 的系统通过让操作员在链外执行，然后给予任何人能力在链上挑战并迫使协议进入争议路径，基于 1-of-n 诚实假设（至少有一个诚实的挑战者来验证有效性；至少有一个诚实的操作员来保证活跃性）。 这个争议路径就是机制。预签名交易和一次性签名（挑战窗口、响应截止日期、最终确定）是桥梁及其出口的“运行时”。 因此，当我们谈论在 BitVM2 上构建时，北极星不是像“无信任”这样的营销术语。 北极星是： • 争议的执行成本足够低， • 链上下文足够客观，以防止“证明错误状态”退出， • 在真实费用条件下持续推进的交易流。 本系列将逐步解析我们如何在 GOAT BitVM2 设计中应对这些约束，一次一个部分。 第二部分即将到来：在 Bitcoin 上部署生产就绪的 zkRollup 的实际障碍。