作者：jolestar，Rooch Network创始人 来源：X，@jolestar
Bitcoin 的可编程性扩展方案可分为两个大的方向：链上扩展和链外扩展。
Bitcoin 链上扩展
这个方向一直受限于 Bitcoin 脚本的编程性。Bitvm 这样的方案尝试通过 Taproot 树来模拟电路，实现图灵完备的计算。但 Bitcoin L1 更大的限制在于 Bitcoin 脚本是无状态的。无论计算多复杂，对状态的所有权都只能表达为时间锁、哈希锁、私钥锁，无法表达出“状态锁”，而这是实现复杂应用的前提。
假设把 Bitcoin 的脚本替换成一个图灵完备的虚拟机，其他条件不变，请设计出一个计数器，任何用户发送交易都可以让它加一，这时就会理解这个限制。
这个计数器场景有什么用呢？在典型的打铭文场景下，需要一个计数器来计算资产的总量。如果链上能表达计数器，就不会有打废铭文的情况了。
用通俗的比喻来解释“状态锁”：如果把 Bitcoin 脚本理解成一个对 UTXO 的智能锁，这个智能锁可以通过密码解锁，可以通过指纹解锁，但它内部不能记录脚本执行后的结果，所以无法实现解锁几次后就不能再解锁的功能。
所以链上扩展如果能配合一次性签名设计出仲裁和挑战机制，就已经非常有突破性了。
Bitcoin 链外扩展
既然链上扩展有瓶颈，那只能寻求链外扩展。为了避免 L2/侧链，on-chain/off-chain 的歧义，统称为链外扩展。
链外扩展需要在几个选项之间取舍：
-
用什么智能合约以及虚拟机。
-
智能合约里如何读写 Bitcoin 上的状态（数据以及资产）。
-
交易写到哪里去，如何保证可用性。
例如，在 AVM 的方案里：
-
选 Bitcoin Script。
-
通过增加新的 OP code 来实现。
-
交易写回 Bitcoin L1。
而 EVM 侧链方案一般是：
-
用 EVM。
-
通过桥跨资产过去。
-
用独立的共识网保证。
文章提到了 RoochNetwork，详细介绍其方案如下：
-
智能合约以及虚拟机：用 Move 以及 MoveVM。
-
智能合约里如何读写 Bitcoin 上的状态：在 L2 执行 Bitcoin L1 的所有交易，将 Bitcoin 的状态（UTXO/Inscription 等）表达为 Move Object。
这样有几个好处：
-
智能合约中可以读取到所有 Bitcoin 上的状态（UTXO/Inscription 等），还包括交易和区块头。
-
L2 的状态可以通过 Object 的动态字段，绑定到 Bitcoin 的状态上（原子绑定），所有权归 Bitcoin 资产的所有者。举几个典型场景：L1 的状态表达地块，L2 上盖房子；L1 的状态表达域名，解析记录在 L2。
-
通过在 L2 的智能合约中生成 Bitcoin Script 以及 Bitcoin 交易，给交易提供可编程性。
如何保证可用性
RoochNetwork 的交易可用性依赖第三方 DA。因为 Rooch 的方案中，L2 会包含所有 L1 的交易，所以不能再写回 L1，只需要把 L2 状态树的根定期写回 Bitcoin 即可。这样也保证 L2 的交易成本足够低，可以给更复杂的应用提供基础设施。
总结
Bitcoin 生态期待可编程性的扩展方案很久，有各种路线和方案的尝试。Bitcoin L1 的可编程性有限，但它的优势是所有状态都是全局的，不存在合约间的割裂。所以无论任何扩展方案，只要该方案在 Bitcoin 上写了数据，就可以和其他方案进行结合，优势互补，最终会涌现出不一样的生态。