提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档
文章目录
- 2.BTC vs ETH vs Solana 账户模型对比
- 2.1 三大账户模型总览
- 2.2 以太坊账户/余额模型
- 2.2.1 核心概念
- 2.2.2 状态转换流程
- 2.2.3 全局状态树（Merkle Patricia Trie）
- 2.3 Solana 账户模型
- 2.3.1 核心概念
- 2.3.2 程序与数据分离
- 2.3.3 租金机制（Rent）Solana
- 2.3.4 PDA（Program Derived Address）
- 2.4 三大模型深度对比
2.BTC vs ETH vs Solana 账户模型对比
2.1 三大账户模型总览
2.2 以太坊账户/余额模型
2.2.1 核心概念
以太坊采用账户模型（Account Model），类似传统银行账户，直接记录每个地址的余额和状态。两种账户类型：
账户结构：
// 以太坊账户状态
struct Account {
uint256 nonce; // 交易计数器（防重放）
uint256 balance; // ETH余额（单位: Wei）
bytes32 storageRoot; // 存储树根哈希（仅合约账户）
bytes32 codeHash; // 代码哈希（仅合约账户）
}
2.2.2 状态转换流程
状态变化示例：
交易前:├─ Alice:{nonce:5, balance:10ETH}└─ Bob:{nonce:2, balance:5ETH}交易: Alice → Bob 转账1ETH(Gas费0.001ETH)交易后:├─ Alice:{nonce:6, balance:8.999ETH}// 余额减少, Nonce增加 └─ Bob:{nonce:2, balance:6ETH}// 余额增加2.2.3 全局状态树（Merkle Patricia Trie）
特点：
- 每个区块有一个唯一的 State Root
- 任何账户状态变化都会改变 State Root
- 通过 Merkle Proof 可验证某个账户状态
2.3 Solana 账户模型
2.3.1 核心概念
Solana 的账户模型最独特：一切皆账户（Everything is an Account）
账户结构：
2.3.2 程序与数据分离
这是 Solana 最重要的设计理念：
优势：
- 并行处理：不同用户的数据账户可以并行修改
- 降低成本：程序代码只需部署一次
- 灵活性：数据结构可以更新，无需重新部署程序
2.3.3 租金机制（Rent）Solana
要求账户支付"租金"以保持活跃状态：
租金计算公式：
2.3.4 PDA（Program Derived Address）
程序派生地址是 Solana 独有的概念，用于创建无私钥账户：
2.4 三大模型深度对比
对比表格
并行处理对比
关键结论：
- 比特币：并行验证能力强，但TPS受限于10分钟出块时间
- 以太坊：同一账户的交易必须串行（Nonce机制），限制了并行能力
- Solana：通过提前声明读写账户列表，实现智能合约级别的并行执行
