作者: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 上写了数据,就可以和其他方案进行结合,优势互补,最终会涌现出不一样的生态。
来源:金色财经