Solana 程序安全：九大漏洞与实战案例

视频 AI 总结： 这段视频的核心内容是关于 Solana 链上程序安全的重要性，以及如何通过理解 Web2 的安全原则来更好地应对 Web3 的安全挑战。主讲人 David 介绍了 Solana 交易的结构，并详细讲解了九种常见的程序漏洞，包括签名检查、程序所有权检查、数据匹配、任意跨程序调用等，并结合实际案例分析了这些漏洞可能造成的严重后果，强调了程序安全对于行业参与者和建设者的重要性。 视频中提出的关键信息： * **Solana 程序安全的重要性：** 代码漏洞可能导致黑客攻击和资产损失。 * **Web2 与 Web3 的安全共通点：** Web2 的安全原则可以应用于 Web3 的程序开发。 * **CIA 三要素的调整：** 在 Solana 公链中，Confidentiality（保密性）被 Control（控制性）取代。 * **Solana 交易结构：** 交易包含签名和指令，指令包含程序 ID、账户和数据。 * **九种常见漏洞：** 签名检查缺失、程序所有权检查缺失、数据匹配错误、任意跨程序调用、重复使用可变账户、类型伪装攻击、PDA 公用、重新初始化攻击等。 * **实际案例分析：** 详细分析了 Soul Land、Crimi Finance、CashRail、Wormhole、Jet Protocol 等案例，说明了漏洞可能造成的巨大损失。 * **防御方法：** 强调了代码审核、使用安全工具、学习案例的重要性，并介绍了 Anchor 和 Pinocchio 框架提供的安全保障。 * **鼓励社区参与：** 欢迎大家加入 Blueshift 的 Discord 社区，共同讨论程序安全问题。

利用 Session Keys 提升用户体验

视频 AI 总结： 该视频主要介绍了如何使用 Session Keys 来改善 Solana 上的用户体验。Session Keys 允许用户在 dApp 中创建会话，从而避免每次交互都需要签名确认的繁琐过程，提升用户体验。MagicBlock 旨在突破 Solana 的限制，构建实时、隐私且流畅的链上应用。 关键信息： * 传统 Web2 登录方式的痛点：每个应用都需要创建账户。 * Web3 的问题：每次交互都需要签名，体验不佳。 * Session Keys 的原理：通过程序派生地址（PDA）存储临时密钥对，实现 dApp 和用户共享会话。 * 使用 Session Keys 的步骤：定义会话规则、创建会话 Token PDA、客户端自动签名。 * MagicBlock 的愿景：构建实时、隐私且流畅的链上应用，突破 Solana 的限制。 * MagicBlock 的优势：低延迟、零费用、可扩展，可用于构建游戏、金融应用等。 * MagicBlock 结合 ephemeral rollup 和 session keys，可以实现实时体验。 * MagicBlock 可以实现隐私支付，创建私有余额，进行实时转账。 * MagicBlock 正在与 Pinocchio 库集成。

Solana 测试工具：LightSVM, surfpool, Mollusk

## 一、为什么 Solana 的测试比想象中复杂 课程首先明确了一个现实问题： - Solana 程序依赖大量 **外部账户状态** - 程序逻辑往往不是“纯函数” - 测试时需要考虑： - 多账户交互 - CPI - Token 状态 - 与其他协议的真实组合行为 因此，Solana 的测试**不能只靠单一工具完成**，而是需要一个分层测试体系。 ## 二、Solana 测试工具的三种核心形态 课程中反复强调，可以把 Solana 测试工具分为三类： ### 1️⃣ 本地测试链（Local Validator） ### solana-test-validator - 官方提供的本地测试节点 - 特点： - 启动快 - 完全本地 - 适合基础功能测试 适用场景： - 单个程序的基本逻辑验证 - 不依赖真实主网状态的开发阶段 局限： - 不包含主网真实账户数据 - 无法模拟复杂的跨协议交互 ### 2️⃣ 单元测试工具（Unit Testing） ### Mollusk 课程中明确指出： - **Mollusk 更偏向单元测试** - 关注的是： - 单个指令 - 单个程序逻辑 - 边界条件与错误处理 特点包括： - 不追求完整链上环境 - 测试速度快 - 适合精准定位 bug 适用场景： - Pinocchio 程序 - 需要精确控制输入输出的逻辑测试 - 对 CU、执行路径敏感的代码 > 课程中多次提到： > > > **Mollusk ≈ 单元测试** > ### 3️⃣ 集成测试 / 主网数据模拟 ### Surfpool 这是本节课测试工具部分的重点。 课程对 Surfpool 的定位是： - **集成测试工具** - 可以在本地环境中： - 拉取主网账户 - 模拟真实协议交互 - 测试与外部合约的组合行为 核心能力包括： - 本地运行，但可按需拉取主网账户数据 - 不需要完整自建 Solana 节点 - 可以测试： - AMM 池 - Token 状态 - 复杂 CPI 调用 课堂中给出的一个关键总结是： > **Surfpool ≈ 带主网数据的本地测试环境** > 适用场景： - 协议集成 - 与真实 DeFi 协议交互 - 接近生产环境的验证 ## 三、Anchor、Pinocchio 与测试工具的关系 ### Anchor 测试 - Anchor 提供 `anchor test` - 本质是： - solana-test-validator - - TS 测试脚本 - 适合： - 教学 - 应用型开发 - 快速验证逻辑 但需要注意： - `anchor test` **不等于** Surfpool - 默认不会拉取主网数据 ### Pinocchio 测试 课程中明确指出： - Pinocchio 不自带完整测试框架 - 更依赖： - Mollusk（单元测试） - Surfpool（集成测试） 这也是 Pinocchio **对工程能力要求更高** 的原因之一。 ## 四、推荐的测试组合策略（非常重要） 课程中给出了一个**被多次确认的实践路径**： ### 推荐测试顺序 1. **Mollusk** - 测单个指令 - 测异常路径 - 测 CU 与逻辑正确性 2. **Surfpool** - 测与其他协议的交互 - 测主网真实账户状态 - 做接近生产的验证 3. **主网测试** - 最终验证 - 成本最高 - 只用于确认结果 这一点在课程中被反复强调。 ## 五、常见困惑的澄清 ### Q1：Surfpool 能不能替代 solana-test-validator？ - 在很多集成测试场景下，可以 - 但用途不同 - 本地 validator 仍适合最基础测试 ### Q2：Anchor test 用的是 Surfpool 吗？ - 不是 - `anchor test` 默认使用本地 validator ### Q3：测试能不能打断点？ - 目前不现实 - Solana 测试更接近： - 日志 - 打印 - 结果验证 ## 六、对初学者的重要提醒 课程中特别强调： - 不要一开始就上最复杂的测试工具 - 先理解： - 程序在干什么 - 账户是如何变化的 否则会出现： - 工具看懂了 - 逻辑反而更混乱 ## 七、课后实践建议（测试方向） - 至少亲手用一次： - solana-test-validator - anchor test - 进阶尝试： - 用 Mollusk 写一个单元测试 - 用 Surfpool 测一次真实协议交互 - 把测试当成： - 理解 Solana 执行模型的一部分 - 而不是单纯的“验收工具” 视频 AI 总结： 该视频主要讲解了 Solana 链上测试的三种工具：LightSVM、surfpool 和 Mollusk，并介绍了它们之间的关联、优势以及使用方法。核心内容是帮助开发者更好地进行 Solana 程序的测试，包括功能测试、性能测试以及套利策略的模拟。 关键信息： 1. LightSVM 是一个功能全面的库，支持多种语言，可以模拟 SVM 运行环境，进行指令级别的测试。 2. surfpool 基于 LightSVM 开发，能够直接从 RPC 获取链上数据，方便模拟真实环境，适合在线套利策略的测试。 3. Mollusk 是一个轻量级的 Rust 测试库，功能有限，只支持指令级别的测试，但可以进行定制化。 4. 这三个测试库最终都依赖 SVM 的源代码。 5. Shuffle 工具功能强大，既有 RPC 接口，又有网页界面，使用简单，适合与组网或开发网结合使用。 6. 实战案例演示了如何使用 surfpool 进行时间旅行和设置账号，模拟 DeFi 应用中的利息计算等场景。 7. 推荐使用 MCP 工具分析 Solana 交易，可以解析交易包含的程序、路径等信息。 8. 强调了在进行 Solana 开发时，需要关注 CU 优化，以降低交易成本。

Solana 链上套利：暗池、聚合器与机器人

视频 AI 总结： 该视频由三位套利大神分享链上分析与套利专题，核心内容是讲解如何在 Solana 链上进行套利，包括寻找暗池、利用聚合器、以及构建自己的套利机器人。强调了链上数据分析的重要性，以及如何通过技术手段提高套利效率和利润。 关键信息： 1. **暗池的寻找方法**：通过 Sourcecam 寻找交易量大的未开源 AMM。 2. **利用聚合器**：使用 Jupiter API 进行询价和交易，简化操作流程。 3. **链上计算**：通过智能合约在链上重新计算最优价格，降低延迟。 4. **成本控制**：分析 GAS 费用、机头费用等成本结构，优化交易策略。 5. **自建机器人**：构建自己的套利机器人，实现自动化交易和利润最大化。 6. **地址查找表（ALT）**：使用 ALT 技术优化合约，加速数据加载。 7. **服务器配置**：建议使用多核 CPU 服务器，提高计算速度。 8. **策略研究**：强调不断研发新的套利策略，以适应市场变化。 文档链接：https://xsglh58murtx.sg.larksuite.com/docx/HMgkdQX4ToahpDxHCSUlqfp3gpe?from=from_copylink

Pinocchio 入门

一、Anchor 与 Pinocchio 的技术关系 这是本节课最核心、也是信息密度最高的部分。 ### 1. 两者在技术栈中的位置 - Anchor - 上层开发框架 - 提供完整脚手架、账户校验、测试与部署体验 - 更适合初学者与应用型开发 - Pinocchio - 底层 Rust crate - 与 `solana-program` 同一层级 - 提供更直接、可控的程序构建方式 - 对 Rust 基础要求更高 课程中的一个关键判断是： > Anchor 是“上层封装工具”，Pinocchio 是“底层引擎组件”。 ### 2. Anchor 2.0 与 Pinocchio 课程明确提到： - Anchor 2.0 正在逐步引入 Pinocchio 作为底层核心库 - 这并不意味着 Anchor 会被淘汰 - 而是 Anchor 继续承担“易用层”，Pinocchio 负责“性能与控制力” 因此，对大多数开发者来说： - **先学 Anchor，再理解 Pinocchio 是更合理的路径** ## 二、推荐学习路径与心智模型 课程中形成的共识路径是： 1. Rust 基础（不要求很深） 2. Anchor（重点掌握账户模型、PDA、CPI、测试） 3. Pinocchio（适合对性能、底层机制有更高要求的开发者） 特别强调： - Anchor 入门阶段不需要精通 Rust - Pinocchio 对 Rust 语法、类型系统、生命周期理解要求更高 ## 三、Vault 抽象为何如此常见 ### 1. Vault 的本质 Vault 是 Solana 程序中非常常见的一种模式，用于： - 暂时托管 Token - 管理资产流向 - 作为权限控制与状态隔离的中间层 ### 2. 为什么教学常从 Vault 开始 课程给出的解释是： - Vault 逻辑足够简单 - 又能覆盖： - PDA - 权限校验 - CPI - Token 操作 因此非常适合作为教学与入门案例。 ## 四、Pinocchio 0.10.x 的关键变化认知 课程中多次提到新版本带来的变化点： - API 调整较多 - 强类型 Address 替代旧版 Pubkey 抽象 - bump 不再被强烈推荐显式保存 - 对 Compute Unit 的使用更加友好 也提醒学员： - 教程与版本可能存在不一致 - 遇到问题时优先对照官方文档与社区说明 ## 五、测试、工具与工程实践提示 ### 1. 测试策略 - Anchor 提供完整测试框架 - Pinocchio 更偏向底层，需要额外测试工具 - Blueshift 推荐使用 mollusk 进行测试 ### 2. 工具链建议 - 使用 rust-analyzer 提升 IDE 体验 - 遇到依赖问题可通过指定版本解决 - 课程中给出了可直接使用的 cargo update 方案

Noah AI：Solana 无代码应用构建，赢取黑客松奖金

视频 AI 总结： 该视频介绍了 Noah AI，一个 AI 驱动的无代码工具，旨在帮助用户在 Solana 上构建功能齐全的链上应用程序，即使他们不具备 Rust 编程技能。视频重点介绍了即将到来的 Solar 黑客松周，鼓励开发者使用 Noah AI 构建 Solana 应用，并有机会赢得奖金、获得 Sirenia 的指导，甚至获得高达 10 万美元的融资机会。 关键信息： * **Noah AI 介绍：** 这是一个无需编码即可在 Solana 上构建应用程序的 AI 工具。 * **Solar 黑客松周：** 从 1 月 28 日到 2 月 4 日举行，奖金池为 3000 USDC。 * **参与方式：** 通过 Noah AI 注册，并可联系 Mike 或 Vesper 获取初始测试代币。 * **评判标准：** 应用必须基于 Noah AI 构建，关注 UI 的可扩展性和创新性。 * **额外福利：** 获胜者有机会获得 Sirenia 的指导和高达 10 万美元的融资。 * **功能演示：** 演示了如何使用 Noah AI 构建一个代币发行平台，并集成了 Solana 程序。 * **SDK 集成：** 可以集成 Jupyter、Radium、Metaplex 等协议。 * **图像生成和编辑：** 可以使用 AI 生成或上传图像，并轻松编辑 Web 应用程序的元素。 * **Bonk Fund 合作：** 允许用户为他们的应用程序直接在 Bonk 上启动代币。 * **代码下载：** 可以下载应用程序背后的代码。 ## Vibe Coding 与黑客松实战思路 ### 1. Vibe Coding 的定位 课程强调，Vibe Coding 更适合： - 黑客松 - 快速 Demo 验证 - 前端不熟或时间受限的场景 核心价值在于： - 降低启动成本 - 快速跑通最小可用版本 - 帮助开发者把精力集中在**业务逻辑而不是样板代码** ### 2. AI 工具的边界共识 课程中反复强调的一点是： - AI 可以辅助写代码 - 但不能替代对链上逻辑的理解 - 上生产或涉及资产安全时，必须人工 review AI 工具更像是“加速器”，而不是“安全兜底”。

Task 3：构建一个 Anchor 托管程序

代码链接：https://github.com/Tools-touch/Task-/

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 - 关键逻辑不只依赖自动生成代码