比特币的脚本故意不做复杂计算，那么想在比特币上验证一笔外部计算——比如核对一个跨链桥转来的证明——该靠什么？BitVM 给出的答案不是给比特币加新操作码，而是换一种信任结构：把计算拆成大量微小片段放在链下，参与者先在链上锁住各自对每个片段的承诺；如果有人主张的结果有问题，任何人只要能指出”哪一个片段算错了”，就能用一条链上交易把这条主张推翻。它把”重放整个计算”换成”只验一处错”，代价是信任模型从共识保护换成了设置阶段与活性假设。这条路线后来出现了几种变体，差异集中在谁能发起挑战、需要几个诚实方。
共同骨架：承诺、指控、一次性签名
这套范式里链上出现的只有承诺和裁决用的资金路径，计算本身在链下。参与者在设置阶段对程序逐段的输入输出承诺上链；主张结果的一方（在 BitVM2 的表述里叫 operator）按顺序公布中间状态，每一段配一组一次性签名。挑战者本地重算，发现某段公布的状态与承诺对不上时，把两组冲突的签名亮出来——一次性签名的性质决定了同时签两个不同值就等于把私钥暴露，这本身就是可被链上验证的作恶证据。规范化的表述是：如果主张者对任一中间状态 equivocates，所有人都能拿这些冲突的 Lamport 签名当欺诈证明。
裁决路径的形态是”要么证明他错、要么等超时”。挑战者如果能指出错误，就用那条交易拿走应当被保护的资金；如果没人推翻，脚本超时后诚实路径放行。BitVM2 把这条最坏路径的交互压缩到至多两轮，且让任何一个跑比特币全节点的人都能发起挑战，而不是仅限设置名单内的成员。
与二层欺诈证明的关键差别
以太坊乐观汇总也讲欺诈证明，但结构完全不同：那里争议解决靠的是一层合约里可重放的执行环境和一笔笔二分式的博弈状态机，验证所需的数据由汇总自身发布在一层或数据层上，诚实假设接近”全网只需一个诚实验证者”。BitVM 家族在两端都不同。一端是”重放”的方式——它不打算在比特币脚本里跑完整程序，而是把程序（例如一个 SNARK 验证器）拆成许多能塞进单笔交易的子程序，谁被质疑谁就在链上执行对应子程序；另一端是信任模型——它明说设置阶段带一个 1-of-n 诚实假设，即设置的 n 方中只要有一个诚实且不丢失其承诺数据，主张者就无法蒙混过关。这两端一起解释了为什么它能把状态大小和轮次压下来，也解释了为什么批评集中在设置环节。
三种风险边界
第一是设置本身。1-of-n 是”只要有一个诚实”而不是”所有人诚实”，它不覆盖更糟的情形：全部参与者串通时能做什么。项目方对运行期最坏情形的说明值得原样理解——即便所有运营者都不诚实，他们也烧不掉存款之外的资产，最坏是烧掉押金，而不是把别人的钱转走。这与”绝对安全”是两码事，评估时应当把它当作一种有前提的降级上限。
第二是活性与时间。挑战窗口靠超时机制推进，主张者可以拖延；能否在窗口内真的发现问题，取决于有没有人持续监控并愿意付出链上成本。挑战不是免费动作，指错方向的那一笔同样有代价，因此设计上需要配套激励，而激励安排通常写在具体桥的实现里而不是范式本身。
第三是数据可用性。BitVM 验证的是”这段计算对不对”，不负责”这些数据是不是全部公开了”。如果主张所需的输入没有被任何人拿到，挑战者无从重算。范式文档不会替你解决这个缺口，只能从具体项目的数据发布安排里核对。
怎么看待这些变体
从原始 BitVM 的双方设定，到 BitVM2 面向公众的无许可挑战，变化的方向很一致：把”谁能推翻作弊”从名单内放到名单外，把交互轮次和链上交易数压下来。变体之外还有各家在比特币上搭 zk 汇总的桥接设计，它们在承诺公开输入、把押金搬到二层、提现路径上各有增补，这些属于具体实现，不是范式保证。核对这类项目时，最值得读的是它的设置仪式记录、挑战者激励与数据发布条款三项——三者缺一个，风险叙述就会明显偏乐观。
本文描述范式与公开文档中的机制，不构成任何投资建议，也不构成对项目安全性的保证。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。