Anchor 入门：SPL 与 Token 2022

本节课程围绕 **Solana 的 SPL Token 体系** 展开，重点帮助学员建立对 **Mint、Token Account、Associated Token Account（ATA）** 的清晰认知，并理解在 Anchor 程序中如何与 SPL Token（包括 Token-2022）进行交互，为后续涉及资产托管、转账、空投等场景打下基础。 ## 一、核心学习目标 通过本节课程，学员应能够： - 理解 SPL Token 的核心账户结构 - 区分 Mint、Token Account 与 ATA 的实际含义 - 理解 PDA 在 Token 管理与托管场景中的作用 - 理解 Anchor 程序与 TS / Python 脚本之间的职责分工 - 对 Token-2022 的扩展能力建立初步认知 ## 二、SPL Token 的三类核心账户 这是本节课讨论最集中、也是最容易混淆的部分。 ### 1. Mint Account（铸币账户） - 定义一种代币本身 - 记录代币的： - 总供应量 - 精度（decimals） - 铸造权限（mint authority） - 每一种 SPL Token 对应 **唯一一个 Mint** 可以把 Mint 理解为“代币的规格说明书”。 ### 2. Token Account（代币账户） - 用于存储某个地址持有的某种代币余额 - 一个 Token Account 只对应： - 一个 Mint - 一个 Owner - 区块浏览器中常把 ATA 也统称为 Token Account，这也是初学者混淆的来源之一 ### 3. Associated Token Account（ATA） - ATA 是一种**特殊规则下的 Token Account** - 由以下三者唯一确定： - 钱包地址 - Mint - ATA 程序规则 特点包括： - 每个钱包地址 + 每种 Mint，**最多只有一个 ATA** - 是官方推荐的钱包持币方式 - 大多数钱包、前端、SDK 默认只使用 ATA > 可以理解为： > > > **ATA 是 Token Account 的“标准形态”** > ## 三、为什么初学者容易混淆这些概念 课程中反复出现的疑问，本质原因在于： - Solana 把一切状态都叫 Account - 区块浏览器往往统一显示为 Token Account - 历史早期存在“非 ATA 的 Token Account”用法 - 不同教程对命名不够统一 课堂给出的关键结论是： - Mint ≠ Token Account - ATA ⊂ Token Account - 大多数应用场景下，可以直接把 **ATA 当作默认 Token Account 使用** ## 四、PDA 在 Token 场景中的作用 ### 1. 程序账户无法签名 - 程序账户本身不能签名 - PDA 也不能直接签名 - PDA 通过 `invoke_signed` 由程序“代签” ### 2. PDA + ATA 的常见组合 在实际开发中，常见模式包括： - 使用 PDA 作为 Token Account 或 ATA 的 owner - 实现： - 资产托管 - 金库 - 合约控制资金流向 课堂中讨论的典型问题包括： - 是否可以把 USDC 转入 PDA 的 ATA - 是否可以再由 PDA 把资金转出到任意用户的 ATA 答案是： **逻辑上可行，但前提是权限与 signer 设计正确** ## 五、Anchor 与 TS / Python 脚本的分工 这是很多新同学容易误解的点。 ### 1. Anchor 的职责 - 编写和部署链上程序 - 定义： - 账户结构 - 权限规则 - 状态变更逻辑 ### 2. TS / Python 的职责 - 与链上程序交互 - 执行： - 创建 ATA - 转账 - 空投 - 查询状态 因此： - Anchor 不是用来写“脚本”的 - TS / Python 不是用来写“合约逻辑”的 二者是明确分层的。 ## 六、关于 Token-2022 的初步认知 课程后半段涉及 Token-2022，并引发了较多提问。 ### 1. Token-2022 是什么 - SPL Token 的扩展版本 - 提供更多原生能力，例如： - 冻结 - 转账限制 - 扩展字段 ### 2. Anchor 中的抽象方式 - 使用 `TokenInterface` trait - 允许同一套程序逻辑同时兼容： - 传统 SPL Token - Token-2022 如果要使用 Token-2022 的特有能力，仍需要明确指定并处理对应逻辑。 ## 七、开发中的安全与认知提醒 课堂中还反复提到一些重要提醒： - 不要随意在脚本中填写真实主网私钥 - 理解代码在做什么，比“能跑起来”更重要 - API 不需要死记，核心是知道： - 用什么场景 - 去哪里查文档 ## 八、课后实践建议 - 自行梳理一张对照表： - Mint - Token Account - ATA - 使用区块浏览器观察真实代币的账户结构 - 尝试用 Anchor + 脚本完成： - 创建 ATA - 向 ATA 转账 - 使用 PDA 控制 Token 流转 - 把 Token 与账户模型的理解写成自己的笔记 文课程档： https://accu.cc/content/solana/project_rule/ https://accu.cc/content/solana/project_control_by_program/ https://accu.cc/content/solana/project_code/ https://accu.cc/content/solana/project_airdrop/ https://accu.cc/content/solana/project_github/ 项目代码仓库地址： - 原生 rust 实现: https://github.com/mohanson/pxsol-spl - Anchor 实现: https://github.com/mohanson/pxsol-spl-anchor

task2：构建一个 Anchor 金库程序

Task2：https://learn.blueshift.gg/zh-CN/challenges/anchor-vault 助教包：https://github.com/daog1/blueshift_anchor_vault https://github.com/solana-foundation/solana-dev-skill

用 Anchor 重写简单链上数据存储程序

本节课程围绕 **Anchor 的基础使用方式** 展开，通过将一个“简单链上数据存储程序”从原生 Solana 写法迁移至 Anchor，实现对 Solana 账户模型、PDA 使用方式以及 Anchor 标准开发流程的系统理解，为后续 Vault 与更复杂合约内容打下基础。 ## 一、核心学习目标 通过本节课程，学员需要掌握以下能力： - 理解 Solana 与 EVM 在数据存储模型上的本质差异 - 熟悉 Anchor 项目的基础结构与开发流程 - 能够使用 PDA 为用户创建并管理专属数据账户 - 掌握账户空间分配与动态扩容的基本规则 - 能够独立排查 Anchor 开发中的常见报错 ## 二、Anchor 开发的基本流程 Anchor 提供了一套高度标准化的 Solana 开发体验，本次课程覆盖了完整闭环。 ### 1. 本地开发与测试流程 典型流程包括： - 安装依赖并初始化环境 - 使用 `anchor build` 编译程序 - 使用 `anchor test` - 自动启动本地 validator - 部署程序 - 执行测试脚本 在开发早期阶段，`anchor test` 是验证逻辑正确性的首选方式。 ## 三、Solana 账户模型与 PDA 的使用 ### 1. Solana 与 EVM 的关键差异 在 EVM 体系中，数据通常直接存储在合约内部。 而在 Solana 中： - **程序本身不存储业务数据** - 数据存储在独立的 **账户（Account）** 中 - 程序通过读写账户来完成状态更新 ### 2. PDA 在本次课程中的角色 本次“用户金库”示例中： - 每个用户对应一个 PDA 账户 - PDA 通过 `seeds + program_id` 派生 - PDA 用来存储用户的金库数据或余额信息 - 用户签名 + PDA 规则共同保证数据归属的安全性 ### 3. 是否需要 Auth 校验 课程中强调了一个常见误区： - PDA 的 owner 通常是 system program - 如果不做额外校验，逻辑层面的“数据归属”并不直观 因此，在真实项目中，建议通过： - 用户 signer - PDA seeds - 明确的字段校验 来确保账户只能被对应用户操作。 ## 四、账户空间（space）分配与计算 账户空间是 Anchor 开发中**最容易出错、但必须理解**的一部分。 ### 1. 基本原则 - Solana 账户在创建时必须一次性声明空间大小 - Anchor 账户默认需要额外 **8 bytes** 用于 discriminator ### 2. 常见写法 课程中对比了两种写法： - `space = 8 + Struct::INIT_SPACE` - 使用辅助函数动态计算空间 ### 3. 动态字段的注意事项 当账户结构体中包含以下字段时： - `Vec<T>` - `String` 必须： - 显式声明最大长度（如 `max_len`） - 否则 Anchor 无法正确计算所需空间 这是初学者最容易忽略、也最常导致运行时报错的点。 ## 五、realloc 与 realloc::zero 的理解 当账户需要扩容时，可以使用 `realloc`。 ### 1. realloc 的作用 - 在已有账户基础上增加空间 - 常用于列表增长、数据追加等场景 ### 2. realloc::zero 的含义 - `realloc::zero = true` - 新增空间会被初始化为 0 - 更安全、更可预测 - `false` - 新空间内容不确定 - 可能带来逻辑或安全风险 在涉及用户资产或关键状态时，推荐开启 zero。 ## 六、常见报错与排查方向 ### 1. Program ID 不匹配（最常见） **错误类型** `DeclaredProgramIdMismatch (4100)` **排查思路** - 确认 `Anchor.toml` 中的 program id - 使用以下命令获取真实部署 id ```bash solana-keygen pubkey target/deploy/<program>-keypair.json ``` - 确保以下三处完全一致 - `declare_id!` - `Anchor.toml` - 实际部署的 program id ### 2. 找不到 .so 文件 **错误表现** - deploy 阶段提示找不到 program 文件 **解决思路** - 确认 `anchor build` 成功执行 - 检查 `target/deploy` 目录下是否生成 `.so` 文件 ### 3. 工具链或 Solana CLI 版本问题 **典型现象** - toolchain 名称无效 - 编译阶段直接失败 **解决思路** - 检查本地 solana-cli 版本 - 按课程推荐版本重新安装或切换 - 保证 Anchor 与 Solana 版本兼容 ### 4. 测试脚本依赖缺失 **错误表现** - `ts-mocha` 找不到 **解决思路** - 先执行 `yarn install` - 确保测试相关依赖已正确安装 ## 七、课后实践建议 - 独立完整跑通一次项目流程 - build - test - deploy - 把以下内容整理成自己的 checklist - PDA 设计 - 权限校验 - space 计算 - realloc 使用场景 - 为毕业设计提前养成习惯 - 每次 deploy 前检查 program id - 关键逻辑不只依赖自动生成代码

AI Vibe Coding

提交截止时间：1.28周三7pm 提交黑客松后一定要记得填这个表 https://forms.gle/hbfntLuZkJ3jeSJS7 黑客松提交指南：https://docs.google.com/document/d/1Q3sqNiZNDxugMP9OYNk0rSoBAou1jS_dbS7hfQWPuto/edit?usp=sharing Ai vibe coding 参赛方式： 1. 项目提交： 开发者使用自己的 X (Twitter) 账号发布推文，介绍黑客松参加的赛道分类、项目概况、以及任何其他希望评委和用户了解的信息。发布的文案必须艾特 [@trendsdotfun](https://x.com/trendsdotfun) 和 [@solana_zh](https://x.com/solana_zh)。如果是已经在X上发布的项目，务必引用转发 (Quote RT) 项目原始的发布帖子，并艾特 [@trendsdotfun](https://x.com/trendsdotfun) @[solana_zh](https://x.com/solana_zh) \+ 写明参加的黑客松分类。 2. 额外信息： 在主推文下方的评论区，提供所有相关链接（如 GitHub 链接或其他任何体验产品需要的链接）。 3. 所有大赛评委将会基于个人的兴趣和任意参加黑客松的项目进行交互和评论，这些交互和评论并不代表最终评选结果，但是我们非常鼓励大家与评委们互动！也可以用这种方式为自己的项目争取更多人气与热度！ ⚠️参加黑客松tips： 1. 除了可以争取黑客松奖金，Solar 还为大家准备了毕业奖金（即使黑客松没有获奖，也会有一份毕业奖励） 2. Building 期间经常与官方账号互动，与评委互动，让社区知道你 3. idea 参考 https://superteam.fun/build https://blog.colosseum.com/announcing-the-winners-of-the-solana-cypherpunk-hackathon/ 4. 如果不跟链上交互，部署到本地也可以，也可以不跟链上交互，也不是必须要用 Solana 的技术栈，氛围跟 Solana 相关即可 5. 推荐推文用中文 6. 推荐录一个视频（参考colosseum winner），社区更容易发现自己，录屏，介绍功能，不用露脸，有声音就行 7. 推荐 fork templates 来做可以更高效， https://solana.com/developers/templates

Solana 2026 Task 1：铸造 SPL Token (使用 web3.js)

✅ Task 1: 铸造 SPL Token (使用 web3.js) https://learn.blueshift.gg/zh-CN/challenges/typescript-mint-an-spl-token ? task1助教包：https://github.com/Tools-touch/Task-/

将简单链上数据存储器扩展为可交易代币程序

Mohanson老师通过解答学员实战报错，深入探讨了 Solana 处理高并发时的底层真相及网络协议限制。 ### **1. 并发执行的真相：账户锁定 (Locking)** - **并行转串行**：Solana 虽然支持并行处理，但前提是交易涉及的账户不冲突。 - **热点账户瓶颈**：当成千上万人同时买入同一个流动性池或抢购同一个 NFT 时，由于它们都操作同一个账户，系统会强制将其转为**串行执行**。这解释了为何在极端热点下，用户会感受到“局部拥堵”。 - **交易所方案**：交易所内部转账通常在中心化数据库完成，仅在充提时与链上交互，以规避链上账户锁定的性能限制。 ### **2. 解决包大小限制：LUT (Address Look Up Tables)** - **1280 字节限制**：受 UDP 协议 MTU 限制，单笔交易的数据包极其有限，无法包含过多的账户地址（通常上限为 20-30 个）。 - **LUT 地址查找表**：当业务逻辑极其复杂（如聚合器交易涉及 100 个账户）时，通过 LUT 在链上建立“通讯录”，交易中只需传“索引编号”即可。这极大压缩了交易体积，是复杂应用开发的必备技巧。 ### **3. 交易费用构成与报错排查** - **费用公式**：`Total Fee = Fixed Transaction Fee + Priority Fee + Account Rent`。 - **优先费 (Priority Fee)**：在高并发期间，通过增加优先费可以获得验证者的优先打包权。 - **报错解析**：`Attempt to debit an account but found no record`。这通常是因为目标账户尚未创建或余额不足以支付租金押金，导致交易模拟阶段就报错回滚。 ### **4. PDA (Program Derived Address) 的付费与管理** - **谁使用谁付费**：PDA 的创建费用（租金）由用户支付。 - **管理权限分离**：用户虽付了钱，但没有私钥，无法直接动用资金；只有 Owner 程序能通过 `invoke_signed` 根据 Seeds 派生签名来管理其中的资产。 --- --- **总结陈述：** 本次课程深入到了 Solana 的**工程边界**。理解“账户锁定导致的串行化”能帮助你设计更好的业务并发逻辑；而掌握 **LUT** 和 **Rent 管理** 则是解决实战中“发不出交易”和“交易莫名报错”的关键。 文档：https://solana.com/zh/docs/intro/installation 附件中有社区小伙伴 Dean 分享的课程笔记

互联网资本市场

Yao Yao 结合其在亚马逊、交易所及基金会的复合背景，分享了 Solana 如何通过技术特性推动机构级应用落地。 ### **1. 亚太区：从“跟随者”到“技术引擎”** - **开发者红利**：亚太区开发者不仅在数量上占优，更在 DeFi 协议的复杂逻辑（如聚合器、衍生品）上贡献了全球领先的代码量。 - **基金会的角色转变**：基金会不只是提供 Grant（奖金），核心在于**资源分发与信誉背书**。通过将优秀的亚太开发者对接给全球顶级 VC（如 a16z）和交易所，实现项目的商业化落地。 ### **2. 传统机构入场：从“观望”到“基建融合”** - **亚马逊 (AWS) 的案例**：大厂看重的是**云端集成能力**。Solana 的节点节点可以轻松部署在 AWS 上，这种“云原生”的友好性降低了传统企业进入 Web3 的门槛。 - **成本即战略**：对传统机构而言，高吞吐量不仅是技术指标，更是财务指标。Solana 的低费率允许机构在链上进行**高频对账与清算**，这在以太坊上由于 Gas 费波动是无法实现的商业逻辑。 ### **3. Token Extensions (Token-2022) 的商业终局** Solana 杀入主流金融圈的“杀手锏”： - **可控的去中心化**：机构需要“有条件的监管”。 - **合规性 (Compliance)**：通过 Transfer Hooks 实现自动化 KYC，让每一笔转账都符合特定地区的法律。 - **资产安全 (Asset Security)**：永久代理权（Permanent Delegate）解决了机构最担心的“私钥丢失导致国有/企业资产流失”的合规痛点。

Solana 2026 C3 QA

Solana Bootcamp 2026 Course 3 QA

Solana 入门：简单链上数据存储器

Mohanson主要分享了 **“Account Model (账户模型)”** 的实战应用以及如何编写具备生产能力的 Rust 程序。 - **1. 开发环境与工具链** - **本地验证者 (`solana-test-validator`)**：本地测试是开发的基石。它可以完全模拟主网行为，支持重置状态。 - **RPC (Remote Procedure Call)**： - **端口 8899**：默认的 HTTP RPC 端口，用于发送交易和查询数据。 - **常用指令**：`getAccountInfo` 是最核心的读取函数，用于获取账户的 Lamports 余额、Owner 和 Data。 - **2. 核心架构：逻辑与数据的彻底解耦** 这是 Solana 区别于以太坊（EVM）的最本质特征： - **Stateless Program (无状态程序)**：Solana 的程序（Smart Contract）只包含执行指令的代码，不存储任何业务数据。 - **Data Accounts (数据账户)**：所有状态信息都必须存储在独立的数据账户中。 - **并行处理能力 (Parallel Execution)**： - **交易声明**：交易必须预先列出所有要操作的账户。 - **运行时调度**：只要两笔交易操作的是不同的账户，验证者就可以在多个 CPU 核心上同时执行它们。 - **3. PDA (Program Derived Address) —— 程序派生地址** PDA 作为重点，用于实现“程序自主管理账户”： - **计算公式**： Address=hash(Program ID+Seeds+Bump) - **特性**： - **无私钥**：PDA 不在 Ed25519 椭圆曲线上。 - **程序签名**：程序可以通过 `invoke_signed` 函数，利用 Seeds 和 Bump 为该 PDA 签署交易。 - **应用场景**：Vault（金库）账户、用户配置文件（Profile）、去中心化订单簿的撮合账户。 - **4. 链上存储与租金管理 (Rent Management)** - **Lamports 与租金**：链上空间昂贵。账户内必须持有一定数量的 SOL 来支付存储费。 - **Rent Exempt (租金豁免)**：若账户余额足以支付 2 年的租金，节点将不再扣费。目前的标准做法是所有账户都必须保持“租金豁免”。 - **动态调整 (`realloc`)**： - 当存储内容增加时，如何动态扩展账户空间。 - **安全检查**：必须判断发起者是否有权修改，并确保账户内有足够的 SOL 补足新增空间的租金。 - **5. Rust 程序编写要点** - **Entrypoint (入口点)**：所有 Solana 程序的唯一入口。Rust `pub fn process_instruction( program_id: &Pubkey, accounts: &[AccountInfo], instruction_data: &[u8], ) -> ProgramResult` - **Borsh 序列化**：用于将 Rust 中的 `struct`（结构体）转化为可在链上存储的二进制流（Binary stream）。 - **部署限制**：由于 UDP 包大小限制（通常为 1280 字节），部署大型程序会涉及成百上千次连续的交易指令。 文档：https://solana.com/zh/docs/intro/installation 附件中有来自社区小伙伴 Dean 的笔记分享

互联网资本市场的技术实现

Mike 主要分享的内容是围绕 **“Institutional DeFi (机构级去中心化金融)”**，探讨了传统机构为何在此时集体转向区块链。 - **1. 互联网资本市场 (Internet Capital Markets) 的定义** - **愿景**：将全球资产（国债、股票、货币基金）置于统一的底层共享账本上，实现流动性的实时流转。 - **核心优势**： - **24/7/365 运行**：打破传统金融市场的休市限制。 - **即时结算 (T+0)**：大幅降低资本占用，优化企业的资产周转率。 - **可编程性**：通过智能合约自动执行分红、投票、合规检查。 - **2. 稳定币与跨境支付的革新** - **白标模式 (White-labeling)**：Mike 提到 PayPal 选择 Paxos 作为发行方的案例。这种合作模式允许传统非金融机构利用现有合规框架快速入局。 - **支付成本**：传统跨境汇款（如 SWIFT）涉及多个中继行，每笔费用高昂且耗时。在 Solana 上，稳定币支付不仅成本微乎其微，且能提供确定性的到账时间。 - **3. Token Extensions (Token-2022)：机构入场的“敲门砖”** Mike 详细拆解了 Solana 协议层如何原生支持合规需求： - **Transfer Hooks (转账钩子)**：这是机构最看重的功能。它允许在每一笔转账发生前，自动调用一个“验证程序”。如果接收方未通过 KYC 或属于受限制地区，转账会被底层协议自动拒绝。 - **Confidential Transfers (隐私转账)**：利用零知识证明（Zero-Knowledge Proofs）隐藏交易金额和余额，同时允许发行方持有“审计钥 (Viewing Key)”以满足监管。 - **Interest-bearing Tokens**：原生计息代币。可以直接在代币元数据中设置利率，适合代币化债券和货币基金。 - **Permanent Delegate (永久代理权)**：在发生法律纠纷、黑客攻击或私钥丢失时，发行方有权干预资产，确保合规可控性。