UTXO 的独特性能否催生新的生态模式?(上篇)

6 月 10 日,RGB++ 协议作者、CELL Studio 创始人 Cipher,DotSwap 联合创始人 Lin,Shell Finance 联合创始人 Timxie,以及 TBC(Turingbitchain)的 CMO NIGO 做客 UTXO Stack 的推特 Space,畅聊 UTXO 模型能否催生比特币生态新模式。

UTXO Stack 是模块化的 BTC L2 一键发链平台,可以帮助项目开发者一键发行基于 UTXO 架构的比特币 L2,并且原生集成了 RGB++ 协议。在安全性上,UTXO Stack 通过质押比特币、CKB 以及比特币 L1 的资产来保证 L2 的安全。简单来讲,我们可以把 UTXO Stack 想象成比特币生态的 OP Stack + EigenLayer。

UTXO Stack 已经完成种子轮融资,由 ABCDE 和 SNZ Capital 共同领投,OKX Ventures、Waterdrip Capital、Matrixport、y2z Ventures、DRK Lab 和 Bitcoin Magazine 母公司 BTC Inc 风投部门 UTXO Management 等多家知名机构跟投。

以下是根据音频整理的重点内容:

1、UTXO 模型和账户模型在设计哲学、安全性、效率等方面,有什么本质的区别和优势?

Cipher:我觉得主要是设计哲学和效率有一些区别,安全性可能更多的还是看共识机制,和账户模型关系不大。

设计哲学上,UTXO 其实更偏验证,而不是偏计算。我们知道以太坊的账户模型,你去写程序或者发交易的时候,你并不知道这个交易结果,你发的是一个动作或者是一个函数调用,那至于这个调用的结果是什么,只有交易被打包成区块之后你才知道结果。

典型的例子是,假设你的账户里面只有 0.1 个 ETH,能不能发一笔往外转账 0.2 个 ETH 的交易?可以的,你发出去,但是这笔交易可能进交易池之后,它会被打包,然后返回错误,因为你没有这么多钱,但是你的 gas fee 还是会被扣掉。但是如果你发送的同时,刚好有人给你账户上转了一笔钱,使得你的账户余额超过 0.2 个 ETH,那你这笔交易就成功执行了,当然也要扣 gas fee。

但是对于 UTXO 模型而言,你这笔交易就发不出去,因为你账户钱不够,你凑不出来足够的 input。所以在 UTXO 模型下面不存在交易失败这种状态,它只存在交易成功或者发不出去这两种状态,即所谓的交易失败是验证不通过,也不会扣你的手续费。UTXO 更认为区块链就是个验证机器,而不是计算机器,而采用账户模型的以太坊曾经有一个外号叫世界计算机,它是要计算的,完全是不同的设计哲学。

效率方面两者也有非常大的区别。UTXO 明确地指出之前使用的是哪些状态,然后把它销毁掉,更新成新的状态。而以太坊在函数调用的时候,并不知道在调用之前它会访问哪些状态,所以它只能按最差情况处理,就是对所有的状态都不做预处理。因此,以太坊每一笔交易只能串行执行。普通的一台桌面电脑,它的 CPU 至少是六核 12 线程,但是对于标准的 EVM 来说,仍然是单线程去执行。而 UTXO 不同, UTXO 天然就是并行的,它的所有交易都是自动可以区分哪些交易是冲突的,甚至冲突的交易都不会发到交易池里面,因此 UTXO 区块链的效率明显高于账户模型。当然现在有一个叙事叫做并行 EVM,想用某种形式解决这个问题,但是从刚才的描述大家也能意识到这不可能从本质上解决。

Tim Xie:我很认同刚刚 Cipher 讲的 “比特币 UTXO 模型更偏验证,以太坊的账户模型更偏计算”。在 DeFi Summer 的时候,我们去做一些 swap,以太坊的 gas fee 会很高,虽然相比于比特币,以太坊的出块速度更快、区块更大、性能更好,但以太坊对于扩容的需求其实比比特币还要更高。为什么呢?原因在于以太坊是一个计算模型。我们玩 DeFi,支付的 gas fee,可能有 98% 都是花在计算上,在验证、传播和存储账户状态这部分的花费其实是非常少的。比特币是一个验证网络,它不做计算,所以我们在比特币二层上做 lending 或者 swap,同样的场景下,手续费反而比以太坊那边还要便宜。

第二个是并发。EVM 为什么是串行的,刚刚 Cipher 解释得非常清楚,UTXO 则可以做并发,这点在做业务上会带来什么差异点呢?在以太坊上做 lending,你需要先存款然后才能借款,因为业务逻辑是你要有抵押物,要先等抵押的这笔交易确认了,状态固定了,它才可以去计算你的抵押物净值和清算阈值,让你借款,这一切是串行的。而 UTXO 可以做并发,我们可以把所有的交易尽可能压缩在一起,这意味着可以把用户的存款交易和借款交易合并成一起,提高效率。

从我们的感受上来讲,在比特币上用 UTXO 模型做 DeFi,最后给用户带来的体验其实并没有人们想象中那么的差,虽然体验不如以太坊或者 Arbitrum 上的应用那么丝滑,但也不会太差,还是可以用的。

Lin:我做一个补充。现有的技术在不断地演进,我认为 UTXO 不是不做计算,它同样也是可以做计算的。比如大家最近热议的比特币操作码 OP_CAT, 如果启用,我们就可以在比特币的 UTXO 中保留状态。如果我们把各种比特币原生的限制都拿掉的话,我们可以在比特币的 UTXO 中去模拟无数个以太坊,每一个 UTXO 都可以是一个以太坊的状态,然后把数据和执行在这个状态当中进行延续,从而使这个状态一直往下推演下去,虽然这样不一定能做到完全的 EVM 兼容。

所以我认为比特币一样可以做计算,而且比特币的逻辑是你随时可以开新的线程,你随时可以分裂出一个新的 UTXO,新的 UTXO 和原来的 UTXO 完全切割开来,这是比特币 UTXO 在计算上的一个特点。

加入 OP_CAT 之后,将会带来很巧妙的一些应用场景。比如说,以太坊 ERC-20 代币会维护一个列表,可以知道哪些账户有多少钱,加入 OP_CAT 之后,在比特币上我们也可以做类似的事情,甚至可能比以太坊做得更好。

在 UTXO 当中,数据共享其实是一个很大的未知的空间。比如说 Covenants(限制条款),现在还需要一段时间的建设,等这个事情往前推进了以后,在不同的 UTXO 当中如何实现共享数据,在交易当中如何引用交易之外的数据等等,或许会有突破。

NIGO我一直认为以太坊把比特币的 UTXO 模型改成了账户模型,其实是典型的画蛇添足,而且把本来能够进行并发的系统变成了一个串联的系统。以太坊被很多人称为世界计算机,一个普通人的计算任务凭什么要让全球的矿工去计算,这个过程耗费巨大能量,而且成本很高,但并没有带来什么实质性的好处,反而耽误了整体的效率。以太坊转为 PoS 之后,更是让整个网络的矿工(节点)失去了进化动力。而中本聪设计的 UTXO 模型,天然适合高并发、高性能,我相信会有更多的 Web3 用户看到 UTXO 模型的潜力。

2、是 UTXO 模型导致比特币不具备智能合约能力吗?如果要在 UTXO 模型的基础上实现智能合约能力,一般通过什么机制来实现?

Cipher:肯定有很多种方法可以在 UTXO 模型的基础上实现智能合约能力,我介绍一下我最熟悉的 CKB 是如何实现的。

CKB 引入了 lock script,它和比特币的 lock script 是一致的,当这个 UTXO 被花费的时候,lock script 会自动执行,它会根据 witness 里面的数据来作为输入,以及当前的交易也会作为输入来执行。它跟比特币的 lock script 的区别是,它支持一个完整的图灵完备的虚拟机,而不是比特币那种非常有限的脚本环境,所以在解锁的这个阶段它是图灵完备的。

同时,CKB 又引入了 type script 字段,这个字段不论是输入还是输出它都会执行,它更多的是作为这个资产的类别,或者说同一个 type 就代表同一种资产这种逻辑来执行的。比如说,fungible token 交易前后总量保持不变,non-fungible token 交易前后这个数量保持不变、内容保持不变,或者用来判断谁有权利如何去增发一种新的资产,等等。它本身也是一个图灵完备的 VM。

CKB 的虚拟机基于 RISC-V 硬件指令集,任何的调整都涉及到重新的流片,所以 RISC-V 指令集的设计非常的精简、高效和周全。

总结一下,CKB 采用了 RISC-V 的虚拟机,它是图灵完备的,而且它还有 lock script 和 type script 两个地方来存放智能合约的脚本,并且还有一个叫 data 的字段来存放智能合约的状态,所以它是一个完整的合约执行环境。

Tim Xie:在我们 Shell Finance 的整个产品构建过程当中,因为我们要做 lending protocol,要做清算,所以需要一些高级合约的功能,最后我们选择了 DLC(Discreet Log Contracts,谨慎日志合约)。DLC 和闪电网络都属于同等级别的扩容技术,都是 offchain,不同点在于闪电网络主要做 payment,而 DLC 主要用来做 oracle。我们其实不是图灵完备的,限制依然很多,但即便是在限制很多的情况下,通过 DLC 我们就已经能够做 lending 了。

比特币其实有很多 OP Code,如果能启用或者解锁比如之前 DotSwap 的 Lin 提到的 OP_CAT,或是其他一些操作码,那我们其实也可以继续沿着闪电网络和 DLC 这样的路线来去创造出更多的可能性,智能合约肯定是能做的。核心点就在于有没有需求,有没有用户,有没有市场,有没有更多的人去投入时间和投入精力去构思它、去使用它、去满足用户的需求。只要有人使用,有市场,那新的想法、新的概念自然会出来。

我现在敢肯定的是比特币生态的形态一定会跟 EVM 那边完全不一样。也许在业务层面,用户的感受可能差不多,同样都是做 swap 和 lending,同样都有 oracle,但背后的体系以及最后能够使用的工具其实有巨大的差异性。如果是在比特币主网,这个差异会更大,所以我其实比较期待有较好 UTXO 结构的 L2,因为它可以更大地释放比特币生态的潜力。

Lin:我觉得把一个东西设计成图灵完备其实不是很难的事情,反而图灵不完备是很难的,把脚本设计成非图灵完备其实是个非常高深的技术活。

比特币原先的脚本是可以做到图灵完备的,只是现在的比特币很多能力被封印了,比如我之前提到的 OP_CAT,它是一个很重要的能力,但这个能力却被操作符禁用了,而不是说比特币一开始设计的时候没有这些操作符。比特币在一开始的时候涉及了非常多的操作符,但是因为所谓的安全性,或者是所谓的这种安全性的隐患,或者是没有搞清楚到底是什么、怎么用等等,就把某些操作符给禁用了。更有甚者,很多本来是可以用来做智能合约的这种功能,被所谓的标准交易做了一个过滤。我们都说比特币是一个去中心化的系统,但在这个去中心化的系统中,竟然还有一个叫标准交易的东西,它是由某些组织来决定的。标准交易在矿工领域是不存在的,因为矿工可以去打包任何的合法交易,它是基于用户端的一个 policy 问题。

所以总的来说,我觉得原始比特币的这种能力本身是很强大的,但是现在比特币受到了劫持,大家如果有兴趣的话,可以看一下 Roger Ver 的书《Hijacking Bitcoin: The Hidden History of BTC》。因为比特币原始的能力受到了封印,所以我们就被迫地在各种地方去找出路,这是我们目前所面临的一个现状,但是比特币的前途和未来肯定是比较好的。

我一直在说现在的很多所谓的比特币 L2 其实是寄生虫协议,它们并不是把自己的价值贡献到比特币上,也没有办法让矿工有更高的收入,但实际上也确实是没有办法,因为比特币的限制非常多。我讲个类比,HTTP 协议其实是构建在 TCP/IP 协议上的 L2,而我们的 HTML 协议又是构建在 HTTP 协议之上的。这里我觉得才是一层一层的概念,而不是说交易数据完全的从 TCP/IP 里面分离出来,从上一层协议里面分离出来,去另外一个地方跑,然后回头跟别人说我这个是二层协议。真正的二层协议其实是一层一层堆叠的,所以,我们去构建的那些 L2,它也应该是在上一层里面被接受为合法的交易。这就是为什么我们现在正在一层的 swap 上面做探索的一个很重要的原因。我们认为大部分情况下我们其实是要 settle 到一层,我们要在一层上面有很多的验证和共识的承载,而不是说我去做一个所谓的资产桥,然后把大家的资产搬到另外一个地方,这可能不是一个特别好的事情。

NIGO:UTXO 模型能否支持复杂的智能合约功能?当然是可以的。它就是将合约的逻辑和数据存储在 UTXO 中,然后将合约的调用和参数作为 input 来尝试解锁合约,通过 BVM(Blockchain Virtual Machine)执行合约的逻辑,最终通过解锁函数返回 ture or false 来达到控制合约状态的目的。这种模式可能对于以太坊智能合约的开发者来说有些陌生,但实际上,如果你结合函数式编程思想,再配合一些概念的转换,UTXO 智能合约可以实现非常复杂的逻辑。

UTXO 模型由于不存在全局状态,因此它需要将合约的状态和逻辑存储在 UTXO 中,然后通过 UTXO 交易调用链的传递来进行状态的传递和转换,所以每一次的 UTXO 交易都会消耗之前的 UTXO,并生成新的 UTXO,通过这种方式可以实现合约的链式状态转移。所以,能否解锁 UTXO,也就对应着合约的执行结果,它是否允许状态进行转移。如果合约判断不允许修改状态,比如不允许转账、不允许修改数据等,它则会返回 false,那 UTXO 不会被解锁,合约执行失败。

我们把合约看作对数据状态进行转移操作的状态机,那么这里就可以看出来 UTXO 合约和账户型合约的区别。账户合约的 EVM 是要维护全局状态,一个交易可能导致 EVM 进行多次的状态转移,频繁的修改状态数据直到合约执行或者 gas 消耗完。而 UTXO 合约的交易,它是一个 input 合约,调用只会触发一次状态转移,并且无论合约内部的逻辑多复杂,状态转移多少次,BVM 只会将最终的状态转移结果记录在链上。所以 UTXO 合约没有全局状态,只有一个个等待被执行的函数。

UTXO 是多输入多输出,以太坊想做的,包括 Monad 也想做的并行 EVM, 其实完全可以通过 UTXO 来实现,需要转移状态就要先找到这个状态所在的函数,通过函数调用来修改状态,并且生成新的函数,这样的模式使得 UTXO 合约的状态转移更加清晰了。

UTXO 合约并不依赖外部状态,因此,一次合约调用,无论调用多少次,它的结果必然是确定的,所以这也就跟合约的分析和调试以及单元测试带来了巨大的便利。而 EVM 合约要依赖全局状态,所以合约的执行结果很可能会受到外部环境的影响,导致合约的执行结果不确定,比如说余额够是一个结果,不够又是另一个结果。所以这也是 EVM 合约的安全性和可预测性的一个重要问题。

当然,每次将状态传递下去也不是没有代价的,在一些需要溯源的场景中,状态可能会随着 UTXO 传递链条的增大而增大,因为溯源是需要校验的,数据越来越多,所以状态本身会无限膨胀。我们 TBC 通过其他技术和哈希、数据抽取等密码学的手段,将状态膨胀的一大的问题给解决了。所以 TBC 的智能合约区别于其他 UTXO 链的一个重要特点是, UTXO 模型是 TBC 进行无限扩容的一个基础,使 UTXO 模型进行标准的转账交易是非常简单的。

综上,TBC 在充分考虑了 UTXO 模型的优势和缺点,在吸取以太坊和其他 UTXO 公链精华的基础上,引入了一个 BVM 的概念和其他技术来实现真正的一层 UTXO 的智能合约,然后配合更加友好的一些智能合约开发工具,降低了编写和部署 BVM 智能合约的门槛。