本文旨在学习和理解 UTXO 模型. 它使用一种易于理解的方式来简单地整理出从BTC到$SUI的UTXO模型和实现方法. 我将提供全面的概述，为了清晰和深入，我们将在此对其进行扩展，从而确保进行专业和透彻的分析.

作为 比特币的核心设计原则 之一，UTXO模型自诞生以来已成为区块链领域的重要技术范例. 它在确保交易安全性和可追溯性方面起着重要作用，并提供了除传统账户余额模型之外的另一条途径.

随着近年来区块链技术的不断更新和迭代，UTXO 模型本身也在不断发展和扩展.

UTXO 及其起源简介

UTXO模型或未花费的交易输出是比特币的基本概念，其中每笔未花费的交易输出都作为UTXO进行跟踪. 该模型将交易视为现金，其中支出涉及选择特定的UTXO来支付金额，而不是修改单一余额.

示例：爱丽丝和鲍勃各起价为5美元. 在账户模型中，如果鲍勃抢走爱丽丝2美元，爱丽丝的余额变为3，鲍勃的余额变为7. 在UTXO模型中，爱丽丝的5美元UTXO用于创建两个新的UTXO：2美元给鲍勃，3美元返还给爱丽丝，鲍勃现在持有他最初的5美元UTXO和新的2美元UTXO，总共7美元.

正如 [了解UTXO：综合指南]（https://community.magiceden.io/learn/utxo-guide）中所详述的那样，这种方法可确保透明度并防止双重支出，在链上公开跟踪每个UTXO，同时通过匿名地址保护隐私.

不难看出，爱丽丝只剩下3美元，鲍勃只剩下7美元. 这种会计方法类似于小学加法和减法，经常出现在银行系统中，被称为账户/余额模型. 在其中，账户余额作为单一值存在.

如果使用与账户模型不同的方法，例如 UTXO 来表示 Alice 和 Bob 之间的财富转移，则图表将有所不同：

与账户/余额模型的比较

账户/余额模型在银行业中很常见，它保持每个账户的单一余额，每笔交易都会更新. 它很简单，但是当多笔交易修改同一个账户时，会出现争用问题，通常需要锁定并导致性能瓶颈，尤其是在高交易量的情况下. 相比之下，UTXO 模型，如 [探索UTXO模型：它在区块链世界中的与众不同之处是什么？] 中所述(https://blog.defichain.com/exploring-the-utxo-model-what-sets-it-apart-in-the-blockchain-world/) 通过在独立的 UTXO 上处理事务来避免这种情况，实现无锁的并行执行，从而提高吞吐量和并发性.

隐私是另一个优势，加密钱包每笔交易都会生成新的地址，这使得与个人关联变得更加困难，这与账户模型的固定地址不同，后者更容易受到关联分析的影响. 但是，UTXO在处理复杂业务逻辑（例如多阶段合约）方面的局限性导致了以太坊基于账户的模型，如 什么是UTXO？未花费的交易输出说明.

SUI 的对象模型：桥接 UTXO 和账户模型

正如 X 帖子中所详述并受 对象模型 | Sui 文档 支持的那样，SUI 以对象而不是账户为中心存储，有两种密钥类型：OwnedObject（地址所有者）和 SharedObject.

OwnedObject增强了UTXO，只有所有者才能操作，并且每个版本仅使用一次，这符合UTXO的原则. 例如，地址拥有的对象只能由其所有者修改，类似于花费 UTXO.

相反，每个人都可以访问SharedObject，类似于账户模型，但需要达成共识才能排序读取和写入，从而解决了状态争议，如 Sui Components | Sui 文档 所述. 这是通过本地排序等特殊处理来管理的. Sui 的面向对象方法 重点介绍了 SUI 的模型如何影响可扩展性、安全性和用户体验.

SUI 中的所有权类型

所有权类型	描述	可访问性
地址所有	由特定的 32 字节地址（账户地址或对象 ID）拥有	只有其所有者可以访问
不可变	无法变异、转移或删除；没有所有者	任何人都可以访问
共享	共享使用0x2::transfer::share_object功能	所有人均可访问
Wrapped	通过将struct类型为的字段放入另一个字段来组织数据结构	未指定

拥有的对象包括地址所有者，与 UTXO 一致，而共享对象可以明确供所有人访问，这符合账户模型的更广泛访问权限.

我的结论和未来的考虑

从比特币的UTXO到SUI的对象模型的过渡代表着一次重大演变，它提供了灵活性，并通过SharedObject解决了UTXO在复杂逻辑中的局限性，同时通过OwnedObject保留了UTXO的并发优势.

正如《探索 Sui 的以对象为中心的模型和移动编程语言》中所探讨的那样，这种双重方法将 SUI 定位为一个多功能平台，有可能为区块链数据模型设定新的标准.