技能介绍

要解决什么问题

在 Solana 上写程序时，开发、安全审计和规模化状态存储往往是三条割裂的学习路径，但底层都是同一套运行时模型：账户所有权、PDA、CPI 与 SPL/Token-2022。新手容易在「能跑起来」和「不会被任意账户参数打穿」之间踩坑；业务上又常遇到大量代币账户带来的 rent 成本，以及交易里账户数、CU 上限带来的工程约束。

技能如何组织内容

本技能按三条主线并列展开，并共用同一套参考地图：

Development：推荐从 Anchor 入手（宏、IDL、TypeScript 客户端生成），需要极致体积或算力时再对照 native Rust；覆盖账户/PDA/CPI、代币操作与校验、测试金字塔（含 Mollusk、Surfpool 主网 fork）、部署与 solana-verify 生产构建、客户端与版本化交易（ALT）、持久 nonce 等。
Security & Auditing：以「攻击者可向任意指令传入任意账户」为前提，按指令逐项检查 signer/owner/writable、checked_* 算术、PDA canonical bump、CPI 目标校验与预言机数据；对照漏洞模式清单与严重级别模板输出审计结论。
ZK Compression：通过 Light Protocol 将状态写在账本而非传统账户，用 Groth16 有效性证明校验变更；适合海量、低频更新的代币账户或 PDA，查询侧依赖 Photon（如 Helius RPC）。

常见任务表把「新建程序、初始化 PDA、SPL 转账、本地 fork、ALT、离线签名」直接指向对应 reference，减少在文档海里盲搜。

适用边界与注意点

Anchor vs native：标准 DeFi/NFT 与需要 TS 客户端时优先 Anchor；算力与二进制体积敏感时再 native，或热路径混用。
ZK Compression：单次写入额外 ~100k CU 与证明体积，频繁更新（例如生命周期写入次数很高）仍宜用常规账户；V2 批量状态树显著降低根更新成本，但仍要评估索引与基础设施依赖。
安全：生产路径避免 saturating_*、unwrap()、未校验的 init_if_needed 与任意 CPI；账户在外部变更后需 reload，算术与关闭账户逻辑要按清单逐项过。