本文由 AI 生成，请独立核实重要信息。

Solana 账户模型详解

Crypto Wiki|Oct 9, 2026|★★★★★★4.5 (500 人评分)
Solana 账户模型Solana 账户程序派生地址Solana 租金豁免Solana 并行执行
AI 摘要

Learn how Solana's account model stores state, manages ownership, and enables parallel transaction processing for developers and investors.

Solana 账户模型将余额、程序代码、代币持有量和应用程序状态存储在具有明确所有权规则的独立账户中。这篇通俗易懂的指南在深入介绍字段、账户类型、租金豁免和实际示例之前，先为普通读者解释该模型。

诸如租金处理、账户大小限制和客户端 API 等实现细节可能会发生变化。开发人员在部署前应查阅当前的 Solana 文档并查询当前网络参数。

如果您来自以太坊，Solana 的账户模型起初可能会感觉有些颠倒。这种反应是一个正确的起点。您在以太坊上建立的思维模型无法顺利迁移，试图强行套用会在每一步都造成困惑。

Solana 账户模型是通过该架构系统，将所有链上状态存储在称为账户的离散存储单元中。每个钱包余额、程序、代币持有量和应用程序状态记录都存在于一个独立的账户中，该账户具有明确的所有者、lamport 余额以及关于谁可以对其进行读写的明确规则。在 Solana 上，没有任何东西存在于账户之外。

您可以将 Solana 想象成一个全球性的文件归档系统。每段数据都存在于一个单独的文件中，称为账户。程序是读取和写入这些文件的应用程序，但程序只能修改其拥有的文件。运行时会在协议层面强制执行这些所有权规则，没有任何例外。

本文将介绍每个 Solana 账户的五个字段、五种不同的账户类型、租金和租金豁免的工作原理、程序派生地址 (PDA) 是什么以及它们为何存在、账户如何创建和关闭，以及为何这种架构使得 Solana 的并行交易处理成为可能。Solana 程序以 Rust（或 C/C++）编写，尽管 Anchor 等框架能抽象掉许多账户管理样板代码。本文将涵盖两者所需的概念基础。

Solana 账户模型：账户剖析

Solana 账户是网络上的一个标记化存储槽，其中包含以 lamport 为单位的余额、任意数据负载以及一组定义其所有者和功能元数据字段。在 Solana 上，所有数据，从钱包余额到程序状态再到代币持有量，都存储在账户中。

Lamports 是 SOL（网络的原生代币）的最小单位。Lamports 之于 SOL 就像美分之于美元，但精度为九位小数：1 SOL 等于 1,000,000,000 lamports。每个账户都包含一个 lamport 余额，用于资助账户在网络上的持续存在，并代表可转让的价值。

每个 Solana 账户包含恰好五个字段：

  • lamports (u64)：账户以 lamport 为单位的余额。此字段用于支付租金，并且可以转账给其他账户。
  • data (字节数组)：原始二进制存储。在可执行账户中，此字段包含已编译的 BPF/SBF 字节码。在数据账户中，它包含结构化的应用程序状态。按照当前主网参数，最大数据字段大小为 10 MB。
  • owner (Pubkey)：对该账户数据字段拥有独占写入权限的程序的 32 字节公钥。对于以太坊开发者来说，这是最反直觉的字段。从协议层面看，您的钱包地址不归您所有；它归 System Program 所有。关于 owner 字段的完整论述，请参见 账户所有权和权限部分。
  • executable (bool)：一个布尔标志。如果为 true，则数据字段包含程序字节码，该账户充当程序。如果为 false，则账户存储状态或持有余额。
  • rent_epoch (u64)：一个用于跟踪上次收取租金的 epoch 的旧字段。截至 2024 年，租金收取已被弃用，取而代之的是默认的租金豁免模式。此字段仍然存在于账户结构体中，但不再积极使用。

以下是钱包账户作为数据结构的样子：

{
  "lamports": 1000000000,
  "data": [],
  "owner": "11111111111111111111111111111111",
  "executable": false,
  "rent_epoch": 0
}

Solana 账户模型账户结构图，显示了五个核心字段：lamports、data、owner、executable、rent_epoch

owner 字段是协议层面的概念：控制数据字段写入权限的程序。Authority 是一个独立约定，存储在程序管理的内部数据中，例如代币账户内的 transfer authority 字段。这两者并不相同；所有权部分会精确地区分这一点。

五种 Solana 账户类型

Solana 有五种不同的账户类型，每种账户类型根据其 owner 字段和 executable 标志，发挥着特定的架构作用。账户类型不是作为一个单独的字段存储的；它是根据账户的拥有者及其是否包含可执行代码来推断的。

System-Owned Accounts（钱包账户）

System-owned 账户只包含用户的 SOL 余额，除此之外别无他物。其 owner 始终是 System Program (11111111111111111111111111111111)，executable 标志为 false，data 字段为空。当您与 Phantom 或 Solflare 分享钱包地址时，您分享的是一个 system-owned 账户的地址。您通过使用您的私钥签署交易来控制它，但 System Program 是协议层面的所有者。

Program 账户是包含已编译 BPF/SBF 字节码的可执行账户。executable 标志为 true，owner 为 BPF Loader。Program 账户在设计上是无状态的；它们只包含代码，从不包含状态。在以太坊上，一个智能合约在一个合约地址处同时存储其代码和状态。在 Solana 上，代码存在于一个 program 账户中，状态存在于单独的数据账户中，始终分开存储。

Program 账户可以存储可执行代码，其中 executable = true，data 字段包含 BPF/SBF 字节码。非可执行的数据账户 executable = false，并存储状态。

Data Accounts（程序拥有的账户）

Data 账户是一种非可执行账户，由特定程序拥有，并将其程序状态存储在其 data 字段中。executable 标志为 false。Owner 是创建和管理该账户的任意程序。您的 USDC 代币余额、一个 DeFi 借贷仓位、一个 NFT 元数据记录：每个都存在于由相关程序拥有的独立数据账户中。

Native Program Accounts 是在网络创世时部署在固定地址的内置程序。它们包括 System Program、BPF Loader、Vote Program 和 Stake Program。这些是核心基础设施程序，用户无法替换或升级。它们的 executable 标志为 true。

Sysvar 账户是 Solana 运行时预先填充的只读账户，让程序可以访问当前网络状态。您可以将 sysvar 账户想象成法院的政府公告栏：公开可读，由权威来源维护，但任何私人实体都无法修改它们。SysvarC1ock11111111111111111111111111111111 的 Clock sysvar 提供当前的区块时间戳和区块号。Rent sysvar 提供当前的租金参数。

账户类型所有者可执行主要用途示例
系统所有（钱包）系统程序false持有 SOL 余额Phantom 钱包地址
程序账户BPF 加载器true存储程序字节码SPL 代币程序
数据账户特定程序false存储程序状态USDC 代币账户
原生程序运行时 (genesis)true核心基础设施投票程序
Sysvar 账户Solana 运行时false网络状态访问Clock sysvar

程序在 Solana 上是无状态的。所有状态都存储在它们拥有并控制的数据账户中。这种逻辑与状态的分离是一项设计决策，使得本文中的其他一切成为可能。

程序 vs 数据账户：逻辑与状态的分离

Solana 程序是无状态的。它们本身不持有任何数据，它们操作的每一部分状态都存储在运行时传递给程序的独立数据账户中。

将 Solana 程序想象成银行的交易处理软件，而数据账户则是个人客户的账户记录。软件知道如何处理充值和提现，但实际余额存在于客户的档案中，而不是软件本身内部。在以太坊上，与之对应的是一家银行，其软件和每个客户的记录都共享同一个锁定的房间，程序及其状态在单个地址处密不可分。

四个属性定义了 Solana 程序如何与账户交互：

  • 程序处理指令，并对调用时传递给它们的账户进行读取或写入。它们不持有自己的状态。
  • 程序一旦部署即不可变，除非开发人员在部署时选择了可升级的加载器。
  • 只有拥有数据账户的程序才能修改该账户的数据字段。任何用户都可以调用程序，但对任何账户的写入权限都受所有权管控。
  • executable 标志在协议层级强制执行这种区分，且在部署后无法更改。

Solana 程序是无状态的，但 Solana 系统作为一个整体是有状态的。状态是持久的；它存在于数据账户中。区别在于状态始终位于程序外部，从未捆绑在程序内部。

这种分离带来了性能上的优势。因为每笔交易在开始执行前必须声明它将读取或写入哪些账户，所以 Sealevel 运行时可以识别非重叠的交易并同时运行它们。关于账户模型如何实现并行执行的完整解释见下文。

账户所有权和权限：谁在 Solana 上控制什么

Solana 账户中的所有者字段标识了拥有修改该账户数据专属权限的程序。在协议层级，只有该程序可以写入数据字段。

所有者字段存储一个 32 字节的程序公钥。对于钱包账户，所有者是系统程序。对于代币账户，所有者是 SPL 代币程序。对于自定义数据账户，所有者是创建它们的任何程序。所有权在账户创建时设置，并由 Solana 运行时在每笔交易中强制执行。

想象一下银行的保险箱。银行拥有该箱子，并且是唯一能够以物理方式打开并修改其内容的实体。你持有一把钥匙，可以指示银行如何处理你的箱子，但只有银行才能接触内容物。在 Solana 上，程序就是银行，而你就是持有钥匙的账户持有人。

所有者 (Owner) 与权限 (Authority) 之间的区别困扰了许多以太坊开发者：

  • 所有者 (Owner)（协议字段）：可以修改账户 data 字段的程序 ID。在账户创建时设置。由 Solana 运行时强制执行，而非由任何程序的逻辑强制执行。
  • 权限 (Authority)（数据惯例）：由所属程序存储在账户 data 字段内的公钥。它授权该程序逻辑内的特定操作。由程序本身强制执行，而非运行时。

对于 USDC 代币账户，代币程序是所有者，可以修改存储在数据字段中的余额。你的钱包是转账权限，即记录在数据字段内的公钥，代币程序在执行转账前会对其进行检查。这些是执行不同功能的逻辑上不同的密钥。将它们混为一谈是 Solana 新开发中最常见的错误之一。

Solana 账户租金和免租金说明

Solana 上的租金是一种存储费用，以 lamports 计价，向账户收取以补偿验证者维护链上状态的成本。持有最低 lamport 余额（即免租金阈值）的账户可永久免除租金费用，且永远不会被运行时清除。

什么是 Solana 租金？

验证者必须将所有活跃账户状态存储在内存中。无限数量的零余额账户将成为针对网络的拒绝服务攻击向量，因此 Solana 要求账户持有最低 lamport 余额，作为支付存储成本的承诺。最初的租金模型按 epoch 收取与数据大小成比例的费用，低于最低余额的账户将被垃圾回收。该模型已被弃用。

根据当前的 Solana 主网参数（在 SIMD-0084 中正式确定），所有新账户在创建时必须免租金。账户结构中的 rent_epoch 字段现在是一个遗留字段。

免租金如何运作

要使你的账户免租金，请在提交创建交易时为其注入至少与其数据大小对应的最低 lamport 余额。按当前网络参数：

  • 0 字节账户（钱包）：约 890,880 lamports (~0.00089 SOL)
  • 165 字节账户（标准代币账户）：约 2,039,280 lamports (~0.00204 SOL)
  • 1,024 字节数据账户：约 7,180,800 lamports (~0.00718 SOL)

这些值是近似值，可能会随运行时参数的变化而改变。使用 Solana CLI 或 getMinimumBalanceForRentExemption RPC 方法计算当前确切的最小值：

solana rent 0       # 0 字节账户的免租金金额
solana rent 165     # 标准代币账户的免租金金额

免租金就像存储单元的押金。你锁定最低 lamport 余额以保证账户在网络上的存在。与手续费不同，这笔押金是完全可回收的。当你关闭账户时，这些 lamports 将退还给你。

租金计算中使用的 lamport 单位已在账户解剖部分定义。要在程序创建数据账户时使其免租金，请在构建创建交易之前在客户端调用 getMinimumBalanceForRentExemption(dataSize)，然后在指令中包含该 lamport 金额。

Solana vs 以太坊 vs 比特币：账户模型比较

Solana 账户和以太坊账户有什么区别？

在以太坊上，智能合约将其代码和状态捆绑在同一个地址。合约账户同时持有逻辑及其操作的数据。在 Solana 上，代码和状态始终位于不同的账户中：程序（逻辑）存在于可执行账户中，而所有状态都存在于这些程序所拥有的独立数据账户中。这种分离是 Solana 所有差异化设计的架构基础。

比特币采取了完全不同的方法，使用 UTXO（未花费交易输出）模型。UTXO 就像支票簿中未兑现的支票：每笔交易消耗现有的输出并创建新的输出。没有随时间持有余额的持久账户。你的余额是与你的密钥相关联的未花费输出的总和。比特币的模型早于可编程状态的概念，这就是为什么其智能合约能力仅限于比特币脚本 (Bitcoin Script)。

功能比特币 (UTXO 模型)以太坊 (EVM 模型)Solana (账户模型)
状态存储单元未花费交易输出 (UTXO)账户 (EOA 或合约)账户 (5 种类型变体)
逻辑与状态不适用（无合约状态）共同部署在合约账户中始终分离（程序 + 数据账户）
账户所有权UTXO 被花费，非持久所有由私钥 (EOA) 或合约代码控制由系统程序或特定程序所有
存储成本机制无持久存储费每步操作消耗 Gas；无押金免租金 Lamport 充值（可收回）
并行执行受限 (UTXO 集扫描)顺序执行（全局状态冲突）高（前期账户声明支持调度）
智能合约模型受限 (Bitcoin Script)全功能 (Solidity，状态共存)全功能（程序无状态，状态外置）

包括以太坊、Polygon、BNB Chain 和 Avalanche C-Chain 在内的 EVM 兼容网络都共享同一种账户模型，而 Solana 则与此不同。一次对比即可涵盖所有这些网络。

在以太坊上，用户钱包被称为外部拥有账户 (EOA)。在 Solana 上，对应的是由密钥对控制的系统所有账户；其机制类似，但所有者字段被显式设置为系统程序，而不是隐式的。

以太坊开发者必须摒弃的旧观念

在编写可运行的 Solana 程序之前，需要进行三个心智模型的转变：

  1. 程序不持有自身状态。数据账户才持有。不要在程序地址中寻找状态。
  2. 在协议层面，你钱包的所有者并不是你。你通过签名控制账户；系统程序拥有数据字段。
  3. 存储不是免费的。每个数据账户都需要 Lamport 充值以实现免租金。在设计创建账户的程序时，请为这项成本做好预算。

Solana 将代码与状态严格分离是并行执行的前提，这一关联在 Sealevel 与并行执行章节 中有详尽探讨。

账户模型如何驱动 Solana 的速度：Sealevel 与并行执行

Solana 的账户模型实现了并行处理，因为每笔交易在执行开始前必须显式声明它将读取或写入的完整账户列表。Sealevel 作为 Solana 的并行智能合约运行环境，利用这些前期声明来识别涉及不同账户的交易，并同步执行它们。

以下是具体的因果链条：

  1. 在任何执行发生前，Solana 交易包含一份其将访问的所有账户的完整列表，每个账户被标记为只读或读写。
  2. Sealevel 检查当前时段 (Slot) 中的所有待处理交易。
  3. 共享至少一个读写账户的交易将按顺序排列。访问完全不同账户的交易被识别为互不冲突。
  4. 互不冲突的交易在多个 CPU 核心上同步执行。

以太坊的 EVM 针对共享的全局状态顺序执行交易。由于合约状态与合约代码部署在一起，要确定读写冲突需要先执行交易，这使得在执行前进行静态调度变得不可能。

可以将 Sealevel 想象成一家拥有许多结账通道的超市。每笔交易就是一个带有声明清单的顾客。只要两位顾客没有伸手去拿同一件商品，他们就可以同时结账。Solana 提前准确知道每笔交易需要什么，因为账户模型强制要求预先声明。

由 Solana 联合创始人 Anatoly Yakovenko 发明的历史证明 (PoH) 提供了一个加密时钟，允许验证节点在无需实时协调的情况下就交易顺序达成一致。Solana 使用权益证明 (PoS) 进行共识（验证节点质押 SOL 参与区块生产），并使用 PoH 作为时间层。结合账户模型的前期账户声明，这种架构允许 Sealevel 并行处理不冲突的交易，而无需在每个步骤等待全网确认。

账户模型不仅仅是一个孤立的存储方案。它是实现并行性的前提，也是 Solana 吞吐量和扩展性优势的技术根源。

实际案例：Solana 上的代币账户、NFT 和 DeFi

Solana 上的每项资产——无论是代币余额、NFT，还是流动性仓位——都是一个具有特定数据布局的 Solana 账户。上述抽象架构体现在每个 Solana 用户都会遇到的三种模式中。

SPL 代币账户

SPL 代币是 Solana 上对应以太坊 ERC-20 的代币，由 SPL 代币程序管理，该程序拥有网络上所有的代币账户。你的钱包地址仅持有 SOL (Lamports)。你持有的每种代币，无论是 USDC、JTO、BONK 还是其他任何代币，都存在于由 SPL 代币程序拥有的专用代币账户中。

代币账户的数据字段存储三类信息：代币铸造地址（该账户持有哪种代币）、所有者权限公钥（你的钱包地址，用于授权转账）以及当前的代币余额。在以太坊上，给定代币的所有 ERC-20 余额都存在代币合约的内部映射中。在 Solana 上，每个（用户，代币）组合都需要自己的专用账户。

这就是为什么 Solana 钱包在第一次接收新代币时会提示你创建代币账户。按当前网络参数，对于标准的 165 字节账户，该创建过程需要大约 0.00204 SOL 的免租金 Lamport 充值。

关联代币账户 (ATA)

关联代币账户 (ATA) 是一种代币账户，其地址是根据你的钱包地址和代币铸造地址确定性派生的 PDA。由于地址是确定性的，任何协议都可以计算出你的 USDC 账户应该在哪里，而无需存储查找表。ATA 是几乎所有 Solana 钱包和协议使用的标准代币账户类型。

ATA 是 PDA 派生的一种应用。你可以为同一个铸造地址拥有多个代币账户，但 ATA 是协议默认使用的规范账户。

Solana 上的 NFT

Solana 上的 NFT 至少由两个账户组成：一个由代币程序拥有的铸造账户（定义代币供应量恰好为 1），以及一个由 Metaplex 代币元数据程序拥有的元数据账户（存储 NFT 的名称、符号、图像 URI 和版税配置）。NFT 图像不存储在链上；只有指向它的 URI 存在于元数据账户中。代币余额 (1 NFT) 存储在代币账户中，与任何其他 SPL 代币相同。

Solana 上的去中心化金融协议（包括去中心化交易所、借贷平台和流动性池）将每个用户仓位、资金池状态和协议配置存储在专用数据账户中，并通过程序拥有的 PDA 自主控制池内资金。

为什么 Solana 账户模型对 SOL 至关重要

注： 本节解释 Solana 账户模型如何影响 SOL 的技术效用。本文内容均不构成财务建议或投资推荐。

账户模型不仅是开发者关心的问题。在各大加密货币交易所均可交易的 SOL 是网络的原生效用代币。账户模型是网络层需求和使用 SOL 的主要机制。

SOL 通过三种不同的机制在账户模型中被使用：

免租金充值： Solana 上的每个账户都必须持有 Lamport 余额才能存在于网络上。由于任何时候都有数百万个代币账户、程序数据账户、NFT 记录和去中心化金融状态账户处于活跃状态，这为 SOL 创造了持续的基础需求。只要账户保持开启状态，这些 Lamport 就会被锁定在账户中，从流动循环中移除。

交易费用： 每一个创建或修改账户的交易都会支付一笔以 lamports 为单位的基础费用。根据当前费用结构，每笔费用的部分将被销毁，从而在每次交易中减少流通供应量。

验证者质押： 验证者通过 Solana 的权益证明机制质押 SOL 来参与共识，并因验证网络上的账户状态转换而获得奖励。

随着链上活动的增长，更多的 DeFi 协议、更多的 NFT 系列、更多的代币启动，账户数量也随之成比例增长。更多的账户需要更多的 SOL 锁定在租金豁免充值中。

锁定在租金豁免账户中的 lamports 类似于网络持有的保证金：不会被花费，但只要这些账户保持开放就会被占用。当账户关闭时，这些 lamports 将返还给所有者。

相关 Solana 架构资源

与 Solana 程序库 一起理解代币账户会更容易，而并发性则在 Sealevel 并行处理 指南中得到解释。读者可以查看 SOL 价格页面;)，评估质押相关产品的用户可以单独查看 SOL 赚币,)，包括其当前条款和风险。

常见问题解答：Solana 账户模型

Solana 账户和以太坊账户有什么区别？

在以太坊上，一个智能合约在同一地址存储其代码和状态。在 Solana 上，代码和状态始终位于不同的账户中：程序是无状态的可执行账户，而所有状态都存在于由这些程序拥有的独立数据账户中。这种分离使得 Sealevel 能够并行执行非冲突交易，这在以太坊的同址状态模型中是不可能的。

Solana 上的租金是什么以及它是如何运作的？

Solana 上的租金是在网络上存储数据的成本，以 lamports 计价。账户无需支付持续费用，但必须预先充值最低 lamport 余额（租金豁免阈值），以避免被运行时清除。该充值是可恢复的：当账户关闭时，lamports 会返还给所有者。对于标准的 165 字节代币账户，根据当前网络参数，该充值约为 0.00204 SOL。

什么是 Solana 上的程序派生地址 (PDA)？

PDA 是一个 Solana 账户地址，通过程序 ID 和一组种子值确定性地派生而来。它没有对应的私钥，因此只有派生它的程序才能通过跨程序调用 (CPI) 代表其授权交易。PDA 为程序提供了对账户的自主、无需信任的控制，这是 DeFi 协议、NFT 托管和关联代币账户的要求。

Solana 的账户模型如何实现并行处理？

每个 Solana 交易在执行前都必须声明它将读取或写入的所有账户的完整列表。Sealevel（Solana 的并行智能合约运行时）利用这些声明来识别非冲突交易，并在多个 CPU 核心上同时执行它们。这种静态调度之所以可行，是因为代码和状态存在于独立的、明确拥有的账户中，使得读/写冲突在执行开始前即可检测到。

Solana 账户中的 owner 字段是什么？

owner 字段是一个 32 字节的公钥，用于标识有权修改账户 data 字段的程序。对于钱包账户，owner 是 System Program。对于代币账户，owner 是 SPL Token Program。owner 字段是一个由 Solana 运行时强制执行的协议级概念。它不同于某些程序管理的数据账户（如代币账户）内部存在的“authority”字段。

SOL 在账户模型中是如何使用的？

SOL 通过三种机制在账户模型中使用：每个账户必须持有一个 lamport 余额（SOL）才能在网络上存在；创建账户需要 SOL 来为租金豁免充值提供资金；处理和存储账户状态的验证者必须质押 SOL 才能参与共识。随着网络的增长，对 SOL 的结构性需求也随之增长。

Sealevel 是什么，它与账户有什么关系？

Sealevel 是 Solana 的并行智能合约运行时。它可以同时执行多个交易，因为 Solana 的账户模型要求每个交易预先声明它将读取或写入的账户。Sealevel 利用这些声明来识别非冲突交易，并将它们安排为并行运行。没有账户模型的预先声明，这种静态调度是不可能实现的。

Solana 上的钱包账户和程序账户有什么区别？

钱包账户是一个系统拥有的账户，其 data 字段为空，仅持有 SOL 余额，由一个密钥对控制。程序账户是一个可执行账户，executable = true，包含已编译的 BPF/SBF 字节码；它由 BPF Loader 拥有，自身不持有任何状态。在 Solana 账户五种类型 部分的账户类型表中并排展示了所有五种变体。

一个 Solana 交易可以引用多少个账户？

根据当前主网参数，单个 Solana 交易最多可以引用 64 个账户，通过地址查找表 (Address Lookup Tables) 从最初的 32 个增加。每个账户在执行开始前必须声明为只读或读写。这种预先声明是 Sealevel 能够在不先运行交易以检测冲突的情况下安排并行执行的原因。

一个 Solana 账户可以持有多个代币吗？

不可以。每种 SPL 代币类型都需要自己的专用代币账户。一个钱包地址只持有 SOL；每种额外的代币都需要一个通过其 authority 字段链接到钱包的单独代币账户。这就是为什么当您接收以前未持有过的代币时，Solana 钱包会提示您创建一个新的代币账户，并且该创建会产生一笔小额的租金豁免 lamport 充值。

主要收获

  • Solana 上的每一份链上状态都存在于一个具有五种字段的账户中：lamports、data、owner、executable、rent_epoch。
  • 程序是无状态的。所有状态都存在于程序拥有和控制的独立数据账户中。
  • 账户需要一笔 lamport 充值（租金豁免）才能在网络上持久存在。该充值在账户关闭时可恢复。
  • PDA 是没有私钥的地址，从程序 ID 和种子确定性地派生而来，只能由创建它们的程序通过 CPI 进行签名。
  • 每个交易都会预先声明其账户访问列表。Sealevel 利用这些声明同时执行非冲突的交易。

后续步骤

  • 有关具体实现，请参阅 Solana 账户文档，位于 docs.solana.com。
  • 开发其首个 Solana 程序的开发者可以从 Anchor 框架, 开始，该框架抽象了许多账户管理样板代码（程序以 Rust 或 C/C++ 编写）。
  • 对于 JavaScript/TypeScript 的实际代码示例和工作示例，Solana Cookbook 提供了实践参考资料。