solana development

Claude Code 真比手写 Solana 程序更好么？

视频 AI 总结： 作者挑战 Claude Code 编写了一个 Solana Coin翻转程序，但程序存在多个严重安全漏洞。通过分析随机性实现缺陷（使用 byte 模 100 导致概率偏向玩家）和交易原子性漏洞（下注和支付在同一事务中，可选择性中止），作者成功利用这些漏洞缓慢抽干了合约资金池。即使 Claude 修复了随机偏差，作者仍通过交易级攻击（前置一个条件转移指令）继续获利。视频强调 AI 生成的代码不能盲信，必须经过人工安全审计。 关键信息： - Claude 编写的Coin翻转程序存在随机性偏差：使用 1 字节值模 100（最大值 255），导致玩家胜率约 57% 而非设计的 49%。 - 业务逻辑错误：资金池检查规则（必须持有 2 倍赌注才能支付）实际上无法防止持续小额定损。 - 交易原子性漏洞：下注和支付在同一交易中完成，攻击者可附加一个转账指令保护自己——若获胜则成功，若失败则整笔交易回退，只需承担手续费。 - Claude 提出的 commit-reveal 方案（将下注和结果判定分两笔交易）仍然存在可预测 slot 的风险，作者认为仍可被黑客利用。 - 核心教训：LLM 辅助编程时仍需开发者自行审查安全逻辑，不能完全信任 AI 的“安全声明”。

336 0 0 2026-06-11 23:46

Solana教程 批量代币指令

视频 AI 总结： 该视频深入解析了 Solana Token Program 的批量指令（batch instruction）功能。首先通过对比测试说明，在顶层直接执行多条指令时批量反而消耗更多计算单元，但在 CPI（跨程序调用）场景下，批量指令能显著节省计算，因为 CPI 本身开销大。视频遍历了 Token Program 几乎所有可批量指令（如初始化铸币、铸造、转账、冻结、解冻、批准、撤销、销毁、关闭账户等），并排除了嵌套批量。同时实测了批量容量限制：主要受交易大小和单指令最多 255 个账户引用约束，例如 revoke 最多可批量 127 条，transfer 约 73 条。最后演示了如何解码批量指令内部的子指令。视频作者认为该功能计算优化幅度有限，且增加了解析复杂度，但既然已上线，开发者应利用它以节省 CPI 成本。 关键信息： - 批量指令在顶层调用时反而浪费计算，仅在 CPI 中才有优势（单次 CPI 开销大，批量合并为一次 CPI 可省 600+ 计算单元）。 - 几乎所有 Token Program 的常用指令都可批量（除 batch 指令自身），包括初始化铸币/账户、铸造、转账、销毁、冻结、解冻、批准、撤销、关闭账户、提取超额 lamports 等。 - 批量指令的数量限制：受交易大小（约 1232 字节）和单指令最大账户数（255）影响。例如 revoke（2 账户）最多 127 条；transfer（3 账户）最多约 73 条；burn（3 账户）约 60 条。 - 批量后的解码比较复杂，需要逐层解析顶层 batch 指令内的子指令。 - 该功能已在主网（epoch 971）生效，但实际收益不大，主要适合需要频繁 CPI 调用 Token Program 的程序。 Chapters: 0:00 intro 1:10 efficiency 9:04 what can we batch 24:57 biggest batch possible 37:12 parseBatchInstruction 41:29 conclusion

523 0 0 2026-05-26 22:40

Solana 开发 Day6 : 序列化与反序列化

视频 AI 总结： 本视频讲解在 Solana 开发中手动处理数据序列化与反序列化的必要性。通过使用 Pinocchio 框架（而非 Anchor），演示如何定义账户结构、手动编码/解码指令数据与账户存储，并对比了手动操作、Borsch 库以及指针转换等不同实现方式。强调开发人员需自行决定数据字节的排列顺序和含义，从而更深入理解账户底层表示。 关键信息： - 序列化/反序列化是 Solana 开发的核心技能，开发者需自行定义账户数据及指令数据的字节布局。 - Pinocchio 相比 Solana SDK 更高效，但需要手动处理入口点、账户验证和数据打包。 - 常见序列化库如 Borsch 存在局限性（如对地址类型支持不佳），手动实现或使用更高效方案更受推荐。 - 客户端可通过相同定义的 codec 对账户数据进行反序列化，以获取有意义的字段值。 - 视频提供了手动序列化、使用 Borsch、以及通过 unsafe 指针直接操作内存三种实现方式，并对比其优缺点。

108 0 0 2026-05-25 17:36

Solana 开发 Day5 : 代币

视频 AI 总结： 本视频是 Solana 开发入门系列第五天，核心讲解 Solana 上的代币机制。代币在 Solana 上通过代币程序（Token Program）管理，无需部署自定义合约即可创建。代币分为两种标准：Token Keg（传统）和 Token Extensions（新功能）。视频演示了通过 CLI 和 TypeScript 编程方式创建铸币账户（mint）、关联代币账户（ATA）、铸造和转移代币的完整流程，并强调了账户所有权、PDA 和序列化等关键概念。 **关键信息：** 1. Solana 代币通过 Token Program（Token Keg 或 Token Extensions）管理，无需自行编写合约。 2. 代币核心账户：铸币账户（mint）定义代币类型，代币账户（token account）存储余额，推荐使用关联代币账户（ATA）。 3. 创建代币需先通过系统程序创建账户，再调用初始化铸币指令；铸造和转移需要正确的签名和账户关系。 4. ATA 是 PDA，由关联代币程序通过种子（钱包、代币程序、铸币地址）派生。 5. 代币具有小数位（默认为9），转移即更改授权人，任何持有授权者均可销毁代币（burn）。 6. 实际编程中需注意区分 Token Keg 与 Token Extensions 的导入路径，避免账户不匹配错误。

109 0 0 2026-05-25 16:59

一钥签万物：Solana Keychain 统一签名接口框架

视频 AI 总结： 1. 视频核心内容： 本视频介绍 Solana Keychain——一个统一签名接口的框架，支持多种签名后端（本地密钥、Turnkey、Privy 等）。作者通过实际编码，演示了只需替换少量配置即可轻松切换签名方式，大幅简化开发者对不同 SDK 的集成工作，并最终成功配置了本地 Vault 签名。 2. 关键信息： - Solana Keychain 提供统一的 Solana 签名接口，底层支持多种实现（内存、Turnkey、Privy、Vault 等）。 - 使用 Keychain Signer 可屏蔽各 SDK 差异，开发者只需传入对应凭据（如 API 密钥、钱包 ID），无需深入理解各服务细节。 - 本地密钥对、Turnkey、Privy 三种签名的代码结构几乎一致，切换仅需修改 backEnd 和参数。 - Vault 配置较复杂（需本地或集群部署、TLS 证书、Token等），但最终同样可通过 Keychain 无缝集成。 - 该框架提高了开发效率与密钥管理灵活性，适合需要多签名服务或升级安全性的 Solana 项目。

94 0 0 2026-05-21 12:43

Solana教程: Quasar 与 Pinocchio 对比

视频 AI 总结： 本视频比较了 Solana 上的两个编程框架 Pinocchio 和 Quasar。作者通过编写相同功能的程序（空程序、带账户、初始化加计数器）并测量计算单元消耗，发现两者效率都很高，但侧重点不同：Pinocchio 更底层、更高效，已通过实战审计；Quasar 则更开发者友好（类似 Anchor），默认支持零拷贝，但仍在 beta 阶段。选择取决于需求：追求极致控制用 Pinocchio，快速开发用 Quasar。 关键信息： - 两者都聚焦计算效率与编译体积优化，但 Pinocchio 出现更早、经过审计（如 pToken），Quasar 未审计。 - 空程序测试：Pinocchio 正常入口点 4 CU，懒加载 2 CU；Quasar 6 CU。 - 带 10 个只读账户：Pinocchio 正常 84 CU、懒加载 2 CU；Quasar 6 CU（忽略账户）。 - 初始化+修改计数器：Pinocchio 43 CU，Quasar 57 CU（Quasar 多做了账户检查）。 - 账户大小不影响计算单元（零拷贝避免反序列化全部数据）。 - Pinocchio 提供底层控制（需手动实现校验），Quasar 提供高层抽象（类似 Anchor）。 - 结论：Pinocchio 适合极致效率与安全场景，Quasar 适合快速高效开发。

248 0 0 2026-05-09 11:35

Solana教程: 利用 SIMD-296 实现更大的交易

视频 AI 总结： 本视频是一个关于 Solana 区块链的教程，核心内容是介绍并实际操作了 Solana 改进提案 SIMD 296，该提案旨在将交易大小上限从 1232 字节提高到 4 千字节。视频演示了如何使用 Surfpool 的 Surfnet（一个临时测试网络）来发送大型交易，并展示了在现有主网限制下无法发送的大型交易如何在测试网络上成功发送和确认。 视频中提出的关键信息： 1. SIMD 296 提案的核心是引入新的 v1 交易格式，支持更大的交易容量（4KB），以满足更复杂的用例需求。 2. 目前可以通过 Surfnet 测试网络（一个临时集群）提前体验和测试大型交易功能。 3. 实际操作中遇到了测试网络浏览器界面的一些技术问题（如 CORS 错误），但通过创建本地代理服务器得以解决。 4. 使用 SolanaKit 工具包可以构建并发送大型交易，而交易大小的限制实际上由 RPC 强制执行。 5. 测试中验证了交易大小上限确实为 4096 字节，并且即使包含大量账户（最多 64 个）和大块数据，交易也能成功发送。 6. 这项改进未来将部署到开发网（devnet）和主网（mainnet），为开发者提供更大的灵活性。

140 0 0 2026-05-07 16:45

Solana Anchor v2 大改进

视频 AI 总结：本视频介绍了 Solana 上 Anchor v2 的预发布版本，强调其相较 v1 的巨大效率提升（二进制缩小 90% 以上，速度快 6 倍）。主持人演示了安装、创建程序、编写指令、测试和部署流程，并对比了 v1 与 v2 在二进制大小和计算单元消耗上的差异。他同时指出 v2 基于 Pinocchio 重建，默认安全，但尚未正式发布且未经审计，不建议用于生产环境。 关键信息： - Anchor v2 使用 Pinocchio 作为底层，大幅提升效率。 - v2 二进制大小和 CU 消耗远低于 v1（示例中增量指令仅 200 CU，而 v1 需 2,000 CU）。 - 核心变化：地址类型从 `pubkey` 改为 `address`，移除 `has_one` 约束，改用 `address` 检查，以及移除 `info` 生命周期。 - v2 目前为 alpha 阶段，未审计，API 可能变化，需通过 git 依赖 `anchor-next` 分支。 - 测试使用 Light SVM 本地环境，无需部署。 - 迁移 v1 程序到 v2 需修改部分语法（如空间不再手动指定），但总体流程相似。

124 0 0 2026-05-07 16:06

Solana教程：使用Quasar实现零拷贝

视频 AI 总结： 本视频是一个关于如何使用 Quasar 框架编写 Solana 程序的教程。视频核心是演示 Quasar 这一支持“零拷贝”的 Solana 程序框架的使用方法，并通过一个简单的“心情账户”示例程序，展示了从项目创建、添加状态和指令、编写逻辑、本地测试到最终部署和交互的完整流程。教程旨在让观众了解 Quasar 与 Anchor 框架的异同，并体验零拷贝技术带来的性能优势。 视频中提出的关键信息： 1. **Quasar 框架核心**：Quasar 是一个可以让开发者使用“零拷贝”技术编写 Solana 程序的框架，这意味着程序可以直接操作账户内存中的数据，无需进行序列化/反序列化或堆内存分配，从而提升性能和效率。 2. **项目搭建与工具**：视频演示了如何安装 Quasar CLI、初始化项目、以及其项目结构（包含 `lib.rs`、`Cargo.toml`、`quasar.toml` 等）。Quasar 内置了测试框架（Quasar SVM）和客户端代码生成功能，简化了开发和测试流程。 3. **核心概念与用法**： * **账户定义**：使用 `#[derive(Accounts)]` 宏定义指令所需的账户，并通过如 `#[account(mut)]`、`#[account(init)]` 等属性指定账户的约束条件（如可变性、初始化）。 * **指令实现**：指令逻辑在单独的文件中实现，通过 `impl` 块为账户结构体添加方法。 * **数据访问**：在“零拷贝”模式下，可以直接通过指针（引用）来读写账户数据字段。 4. **开发体验**： * Quasar 提供了类似 Anchor 的开发体验，但账户鉴别器（discriminator）为1字节（Anchor 为8字节）。 * 框架可以通过 CLI 快速“脚手架”式地添加状态（state）和指令（instruction）。 * 视频中遇到了并演示了如何解决一个关于账户签名验证的 bug（在 `set_mood` 指令中，`mood_account` 被意外要求签名），并指出这是框架当前的一个问题。 5. **部署与交互**：视频展示了如何构建、部署程序到 DevNet，并使用 TypeScript 和 Rust 脚本与部署的程序进行交互，调用 `initialize` 和 `set_mood` 指令。 6. **注意事项**：视频开头提及 Quasar 仍在积极开发中，尚未经过审计，因此不建议直接用于生产环境。

141 0 0 2026-04-22 11:29

如何让 Solana 程序实现返回值

视频 AI 总结： 本视频深入探讨了 Solana 区块链上程序如何实现返回值功能。核心内容在于，虽然 Solana 程序指令通常只返回成功或错误状态，但通过一个专门的“返回数据”缓冲区，程序可以返回最多 1KB 的数据。视频详细演示了如何在 Rust（使用 Pinocchio 框架）和 Solana CLI 中实现设置、获取和清除返回数据，并通过实际代码示例展示了跨程序调用（CPI）时返回数据的传递机制。 关键信息： 1. Solana 程序可以通过 `set_return_data` 函数（来自 `solana_program::cpi`）向一个每笔交易专用的缓冲区写入返回数据，最大容量为 1024 字节。 2. 调用者程序可以使用 `get_return_data` 函数从该缓冲区读取数据，并能获取设置该数据的程序 ID。 3. 返回数据缓冲区在每次 CPI 调用前会自动清空，但在调用后不会自动清空，因此程序需要注意返回数据的来源是否预期。 4. 返回数据的一个典型应用场景是：一个程序（如代币程序）通过返回数据告知调用者所需账户的大小等信息，调用者（如前端或其他程序）可以通过模拟交易或解析交易结果来获取此数据，而无需实际执行完整的链上交易。 5. 视频通过创建“返回答案”和“调用程序”两个示例程序，完整演示了设置返回值、在 CPI 中获取并使用返回值、以及处理返回数据过大等错误的整个过程。

122 0 0 2026-04-22 11:04

使用Kora 在Solana 进行无Gas交易

视频 AI 总结： 本视频是一个关于 Solana 区块链上 Kora 服务的进阶教程。核心内容是演示如何设置一个 Kora 节点，使其能够为调用特定程序的交易支付费用，从而让用户无需支付任何费用即可使用该程序。视频中，作者首先部署了一个简单的 Anchor 程序作为示例，然后详细讲解了 Kora 的配置文件设置，特别是如何通过配置实现“免费”定价模型，并限制只允许调用目标程序，以控制成本和安全风险。最后，作者展示了如何使用 TypeScript 客户端与 Kora 节点交互，构建并发送由 Kora 支付费用的交易。 视频中提出的关键信息： 1. Kora 允许设置不同的定价模型：免费、固定费用或基于成本的百分比加成（Margin）。免费模型适用于完全赞助的应用场景。 2. 配置 Kora 时，必须严格限制允许的程序和操作（例如禁止系统转账），以防止攻击者滥用免费服务耗尽资金。 3. 使用免费定价模型存在安全风险，需要配置保守的交易限额（如最大 Lamports 消耗）并考虑添加身份验证。 4. 与 Kora 节点交互时，可以通过其提供的客户端获取付费签名，构建交易后由 Kora 签名并支付费用，用户无需拥有 SOL。 5. 当前 Kora 的 TypeScript 客户端 `signAndSendTransaction` 方法可能存在 bug，但手动获取签名后发送交易的方式是有效的。 6. 可以配置 Kora 只允许特定的程序指令，但需要注意，如果允许计算预算（Compute Budget）程序，用户仍可能发送仅包含该指令的空交易，造成资源消耗。

133 0 0 2026-04-22 10:42

Solana 交易中继器 Kora： 代币代付 Sol 手续费

视频 AI 总结： 本视频介绍了 Solana 基金会推出的交易中继器解决方案 **Kora**。它旨在解决 Solana 用户因钱包中缺乏 SOL 而无法支付交易手续费的痛点。通过 Kora，开发者可以实现“无 Gas 交易”，允许用户使用 USDC 等其他代币支付费用，或由应用方直接代付。视频深入浅出地演示了 Kora 的工作原理、环境配置以及如何在 DevNet 上完成一个由第三方代付手续费的共同签名交易流程。 视频中提出了以下关键信息： 1. **核心定位**：Kora 是一个 JSON RPC 服务器和中继器，充当 Solana 交易的第三方费用支付者（Fee Payer）。 2. **解决的问题**： * **新用户门槛**：用户无需持有 SOL 即可进行交易。 * **资产受限**：解决钱包中只有代币（如 USDC）却因没 SOL 而无法转账或兑换的“死锁”状态。 * **应用场景**：适用于游戏（代付手续费以提升体验）、钱包恢复工具及需要受信任签名者的特定程序。 3. **工作流程**： * 用户构建交易并加入向 Kora 支付代币的指令。 * 用户进行部分签名（Partial Sign）后发给 Kora 节点。 * Kora 验证交易（检查白名单、费率等）后进行共同签名（Co-sign）。 * 返回完全签名的交易并提交至区块链。 4. **高度可配置性**：开发者可以通过 `toml` 文件定义验证规则，包括允许调用的程序 ID、支持支付的代币种类、签名者策略（如轮询）、速率限制及单笔交易最高代付金额。 5. **安全性与集成**：Kora 经过审计，支持多种签名后端（如私钥、Turnkey、Privy 等），并提供 TypeScript SDK 方便开发者集成。 6. **实操演示**：视频展示了如何启动本地 Kora 节点，配置模拟预言机（Mock Oracle）获取代币价格，并成功在 DevNet 上完成了一笔由 Kora 代付 SOL、用户支付“伪 USDC”的交易。

165 0 0 2026-04-17 20:02

Anchor v1.0.0 有哪些更新

视频 AI 总结： 本视频深入探索了 Solana 开发框架 Anchor 1.0 的发布候选版（RC2）。视频核心内容围绕 1.0 版本带来的重大改进展开：首先，程序二进制体积显著减小（约 25%），这归功于 IDL 不再内置于程序中，而是通过专门的元数据程序管理；其次，CLI 模板引入了更模块化的目录结构，鼓励开发者将逻辑拆分；最后，重点演示了新增的 `Migration` 账户类型，它极大地简化了账户布局升级（如增加字段）的复杂流程。整体而言，Anchor 1.0 在保持兼容性的同时，显著提升了开发效率和程序性能。 视频中提出了以下关键信息： 1. **程序体积优化**：由于 1.0 版本不再将 IDL 存储在程序 binary 中，而是利用 `Program Metadata` 程序处理，程序体积大幅缩减（示例中从 200KB 降至约 157KB）。 2. **模块化项目结构**：新版 CLI 初始化的项目不再将所有代码堆叠在 `lib.rs`，而是自动生成 `instructions`、`state`、`error` 等文件夹，引导开发者进行更好的代码组织。 3. **`Migration` 账户类型**：这是 1.0 的核心新特性，允许开发者定义从旧版本账户结构到新版本的平滑迁移逻辑，配合 `realloc` 约束可轻松处理账户空间扩展。 4. **CLI 命令更新**： * 引入 `anchor keys sync` 命令，可自动同步源代码中的程序 ID。 * `anchor deploy` 逐渐被 `anchor program deploy` 取代。 5. **IDL 管理变更**：IDL 现在上传至独立的元数据账户，浏览器（如 Solana Explorer）将通过该机制解析程序指令。 6. **依赖与包名变更**：随着 Solana 基金会接管 Anchor，NPM 包和 Rust 依赖项正逐步迁移至新的命名空间（如从 CoralXYZ 转向 AnchorLang 相关路径）。 7. **平滑升级**：作者指出，从 0.32.1 版本升级到 1.0 并没有太多破坏性变更（Breaking Changes），现有简单程序通常可以无缝迁移。

142 0 0 2026-04-17 15:39

哪款 AI 在 Solana 开发上表现最好

视频 AI 总结： 本视频通过一场“氛围编程”（Vibe Coding）实验，对比了 ChatGPT、Gemini、Grok 和 Claude 四款 AI 模型在 Solana 区块链开发上的实战表现。作者设定了一个简单任务：编写一个允许用户 A 存款并指定用户 B 提取 Sol 的托管程序。实验不仅测试了 AI 编写 Rust 合约（基于 Anchor 框架）的能力，还考察了其生成前端测试脚本及处理现代工具库（如 Solana Kit）的准确性。最终，Gemini 凭借对新工具的卓越适配性脱颖而出，而 ChatGPT 表现最差。 **视频中的关键信息：** 1. **模型表现排名**：作者给出的最终排名为 Gemini > Claude > Grok > ChatGPT。 2. **Gemini 的优势**：在 Pro 模式下表现最惊艳，不仅代码逻辑合理（采用 UTXO 模式并使用 `close` 约束节省租金），还成功生成了基于 Kodama 的现代客户端代码，几乎开箱即用。 3. **Claude 的特点**：提供了最完整的项目结构和详尽的 Readme 文档，具备极强的错误修复能力（如解决 Rust 借用检查器问题），但在适配最新的 Solana Kit 时存在幻觉。 4. **ChatGPT 的局限**：在处理 Rust 依赖冲突和环境配置时表现欠佳，且未能提供可运行的 TypeScript 客户端脚本，开发体验较为挫败。 5. **Grok 的表现**：中规中矩，生成的代码简洁但设计选择较独特（每个接收者一个金库），在处理复杂依赖时需要人工干预。 6. **开发建议**：AI 已能胜任基础的 Solana 合约开发，但开发者仍需具备调试能力，尤其是在处理不同 AI 模型对现代工具库（如 Web3.js v2 或 Solana Kit）的理解偏差时。 7. **设计差异**：四款 AI 在处理“租金回收”和“金库账户设计”上各有千秋，反映了 AI 在理解 Solana 账户模型时的不同逻辑倾向。

194 0 0 2026-04-15 18:48

Solana基础知识 day4：PDAs 和 CPIs

视频 AI 总结： 本视频深入探讨了Solana开发中的核心概念：程序派生地址（PDA）、跨程序调用（CPI）和签名机制。视频解释了Solana程序的公开性，以及如何通过“权限账户”（Authority）和签名来限制对程序功能的访问。它详细演示了程序如何通过CPI调用其他程序，并重点介绍了PDA作为一种特殊地址，允许程序在没有私钥的情况下进行“签名”，从而实现程序级别的权限控制和账户创建。理解这些概念对于Solana开发者至关重要。 关键信息： 1. **Solana程序公开性与权限控制：** Solana上的程序是公开的，任何人都可以调用。为了限制特定操作（如修改状态），需要引入“权限”（Authority）概念，即一个被授权执行操作的账户。 2. **签名（Signatures）的重要性：** 签名是证明账户所有权和授权的关键。程序必须显式检查签名，以确保只有拥有私钥的账户才能执行受限操作。一个交易可以包含多个签名。 3. **跨程序调用（CPIs）：** Solana程序可以通过CPI调用其他程序的功能，这是Solana可组合性的核心。Anchor框架会简化一些常见的CPI（例如创建账户时调用系统程序）。 4. **程序派生地址（PDAs）：** * **定义：** PDA是一种特殊的Solana地址，它没有对应的私钥。 * **生成方式：** PDA通过一组“种子”（seeds）和一个程序ID确定性地生成。相同的种子和程序ID总是生成相同的PDA。 * **核心功能——程序签名：** PDA允许程序在CPI中代表该地址进行“签名”（通过`invoke_signed`指令并提供种子），从而使程序本身能够充当权限方，而无需拥有私钥。 * **账户管理：** PDA常用于创建程序拥有的账户。通过将特定数据（如用户公钥）作为种子，可以实现“每个用户一个账户”或“每个程序一个账户”等逻辑，确保账户的唯一性和绑定性。 * **开发实践：** 在创建程序账户时，使用PDA是一种推荐的做法，因为它简化了账户管理，并允许程序进行签名。 5. **手动构建指令：** 视频演示了如何通过已知程序ID、账户地址和数据来手动构建并发送Solana指令，以理解交易的底层结构。 6. **开发最佳实践：** 强调了不必要时不要将账户设置为可写，以及程序必须显式检查签名以确保安全性，避免“忘记签名检查”的常见错误。

264 0 0 2026-03-27 12:05