T10 · Solana Program

一个现实问题

你打算把 T7 那个押金合约搬到 Solana 上。第一行就卡住了。

你想写 balanceOf[用户] += 金额，但程序里没有存储。没有状态变量，没有 mapping，翻遍文档也找不到「这份程序自己的数据放在哪」。

接着是第二个意外：调用方在发交易时，必须提前列出这笔交易会读写哪些账户。不是程序去找数据，是调用方把数据递给程序。

第三个意外紧接着来：既然账户是调用方递进来的，那他递错一个会怎样？他把别人的账户递给你，你照着改，会发生什么？

三个意外指向同一件事：Solana 上，「这块数据是谁的」不是链替你保证的，是你自己要证明的。这一章就是在回答：状态放在哪，以及怎么证明它是对的。

思想实验

把一个 Solana 程序想成一个没有硬盘的纯函数。

它只有代码，没有私有存储。每次被调用时，调用者会递给它一叠文件夹（账户），函数读这些文件夹、改这些文件夹，然后结束。文件夹不属于函数，函数只是被授权去改它们。

每个文件夹上贴着四样信息：

地址        这个文件夹放在哪
owner       哪个程序有权修改它的内容
data        里面装的字节
lamports    里面存了多少钱（同时也是它的「租金押金」）

关键的一条：只有 owner 那个程序能修改文件夹的内容。 别的程序可以读，但改不了。这是整个模型的地基。

现在推演两个问题。

问题一：调用者可以递错文件夹吗？

可以，而且非常容易。你的程序要「给用户的计数器加一」，用户递给你的却是另一个人的计数器。函数照着改了，因为对函数来说，它只看到一叠字节。

所以：程序必须自己检查「你递给我的这个文件夹，确实是我认识的那一个」。 在 EVM 上，balanceOf[msg.sender] 这个表达式本身就保证了你只能碰自己的那一格；在 Solana 上，这个保证要你亲手写出来。

问题二：既然文件夹是被递进来的，程序怎么创建一个「只属于自己」的文件夹？

答案是让文件夹的地址从程序 ID 和一段自己定的标签推导出来。这样的地址有两个性质：任何人都能算出它是哪个地址（所以客户端知道该递哪一个），但没有人拥有它的私钥（所以只有派生它的那个程序能代表它行动）。

于是 EVM 里的 balanceOf[用户] 在 Solana 上变成了「用 [标签, 用户地址] 派生出来的那个账户」。mapping 的每一个格子，在这里都是一个独立的、可寻址的账户。

你来决定

你要写一个最简单的计数器：每个用户有自己的计数，调用 increment 加一。怎么保证「用户只能加自己的」？

观察结果

四个选项摆在一起，能看出 Solana 的账户模型是怎么同时决定安全和性能的：

一条必须刻进肌肉记忆的结论：

在 EVM 上，链替你保证了「你只能动自己那一格」。在 Solana 上，这句话是你自己写出来的一行校验。

这不是哪个模型更好的问题。它是一个交换：Solana 把「读写哪些数据」提前声明出来，换来了并行执行的能力；代价是校验责任从平台转移到了程序作者。

这也解释了为什么 Solana 的安全审计清单和 EVM 完全不同。EVM 审计的重点是重入、溢出、权限；Solana 审计的重点几乎全是账户校验的各种漏检。

建立模型

账户的五个字段

Account
 ├─ address      32 字节的地址
 ├─ owner        哪个程序能修改 data。普通钱包的 owner 是系统程序
 ├─ data         任意字节。程序自己决定怎么解释它
 ├─ lamports     余额。同时必须达到「免租门槛」，否则账户会被回收
 └─ executable   这是一个程序，还是一份数据

三类账户，对应三种角色：

账户校验清单

这是这一章最该被打印出来贴在显示器上的东西。每一个传入的账户，都要过一遍：

1. owner 对吗？ 这个账户的 owner 是不是我这个程序？不是，就说明数据不可信。
2. 地址对吗？ 如果它应该是一个派生账户，用同样的标签重新推导一遍，和传进来的地址比对。
3. 签名了吗？ 需要授权的账户，是不是真的在这笔交易里签了名？只检查地址不检查签名，等于没检查。
4. 类型对吗？ 两种不同结构的账户，字节长度可能一样。必须有一个标记区分，否则攻击者可以把 A 当 B 传进来。
5. 是不是同一个？ 需要两个不同账户的地方，检查它们的地址不相等。很多「从自己转给自己」的漏洞就出在这里。
6. 可写吗？ 需要修改的账户，调用方有没有把它标成可写。

漏掉任何一条，都对应着一类真实存在过的攻击。第 3 条和第 1 条是历史上被利用最多的两条。

派生地址与程序间调用

派生地址：用程序 ID 加上一组自定的标签，算出一个落在曲线之外的地址——也就是说，数学上不存在对应的私钥。没有人能用私钥代表它签名，但派生出它的那个程序可以在调用时代表它「签名」。

这一条性质有两个直接用途：

• 把它当 mapping 的格子用：[b"counter", 用户地址] 就是那个用户的计数器。
• 把它当金库用：资产存在一个派生账户里，只有程序逻辑能把钱转出去，任何人拿私钥都不行。

程序间调用：一个程序在执行过程中调用另一个程序。调用时可以带上自己派生账户的标签，让被调用方相信「这确实是我这个程序授权的」。转代币、创建账户、调用其他协议，全都走这条路径。

用框架把校验变成声明

手写上面那六条检查，又长又容易漏。主流的 Rust 框架把它们变成了声明式的约束，写在账户结构上：

use anchor_lang::prelude::*;

// 部署前用 `anchor keys list` 拿到真实的程序 ID 替换这里，不要照抄
declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");

#[program]
pub mod counter {
    use super::*;

    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
        let counter = &mut ctx.accounts.counter;
        counter.authority = ctx.accounts.user.key();
        counter.count = 0;
        Ok(())
    }

    pub fn increment(ctx: Context<Increment>) -> Result<()> {
        let counter = &mut ctx.accounts.counter;
        // 生产代码用 checked_add，溢出时返回错误而不是回绕
        counter.count = counter.count.checked_add(1).unwrap();
        Ok(())
    }
}

#[account]
pub struct Counter {
    pub authority: Pubkey,   // 32 字节
    pub count: u64,          // 8 字节
}

#[derive(Accounts)]
pub struct Initialize<'info> {
    // init        由本程序创建这个账户，并成为它的 owner
    // payer       谁出钱付免租押金
    // space       8 字节的类型标记 + 32 + 8
    // seeds/bump  地址由固定标签和 user 推导，任何人都能算出来，但只有本程序能写
    #[account(
        init,
        payer = user,
        space = 8 + 32 + 8,
        seeds = [b"counter", user.key().as_ref()],
        bump
    )]
    pub counter: Account<'info, Counter>,

    #[account(mut)]
    pub user: Signer<'info>,          // Signer 这个类型本身就强制了「必须签名」

    pub system_program: Program<'info, System>,
}

#[derive(Accounts)]
pub struct Increment<'info> {
    // seeds/bump  重新推导一遍地址，和传进来的比对
    // has_one     账户数据里的 authority 必须等于下面那个 authority 账户
    #[account(
        mut,
        seeds = [b"counter", authority.key().as_ref()],
        bump,
        has_one = authority
    )]
    pub counter: Account<'info, Counter>,

    pub authority: Signer<'info>,
}

这段代码里，六条校验被框架接管了五条：

• Account 这个包装类型自动检查 owner 是本程序，以及类型标记匹配（那多出来的 8 字节就是类型标记）。
• seeds 加 bump 自动做地址重新推导与比对。
• Signer 类型自动检查签名。
• mut 声明可写。
• has_one 做字段与账户的一致性比对。

但框架接管的是「你写出来的那些约束」，不是「你忘了写的那些」。 上面的 increment 如果去掉 has_one 和 seeds，它仍然能编译、能跑、能通过所有正常测试——然后被任何人拿去改别人的计数器。这一点在 AI Lab 里会被专门验证。

它叫什么

动手

solana --version
anchor --version
anchor init counter

anchor build
anchor keys list      # 输出你这个项目的程序 ID

solana config set --url devnet
solana airdrop 2
anchor deploy

solana account <你算出来的账户地址>

AI Lab

第一步：
这是一个 Solana 程序。逐个指令、逐个账户列出：
它期望这个账户是什么、代码里实际做了哪些校验、缺了哪些校验。
用表格输出，不要给修复建议。

第二步：
挑出你认为最严重的那一条，写出一个具体的攻击：
攻击者用什么账户、按什么顺序发什么指令、最终得到什么。
要具体到每个账户传什么，不要用抽象描述。

第三步：
写一个测试，它在当前代码上必须成功执行攻击，在修好之后必须失败。

真实案例

改一个变量

带走的问题

本章自测