我们可以把 UTXO Stack 想象成比特币生态的 OP Stack + EigenLayer。

整理：CKB

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 智能合约的门槛。