在 Solana 中，几乎所有链上状态都通过账户来表示。与传统区块链架构将代码和存储紧密耦合不同，Solana 将可执行程序与状态存储分开。这种设计使得 Solana 账户模型成为开发者在网络上构建应用时最重要的概念之一。
理解账户字段对于使用钱包、SPL 代币、NFT、PDA 或 DeFi 协议至关重要。
Solana 账户的核心结构
Solana 账户通常在内部表示为：
pub struct Account {
pub lamports: u64,
pub data: Vec<u8>,
pub owner: Pubkey,
pub executable: bool,
pub rent_epoch: Epoch,
}
每个字段在 Solana 运行时中具有不同的用途。
Lamports
字段
lamports
存储与该账户相关的 SOL 余额。
pub lamports: u64
Lamports 是 SOL 的最小单位。
1 SOL = 1,000,000,000 lamports
这在概念上类似于：
- 以太坊中的 Wei
- 比特币中的 Satoshi
Lamports 被用于：
- 交易费用
- 租金豁免
- 持有 SOL 余额
- 资助新账户
例如：
5 SOL = 5,000,000,000 lamports
在 Solana 上，每个账户必须保持一定的余额，以便在链上保持活跃状态。
数据
data
字段存储任意的二进制数据。
pub data: Vec<u8>
这是存储应用状态的地方。
在 Solana 中，程序是无状态的可执行文件，而数据账户则单独保存可变状态。由于这种架构，几乎每个去中心化应用都在很大程度上依赖于账户数据布局。
存储数据的示例包括：
SPL 代币账户
代币账户通常存储：
- 铸造地址
- 所有者地址
- 代币数量
- 委托信息
- 信息
- 账户状态
NFT元数据
NFT元数据帐户可能包含：
- 名称
- 符号
- 元数据 URI
- 版权配置
- 创作者地址
DeFi协议
流动性池和自动做市商通常存储：
- 池储备
- 费用结构
- LP供应
- 管理设置
大多数Solana程序使用以下格式序列化账户数据：
- Borsh
- Anchor序列化
- 原始字节布局
所有者
owner
字段指定哪个程序控制该账户。
pub owner: Pubkey
这是一个
Solana 中最重要的安全机制之一。
只有拥有者程序被允许修改账户的数据字段。
例如：
系统程序
11111111111111111111111111111111
系统程序拥有标准的 SOL 钱包账户。
SPL 代币程序
SPL 代币程序拥有：
- 代币账户
- 铸币账户
自定义程序
如果开发者为自定义协议创建一个 PDA 账户，拥有者字段通常设置为项目的程序 ID。
这种拥有模式在程序之间创建了严格的执行边界，防止未授权的状态修改。
可执行性
executable
字段用于确定账户是否包含可执行的程序代码。
pub executable: bool
如果值为：
true
则该账户被视为程序账户。
程序账户存储可以被 Solana 运行时执行的已编译 BPF 字节码。
典型示例包括：
账户类型 可执行性
钱包账户 false
代币账户 false
PDA账户 false
程序账户 true
大多数 Solana 账户是不可执行的数据账户。
租赁周期
rent_epoch
字段与 Solana 的租赁系统相关。
pub rent_epoch: Epoch
由于链上存储会消耗验证者资源，Solana 最初引入租金以防止无限制的存储增长。
账户余额不足时，最终可能会被网络收回。
如今，大多数应用程序通过使账户免于支付租金来完全避免租金收取。
开发者通常使用以下函数计算所需的最低余额：
getMinimumBalanceForRentExemption(space)
一旦账户持有足够的 lamports 满足免租金要求，就可以永久保持活跃状态。
账户地址和公钥
在使用 RPC API 时，开发者通常会看到额外的
字段：
{
"pubkey": "...",
"account": {
"lamports": 123,
"owner": "...",
"data": "...",
"executable": false,
"rentEpoch": 123
}
}
pubkey
是账户地址。
有趣的是，公钥并未存储在账户结构内部。相反，Solana 在内部将地址映射到账户数据结构。
从概念上讲，这类似于：
HashMap<Pubkey, Account>
为什么 Solana 使用这种架构
账户模型是 Solana 实现极高吞吐量的原因之一。
在执行交易之前，Solana 要求交易需要
声明哪些账户将被读取或写入。
这允许运行时确定：
- 哪些交易发生冲突
- 哪些交易可以并行运行
- 哪些状态访问是孤立的
因此，Solana可以同时处理许多独立的交易，而不是依次执行所有交易。
这种并行执行模型与许多传统区块链 fundamentally 不同。
