T11 · Token Program

一个现实问题

在 EVM 上发一个代币，流程你已经很熟了：写一份合约、部署、拿到一个地址，用户的余额存在你这份合约的 mapping 里。你的代币 = 你的一份代码。

你到 Solana 上做同一件事，三个意外接连出现。

第一个：你没有部署任何程序，只发了一笔交易，代币就有了。总量、精度、谁能增发，全部设置好了。你写的代码行数是零。

第二个：你想给朋友转 100 个，失败了。原因是「对方还没有这个代币的账户」。你得先替他开一个户，而且开户要交一笔押金。

第三个：你想在转账时加一点自定义逻辑——比如每笔抽 1%。你找不到任何地方可以写这段代码。

三个意外指向同一个问题：这个代币的逻辑到底跑在哪里？如果不是我的代码，那是谁的？

思想实验

对比两种发币方式。

方式 A：每个代币自己开一家银行。

你盖一栋楼（部署合约），楼里放一本账本（mapping），账本上记着「谁有多少」。一千个代币就是一千栋楼、一千本账本、一千份几乎一模一样的代码。

钱包要支持一千个代币，理论上要认识一千栋楼——好在大家盖的楼长得差不多（T9 的标准），所以钱包按同一套接口去问就行。但「长得差不多」不是强制的，所以就有了 T9 那三天的事故。

方式 B：全世界只有一套银行软件。

不盖楼了。所有代币共用同一份程序。每个代币只是一条发行信息：总量多少、精度几位、谁能增发、谁能冻结。而每个人的余额，是一个属于他自己的独立账户，账户里写着三件事：这是哪个代币、属于谁、有多少。

现在把这个模型的后果一条条推出来，这一章的所有内容都在里面：

1. 钱包只要认识一份程序，就认识所有代币。 显示、转账、授权全部统一，不需要为每个代币适配。
2. 代币作者没有地方写自定义逻辑。 转账的代码是那份共享程序的，不是你的。于是 T9 里的「转账扣费」「余额自变」这些东西，在这个模型下根本不可能存在。
3. 余额账户必须显式创建。 因为它是一个独立的账户，得有人创建它、有人为它的存储付押金。「给谁转账，谁得先有户」就是从这来的。
4. 想要自定义行为，只能由那份共享程序开放扩展点。 于是有了新版本的代币程序和它的扩展机制。

第 2 条和第 4 条合起来是这一章最有意思的地方：Solana 先用「共享程序」消灭了 T9 的那一整类坑，然后又用「扩展」把其中一部分有节制地放了回来。

你来决定

你要给 500 个新用户空投代币，他们大多数还没有这个代币的账户。怎么处理？

观察结果

四个选项本质上都在回答同一个问题：这块存储的押金，由谁出，归谁。

一条值得单独记住的结论：

同一笔存储成本，在 EVM 上藏在 Gas 里由转账者一次性烧掉，在 Solana 上变成一笔可退还的押金，归账户所有者。

这不是谁更便宜的问题，是成本被放在了不同的位置，因此可以被不同的人利用。上面那个「领空投再关户拿押金」的套路，在 EVM 上根本不存在，因为那笔钱一开始就烧掉了，没有人能退。

设计任何 Solana 上的发放机制时，把这一条放进风险清单：你付出去的押金，最终会落到谁手里。

建立模型

两种账户

Solana 上的代币由两类账户构成，它们都是 T10 讲的普通账户，owner 是那份共享的代币程序。

Mint 账户（一个代币一个）
 ├─ supply             当前总量
 ├─ decimals           精度
 ├─ mintAuthority      谁能增发。可以设成「无」，从此不可增发
 └─ freezeAuthority    谁能冻结持有人的账户。可以设成「无」

Token 账户（一个人一个代币一个）
 ├─ mint               这是哪个代币的账户
 ├─ owner              这个账户属于谁
 ├─ amount             余额
 ├─ delegate           授权给谁，以及授权多少
 └─ state              正常 / 已冻结

关联账户是其中最重要的一个约定：一个人的某个代币账户，地址由「持有人地址 + 代币程序 + Mint 地址」派生出来。这正是 T10 的派生地址在起作用——任何人都能算出「某某人的某某代币账户在哪」，不需要查询。

钱包能列出你所有的代币余额，靠的就是这个：按 owner 过滤出所有属于你的代币账户。

和 ERC20 逐条对照

这张表是这一章的核心产出，值得反复看：

倒数两行特别值得注意：增发和冻结在这里是程序原生能力，写在数据字段上，任何人都能一眼查到。 在 EVM 上你得读源码才知道有没有后门；在这里，只要读一下 Mint 账户，mintAuthority 和 freezeAuthority 是不是空，一目了然。

这是一个被低估的优点：把权限变成数据，比把权限藏在代码里更容易审计。

新版代币程序与扩展

共享程序解决了一致性，也带来了刚性：没有人能加任何新功能。于是出现了一个新版本的代币程序，它在保持同样模型的同时，允许在创建 Mint 时选择开启若干扩展。

常见的扩展覆盖这几类能力：转账时收取费用、代币不可转让、新账户默认冻结、元数据直接存在 Mint 上、利息累积、以及在转账时调用一个外部程序的钩子。

到这里，一件值得停下来想的事发生了：

转账收费、余额自变、转账时调用外部代码——这些正是 T9 里让集成方翻车的那几类行为。

区别在哪？在于它们现在是显式声明在账户上的，而不是藏在代码里的。集成方可以在接受一个代币之前，读一遍它开了哪些扩展，然后决定支不支持。T9 里你必须读源码才能发现的东西，在这里变成了一个可以被程序化检查的字段。

但风险并没有消失，只是换了形态：

• 钱包和协议需要逐个扩展去适配。 一个开了冷门扩展的代币，在很多界面上会显示异常，或者干脆不显示。
• 转账钩子意味着转账会执行外部代码。 集成方必须把它当成不可信的外部调用来对待——这和 T9 里那个带回调的代币标准是同一类风险。
• 老的集成方完全不认识这些扩展。 按旧假设写的代码，遇到收费扩展照样记错账。

所以这一章的真正结论是：共享程序消灭了「行为不可预测」，扩展把它以「可声明、可检查」的形式放了回来。可检查不等于安全，只是让检查成为可能。

它叫什么

动手

solana config set --url devnet
solana address
solana airdrop 2
solana balance

spl-token create-token --decimals 6

solana account <MINT 地址>
spl-token display <MINT 地址>

spl-token create-account <MINT 地址>
spl-token mint <MINT 地址> 1000
spl-token balance <MINT 地址>

solana-keygen new --no-bip39-passphrase -o ./wallet2.json
solana address -k ./wallet2.json

spl-token transfer <MINT 地址> 10 <WALLET2 地址>

spl-token transfer <MINT 地址> 10 <WALLET2 地址> --fund-recipient

spl-token address --token <MINT 地址> --owner <WALLET2 地址> --verbose
spl-token accounts --owner <WALLET2 地址>

spl-token authorize <MINT 地址> mint --disable
spl-token mint <MINT 地址> 1

spl-token create-token --help

AI Lab

第一步：
列出新版 Solana 代币程序提供的扩展能力。每一个说明：
它改变了什么行为、必须在什么时候开启、能不能事后关闭。
如果你不确定某个扩展是否存在，明确标注出来。

第二步：
在这些扩展里，哪些会让按旧假设写的集成方出错？
具体说明：会错在哪一步、错的表现是什么。

第三步：
把这些扩展和 ERC20 世界里的非标准实现做一个对照表：
哪些是同一类问题的两种形态？哪些是 Solana 独有的？

真实案例

改一个变量

带走的问题

本章自测