一文读懂账户模型与 UTXO 模型的区别与联系 - 区块链前沿 - BitMere

在区块链世界中，人们普遍认为，在可用性方面，帐户模型比 UTXO 模型更有优势，我一直在努力弥合区块链 [1] 中的 UTXO 模型和帐户模型之间的差异。

关于这个问题，有一些初步尝试 [2]。

但是最近，我开始觉得 UTXO 模型和账户模型本质上是一样的，或者如果我们用术语来重新表述的话，UTXO 模型只是一个软件定义的版本的账户模型。如果你对此感到疑惑，我将在下面详细解释。

为了使事情更容易理解，在这篇文章中，我将只使用 UTXO 模型的说法。了解我们的人都知道，我们将 UTXO 模型推广到了 cell 模型。cell 模型的附加优势在这里并不重要。下面我将讨论任何能够存储数据的 UTXO 模型 (比如 CKB 的 cell 模型，或者在使用 OP_PUSHDATA 的老式普通的比特币的 UTXO 模型)，在编程模型方面都可以与帐户模型等价。

什么是账户模型？在基于账户模型的区块链中，交易只说明操作或带有参数的函数调用。实际的状态，是从区块链中计算和推导出来的，如下图所示 :

而在基于 UTXO 的区块链中，状态都包含在交易中。你直接在交易中放入你想要的数据。通常，多个 UTXO 可以一起工作来提供整个状态的一部分。当你希望更改一部分数据时，你可以将该部分的 UTXO 作为交易中的输入包括进来，并提供一个包含更新数据的新 UTXO。

如下图所示：

关于这两种模型的争论已经有一段时间了。一个明显的考虑是，账户模型的交易体积更小，但作为交换，必须在基于账户的区块链中计算状态，更糟糕的是，同一账户的交易需要顺序执行。另一方面，基于 UTXO 的区块链只需要进行验证工作，以确保提交的数据格式正确，访问同一账户不同部分的交易也可以并行验证，以获得更好的性能。但是，我们要付出交易体积比较大的代价，因为交易需要包含实际的数据。

但这不是本文的重点，每种解决方案都有避免各自缺点的方法。人们普遍认为，在构建 DApp 时，账户模型比 UTXO 模型更具有优越性。另一种说法是，基于 UTXO 的区块链不能使用帐户模型拥有 DApps。这是真的吗 ? 让我们在这里找到答案。

一个小转换我们将在这看到一个类似于 ERC20 的 token 的转账操作。在帐户模型中，通常有一个 token 帐户存储所有用户的 token 余额。当有人想要转账时，只需要提交说明 from, to 和 balance 的交易以进行转帐：

然后，区块链执行链上的交易，并更新包含更改的内部状态。

我们如何在 UTXO 模型中表示它？一种观察是，典型的基于帐户模型的通过键-值存储表示整个帐户状态。我们可以接受同样的抽象概念：

为每个帐户创建预定好的一定数量的 cell(注：可理解为格子)。实际上，你只需要定义这里的数字，缺少的 cell 可以解释为虚拟的 cell。

每个单元格都将整个空间的一部分存储在键-值中；

如果交易需要更新某个值，它首先查找包含该值的键的 cell，并将相应的 cell 作为交易输入，然后提供一个包含更新数据的新的 cell;下图显示了这种交易示例：

这里整个帐户状态包含 4 个 cell，但是由于只需要更新 2 个 cell，所以交易只包含这 2 个 cell。

你可能会注意到，这看起来很像数据库和文件系统中使用的 B-tree[3] 数据结构。在 B-tree 结构中，你希望最小化实际修改的 page，这与我们基于 UTXO 的设计完全相同：你希望在交易中包含和修改尽可能少的 cell。这意味着虽然我们拥有一个简单的设计，但是你可以利用在 B-tree 领域积累的丰富的研究来构建更好的设计，从而提供更好的结果。

如果我们考虑这里的方案，它实际上并没有利用任何特定于应用程序的知识，唯一的假设是帐户模型使用键-值存储，现在已经是这种情况了。这意味着我们可以在 UTXO 模型的基础上构建一个账户模型 generator：

generator 响应来自 DApp 开发者的读取请求，查询该账户当前活动的 cell，提取所提供的键的值；

generator 还接受帐户模型风格的函数调用，它使用当前的活动的 cell 运行该函数，并生成包含更新 cell 的交易，将交易传递给区块链以供接受。为了提高灵活性，我们可以在这里引入账户模型风格的虚拟机，如 EVM、Move 等 ;

然后，链上智能合约可以运行由 generator 运行的相同代码，以验证生成的数据是否正确。如果使用了 EVM 或 Move 这样的 VM，我们可以将相同的 VM 移植到链上智能合约，并在这里执行相同的操作。当然，需要构建这个新的 generator，使基于 UTXO 的区块链的行为类似于基于帐户的区块链。我在这里的观点是，这是一条完全可行的路线，这意味着基于 UTXO 的设计，永远不会妨碍基于帐户模型构建的 DApp。

在 Generator 中复制逻辑不是一个坏主意对这条路线的不断批评，也是我之前所担心的，是我们在链外 generator 部分和链上智能合约中都复制了逻辑。但最近，我一直在质疑这一点：这真的是一个问题吗？在区块链的世界里，一个被广泛遵循的原则是「不要相信它，去验证它」（don't trust, verify）。一项交易中包含的智能合约不仅会在单个节点上运行，还将在每个区块链节点上运行。我们已经执行了 N 次相同的智能合约，如果 generator 再执行一次，并使其成为 N + 1，这真的很重要吗？我们都知道 N + 1 和 N 没有区别。我个人认为 generator 部分只是另外一个轻量级客户端节点，可以再次验证智能合约。这不会给我们现有的区块链设计带来任何问题。

如果你仍然对此感到疑惑，那么实际上还有另外一个观点：除基于键值存储的帐户模型外，以上设计均基于其他假设。当我们谈论特定的 DApp 时，很有可能会利用某些属性，因此链上智能合约不必运行与链下 generator 完全相同的代码。例如，在一个 ERC20 token 例子中，实际上只有 2 条规则需要在链上验证：

交易具有有效的签名；

正常交易不能发出大于当前发行量的 token。一旦满足了这两个规则，ERC20 相关代码的其余部分就可以在链下安全地运行了。这意味着你不必再次在链上重新运行相同的代码。但这只是针对特定 DApp 的优化，我甚至会质疑是否有必要进行优化。对我来说，前面的更通用的解决方案已经工作得很好了。

软件定义世界当然以上描述的 generator 部件需要进一步开发。但是，如果我们将目光投向区块链世界之外，再看看一般的软件行业，我们会注意到一种不可阻挡的趋势：

CPU 从 CISC[4] 设计转移到 RISC[5] 设计，使用基于软件的编译器来填补 RISC 中缺失的部分。

高度专业化的基于硬件的交换机正在被利用复杂软件 [6] 的普通计算机吃掉

附加存储或存储区域网络的传统网络已被采用软件定义的存储 [7] 的商品云所取代

即使在通讯塔中，也已经部署了更多软件 [8] 提供更好的性能你注意到一个模式了吗？我们看到的是一个复杂的硬件被简单的硬件迅速取代的世界。越来越多地使用高度专业化的软件来补充过去硬件中的功能。在 Nervos Network 中，我们认为区块链更像是硬件而不是软件，并且，如果我们看看 UTXO 模型与帐户模型的争论，我们会看到类似的冲突：

基于帐户的区块链在区块链（硬件）部分增加了更多逻辑；

基于 UTXO 的区块链在区块链（硬件）部分中加入了更少的逻辑，并利用软件来补充更多的特性。如果我们只看到一种或两种情况，这可能只是一个异常，但我们看到的是：从行业角度来看，看到了更多从硬件向更多软件的转变。我不确定你的看法，但我个人认为，我们这个行业的所有聪明人都做出了正确的选择