以太坊究竟靠什么颠覆了“比特币是钱包地址+余额”的单一模式？答案在「账户设计」。本文将带你全面理解 以太坊地址、外部账户、合约账户 三者的区别与协作方式；同时剖析 以太坊余额、ERC20 通证 在链上如何被记录，如何被状态树快速检索。
账户模型 vs. UTXO：为什么以太坊选了这条路？
比特币依赖未花费交易输出（UTXO）——简单，却难以为复杂业务（如智能合约、多签、代币分红）提供便捷表达。
以太坊改用「账户模型」：
- 每个 以太坊地址 即是一个状态单元，随时查阅余额、Nonce、合约代码。
- 交易作为状态转换函数，一次性把多个账户从旧状态推向新状态。
- 通过 Merkle Patricia Tree 把所有账户状态打包到区块里，既保证篡改可见，又方便轻节点 SPV 查询。
两种角色：外部账户与合约账户
| 维度 | 外部账户（EOA） | 合约账户（CA） |
|---|---|---|
| 控制权 | 私钥 | 智能合约代码 |
| 主动发交易 | ✅ 可以 | ❌ 被动触发 |
| 存储代码 | 无 | 有且不可修改 |
| 典型案例 | 普通用户钱包 | 多签钱包、Uniswap 路由合约、ERC20 代币合约 |
外部账户：链上“身份证”
- 配置：Nonce（防重放计数器）、以太坊余额、空代码字段、空存储。
- 用途：签名发起交易、部署合约、调用其他合约、接收 ERC20 通证。
- 安全：助记词、硬件钱包、社交恢复多管齐下。
合约账户：链上“自动化机器人”
- 调用即运行：一旦被外部账户触发，EVM 会按代码执行 智能合约，改变相关账户的状态。
- 存储区：高达数百万 slot，可存放映射、数组、结构体，为 DApp 提供无限可能。
- 不可升级：代码哈希（codeHash）字段生成后不变；如需更新，需使用代理合约模式。
真人场景示例：20 ETH 如何分三步到账？
- Alice 用她的 外部账户 发起合约调用，输入参数：Bob 地址，20 ETH。
- 合约检查自己 以太坊余额 ≥ 20 ETH，同时调用内置的多签逻辑，等待 Charles 的批准。
- Charles 用私钥签名后，合约更新自身状态：扣除 20 ETH，给 Bob 增加 20 ETH。交易打包完成后，新区块同步了所有账户的最新状态。
FAQ：关于以太坊账户，最常见的问题
Q1：外部账户和合约账户地址长得一样，会不会混淆？
A：不会。两者都是 42 字符十六进制地址，但语义明显不同；钱包在 UI 上会标注“外部”或“合约”，方便识别。
Q2：ERC20 通证存在账户的哪里？
A：统一管理在对应的 ERC20 合约账户的存储区。你的地址只是映射键，合约根据映射返回你的通证余额。
Q3：Nonce 用完了怎么办？
A：Nonce 是 64 位整数，日常一辈子也用不完；真正需要注意的是，交易 Pending 过多会被堵塞，适当使用动态 Gas 或批量交易即可。
Q4：为何说合约代码“不可修改”？
A：Metamorphosis 攻击曾利用自毁后重建同名合约篡改逻辑，现已通过 CREATE2 和代理方案规避；本质链上 codeHash 字段仍旧不变。
Q5：如何查询任意地址的实时状态？
A：利用公共 RPC（如 Infura、Alchemy），调用 eth_getBalance 查看 以太坊余额；调用 ERC20 合约的 balanceOf 查看通证余额。
Q6：外部账户能否升级为合约账户？
A：不能。想实现“地址不变+逻辑升级”，可使用代理合约指向新的实现合约，让旧地址继续充当代理。
从区块看账户：Merkle Patricia Tree 的魔法
每条交易执行后，所有变动过的账户被写入 MPT → 生成根哈希 → 存于区块头。轻节点只需同步区块头与零知识证明，就能验证特定地址的 以太坊余额 与 ERC20 余额，无需整条链数据。
总结：正是 外部账户 的灵活性 + 合约账户 的可编程性，使以太坊成为可直接运行金融、游戏、社交等无限场景的“世界计算机”。当你下次在钱包里查看 以太坊地址 时，不妨想一想背后那棵状态树，正默默记录你在链上的每一次转移、每一次投票、每一次质押。