没有比特币，只有UTXO

孟言

Raven 区块链专栏作家

UTXO 代表未使用的交易输出。

在比特币社区中，Transaction 缩写为 TX，所以上面的短语缩写为 UTXO。一般认为 UTXO 是比特币区块链设计的一部分，但实际上 UTXO 与区块链没有必然联系。你可以完全复制比特币区块链，但不要使用 UTXO。

HyperLedger 和以太坊最初并没有使用 UTXO，前者已经切换回 UTXO，而后者打算增加这个选项。我觉得这也是中本聪的过人之处——后人抄袭，中间想做一些小改进，但是做了之后发现原来的版本还是很高的，后来又改回来了另一个...

那么究竟什么是 UTXO？

前不久，听了《卓老板谈技术》的那一集《比特币》，讲了比特币的支付流程，说要给奶茶妹妹5个比特币，所以系统是在他的账户里扣5，给奶茶姐的账户加5，然后把交易记入区块链总账，完成。虽然节目做得很好，但卓老板在这一点上是完全错误的，他描述的是基于账户的方案，而不是比特币实际使用的 UTXO 方案。

如果我们设计一个支付系统，我们肯定会和卓老板一起，给张三一个余额为100元的账户，给李四一个余额为50元的账户。当张三要付给李四 20 元时，请执行以下操作：

1.查看张三账户余额是否充足，如果不足20元，终止交易并报告张三“余额“不足”

2.从张三的账户中扣除20元（假设手续费为零）

3.给李四的账户加20元

当今银行、信用卡、证券交易系统和互联网第三方支付系统的核心都是基于账户并由关系数据库支持。

数据库必须保证两点。首先是要保证业务规则得到遵守，张三有足够的平衡。二是保证事务性，即原子性、一致性、隔离性、持久性（ACID）。这些都是数据库的常识性知识，这里不再赘述。这种基于账户的设计简单直观，已经在 IT 系统设计中使用了几十年。应该说没有问题。

但比特币并非设计为基于账户的系统，而是发明了 UTXO 方案。

理解 UTXO 最简单的方法是描述比特币从诞生到商业世界的起起落落的经历。假设这样一个场景：张三挖了 12.5 个比特币。几天后，他将其中的2.5个付给了李斯。几天后，他和李四各捐出2.5个比特币，凑成5个比特币支付给王舞。

如果是基于账号的设计，张、李、王在数据库中各有一个账号，那么他们的账号变化如下图：

但在比特币中，这个过程是通过UTXO实现的，如下图：

比特币的一笔又一笔交易记录在区块链账本中。

每笔交易都有多个交易输入，即资金来源，也有多个交易输出，即资金去向。一般来说，每笔交易都会花费一个输入并产生一个输出，而产生的输出就是“未花费的交易输出”，也就是UTXO。

比特币交易遵循几条规则。

首先，除了coinbase交易之外，所有的资金来源都必须来自之前一笔或几笔交易的UTXO，就像接上一根水管，一个接一个，一个接一个，一个接一个，一个接一个。他出来，继续，钱在交易之间流动。

第二，任何交易的总交易输入必须等于总交易输出，等式两边必须平衡。

上图中的第一笔交易#1001 是 coinbase 交易。比特币由矿工开采。当矿工竭尽全力寻找合格的区块时，它有权创建一个 coinbase 交易，将新的金额放入其中，并输出交易输出的收款人地址。在一个栏中，以直立的方式写下您的地址。在我写这篇文章的那天（2016 年 8 月 9 日），这个比特币的数量设定为 12.5，市场价格为 48,576 元。这个coinbase交易连同张三挖出的区块被每个节点接受，六次确认后将永远铭刻在历史中。

几天后，张三打算向李四支付2.5个比特币，张三发起了一笔#2001的交易。本次交易的资金来源为“#1001(1)”，即#1001交易的第一个UTXO——张三挖出的coinbase交易。那么在本次交易的交易输出的UTXO项中，把 2. 5 个比特币的收款人地址设置为李四的地址。

请注意，本次交易必须提前产生12.5个比特币的输出项全部消费，并且因为张三只打算支付李斯2.5个比特币，才能消费剩余10个比特币，他必须把剩下的10个比特币支付给自己，这样才能满足输入输出平衡的规则。

过几天，张三和李四打算用AA系统一起给王舞5个比特币。然后张三或者李四发起交易#3001，在交易输入部分，有两个资金来源，分别是#2001(1)和#2001(2)，分别代表(1)和(<@)2)项UTXO。然后在这个交易的输出部分做同样的事情，给王五5个比特币，把张三剩余的7.5个比特币还给自己。以后如果王五吴想花他的 5 个比特币 对于比特币，资金来源必须在他的交易中注明为#3001(1).

所以，没有比特币，只有 UTXO。当我们说张三拥有 10 个比特币时，我其实是指在当前的区块链账本中，几笔交易的 UTXO 项的接收者都写了张三的地址，这些 UTXO 项的总和是 10。因为在在比特币系统中，一个人所能拥有的地址资源可以说是取之不尽用之不竭。要知道你在大量地址中收到了多少个 UTXO，你无法计算，需要代你使用比特币钱包 Tracking 计算。

以上是对UTXO的简单介绍。

那么 UTXO 高在哪里？

比特币的很多技术点并不是中本聪的独创性。例如，基于“工作量证明”的共识机制是由 Adam Back 在 Hashcash 中提出的，将所有交易计入总账并为交易打上时间戳，以防止双花攻击的思想是由 Wei Dai 提出的。 b-money 和 Nick Szabo 的 Bitgold，更何况比特币网络是一个零优化的泛洪 P2P 网络，单就 P2P 技术而言，在很多方面都赶不上 2001 年出现的 BitTorrent。

但是有三个技术点绝对是中本聪独创的，一个是区块链的设计，一个是UTXO，一个是智能合约。而这三个设计都非常巧妙，被斯坦福大学密码学和计算机安全教授 Dan Boneh 评为“极其出色”，“必将激发无穷无尽的创新”。

当然，但中本聪最引人注目的不是这三个单点的创新，而是将所有这些技术点与加密货币本身的特性相结合，设计了一套“惩恶扬恶” ”。 “好的”经济激励体系将技术创新和制度设计结合成一个紧密结合的体系。

在这个系统中，任何人都可以建立一个匿名节点，编写破坏性代码，然后进行匿名攻击，即使你成功攻击并窃取了大量财富，你的身份也不会暴露，所以可以逍遥法外它。

这个系统是赤裸裸的，给盗贼打开了大门，让你可以攻击和破坏，而且即使你成功突破防线，窃取大量财富，整个比特币系统不仅不会惩罚你，还能牢牢保护您的赃款。然后悬赏100亿美元，运行了七年。到目前为止，对主链的攻击还没有成功，一次也没有。

中本聪将比特币设计得像数学原理一样漂亮，很多后来者甚至无法复制这个级别。我认为这就是为什么加州大学洛杉矶分校的金融学教授 Bhagwan Chowdhry 提名中本聪作为 2016 年诺贝尔经济学奖的候选人。相信中本聪在比特币上的很多设计思想，以及整个比特币开发者社区做出的很多改进，不仅是区块链的创举，也成为IT系统设计创新思想的源泉。

UTXO 的设计值得深思。它的设计方案在《什么是UTXO》一文中有介绍。本文将讨论 UTXO 的优缺点。

为什么中本聪会这样设计比特币？考虑到他不应该是一个从未来穿越回来的角色，按照常识，他一开始应该是从基于账户的系统开始设计的，但后来他决定改用UTXO方案。肯定有问题。

很遗憾，这些问题的答案在比特币的源代码中找不到。比特币的开发始于 2007 年 5 月，Github 上最早的比特币源代码版本是 0.1.5，由中本聪在 2009 年 9 月 16 日推送，但其中，设计的UTXO已经形成。

后来有人翻出了他们的旧电子邮件，找到了 2008 年 9 月版比特币的代码。该代码是在比特币区块链上线前几周发布的，应该非常接近比特币创世纪运行的版本。但仔细看，UTXO 也已经敲定。我们注定无法通过代码研究发现UTXO的设计上下文。

其他文学呢？两者都不。中本聪在发表比特币之前，主要是和一些密码学专家交换电子邮件，外界是看不到的。他积极参与论坛讨论，主要是在比特币发布之后。在 UTXO 设计的形成过程中，我找不到任何关于他的提及。

由于这些选项都不起作用，我们只能猜测。

我的猜测是，中本聪最初设计比特币时，也采用了账户方案。但在 2007 年下半年或 2008 年上半年的某个时候，中本聪发现基于账户的方案存在问题并创建了 UTXO 方案。

那么基于帐户的解决方案存在哪些问题？

如果您要使用基于帐户的方法，那么您肯定需要一个数据库。这个数据库可以让你轻松查询张的各个账户余额三、李四。

而UTXO方案当然也需要一个数据库，记录当前系统中每一个“未使用的交易输出”，也就是比特币。当节点收到一笔交易时，需要在UTXO数据库中查询该交易引用的UTXO是否存在，以及其收款人（owner）是否为当前新交易的付款人。事务结束后，需要对数据库进行相应的更新。

首先要明确一点，不管是账户数据库还是UTXO数据库，都必须是去中心化的，每个节点一个clone一定不能中心化。如果比特币系统有一个中央数据库，那么无论你有多少节点，每笔交易都必须到中央数据库进行验证，然后进行“转账”的交易操作，那么就根本不会“去中心化”。比特币一文不值，还是老老实实用支付宝吧。

由于每个节点都会克隆一个数据库，并根据交易流程同步修改，那么账户数据库和UTXO数据库有什么区别？

进一步思考，我们会发现还是有很大的不同。

首先，从长远来看，账户数据库会无限扩大，而UTXO数据库会小很多。

你要知道比特币是一个匿名系统，它的账户就是“地址”。每个比特币用户可以拥有几乎无限的地址。从比特币系统的角度来看，绝对不知道这两个地址是否对应同一个人。

而比特币鼓励用户打开大量地址。有的钱包软件甚至在每次交易时都会开一个新账户，每次支付都会开一堆账户来分散资金，保证匿名。更何况，还有很多用户出于好奇，下载了一个比特币钱包，为它申请了几十个地址，然后就冰冷地躺在那里，从不使用它。或者有些地址用了之后就不再使用了，甚至干脆被所有者遗忘了。但是所有这些有用和无用的地址都必须记住在我们的帐户数据库中。

时间越长，账户数据库中“废弃账户”的比例就会越大，数量会无限扩大。这怎么能忍？要知道，比特币矿机每次处理一笔交易，都需要查询这个数据库。当数据库规模无限扩大时，查询速度也会变慢，耽误比特币矿机的挖矿竞争，这是不可接受的。

相比之下，UTXO 存储所有“有用的”数据，即当前未被消费的比特币。矿工需要查询和操作 UTXO 数据库才能验证交易。这个过程一定要快，而且越快越好，这样他们才能领先于其他人在挖矿竞争中获胜。

得益于UTXO方案，比特币到现在已经运行了近八年，整个数据库还不算太大。到2016年5月，压缩后的体积约为1.5GB，估计解压后的体积约为8GB，完全可以放入内存。如果是账户数据库，估计内存都爱不下去了。

其次，UTXO 数据库允许并行事务操作。在账户数据库中，如果张三要给李四转账20元，他需要进行一次数据库交易，从张三的账户中减去20，再给李四的账户加上20。如果同时王舞要给张三转账30元，那么这笔交易必须排队，不能并行。

之所以会这样，是因为两个交易都需要处理“张三的账户余额”的共享状态。在 UTXO 中，数据库跟踪比特币所有权的转移，而不是账户状态。不管张三自己有多少收支交易，这些收支交易都是在不同的比特币上进行的，更重要的是，这些交易不共享任何状态，所以不会互相干扰，所有这些事务可以并发执行。这不仅带来了快速的好处，更重要的是，带来了可扩展性和分布式的好处。

在许多大型互联网公司中，分布式事务的处理是核心技术竞争力之一。它需要一支非常强大的精英技术团队，大量长期持之以恒的投入和维护和改进，才能在这个领域立足​​。坚守阵地。有没有可能发明一个基于UTXO的技术系统，让事务性事务处理也可以完全分布式？ UTXO 的应用领域是否更广？

例如，当你在天比特商城花费10比特币购买一件衣服，而知笔宝并没有从你的账户中扣款，但在一次交易中，该衣服的所有权与10比特币的所有权发生了反转，这样衣服的主人就从商人变成了你，比特币的主人从你变成了商人。

请注意，此过程不与同时进行的任何其他事务共享状态，并且可以轻松确保逐个事务的事务完整性。这样的交易过程可以很容易地大规模分布。交易量大时增加节点，交易量小时减少节点。在这样的架构下，我们不必兴奋和崇拜天币商城和天币宝一天完成的数百亿交易，因为从技术上讲这已经不是什么大不了的事了。当然怎么拥有比特币账户，这只是一个猜想。真的会是这样吗？还有其他坑吗？这是一个极具吸引力的话题，值得在未来不断讨论。

当然，UTXO 也有一些缺点。

首先，UTXO方案实现起来不太容易怎么拥有比特币账户，比较复杂。这也是以太坊一开始没有采用UTXO方案的原因。

其次，UTXO 数据库现在非常臃肿。 2015年5月UTXO数据库压缩后为650MB，解压后占用内存4GB。一年后，压缩卷为1.3GB，解压占用8GB内存。一年一翻的速度，谁也受不了。比特币大亨 Galvin Andersen 曾估计，到 2025 年，要将 UTXO 数据库放入节点内存，仅购买内存就要花费 4000 美元。

UTXO 通胀问题也让人们担心比特币区块扩容。如果比特币的区块从 1MB 扩大到 2MB，那么 UTXO 会扩大得更快。

现在也有人提出了解决问题的建议，有人说通过激励机制鼓励节点合并UTXO，也有人提出放宽一些验证要求，允许节点将UTXO上盘。 Peter Todd提出了完整的建议，有兴趣的可以点击这里()。

在翻阅旧论文的过程中，我亲眼目睹了 2010 年一位名叫 Red 的黑客和 Satoshi Nakamoto 之间的讨论。 Red 建议不应再将当前的 UTXO 集存储在数据库中，而只存储铸币记录：这些比特币是何时开采的，收款人是谁。然后，每当有一笔交易发生时，钱包软件负责将所用比特币从被挖出到本次交易的所有兑换记录提交给节点，节点只需对所有这些记录进行验证即可。如果扣减和数字签名匹配，则可以批准交易。

例如，这就像买卖二手房。

政府只有这处房产的原地契，而张三和李四的买卖双方都需要把原地契和所有的历史转让合同一一拿下，最后拟定自己的合同对于这次销售，来办公室。办事员先从档案中调出房产的原地契，比对原地契，证明这里的房产自竣工之日起确实是区政府认可的合法房产，然后核实并调换逐个。手上合同，检查易手过程是否环环相扣，检查签字是否真实，直到最新的合同，确认当前房产确实为张三所有，再查看最新的“张三在此售出房产”给李四”合同，主要是检查签字，当然还要检查其他条件。审核通过后，加盖公章，批准交易。请注意，这份合同不必由政府存档，但应由李斯带回保管。下次李斯想把房产卖给王舞时，他需要拿着原地契给政府职员出示，直到“张三把这里的房产卖给李斯”的合同，以证明他确实是业主的当前财产。全部。

该方案的优点是原始造币记录（相当于原始房屋契约）的数量呈线性增长，每个区块只生成一个这样的记录，因此相应的数据库不会出现体积膨胀。在所有比特币都被挖出之后，数据库就会停止增长。

缺点是复杂性完全归咎于钱包软件和节点验证过程。对于每笔交易，钱包都会向节点提交一个越来越长的比特币变化记录。而且节点也得从这些比特币诞生的那一刻开始，一一进行校验，交易验证的性能会大打折扣。

正是出于这个原因，中本聪当时并没有接受这个计划。然而，这主要是因为货币波动过快。相同的解决方案在其他应用场景中可能是可行的。所以我在这里详细介绍一下。

本文首发于公众号“孟岩的区块链思维”/作者：孟岩（slickmonk@qq.com），Raven区块链专栏作家，本文由Raven区块链授权发表。

如需转载/投稿，请扫描以下二维码联系