提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档
文章目录
- [2.BTC vs ETH vs Solana 账户模型对比](#2.BTC vs ETH vs Solana 账户模型对比)
-
- [2.1 三大账户模型总览](#2.1 三大账户模型总览)
- [2.2 以太坊账户/余额模型](#2.2 以太坊账户/余额模型)
-
- [2.2.1 核心概念](#2.2.1 核心概念)
- [2.2.2 状态转换流程](#2.2.2 状态转换流程)
- [2.2.3 全局状态树(Merkle Patricia Trie)](#2.2.3 全局状态树(Merkle Patricia Trie))
- [2.3 Solana 账户模型](#2.3 Solana 账户模型)
-
- [2.3.1 核心概念](#2.3.1 核心概念)
- [2.3.2 程序与数据分离](#2.3.2 程序与数据分离)
- [2.3.3 租金机制(Rent)Solana](#2.3.3 租金机制(Rent)Solana)
- [2.3.4 PDA(Program Derived Address)](#2.3.4 PDA(Program Derived Address))
- [2.4 三大模型深度对比](#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 状态转换流程

状态变化示例:
bash
交易前:├─ Alice: {nonce: 5, balance: 10 ETH}
└─ Bob: {nonce: 2, balance: 5 ETH}
交易: Alice → Bob 转账 1 ETH (Gas费 0.001 ETH)
交易后:├─ Alice: {nonce: 6, balance: 8.999 ETH} // 余额减少, Nonce增加
└─ Bob: {nonce: 2, balance: 6 ETH} // 余额增加
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:通过提前声明读写账户列表,实现智能合约级别的并行执行