如果未来
区块链的目标是作为通用平台，用以存储多种类型的数据，则其日志格式与存储必须回归数据库的通用性本源。当前的账本模式可以作为该体系中的一个特别模块存在用以进行账户间结算，但是无法将其扩展为通用业务平台。
既然要成为通用数据存储平台，那么UTXO模型存在一定局限性。在一个典型的银行业务中，零售业务可能会包含千万甚至亿级别的账户，不同账户可能使用不同的利息计算规则，也可能存在冻结等特殊状态。而交易流水信息每天可能达到千万笔，如果将其业务扩展到非
金融行业，流水信息每天几亿也是可能的。因此，从一个通用账户+流水的业务模型中，一般企业会建立一个账户表与一个流水表，以不同的策略进行管理。
账户表俗称余额类数据，在典型的数据治理体系中需要做到定期快照备份（例如月初数和月末数）；而流水表则成为流水类数据，一般来说以原始交易格式直接存储和备份。通过对余额类数据快照备份的恢复，对指定账号重做某个时间范围内的全部交易流水，可以得到该账号任意时间点的余额信息。
而UTXO的本质在于日志存放的信息不是记录的最终结果，而是变化行为。在传统数据库中，每条事务记录的是数据的写前与写后内容。例如将一条记录从5更改为8，其数据库日志记录原始数据为5且新数据为8，而不是记录“+3”的操作。但是UTXO记录的是变更信息，其主要的目的是解决双花问题（例如对于一个有100块钱的账号，一个人在中国转走10块钱，另一个人在美国同时转走10块钱，如果记录的是最终结果，那么中国的服务器会认为这个人有90块，美国的服务器在没有全局锁的情况下也会认为这个人有90块，最终写到区块中就变成90块余额，而非80）。
UTXO的机制可以有效地在无锁的情况下避免双花问题，但是其劣势则在于不存储余额表，所有的信息均通过重做流水数据，从零开始生成。对于一个存在了十年以上，包含几百亿笔交易的系统来说，这样的做法就好比每次重启都要从都重做几百笔交易并存入内存中（或KV数据库里），是一种非常原始且不经济的方式。
另一方面，区块链日志的结构看来，由于多活系统中全局锁很难实现，因此需要通过交易日志结构的调整来满足传统数据库中事务的功能。传统数据库中当涉及到两账户之间转账操作时需要开启一个事务。在事务日志中一个账户增加一个账户减少的业务逻辑，需要体现为包含三条记录的链表（最后的提交操作也是一个记录）。在数据库崩溃或发生异常后，只要通过重做所有的任务，并最后对全部没有提交记录的事务进行反向操作，即可得到原子性（Atomic）与持久性（Durability）。
而在区块链体系中由于不存在事务的概念，同时操作日志与结算业务进行了紧密耦合，因此每条交易记录都会包含一个输入账号以及若干个输出账号，也就是说只要一条事务记录被成功发送给一个节点，则可以保证在该记录内部的全部输入输出账户统一进行了变更。可以说，区块链通过定制化交易日志简化了事务操作的复杂性，但是带来的影响便在于业务与代码的紧密耦合不可分割。
但是无论如何，首先UTXO并不是通用数据结构，而是为交易业务高度定制化的数据结构，如果想要运行图灵完备的智能合约（或者说存储过程），使用UTXO会有很多局限性。第二，对长期运行的大型系统（相比起大中型银行核心交易系统所产生的交易流水，
比特币从诞生到现在的交易量少得可以忽略不计），UTXO每次初始化需要全部的历史交易日志。这种模式完全不可能适用于大型交易系统。
因此，可以存在两种做法解决该问题。第一种方式使用传统账户表与流水表的机制，将UTXO以流水的方式体现出来，同时定期保存账户快照，以避免每次重构数据库都需要重做全部交易（这种机制需要考虑到账户与流水表在多活系统中，没有全局锁的情况下如何实现一致性的问题）。而对于非结算类交易，通用型
区块链项目则可能采用日志结合用户数据存储的模式，才能够普适性地满足通用业务需求（这种机制需要依靠比nonce更好的排序机制避免双花）。
版权申明：本内容来自于互联网，属第三方汇集推荐平台。本文的版权归原作者所有，文章言论不代表链门户的观点，链门户不承担任何法律责任。如有侵权请联系QQ：3341927519进行反馈。
