Payload Logo
稳定币产品与平台

你看到的“余额”并不是真的余额:账户模型 vs UTXO 模型,链上资产究竟是怎么记录的?

Date Published

你看到的“余额”并不是真的余额:账户模型 vs UTXO 模型,链上资产究竟是怎么记录的?

{{{##anchor=preface}}}

前言

很多人在第一次接触区块链时,都以为自己钱包里那个“100 USDT”的数字,就像银行 App 一样,是系统专门为你记的一笔“余额”。可实际上,链上世界从来没有“余额”这个概念,有的只是“交易的累积结果”。钱包只是根据这些历史记录,算出一个“你现在大概有多少”。

更让人意外的是:不同公链记录资产的方式甚至完全不同。一部分链(如以太坊)使用所谓的账户模型(Account Model);另一部分链(如比特币)使用UTXO 模型(Unspent Transaction Output)。这两套体系差别之大,让它们在性能、安全、隐私、使用体验等方面,都呈现出天生的不同。

如果你想真正理解链上资产是怎么存储、更新、确认、保护的,就必须知道: 你的“余额”到底是怎么算出来的?为什么有些链交易记录看起来像流水账,而另一些链看起来像不断分割的零钱?为什么某些链天生适合智能合约,而有些链则特别安全可靠?

这一篇,我们就把账户模型与 UTXO 模型的底层逻辑,讲清楚到你可以一眼看懂一条链的设计哲学。

{{{##anchor=part-1.2}}}

1. 链上世界没有“余额”,只有历史记录

先把一个误解拆掉:

你钱包里的余额不是存储在某个地方,而是从历史交易中“推算出来”的。

换句话说:

  • 区块链不记录“你现在有多少钱”;
  • 它只记录“你曾经收到/花出了多少钱”;
  • 余额只是这些记录累加、抵消后的最终结果。

这跟银行完全不同。银行会直接在你的账户数据库中保持一行:

| 账户 | 当前余额 |
|------|-----------|
| 你 | 1,000 元 |

但链上从不这样做。链上账本是“只追加,不修改”,每一行都只能代表一笔新的事实: 谁给了谁多少钱。

{{{##anchor=part-1.3}}}

2. 账户模型:以太坊、BSC、TRON 等主流链的选择

账户模型听起来高级,其实很好理解,它跟银行系统更接近。

每个地址都有一个“账户状态”:

  • 余额
  • 随机数(Nonce)
  • 合约代码(如果是智能合约地址)
  • 存储内容(智能合约的内部变量)

当你转账时,本质上是:

“把这个地址的余额 -X,再把对方地址的余额 +X。”

链上节点会根据交易顺序依次更新这两行数据。

{{{##anchor=part-1.3-账户模型的直观优点}}}

账户模型的直观优点

  1. 余额清晰、很好理解 转账就是加加减减。
  2. 天然适合智能合约 合约需要维护状态,例如:
  • 你在某个池子里的存款是多少
  • 哪些地址有多少 LP
  • 某个游戏玩家装备升级到几级

这些都依赖“可更新的账户状态”。

  1. 兼容 ERC20 / TRC20 等代币标准 因为代币实质上就是一段智能合约代码,负责更新每个地址的“代币余额表”。

{{{##anchor=part-1.3-账户模型的缺点}}}

账户模型的缺点

  1. 并行处理难度大 因为转账更新的是“同一份状态”,不同交易可能冲突。
  2. 隐私弱 所有操作都写在账本上,一个地址的活动很容易被分析。
  3. 链容易拥堵 因为所有节点需要依照顺序更新同一个世界状态。

{{{##anchor=part-1.4}}}

3. UTXO 模型:比特币的“零钱包逻辑”

UTXO 全称是 Unspent Transaction Output,意思是“尚未花掉的交易输出”。

举个真实又好理解的比喻:

每一笔你收到的钱,都是一张独立的纸币。 这些纸币不能被拆开,花时必须整体花出,再找零。

例如:

你收到两笔比特币:

  • 0.4 BTC
  • 0.6 BTC

你的钱包显示余额 1.0 BTC,但实际上:

  • 并没有一行“余额 = 1.0”
  • 这两个 UTXO 就是你的资产本体

当你要支付 0.7 BTC 时,比特币网络会:

  1. 花掉 0.4 + 0.6 这两个 UTXO
  2. 支付 0.7 给对方
  3. 找零 0.3 给你,生成一个新的 UTXO

这种“不断生成新零钱”的方式,就是比特币的记账方式。

{{{##anchor=part-1.4-utxo-的优点}}}

UTXO 的优点

  1. 安全性极强 每个 UTXO 独立验证,不依赖全局状态。
  2. 天然分片(可并行处理) 不同 UTXO 互不影响,可并行验证。
  3. 隐私性更强 不像账户模型那样可以一眼看出完整余额。

{{{##anchor=part-1.4-utxo-的缺点}}}

UTXO 的缺点

  1. 不适合智能合约 因为没有可更新的“账户状态”,难以构建复杂逻辑。
  2. 开发复杂度高 钱包必须管理一堆“零钱”,不像账户模型那样直观。
  3. 使用门槛更高 新用户理解起来比账户模型更抽象。

{{{##anchor=part-1.5}}}

4. 账户模型 vs UTXO:完整对照表

| 特性 | 账户模型(ETH/BSC/TRON) | UTXO 模型(Bitcoin) |
|------|-----------------------------|---------------------------|
| 资产表示 | 一条记录(余额) | 多个独立的“零钱盒子” |
| 转账方式 | 余额加减 | 消耗旧 UTXO → 生成新 UTXO |
| 并行处理 | 较弱 | 很强 |
| 安全性 | 高 | 极高 |
| 隐私 | 较弱 | 中等偏强 |
| 智能合约 | 完全支持 | 天然不适合 |
| 应用场景 | DeFi、稳定币、应用层 | 价值存储、清算层 |

一句话总结:

  • 账户模型:用来“运行应用”的链
  • UTXO 模型:用来“保存价值”的链

这来自两者天生的设计哲学。

{{{##anchor=part-1.6}}}

5. 稳定币为什么一般不在 UTXO 模型上发行?

因为稳定币本质上是“三件事”:

  1. 一个代表美元的代币单位
  2. 一个更新“谁持有多少代币”的状态表
  3. 一个可被授权和转账的智能合约

这些都依赖“可更新状态”,而比特币的 UTXO 模型不支持。

因此:

  • USDT 在 Bitcoin(Omni)上曾经运行过,但体验极差
  • 今天几乎所有稳定币都运行在账户模型链
  • Tron、ETH、BSC、Solana、L2 是最成熟的载体

这也是为什么跨链、DeFi、支付、钱包这些生态,可以在稳定币体系上百花齐放。

{{{##anchor=part-1.7}}}

6. 钱包呈现的“余额”到底是怎么算的?

两种模型的处理方式完全不同:

{{{##anchor=part-1.7-账户模型链}}}

账户模型链:

钱包直接查询:

```
合约内的你地址的余额字段
```

更新方式是:

```
balance[from] -= X
balance[to] += X
```

非常直观。

{{{##anchor=part-1.7-utxo-模型链}}}

UTXO 模型链:

钱包必须:

  1. 搜集所有属于你地址的 UTXO
  2. 把未花掉的加在一起
  3. 得出余额数字

所以你看到“1 BTC”,其实是多个零钱的总和。

{{{##anchor=part-1.8}}}

7. 为什么账户模型“容易被黑”?UTXO 却极难?

不是因为链安全性差,而是因为:

账户模型链必须支持智能合约 → 智能合约越复杂 → 出错机会越大。

真实例子包括:

  • Uniswap 欺诈授权
  • 顶级 DeFi 协议合约漏洞
  • 用户授权给恶意合约导致资产被盗

而比特币只支持极其有限的脚本能力,等于“自己封住了被攻击的窗口”。

因此:

账户模型强调“功能丰富”,UTXO 模型强调“极致安全”。

{{{##anchor=summary}}}

总结

账户模型与 UTXO 模型,是两种完全不同的设计哲学:

  • 一个追求“可编程资产”(适合稳定币、DeFi、应用生态)
  • 一个追求“绝对安全与去中心化”(适合价值存储体系)

理解两者的差异,你就能真正理解:

  • 为什么以太坊和比特币走出了完全不同的发展路线
  • 为什么稳定币只能运行在账户模型链上
  • 为什么你的钱包余额“不是数据库里的数字,而是历史行为的结果”
  • 为什么某些链快,但某些链稳

理解这一层,链上的许多困惑都会得到统一的解释。

{{{##anchor=resources}}}

相关资源

  • Ethereum Accounts 文档
    <https://ethereum.org/en/developers/docs/accounts/>
  • Bitcoin UTXO 结构说明
    <https://developer.bitcoin.org/devguide/transactions.html>
  • 比特币 Script 介绍
    <https://en.bitcoin.it/wiki/Script>
如果你觉得这篇文章让你真正理解了“余额背后的逻辑”,也可以分享给正在学习区块链原理的朋友。理解资产如何被记录,是进入稳定币和 Web3 世界最重要的一步之一。