Bitcoin 可编程性的链上与链外扩展

Bitcoin 的可编程性扩展，长期看其实可以分成两条路线：链上扩展 和 链外扩展。

链上扩展

链上扩展一直受限于 Bitcoin 脚本的编程性。BitVM 这样的方案，尝试通过 Taproot 树去模拟电路，实现更强的计算能力。但 Bitcoin L1 更大的限制其实不只是“算得够不够复杂”，而是它的脚本本身是无状态的。

也就是说，无论计算多复杂，对状态所有权的表达最后还是只能退回到这几种形式：

它并不能表达“状态锁”，而这恰恰是复杂应用成立的前提。

可以做一个简单假设：如果把 Bitcoin 的脚本替换成一个图灵完备的虚拟机，其他条件都不变，你能不能在链上设计出一个任何人都能调用、每次调用就加一的计数器？只要认真推这个问题，就能很快理解 Bitcoin L1 当前的限制。

这个限制其实并不抽象。比如铭文场景，本质上就需要一个计数器来计算资产总量。如果链上原生能表达这种计数器状态，就不会有“打废铭文”这类问题。

换个更直观的比喻：如果把 Bitcoin 脚本理解成一个装在 UTXO 上的智能锁，这个锁可以通过密码解锁，也可以通过指纹解锁，但它没法把“前一次解锁后的结果”记在自己内部，所以也就很难表达“解锁三次之后再也不能开”这种状态型逻辑。

所以，从链上路线看，如果能在现有脚本能力之上，配合一次性签名等机制设计出仲裁和挑战机制，就已经是很大的突破了。

既然链上扩展有明显瓶颈，那就只能寻求链外扩展。为了避免 L2、侧链、on-chain、off-chain 这些词的歧义，这里统一叫 链外扩展。

链外扩展主要要在三件事之间做权衡：

比如 AVM 的方案里，智能合约能力更贴近 Bitcoin Script，并尝试通过增加新的 OP code 来扩展状态访问，同时继续把交易写回 Bitcoin L1。而很多 EVM 侧链方案的做法则是：

Rooch 走的是另一条路线：

智能合约以及虚拟机：Move 和 MoveVM。
读写 Bitcoin 状态：在 L2 中执行 Bitcoin L1 的所有交易，把 Bitcoin 状态（UTXO、Inscription 等）表达成 Move Object。
可用性：L2 交易不再写回 L1，而是依赖第三方 DA，只把 L2 状态树的根定期写回 Bitcoin。

这样做的好处很明确：

智能合约可以直接读取 Bitcoin 上的各种状态，包括 UTXO、Inscription、交易、区块头。
L2 状态可以通过 Object 的动态字段，绑定到 Bitcoin 状态上，实现一种原子绑定。比如：L1 状态表达地块，L2 上盖房子；L1 状态表达域名，L2 上维护解析记录。
L2 智能合约还可以进一步生成 Bitcoin Script 和 Bitcoin 交易，为交易本身提供更强的可编程性。

因为 Rooch 的方案里，L2 会包含所有 L1 交易，所以它不能再像普通 Rollup 那样把交易回写到 L1，只需要把状态树根定期写回 Bitcoin 即可。这样反而让 L2 交易成本有机会降下来，为更复杂的应用提供空间。

Bitcoin 生态期待可编程性扩展很久了，也已经出现了许多不同路线的尝试。Bitcoin L1 的可编程性确实有限，但它有一个独特优势：所有状态仍然是全局共享的。这意味着，只要某种扩展方案在 Bitcoin 上写入了数据，它理论上就可以和其他方案互相组合，而不是彼此完全割裂。

所以，真正值得持续观察的，不只是“哪条路线更强”，而是这些路线最后能不能在 Bitcoin 这个全局状态底座上形成组合关系，逐步长出新的应用生态。