作者：jolestar，Rooch Network创始人 来源：X，@jolestar
Bitcoin 的可编程性扩展方案可分为两个大的方向：链上扩展和链外扩展。
这个方向一直受限于 Bitcoin 脚本的编程性。Bitvm 这样的方案尝试通过 Taproot 树来模拟电路，实现图灵完备的计算。但 Bitcoin L1 更大的限制在于 Bitcoin 脚本是无状态的。无论计算多复杂，对状态的所有权都只能表达为时间锁、哈希锁、私钥锁，无法表达出“状态锁”，而这是实现复杂应用的前提。
假设把 Bitcoin 的脚本替换成一个图灵完备的虚拟机，其他条件不变，请设计出一个计数器，任何用户发送交易都可以让它加一，这时就会理解这个限制。
这个计数器场景有什么用呢？在典型的打铭文场景下，需要一个计数器来计算资产的总量。如果链上能表达计数器，就不会有打废铭文的情况了。
用通俗的比喻来解释“状态锁”：如果把 Bitcoin 脚本理解成一个对 UTXO 的智能锁，这个智能锁可以通过密码解锁，可以通过指纹解锁，但它内部不能记录脚本执行后的结果，所以无法实现解锁几次后就不能再解锁的功能。
所以链上扩展如果能配合一次性签名设计出仲裁和挑战机制，就已经非常有突破性了。
既然链上扩展有瓶颈，那只能寻求链外扩展。为了避免 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 上写了数据，就可以和其他方案进行结合，优势互补，最终会涌现出不一样的生态。
