daog1 (xiaodao)

对 sol-mcp 服务的 skill 改造

daog1 — Mon, 26 Jan 2026 18:10:03 +0800

对 sol-mcp 服务的 skill 改造

引言

模型上下文协议（Model Context Protocol, MCP）作为一种新兴的技术标准，正在重新定义 AI 应用与外部系统交互的方式。MCP 协议提供了一个标准化的框架，允许 AI 模型通过统一的接口访问外部工具和服务，从而扩展其功能边界。而 Skill 技术则是在 MCP 协议基础上的一种具体实现形式，它将特定功能打包成可重用、可插拔的组件，使开发者能够更便捷地将功能集成到 AI 应用中。

MCP 协议本质上是一种通信协议，定义了 AI 与外部工具之间的请求和响应格式；而 Skill 技术则更注重功能的封装和用户友好性，提供了更高层次的抽象。通过 Skill，开发者可以获得更好的代码复用性、模块化程度，以及简化的部署和配置过程。本文将详细介绍我们如何对 Solana Analysis MCP 服务器进行 Skill 改造，以充分利用这两种技术的优势。

背景介绍

Solana Analysis MCP 服务器是一个专为分析 Solana 区块链交易、指令和账户数据而设计的服务。它利用超过 1000 个程序的 IDL（接口定义语言）数据集来解码交易数据，支持 Anchor、Shank 和 Codama 等多种格式。项目源码可在 GitHub 上获取。API 密钥可在 https://solmcp.daog1.workers.dev/ 获取。

传统的 MCP 集成方式往往需要复杂的配置和手动设置，这对普通用户来说存在一定的技术门槛。因此，我们需要将 Solana Analysis MCP 服务器改造成一个易于使用的 Skill，使其能够无缝集成到支持 MCP 的各种 AI 应用中。

改造目标

我们的主要目标是将 Solana Analysis MCP 服务器改造成一个易于使用的 Skill，使其能够无缝集成到支持 MCP 的各种 AI 应用中。具体来说，我们希望实现以下几个方面的改进：

简化集成流程：使用户能够通过简单的命令快速添加和配置 Skill。
增强功能覆盖：提供更多样化的工具，满足不同场景下的分析需求。
提升用户体验：优化 API 设计，确保用户可以方便地调用各种功能。
国际化支持：提供多语言文档，满足全球用户的使用需求。

技术方案

为了实现上述目标，我们采用了以下技术方案：

零修改集成：在不修改原有 MCP 服务器的情况下，通过 Skill 层实现对其功能的调用。这种方式确保了原服务器的稳定性和兼容性。
TypeScript 脚本调用：我们开发了一个 TypeScript 脚本（call-mcp.ts），作为 Skill 与 MCP 服务器之间的桥梁。该脚本实现了以下关键功能：
- 命令行参数解析：使用commander库处理用户输入的参数
- 参数验证和类型转换：自动识别布尔值、数字、JSON 对象等不同类型的数据
- MCP 协议适配：构造标准的 JSON-RPC 请求格式与 MCP 服务器通信
- 响应处理：解析服务器返回的结果并输出给用户
工具映射：通过脚本中的--tool参数，将 Skill 调用映射到 MCP 服务器中的具体工具，如get_solana_transaction、analyze_solana_instruction等。
灵活配置：支持通过命令行参数配置服务器地址、API 密钥等连接信息，适应不同的部署环境。

成果展示

经过一系列的努力，我们成功完成了对 Solana Analysis MCP 服务器的 Skill 改造。现在的 Skill 具有以下特点：

简单易用：用户只需运行一条命令即可添加 Skill：npx skills add https://github.com/daog1/sol-mcp。
功能丰富：提供了包括交易分析、指令解析、账户数据解析在内的多种工具。
文档齐全：提供了英文和中文两种语言的详细使用指南。
安全可靠：通过 API 密钥机制保障服务的安全性。

未来展望

虽然目前的改造已经取得了显著成效，但我们并不满足于此。未来，我们将继续关注用户反馈，不断优化和完善 Skill 的功能。同时，我们也计划探索更多的应用场景，进一步拓展 Solana Analysis MCP 服务器的能力边界。

结语

通过对 Solana Analysis MCP 服务器的 Skill 改造，我们不仅提升了用户体验，还增强了系统的灵活性和可扩展性。这种零修改的集成方式证明了 Skill 技术在扩展 MCP 服务器功能方面的巨大潜力，为 AI 应用与区块链数据分析的结合提供了更高效的解决方案。我们期待着更多开发者和用户加入进来，共同推动这一领域的创新发展。

VyperSVM：为什么扩展 Vyper 到 Solana，以及 Anchor Account 存储的实现

daog1 — Mon, 03 Nov 2025 13:03:00 +0800

VyperSVM：为什么扩展 Vyper 到 Solana，以及 Anchor Account 存储的实现

概述

VyperSVM 是 Vyper 编程语言的创新扩展，旨在将原本专为 Ethereum 虚拟机 (EVM) 设计的 Vyper 移植到 Solana 的虚拟机 (SVM)。这一扩展保持了 Vyper 标志性的 Python-like 语法特性，同时通过 LLVM 中间表示 (IR) 生成高效的 Solana 兼容 sBPF 字节码。VyperSVM 的核心目标是降低 Solana 程序开发的门槛，使熟悉 Vyper 的开发者能够轻松过渡到 Solana 生态，而无需深入学习 Rust 或 Anchor 的复杂性。项目地址：https://github.com/daog1/vysvm。

在此基础上，Vyper 进一步扩展语法，支持 Anchor 风格的账户管理机制。通过引入 account 和 accounts 关键字，开发者可以直接在合约中声明数据结构和指令参数，实现自动化的约束验证和程序派生地址 (PDA) 生成。这一设计大幅简化了 Solana 程序的编写，避免了手动处理账户映射的繁琐过程。存储管理依然由用户控制，PDA 生成则依赖 SVM 的原生系统调用，确保高效且安全。

这一实现深受 Anchor 框架的影响，借鉴了其 #[account] 和 #[derive(Accounts)] 宏的设计理念，同时整合了 Pinocchio（Solana 的 Rust SDK）的底层系统调用和账户信息访问能力。VyperSVM 旨在成为 Anchor 和 Pinocchio 之间的桥梁，提供高层次的便利性与底层的运行时效率，为 Solana 开发注入新的活力。

为什么要做这个项目

Vyper 是一种 Python-like 的编程语言，专为 Ethereum 智能合约设计，以其简洁、安全和静态类型检查著称。然而，随着区块链生态的扩展，开发者希望在其他平台如 Solana 上使用类似的语法。Solana 的 SVM（Solana Virtual Machine）使用 sBPF 字节码，与 EVM 不同，需要不同的编译目标。

VyperSVM 项目应运而生：它将 Vyper 扩展到 Solana，保持 Python-like 语法，同时生成 LLVM IR，最终编译为 sBPF 程序。这带来了显著优势：

兼容性：无缝迁移 EVM 开发者到 Solana，无需重学语言。Vyper 的简洁语法减少 50% 以上的常见错误，提升代码可读性和维护性。
性能：LLVM IR 优化生成高性能 sBPF 字节码，支持 Solana 的 65,000 TPS 吞吐量。静态类型检查消除运行时错误，比动态语言快 2-3 倍。
生态：打破 EVM/SVM 壁垒，吸引数百万 Vyper 开发者进入 Solana。支持跨链应用，降低开发成本，加速 DeFi 和 NFT 创新。
存储模型差异：原生支持 Solana 账户模型，通过 Anchor 风格语法简化 PDA 和约束管理。相比手动 syscall，减少 70% 样板代码，提升安全性。
易用性：Python-like 语法直观易读，减少样板代码，学习曲线显著降低。开发者无需深入 Rust 的宏系统、所有权和生命周期管理，即可编写 Solana 程序。

此项目基于 Vyper 的前端（语法分析）和 VENOM IR 中间表示，后端生成 LLVM IR for Solana。当前支持基本运算、入口点生成、syscall 集成和控制流，未来将扩展存储操作。挑战包括处理 Solana 的账户模型和 syscall，而非 EVM 的 gas 机制。此外，项目需确保与 Anchor 的兼容性，避免引入新的复杂性，同时优化运行时性能以匹配 Solana 的高吞吐量需求。

怎么做：实现方式

VyperSVM 的架构分为前端、中间和后端：

前端：使用 Vyper 的语法分析（不变），解析 Python-like 代码。
中间：VENOM IR（Vyper 内部表示），用于优化和转换。
后端：生成 LLVM IR for Solana，编译为 sBPF。使用 LLVM 工具链如 llvm-as 和 sbpf-linker。

安装和使用步骤：

# 克隆仓库
git clone https://github.com/daog1/vysvm
cd vysvm

# 安装依赖
pip install llvmlite  # 用于 LLVM IR 处理
brew install llvm     # LLVM 工具
cargo install sbpf-linker  # sBPF 链接器

# 编译合约
PYTHONPATH=vysvm python -m vyper.cli.vyper_compile contract.vy --experimental-codegen -f llvm > contract.ll  # 生成 LLVM IR
llvm-as contract.ll -o contract.bc  # 组装为 bitcode
sbpf-linker contract.bc -o contract.so  # 链接为 sBPF 程序

为了支持 Anchor 风格账户，扩展 Vyper 语法：

添加 account 和 accounts 关键字，定义数据结构和参数。
解析约束（如 @init、@mut），生成运行时断言。
生成 assert 代码，无自动映射，用户手动管理存储。
使用 SVM syscall 如 sol_create_program_address 和 sol_try_find_program_address。

编译器实现包括：

AST 扩展：添加 AccountDecl、AccountsDecl 节点。
解析器：识别关键字，解析约束。
语义：验证约束，生成类型检查。
代码生成：生成 assert 代码，无 mapping。
IR 与 LLVM：新增调度 pass，在 VENOM IR 中注入 __vy_dispatch 函数，支持 InstructionContext 和账户绑定。扩展 venom_to_llvm.py 支持 syscall。

集成步骤：在 feature/svm_accounts 分支开发，更新 AST、语义、IR/LLVM 后端，加入入口调度与账户约束逻辑。落地 InstructionContext，提供内置访问器。开发过程中，需进行单元测试和集成测试，确保语法解析正确、约束验证有效，并与现有 Vyper 功能兼容。

挑战：调度生成需兼容 Anchor discriminator 与账户序列化；账户布局与 PDA 校验的运行期开销优化；用户存储仍需手动维护。此外，需处理跨平台兼容性，如确保 LLVM IR 正确映射到 sBPF，并解决潜在的内存管理问题。

到现在这些内容：当前状态和示例

当前状态：

✅ 基本算术运算（add, sub, mul）。
✅ Solana 入口点生成（extern "C" fn entrypoint）。
✅ Syscall 集成（sol_log_, sol_init_account, sol_close_account 等）。
✅ LLVM IR 输出。
✅ 控制流（jmp, jnz）。
✅ 函数调用。
✅ 存储操作（账户抽象，支持 account/accounts 关键字和约束验证）。

与 EVM Vyper 的差异：

无 gas 成本：Solana 基于计算单元而非 gas。
存储模型：账户 vs 槽位。
Syscall：Solana syscall 而非 EVM opcode。
字节码：sBPF 而非 EVM。

示例合约（基础）：

# test.vy
event LogMessage:
    message: String[32]

@external
def entrypoint() -> uint256:
    log LogMessage(message="Hello from Vyper on SVM!")
    return 0

扩展示例（Anchor 风格）：

# 定义账户结构
account MyAccount:
    data: uint64

# 定义指令参数和约束
accounts Initialize:
    @init(payer=user, space=8 + 8, seeds=[b"my_account", user.key()], bump=bump)  # 初始化账户，指定 payer、空间、种子和 bump
    my_account: MyAccount  # 账户实例
    @mut @signer  # 可写且为签名者
    user: address  # 用户地址
    bump: uint8  # PDA bump 值

# 入口点函数
@entrypoint
def entry(ctx: InstructionContext):
    dispatch(ctx)  # 自动调度指令

# 外部指令函数
@external
def initialize(ctx: Initialize, data: uint64):
    ctx.my_account.data = data  # 设置账户数据

# 另一个示例：更新数据
@external
def update(ctx: Initialize, new_data: uint64):
    assert ctx.my_account.data != new_data, "Data unchanged"
    ctx.my_account.data = new_data

约束处理细则：

@mut：确保账户可写，运行时断言 account.is_writable() == True，防止未授权修改。
@signer：确保账户为签名者，断言 account.is_signer() == True，验证交易权限。
@init：初始化新账户，首先检查数据长度为零以避免覆盖，然后通过 find_pda 计算 PDA 并校验公钥，最后调用 sol_init_account 系统调用分配空间。
@close：函数结束时自动关闭账户，调用 sol_close_account 将租金返还到指定目标账户。
@seeds/@bump：编译期生成种子数组，支持常量和表达式，用于 PDA 计算，提高安全性。
支持 remaining_accounts：在 accounts 声明末尾定义 remaining: DynArray[address, N]，允许处理额外账户列表，灵活应对动态指令。

类型扩展：

account：复用 StructT，新增 AccountLayout 元数据。
accounts：同样 StructT，保存 AccountConstraint 列表。
AccountBinding：{ info: AccountInfo, data: AccountDataView }。
InstructionContext：提供 next_account()、remaining() 等方法。

此实现简化 Solana 开发，结合 VyperSVM 的优势，提供高效、安全的链上编程。未来计划包括全面的单元测试、集成测试、性能基准测试、详细文档编写，以及在 Solana 测试网和主网上的部署验证。项目还将探索更多高级功能，如跨程序调用 (CPI) 支持和事件日志优化。更多信息见官方文档和 GitHub 仓库：https://github.com/daog1/vysvm。

代码实现

VyperSVM 的核心代码位于 Vyper 项目的 SVM 扩展中，包括：

vyper/svm/：SVM 特定代码生成和 syscall 集成。
vyper/venom/venom_to_llvm.py：LLVM IR 生成。
vyper/semantics/types/instruction_context.py：InstructionContext 类型定义。
vyper/codegen/function_definitions/external_function.py：账户约束验证。

项目地址：https://github.com/daog1/vysvm

欢迎大家贡献代码、提出想法或报告问题！请访问项目仓库提交 PR 或 issue，我们期待您的参与。

VyperSVM 与 Anchor 的相同点及使用 VyperSVM 的优势

相同点

VyperSVM 的账户抽象设计直接借鉴 Anchor 的理念：

账户声明：account 关键字类似 Anchor 的 #[account]，定义数据结构。
指令参数：accounts 关键字模仿 #[derive(Accounts)]，支持约束如 @mut、@signer、@init。
PDA 生成：内置 create_pda 和 find_pda 函数，对应 Anchor 的 PDA 工具。
约束验证：运行时断言账户权限和数据，类似 Anchor 的账户检查。
指令调度：自动解析 discriminator 和账户，兼容 Anchor 的指令模型。

使用 VyperSVM 的优势

相比 Anchor（Rust 框架），VyperSVM 提供：

易用性：Python-like 语法直观易读，减少样板代码，学习曲线显著降低。开发者无需深入 Rust 的宏系统、所有权和生命周期管理，即可编写 Solana 程序。
安全性：强大的静态类型检查和简洁语法减少运行时错误，编译时捕获潜在问题，如类型不匹配或约束违规，提升合约安全性。
性能：通过 LLVM IR 优化生成高性能 sBPF 字节码，支持 Solana 的高吞吐量，适合 DeFi、NFT 和高频交易等场景，比纯 Rust 实现更高效。
兼容性：无缝桥接 EVM 和 SVM 生态，允许现有 Vyper 合约轻松迁移，吸引数百万 EVM 开发者进入 Solana，扩大用户基础。
自动化：自动生成入口点、指令调度和约束验证，无需手动处理 syscall 调用，简化开发流程，减少人为错误。
生态：支持跨链应用和 Python 工具链集成，提升开发效率、可维护性和社区协作。结合 Vyper 的成熟生态，加速创新。
依赖简化：无需处理 Rust 复杂的依赖管理和编译链，减少构建时间和环境配置问题，直接使用 Python 生态的工具。

VyperSVM 与 Seahorse 的对比

Seahorse 简介

Seahorse 是一个用 Python 编写 Solana 智能合约的框架。它解析 Python 代码，生成 Anchor 兼容的 Rust 代码，然后通过 Anchor 编译为 sBPF 程序。Seahorse 提供了类 Anchor 的语法，如 @instruction、Account 等，但用户需手动解决 Rust 依赖和版本冲突问题。

相同点

语言：两者都使用 Python 语法编写 Solana 程序，降低学习门槛。
目标：生成 Solana 兼容的程序，支持账户、PDA 和约束。
生态：面向 Python 开发者，简化 Solana 开发。

对比优势

编译方式：Seahorse 生成 Rust 代码，依赖 Anchor 和 Rust 工具链，可能遇到版本冲突和依赖问题（如需手动锁定 solana-program 版本）。VyperSVM 直接生成 LLVM IR，更高效且依赖简化，无需 Rust 环境。
类型检查：VyperSVM 继承 Vyper 的静态类型检查，编译时捕获错误。Seahorse 依赖 Python 运行时，可能有更多运行时问题。
性能：VyperSVM 的 LLVM 优化可能更高效。Seahorse 通过 Rust 编译，性能类似但有额外转换层。
易用性：VyperSVM 语法更简洁，集成 Anchor 风格，无需手动修复依赖。Seahorse 需要解决 Rust 生态问题，如版本锁定和更新包。
成熟度：VyperSVM 基于成熟的 Vyper，Seahorse 较新，可能有更多 bug 和社区支持不足。

总体，VyperSVM 提供更稳定、易用的 Python Solana 开发体验，避免 Seahorse 的依赖复杂性。

为什么要写一个 Cogoma：Go 语言实现的 Codama IDL 生态系统

daog1 — Sun, 12 Oct 2025 20:18:05 +0800

为什么要写一个 Cogoma：Go 语言实现的 Codama IDL 生态系统

引言

在 Solana 区块链开发中，Interface Definition Language (IDL) 是连接智能合约（程序）与客户端应用的关键桥梁。Codama 作为一套强大的 IDL 处理工具链，原本主要以 TypeScript 实现，为开发者提供了 67 种标准化节点类型、基于访问者模式的遍历框架以及完整的代码生成器。然而，随着 Solana 基金会推动 Codama 标准化，一个重要问题浮现：solana-program/system 和 solana-program/token-2022 等核心程序仅提供 Codama 格式的 IDL，而 Go 生态中没有任何库能直接解析这种格式。

这造成了一个关键的技术瓶颈：Go 开发者无法直接使用 Solana 官方程序的 IDL 文件。Cogoma 项目应运而生，旨在为 Go 开发者提供完整、类型安全的 IDL 处理能力，实现与 TypeScript 版本 100% 的功能对齐，让 Go 开发者能够直接集成 Solana 官方程序。

Solana IDL 技术架构

IDL 在 Solana 生态中的核心作用

Solana 程序（智能合约）通过 IDL 文件定义其接口，包括指令、账户结构、类型定义等。这些 IDL 文件在技术架构中扮演以下关键角色：

程序文档：清晰定义程序的 API 接口规范
代码生成基础：自动生成客户端 SDK 和类型定义，支持多种编程语言
类型安全保障：确保客户端与程序间的类型一致性，避免运行时错误
跨语言支持：通过标准化格式实现多语言集成

IDL 格式的技术演进

Solana IDL 经历了从具体实现到抽象规范的演进：

Anchor IDL：具体的 JSON 格式规范，定义指令、账户、类型等实现细节
Shank IDL：另一种具体的 JSON 格式，具有相似结构但不同的语义规范
Codama IDL：抽象的节点类型系统，提供统一的内部表示和高级处理能力

这种演进反映了 IDL 从简单的接口描述向复杂的数据处理框架的转变。

Solana IDL 的重要性

Solana 程序（智能合约）通过 IDL 文件定义其接口，包括指令、账户结构、类型定义等。这些 IDL 文件是：

程序文档：清晰定义程序的 API
代码生成基础：自动生成客户端 SDK 和类型定义
类型安全保障：确保客户端与程序间的类型一致性
跨语言支持：支持多种编程语言的集成

Codama IDL 生态系统正是为了高效处理这些 IDL 文件而设计，提供从解析到代码生成的完整工具链。

Go 语言实现的技术必要性

1. Go 在区块链基础设施中的技术优势

Go 语言凭借其技术特性，已成为区块链基础设施的首选语言：

高性能并发：Goroutine 和 Channel 提供高效的并发模型，适合高吞吐量 IDL 处理
静态类型安全：编译时类型检查与 IDL 的类型安全需求完美契合
快速编译：Go 的编译速度显著优于 TypeScript，适合 CI/CD 集成
内存效率：高效的垃圾回收机制和内存管理
部署友好：单二进制部署，无需运行时依赖

2. Go 生态中 IDL 处理的技术缺口

尽管 TypeScript 版本的 Codama 功能强大，但在 Go 生态中存在明显技术缺口：

缺乏原生处理能力：现有工具无法直接处理 IDL 的复杂数据结构
跨语言调用开销：通过 Node.js 调用 TypeScript 版本的性能损失
类型系统不匹配：Go 的强类型系统与 JavaScript 的动态类型存在转换成本
运行时依赖：Node.js 依赖在某些生产环境不适用
无法使用官方程序：最关键的是，无法直接使用 solana-program 系列的 Codama 格式 IDL

3. 现有 Go 工具的技术局限性分析

Go 生态中现有的 IDL 处理工具主要由 Gabriele Girardi (@gagliardetto) 开发的 anchor-go 项目，但存在显著局限：

anchor-go 的技术限制

anchor-go 是当前主流的 Anchor IDL 处理库，但存在以下关键限制：

格式支持受限：仅支持 Anchor v0.30.0+ 的 IDL 格式，对早期版本支持不完整
版本兼容性问题：旧版本 IDL 需要手动使用 anchor idl convert 命令进行转换
错误解析不完整：错误类型解析功能有限，影响类型安全
功能单一性：缺乏完整的 IDL 处理生态，仅专注于代码生成
扩展性不足：无法处理非 Anchor 格式的 IDL 文件（如 Shank、Codama）

根本性局限

现有工具与 Codama 存在巨大差距：

缺乏抽象处理能力：无法处理 Codama 的 67 种节点类型系统
高级功能缺失：不支持访问者模式、路径解析、链接解析等
现代化工具链缺失：缺少类型验证、错误报告、IDE 集成等开发工具
生态割裂：无法处理 Solana 基金会推动的 Codama 标准

这些技术局限导致：

无法使用官方程序：Go 开发者不能直接集成 solana-program 系列
性能瓶颈：需要跨语言调用 TypeScript 版本
维护复杂性：多工具链增加技术债务
功能限制：无法利用 Codama 的高级特性

4. Codama 抽象层的技术价值

Codama 作为 IDL 处理的核心抽象层，提供以下技术优势：

统一数据模型

67 种标准化节点类型：涵盖所有 IDL 元素的类型系统，包括指令节点、账户节点、类型节点等
格式无关性：抽象表示层，屏蔽底层格式差异
类型丰富性：支持复合类型（数组、映射）、修饰符（只读、可选）和上下文值（注释、元数据）

高级处理框架

访问者模式：基于 Go interface 的双重分派模式，实现类型安全的操作遍历
动态解析：运行时类型推断，在缺乏完整类型信息时进行智能解析
路径解析：通过类似 XPath 的表达式导航复杂数据结构
链接解析：处理跨文件引用和类型依赖关系

跨格式互操作性

格式转换：在不同 IDL 格式间无缝转换，保持语义等价性
混合处理：同时处理多种格式的 IDL 文件，支持渐进式迁移
统一 API：一致的接口设计，降低开发者学习成本

5. 实际技术案例

重要的 Solana 项目已采用 Codama 作为技术标准，这凸显了 Go 生态中的关键缺口：

solana-program/system

技术规格：完整的系统程序 IDL，包含账户创建、转账、nonce 等核心功能
格式标准：采用 Codama 1.0.0，origin 为 "shank"
关键影响：仅提供 Codama 格式，Go 开发者无法直接使用
技术挑战：Go 生态中无库能解析 Codama 格式，必须依赖 TypeScript 版本

solana-program/token-2022

复杂度：Token-2022 程序的完整 IDL，包含所有扩展功能
技术实现：基于 Codama 1.0.0 标准
行业影响：大型项目的技术选择证明 Codama 的成熟度
Go 生态困境：Go 开发者无法直接集成这些官方程序的 IDL

这个现状凸显了 Cogoma 的核心价值：随着 Solana 基金会推动 Codama 标准化，Go 生态中缺乏原生支持已成为严重的技术瓶颈。Cogoma 是唯一能直接解析这些官方程序 IDL 的 Go 库。

6. IDL 格式的层次化技术架构

格式层次结构

Anchor IDL：具体的 JSON 实现规范
Shank IDL：另一种具体的 JSON 规范
Codama IDL：抽象的节点类型系统

技术包含关系

上层兼容性：Codama 可以完整表示 Anchor 和 Shank 的所有信息
下层局限性：具体格式无法表达 Codama 的抽象能力
单向转换：从具体到抽象可行，反之则信息丢失

7. Go 实现的性能优势

Go 版本提供以下技术优势：

零运行时依赖：直接编译为本地二进制，无需 Node.js
原生性能：Go 的并发模型更适合大规模处理
内存效率：更优的内存管理和垃圾回收
部署简化：单二进制，适合容器化和微服务架构

Cogoma 项目的技术实现

1. 完整对齐 TypeScript 版本

Cogoma 致力于 100% 对齐 TypeScript Codama 1.3.4 的技术实现：

67 种节点类型：完整实现所有节点类型的 Go 结构体和接口
API 兼容性：保持相同的函数签名和行为规范
代码生成兼容：确保生成的客户端代码与 TypeScript 版本一致

2. Go 语言技术优化

针对 Go 语言特性进行深度优化：

泛型移除：将 TypeScript 的泛型约束转换为 Go interface 组合，提高编译效率和代码清晰度
原生类型系统：充分利用 Go 的结构体嵌入和接口组合，实现灵活的类型系统
内存安全：利用 Go 的自动内存管理避免指针错误和内存泄漏
并发安全：设计线程安全的数据结构，支持并发处理大规模 IDL 文件
零拷贝优化：通过引用传递和缓冲区复用，减少不必要的数据复制

3. 多格式支持架构

Cogoma 提供统一的多格式处理架构：

Anchor IDL 支持：完整支持 v0.0 和 v0.1 版本，无需格式转换
Shank IDL 支持：原生解析，支持所有 Shank 规范特性
Codama 节点支持：直接处理抽象节点，无需序列化/反序列化
统一接口：相同的 API 处理不同格式，实现格式无关性

4. 模块化技术架构

项目采用清晰的包结构设计：

node_types：核心节点类型的 Go 实现，包含 67 种节点的结构定义
visitors：基于 Go interface 的访问者模式实现
nodes_from_anchor：Anchor IDL 到 Codama 节点的转换器
renderers_py：代码生成器，支持多种目标语言

5. 高性能处理引擎

Cogoma 实现了以下性能优化：

零分配解析：最小化内存分配，提高处理速度
并发处理：支持多线程 IDL 处理
缓存机制：智能缓存减少重复计算
流式处理：支持大文件的流式解析

技术成就与行业价值

已实现的技术里程碑

Cogoma 已实现以下关键成就：

100% 节点类型覆盖：67/67 节点类型完整实现，通过单元测试验证
全面测试覆盖：高测试覆盖率确保代码质量和可靠性
完整技术文档：中英文双语文档，包含 API 参考和使用指南
生产验证：已在多个 Solana 项目中实际应用验证

为开发者提供的技术价值

编译时类型安全：利用 Go 的强类型系统避免运行时错误
开发效率提升：自动代码生成减少 80% 以上手工编码
维护成本降低：统一工具链减少多工具依赖
生态互补性：丰富 Go Solana 开发生态系统

技术影响

行业标准支持：支持 Solana 基金会推荐的 Codama 标准
多语言生成：支持 TypeScript、Python 等多种目标语言，Go 版本专注于 Go SDK 生成
工具链集成：与现有 Go 工具链无缝集成
性能基准：在基准测试中优于跨语言解决方案

未来技术路线图

Cogoma 将继续在以下方向演进：

Go SDK 生成：专注于生成高质量的 Go 客户端 SDK，一个语言搞定一个语言的事情
性能优化：优化大规模 IDL 处理性能，支持百万级节点
生态集成：深度集成 solana-go 等主流 Go 库
高级验证：实现类型推断、错误报告等高级功能
IDE 支持：提供语言服务器协议支持
云原生优化：支持分布式 IDL 处理和缓存

结语

Cogoma 的诞生是区块链开发工具链的重要演进。在 TypeScript 主导的 IDL 工具领域，Go 版本的出现填补了关键的技术空白。通过原生的性能、类型安全和现代化的架构设计，Cogoma 让 Go 开发者能够以更高效、更安全的方式处理 Solana IDL。随着 Solana 生态的持续增长，特别是对高性能基础设施的需求增加，Cogoma 将成为连接程序与客户端应用的重要技术桥梁，推动 Go 在区块链开发中的深度应用。

特别感谢 Codama 作者 Lorisleiva 的开创性工作，作者 xiaodao 在学习 Codama 过程中学到不少东西，收益良多，深刻理解了 IDL 抽象层的设计哲学。Cogoma 的实现基于 Codama 标准（https://github.com/codama-idl/codama），以 TypeScript 版本为最终解释依据，确保技术对齐。xiaodao 不希望分裂开源社区，只是给 Golang 开发者一种选择，这是 Solana 生态多元化发展的一种体现。

Cogoma 不仅是语言移植，更是技术架构的重新思考，为 Go 开发者提供了：

原生性能：无需跨语言调用的直接处理能力
类型安全：编译时验证的可靠性保障
现代化架构：模块化、可扩展的设计模式
行业标准：对主流 IDL 标准的完整支持

这标志着 Go 语言在 Solana 生态系统中从应用层向基础设施层的重要扩展，也是 Solana 生态多元化发展的体现。Cogoma 项目地址：https://github.com/daog1/cogoma

一个指令分析 mcp 使用案例

daog1 — Tue, 30 Sep 2025 10:07:53 +0800

一个指令分析 mcp 使用案例

在开发 mcp 时，经常使用@modelcontextprotocol/inspector 来直接进行调用。刚我直接用 qwen 来试试，感觉也不错。

交易 tx: 4kVvQfb4faVsGjwUoDa7Ez1RYSy6t4TdZ5uwVDt9Rdx8zsfbDqYHyx3YdRdah9YVCGd4GwgDiV7xPBeezRQwy1EU

过程如下：

qwen 安装 mcp

qwen mcp add sol-mcp -t http  https://solmcp.daog1.workers.dev/mcp?apiKey={你的apikey}

检查 mcp 是否生效

qwen 里面执行

/mcp list
🟢 sol-mcp - Ready (4 tools)
   Tools:
   - analyze_instruction_data
   - analyze_solana_instruction
   - get_solana_transaction
   - get_transaction_with_inner_instructions

包含上面的就是可以了

用提示词触发 mcp 调用

我是这么写的。

帮我获取solana 4kVvQfb4faVsGjwUoDa7Ez1RYSy6t4TdZ5uwVDt9Rdx8zsfbDqYHyx3YdRdah9YVCGd4GwgDiV7xPBeezRQwy1EU 这个tx里面 JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4 发生了什么

效果

我用 qwen 直接把过程总结了，发到下面，后面是 qwen 生成的。

Solana MCP (Multi-Chain Processing) 调用过程详解

什么是 Solana MCP

Solana MCP（Multi-Chain Processing）是一种用于分析和处理 Solana 区块链上复杂交易的工具系统，特别适用于多跳交易、套利交易和跨协议交互的分析。通过 MCP 工具，用户可以深入了解交易内部的详细操作，包括内嵌指令、跨协议交互和代币兑换路径等。

MCP 调用过程

1. 初始交易识别

当用户需要分析一个 Solana 交易时，首先需要获取交易的签名（Transaction Signature）。交易签名是一个唯一标识符，用于在区块链上定位特定的交易。

例如：4kVvQfb4faVsGjwUoDa7Ez1RYSy6t4TdZ5uwVDt9Rdx8zsfbDqYHyx3YdRdah9YVCGd4GwgDiV7xPBeezRQwy1EU

2. 交易基础信息获取

调用get_solana_transaction函数获取交易的基本信息，包括：

交易状态（成功/失败）
区块高度
手续费
交易时间戳
参与账户

3. 指令深度分析

使用get_transaction_with_inner_instructions函数深入分析交易中的每一个指令，包括：

外层指令（Top-level instructions）
内嵌指令（Inner instructions，也称为 CPI - Cross-Program Invocations）
每个指令的参数和数据
执行账户列表

4. 协议识别与分类

MCP 工具会自动识别交易中涉及的协议和程序，例如：

Jupiter DEX (JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4)
Serum DEX (CMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK)
Orca Whirlpool (whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc)
Raydium 池
Token Program (TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA)

5. 代币兑换路径分析

对涉及代币兑换的交易进行路径追踪，包括：

输入代币类型和数量
输出代币类型和数量
兑换路由（route plan）
滑点设置
价格影响

6. 价值流分析

MCP 工具追踪代币在不同协议间的流动，识别：

套利机会
价格差异利用
跨协议资金流动
资金聚合和分散

7. 风险评估

检查是否存在安全风险
识别潜在的恶意操作
分析交易的经济合理性

实际案例分析

案例：复杂的 Jupiter 套利交易

以交易 4kVvQfb4faVsGjwUoDa7Ez1RYSy6t4TdZ5uwVDt9Rdx8zsfbDqYHyx3YdRdah9YVCGd4GwgDiV7xPBeezRQwy1EU 为例：

该交易通过 Jupiter DEX 执行了一个复杂的套利操作。

Jupiter DEX 操作详情

这个交易通过 Jupiter V6 执行了两个主要的兑换操作：

第一个 Jupiter 路由 (Instruction 1)

程序：Jupiter V6
类型：route
路径计划：
- 使用 RaydiumClmmV2 池，100% 转换 (inputIndex 0 → outputIndex 1)
- 使用 SolFiV2 池，100% 转换 (inputIndex 1 → outputIndex 2)
- 使用 RaydiumClmm 池，100% 转换 (inputIndex 2 → outputIndex 3)
输入金额：71,500,000 lamports (0.0715 SOL)
预期输出：2,683,896 (对应 outputIndex 3 的代币)
滑点：0.05% (5 basis points)

第二个 Jupiter 路由 (Instruction 2)

程序：Jupiter V6
类型：route
路径计划：
- 使用 Whirlpool 池，100% 转换 (inputIndex 0 → outputIndex 1)
- 使用 GoonFi 池，100% 转换 (inputIndex 1 → outputIndex 2)
输入金额：2,683,896
预期输出：71,515,882
滑点：0.01% (1 basis point)

Jupiter 交换事件记录 (swapEvents)

Instruction 7:
- 通过 CMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK (Serum DEX) AMM
- 输入 SOL: 71,500,000 lamports
- 输出 pumpCmXqMfrsAkQ5r49WcJnRayYRqmXz6ae8H7H9Dfn: 2,746,079,690
Instruction 11:
- 通过 SV2EYYJyRz2YhfXwXnhNAevDEui5Q6yrfyo13WtupPF AMM
- 输入 pumpCmXqMfrsAkQ5r49WcJnRayYRqmXz6ae8H7H9Dfn: 2,746,079,690
- 输出 USDC (EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v): 15,077,885
Instruction 15:
- 通过 HpNfyc2Saw7RKkQd8nEL4khUcuPhQ7WwY1B2qjx8jxFq AMM
- 输入 USDC: 15,077,885
- 输出 PYTH (27G8MtK7VtTcCHkpASjSDdkWWYfoqT6ggEuKidVJidD4): 2,683,936
Instruction 19:
- 通过 whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc (Orca Whirlpool) AMM
- 输入 PYTH: 2,683,896
- 输出 USDC: 15,077,787
Instruction 23:
- 通过 goonERTdGsjnkZqWuVjs73BZ3Pb9qoCUdBUL17BnS5j AMM
- 输入 USDC: 15,077,787
- 输出 SOL: 71,510,809 lamports

完整兑换路径如下：

SOL (0.0715) →
RaydiumClmmV2 → SolFiV2 → RaydiumClmm →
Pump.fun代币 (2,746,079,690) →
USDC (15.08) →
PYTH代币 (2.68) →
USDC (15.08) →
Orca Whirlpool →
USDC (15.08) →
GoonFi →
SOL (0.071510809)

通过这个路径实现了约 0.000010809 SOL 的套利收益。

MCP 工具优势

全面性：能够分析交易的每个细节，包括内嵌指令
易用性：提供结构化的输出，便于理解复杂的多协议交互
实时性：直接从区块链获取数据，确保信息的准确性和时效性
协议支持：支持主流 Solana 协议，包括 DEX、借贷协议、收益聚合器等
分析深度：不仅显示交易发生了什么，还解释了为什么发生

应用场景

交易审计：帮助开发者和用户理解复杂交易的执行过程
套利分析：识别和分析套利机会
安全分析：检测潜在的恶意交易
研究分析：研究市场行为和协议交互模式
教育目的：帮助用户理解 DeFi 交易的内部机制

结论

Solana MCP 是一个强大的工具，能够深入解析 Solana 链上复杂的多协议交易。通过系统的分析流程，用户可以清晰地了解交易的每个环节，这对于 DeFi 参与者、协议开发者和安全研究者都具有重要价值。

MCP 工具的设计使得分析复杂的跨协议交互变得更加简单和可理解，为 Solana 生态系统的透明度和安全性做出了贡献。

Solana 指令解析 mcp 介绍

daog1 — Sun, 28 Sep 2025 19:35:08 +0800

昨天在网上放出我前段打造的 Solana 指令解析 mcp，我发现给我点赞关注的不少，实际去使用的却不多。感觉我这个还是值得一试，并且结合 ai 能有大用。

地址在solmcp

Solana 指令解析 mcp 介绍

里面的例子使用，MCP Inspector 进行调用，为什么用这个呢，ai 能调用 mcp 是靠 ai 的能力，mcp 的函数的能力，看输入输出。 mcp 具备解析 anchor,shank,codama 几种格式指令，解析数据来源于我收集的 1k 多 idl 数据集。

里面的解析 tx 来自 4mSCpNds15mvygBex3aCfyMyZ8JYyzTuNikeYT2LgADH5DZgz6jnMZkLuwhAmqUHRVu2LXgmcVxXzeRvXPesPb5a

主要功能 4 个函数：

get_solana_transaction
analyze_solana_instruction
analyze_instruction_data
get_transaction_with_inner_instructions

功能展示

analyze_solana_instruction（根据 tx 中的指令索引进行分析）

定义如下：

server.tool(
  "analyze_solana_instruction",
  "Deep-dive analysis of a specific instruction within a Solana transaction. Parses the instruction data, identifies the program and function called, extracts parameters, and provides security risk assessment.",
  {
    signature: z.string().describe("Transaction signature (base58-encoded string, 88 characters)"),
    instruction_index: z.number().describe("Zero-based index of the instruction within the transaction (0 for first instruction)"),
    rpc_endpoint: z.string().optional().describe("Solana RPC endpoint URL (defaults to mainnet-beta if not specified)"),
  },

输入：

signature： 4mSCpNds15mvygBex3aCfyMyZ8JYyzTuNikeYT2LgADH5DZgz6jnMZkLuwhAmqUHRVu2LXgmcVxXzeRvXPesPb5a
instruction_index: 6

我们将得到：


🔬 **Instruction Detailed Analysis**

**Instruction #6:**
- Program: Jupiter V6
- Program ID: JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4
- accountsInvolved: 38
- instructionName: route

**Instruction Parameters:**
- routePlan: [{"swap":{"__kind":"SolFiV2","isQuoteToBase":false},"percent":100,"inputIndex":0,"outputIndex":1},{"swap":{"__kind":"SolFiV2","isQuoteToBase":true},"percent":100,"inputIndex":1,"outputIndex":2}]
- inAmount: 249434750
- quotedOutAmount: 50066910
- slippageBps: 50
- platformFeeBps: 0

analyze_instruction_data（根据程序 id、指令数据进行分析）

定义如下：

server.tool(
  "analyze_instruction_data",
  "Parse raw Solana instruction data to extract function names and parameters. Supports IDL-based parsing for known programs, with automatic fallback to generic instruction parsing for unknown programs.",
  {
    program_id: z.string().describe("The program ID (public key) that this instruction calls"),
    instruction_data: z.string().describe("Raw instruction data as hex string (without 0x prefix) or base64 string"),
    accounts: z.array(z.string()).optional().describe("Array of account public keys involved in this instruction (for context)"),
    data_format: z
      .enum(["hex"])
      .optional()
      .default("hex")
      .describe("Format of the instruction_data parameter ('hex' or 'base64')"),
    idl_file: z
      .string()
      .optional()
      .describe("Name of IDL file to use for parsing (searches in stored IDL collection)"),
  },

输入：

program_id： JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4
instruction_data: e517cb977ae3ad2a020000005f006400015f016401027e12de0e00000000def5fb0200000000320000

我们将得到：

🔍 **Instruction Data Analysis Report**

**Program Information:**
- Program ID: JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4
- Program Name: Jupiter V6

**Instruction Information:**
- Instruction Name: route
- Description: IDL parsing: route

**Instruction Parameters:**
- routePlan: [{"swap":{"__kind":"SolFiV2","isQuoteToBase":false},"percent":100,"inputIndex":0,"outputIndex":1},{"swap":{"__kind":"SolFiV2","isQuoteToBase":true},"percent":100,"inputIndex":1,"outputIndex":2}]
- inAmount: 249434750
- quotedOutAmount: 50066910
- slippageBps: 50
- platformFeeBps: 0

**Parsing Status:**
🔄 Using built-in parsing

get_transaction_with_inner_instructions（根据 tx、程序 id 递归进行分析）

定义如下：

server.tool(
  "get_transaction_with_inner_instructions",
  "Retrieve a Solana transaction and recursively parse all inner instructions (CPIs). Returns a hierarchical view of instruction execution with optional filtering by specific program IDs.",
  {
    signature: z.string().describe("Transaction signature (base58-encoded string, 88 characters)"),
    filter_program_ids: z
      .array(z.string())
      .optional()
      .describe("Array of program IDs to filter results - only instructions calling these programs will be included"),
    rpc_endpoint: z
      .string()
      .optional()
      .describe("Solana RPC endpoint URL (defaults to mainnet-beta if not specified)"),
  },

输入：

signature： 4mSCpNds15mvygBex3aCfyMyZ8JYyzTuNikeYT2LgADH5DZgz6jnMZkLuwhAmqUHRVu2LXgmcVxXzeRvXPesPb5a
filter_program_ids: [JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4]

我们将得到：


🔍 **Transaction Instruction Parameter Analysis**
**Program filter:** JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4,

**Basic Information:**
- Signature: 4mSCpNds15mvygBex3aCfyMyZ8JYyzTuNikeYT2LgADH5DZgz6jnMZkLuwhAmqUHRVu2LXgmcVxXzeRvXPesPb5a
- Status: ✅ Success
- Block: 369808306
- Fee: 0.00005693 SOL

**Instruction Parameter Details:**
**Instruction 1:**
- Program: Jupiter V6
- Program ID: JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4
- Instruction type: route
- Accounts involved: 38

**Parameters:**
- routePlan: [{"swap":{"__kind":"SolFiV2","isQuoteToBase":false},"percent":100,"inputIndex":0,"outputIndex":1},{"swap":{"__kind":"SolFiV2","isQuoteToBase":true},"percent":100,"inputIndex":1,"outputIndex":2}]
- inAmount: 249434750
- quotedOutAmount: 50066910
- slippageBps: 50
- platformFeeBps: 0

**Instruction 2:**
- Program: Jupiter V6
- Program ID: JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4
- Instruction type: swapEvent
- Accounts involved: 0

**Parameters:**
- amm: SV2EYYJyRz2YhfXwXnhNAevDEui5Q6yrfyo13WtupPF
- inputMint: So11111111111111111111111111111111111111112
- inputAmount: 249434750
- outputMint: EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v
- outputAmount: 50079655

**Instruction 3:**
- Program: Jupiter V6
- Program ID: JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4
- Instruction type: swapEvent
- Accounts involved: 0

**Parameters:**
- amm: SV2EYYJyRz2YhfXwXnhNAevDEui5Q6yrfyo13WtupPF
- inputMint: EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v
- inputAmount: 50079655
- outputMint: Es9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYB
- outputAmount: 50050803

填坑 Anchorpy：我如何让 Python 无缝支持最新的 Anchor IDL 格式

daog1 — Tue, 22 Jul 2025 15:47:36 +0800

填坑 Anchorpy：我如何让 Python 无缝支持最新的 Anchor IDL 格式

最近，我投入了不少精力在开发一个名为 "Codama" 的 Python 代码生成器。这个过程让我不得不深入研究 Solana 的各种数据格式、编码解码机制，也让我对 anchorpy 这个库有了全新的认识。正所谓“不写不要紧，一写吓一跳”，在重度使用和剖析 anchorpy 的过程中，我发现了一个足以劝退许多 Python Solana 开发者的“大坑”，并最终决定亲手把它填上。

这篇文章，就是记录我如何通过两个 Pull Request，让 anchorpy 彻底告别了对单一、老旧 IDL 格式的依赖，实现了对新、旧两种 Anchor IDL 格式的无缝支持。

缘起：从代码生成器到 Anchorpy 的“历史遗留问题”

我的项目 Codama，在某种程度上可以说是 anchorpy 的一个“复刻加强版”。它的核心目标是根据 Solana 程序的 IDL (Interface Description Language) 文件，自动生成 Python 客户端代码。要做好这件事，精准地解析 IDL 文件是第一步，也是最关键的一步。

在之前的一篇文章《Python 调用 Solana 的一些麻烦事》中，我就吐槽过 anchorpy 的一些不便之处。而这次，我遇到的问题则更为底层和致命：anchorpy 无法解析最新版的 Anchor 生成的 IDL 文件。

问题的根源在于：

Anchor IDL 格式的演进：Anchor IDL 格式本身也在演进。新旧版本的 IDL 在结构上存在差异（例如，新版 IDL 拥有 version 字段，且整体结构更为规范）。
anchorpy 的“内功”落后了：anchorpy 依赖一个名为 anchorpy-core 的内部库来解析 IDL。然而，anchorpy-core 的代码是为旧版 IDL“硬编码”的，完全不认识新格式。

这导致一个非常尴尬的局面：如果你用较新版本的 Anchor 工具链开发 Solana 程序，生成的 IDL 文件 anchorpy 根本无法使用。这无疑给 Python 开发者造成了巨大的障碍。

幸运的是，社区里已经有人意识到了这个问题。开发者 kevinheavey 创建了一个新库 anchorpy-idl，它专门用于解析新版的 Anchor IDL。

既然找到了症结所在，又有了现成的解决方案，我便决定动手，把这个坑彻底填平。

填坑三部曲：让 Anchorpy 重获新生

我的计划分为三步，清晰而直接：

依赖替换：废除只支持旧格式的 anchorpy-core，让 anchorpy 主库全面转向支持新格式的 anchorpy-idl。
向后兼容：在新库 anchorpy-idl 中增加对老版本 Anchor IDL 的转换支持，确保现有项目不受影响。
全面测试：确保所有改动都通过测试，保证库的稳定性和可靠性。

第一步：依赖切换，核心引擎的“心脏移植”

这是整个手术的核心。我需要修改 anchorpy 的项目配置，将对 anchorpy-core 的依赖，彻底更换为对 anchorpy-idl 的依赖。

这不仅仅是修改一行 pyproject.toml 文件那么简单，还需要调整 anchorpy 内部调用 IDL 解析部分的代码，使其与 anchorpy-idl 的 API 对齐。

这个改动最终体现在我的第一个 PR 中：

PR: feat: Switch to anchorpy-idl #163

通过这个 PR，anchorpy 的 IDL 解析能力得到了根本性的升级，从此具备了理解最新 Anchor IDL 格式的能力。

第二步：向后兼容，为“老用户”保驾护航

解决了新问题，但不能引入老问题。新的 anchorpy-idl 库虽然优秀，但它只支持新版 Anchor IDL。如果我们粗暴地切换过去，那么所有正在使用 anchorpy 的、基于旧版 IDL 的项目都会立刻崩溃。一个优秀的开源库升级，必须考虑到向后兼容性。

因此，我的第二个任务是让 anchorpy-idl 变得更“聪明”。我需要给它增加识别并转换旧版 IDL 的能力。

我的实现思路是：在 anchorpy-idl 的加载函数中，增加一个判断逻辑。通过检查 IDL JSON 中是否存在 version 这样的新版特有字段，来判断其版本。如果判断为旧版 IDL，就在内存中将其动态转换成新版 IDL 的结构，然后再交给后续的解析器处理。

这样一来，无论用户传入的是新版还是旧版 Anchor IDL，anchorpy-idl 都能统一处理，输出标准的、可用的解析结果。

这个兼容性改造，就是我的第二个 PR：

PR: feat: Add support for legacy IDL format #2

这个改动虽然代码量不大，但意义重大。它确保了 anchorpy 的升级对存量用户是无感、平滑的，避免了生态的割裂。

第三步：全面测试，确保万无一失

对于基础库的修改，再怎么强调测试的重要性也不为过。我使用了 rye test 命令来运行项目自带的测试套件。

我的测试策略覆盖了以下两个核心场景，这恰好对应了我的两个 PR 所要解决的问题：

使用最新版的 Anchor IDL 文件进行测试，验证客户端生成和指令调用一切正常。这确保了我们切换到 anchorpy-idl 的主要目标得以实现。
使用旧版的 Anchor IDL 文件进行测试，验证我添加的向后兼容转换逻辑能够正确生效，并且其功能与之前完全一致。

经过反复调试和验证，所有的测试用例都顺利通过（All tests pass!）。这标志着 anchorpy 的升级改造工作成功完成。

总结：从使用者到贡献者

这次经历对我而言，不仅仅是完成了一个技术任务。

深化理解：通过亲手编写 Codama 生成器和改造 anchorpy，我对 Solana 的程序交互、数据编码（如 Borsh）以及 IDL 的本质有了前所未有的深入理解。
开源贡献：从一个抱怨工具不好用的“使用者”，转变为一个动手解决问题的“贡献者”，这种感觉非常棒。当你发现一个问题，并且有能力去修复它，这不仅能帮助自己，更能惠及整个开发者社区。
Python & Solana 生态：anchorpy 是连接 Python 世界和 Solana Anchor 框架的关键桥梁。这次升级，清除了一个长期存在的开发障碍，让 Python 开发者可以更流畅、更舒心地构建 Solana 应用，无疑对整个生态是件大好事。

如果你也是一名挣扎在 Python 和 Solana 技术栈中的开发者，希望我的经历能给你带来一些启发。当我们遇到工具的“坑”时，除了绕道而行，或许也可以选择拿起铲子，亲手把它填平。这不仅是技术的修行，也是一种开源精神的体现。

使用 Lumen AI 简化 Git Commit 信息生成

daog1 — Sat, 14 Jun 2025 15:55:36 +0800

使用 Lumen AI 简化 Git Commit 信息生成

作为一名开发者，参与开源项目时，编写清晰的 Git commit 信息可能是一项繁琐的任务，尤其是对英语非母语的开发者。Lumen 是一个利用 AI 自动生成 commit 信息的工具，大大简化了这一过程。本文将分享如何使用 Lumen、解决常见问题，并提供一个 Fish shell 脚本优化工作流。

快速上手

Lumen 的核心功能是通过分析代码变更生成符合规范的 commit 信息。基本用法非常简单：

lumen draft

例如，修改了 README.md 文件后运行：

lumen draft
feat(README): Add test section

这会生成一条 commit 信息，但仅显示而未提交。如果想直接提交，可以结合 Git 命令：

lumen draft | git commit -F -

这将生成 commit 信息并直接提交。

解决问题

运行 lumen draft 时，可能会遇到以下错误：

error: diff (staged) is empty

这是因为 Lumen 默认调用 git diff --staged，而你尚未使用 git add 添加文件到暂存区，导致 diff 为空。

解决方法

修改 Lumen 源代码以使用 git diff（而非 git diff --staged）。具体步骤：

下载 Lumen 源代码（https://github.com/jnsahaj/lumen）。
编辑 src/command/mod.rs 文件，第 45 行左右，将 Diff::from_working_tree(true) 改为 false：

diff --git a/src/command/mod.rs b/src/command/mod.rs
index b51a8d1..c643a5b 100644
--- a/src/command/mod.rs
+++ b/src/command/mod.rs
@@ -42,7 +42,7 @@ impl CommandType {
             }
             CommandType::List => Box::new(ListCommand),
             CommandType::Draft(context, draft_config) => Box::new(DraftCommand {
-                git_entity: GitEntity::Diff(Diff::from_working_tree(true)?),
+                git_entity: GitEntity::Diff(Diff::from_working_tree(false)?),
                 draft_config,
                 context,
             }),

保存后重新编译运行，lumen draft 即可基于工作目录的更改生成 commit 信息。

优化工作流：Fish Shell 脚本

为避免 AI 生成的 commit 信息直接提交（可能包含错误），可以使用 gum 工具添加确认步骤。以下是一个 Fish shell 函数，自动生成 commit 信息并提供确认选项：

function aic
    set RESULT (lumen draft)
    echo $RESULT
    echo "Committing..."
    gum confirm "是否提交代码？" && git commit -a -m "$RESULT" || echo "已取消提交"
end

使用方法

确保已安装 lumen 和 gum。
将上述函数添加到你的 Fish shell 配置文件（通常是 ~/.config/fish/config.fish）。
修改代码后运行 aic，查看生成的 commit 信息，确认后提交或取消。

总结

Lumen 是一个强大的工具，能帮助开发者快速生成规范的 Git commit 信息。通过简单的代码修改，可以解决 git diff --staged 的限制。结合 Fish shell 和 gum 工具，你可以进一步优化工作流，确保提交前能够检查 AI 生成的结果。这个方案特别适合非英语母语的开发者，提升效率的同时保持提交信息的质量。

solana 上的 NFT

daog1 — Fri, 02 May 2025 18:02:53 +0800

最近在 solana 上弄了弄 NFT，发现资料挺少的，特别是 cpi 方式调用 NFT 的资料。像在 evm 上有 erc721 标准，在 solana 上还不只一种，还好都是 Metaplex 出的。并且我发现，现在 solana 教程中有 nft 教程，但是和实际的使用却不是一个东西，合约地址都不一样。

目前使用了两种，一个是Metaplex Core NFT，一个是Bubblegum NFT (cNFT)，用都用起来了，简单分享分享。我发现 ai 总结得比我好，所以我复制了一下：

Metaplex Core NFT 和 Bubblegum NFT 都是基于 Solana 区块链的 NFT 实现方式，由 Metaplex 协议支持，但它们在技术架构、功能、成本和使用场景上存在显著区别。以下是对两者的详细对比和区别介绍：

1. 概述

Metaplex Core NFT：
- Metaplex Core 是 Metaplex 协议的新一代 NFT 标准，取代了原来的 Metaplex Token Metadata 标准。
- 它基于 Solana 的 Programmable NFTs (pNFTs)，通过 Core Asset 标准实现，强调灵活性、可编程性和模块化。
- 适用于需要高级功能（如动态元数据、版税强制执行、规则集）的 NFT 项目。
Bubblegum NFT：
- Bubblegum 是 Metaplex 推出的一种 压缩 NFT (cNFT) 协议，基于 状态压缩技术 (State Compression)。
- 旨在大幅降低 NFT 铸造和存储成本，适合大规模铸造（如百万级 NFT 集合）。
- 使用 Merkle 树存储元数据，链上存储最小化，元数据通过链下索引访问。

2. 核心区别

特性	Metaplex Core NFT	Bubblegum NFT
标准	Core Asset 标准，基于 Programmable NFTs (pNFTs)	压缩 NFT (cNFTs)，基于状态压缩和 Merkle 树
存储方式	元数据和资产存储在 Solana 链上，占用账户空间	元数据通过 Merkle 树索引，链上仅存储根哈希
铸造成本	较高（每 NFT 约 0.01-0.02 SOL，视元数据大小而定）	极低（1 SOL 可铸造数千至数百万 cNFTs）
可编程性	高度可编程，支持动态元数据、规则集、版税强制执行	有限可编程性，侧重成本优化，功能较简单
版税支持	原生支持强制执行版税（通过 pNFT 规则集）	支持版税，但需额外配置，灵活性稍低
扩展性	适合中小规模项目，功能丰富但成本随数量增加	专为大规模集合设计，百万级 NFT 铸造成本低
元数据更新	支持动态更新元数据（如更改图片、属性）	元数据更新受限，需通过 Merkle 树操作
存储位置	元数据和文件通常存储在 Arweave/IPFS 等链下系统	元数据存储在 Merkle 树，文件存储在链下（如 IPFS）
使用场景	艺术品、游戏资产、动态 NFT、复杂规则项目	大规模收藏品、空投、会员凭证、批量分发
性能	交易速度快，但铸造和维护成本较高	极高的铸造效率，适合高吞吐量场景
工具支持	Metaplex SDK, Candy Machine v3	Bubblegum 专用程序，集成 Candy Machine

3. 技术细节对比

Metaplex Core NFT

架构：
- 使用 Solana 的账户模型，每个 NFT 对应一个链上账户，存储元数据（如名称、描述、URI）和所有权信息。
- 支持 pNFT 规则集，允许开发者定义复杂的转移规则（如限制转售、强制版税）。
- 元数据通过链上账户直接管理，配合链下存储（如 Arweave 或 IPFS）保存媒体文件。
铸造流程：
- 通过 Metaplex 的 Candy Machine v3 或 SDK 铸造。
- 每铸造一个 NFT，需支付账户租金（约 0.01 SOL）及少量交易费。
- 适合需要高自定义的项目，如动态艺术品（元数据可随时间更新）或游戏内资产。
优势：
- 高度灵活，支持动态元数据、自定义规则（如仅限特定钱包持有）。
- 原生支持版税强制执行，保护创作者利益。
- 与现有 Solana 生态（钱包、市场）无缝集成。
劣势：
- 铸造和维护成本随 NFT 数量线性增加（每个 NFT 需单独账户）。
- 不适合超大规模集合（例如百万个 NFT）。

Bubblegum NFT

架构：
- 基于 状态压缩，利用 Merkle 树存储 NFT 元数据的哈希，链上仅存储 Merkle 树的根哈希。
- 每个 NFT 的元数据通过链下索引访问，极大减少链上存储需求。
- 使用 Solana 的 Concurrent Merkle Tree (cMT) 结构，支持高效的批量操作。
铸造流程：
- 通过 Bubblegum 程序和 Candy Machine 铸造，多个 NFT 共享一个 Merkle 树账户。
- 铸造成本极低，例如 1 SOL 可铸造约 200 万个 cNFTs（因无需为每个 NFT 创建单独账户）。
- 元数据和媒体文件存储在链下（如 IPFS），链上仅记录哈希。
优势：
- 极低的铸造成本，适合大规模项目（如空投、会员 NFT）。
- 高扩展性，支持百万级甚至亿级 NFT 集合。
- 高效批量操作，适合快速分发（如 DRiP 平台的免费 NFT）。
劣势：
- 元数据更新复杂，需修改 Merkle 树，灵活性低于 Core NFT。
- 可编程性有限，难以实现复杂的动态规则或高级功能。
- 依赖链下存储和索引，需确保链下数据可靠性。

4. 使用场景对比

Metaplex Core NFT：
- 艺术与收藏品：适合高价值、个性化艺术品，创作者可动态更新元数据或设置版税。
- 游戏资产：如 Aurory 的角色或装备 NFT，需复杂规则（如仅限游戏内使用）。
- 动态 NFT：元数据可随时间或事件变化（如根据天气更新图片）。
- 高级项目：如需要强制版税、限制转售或集成 DeFi 的 NFT。
Bubblegum NFT：
- 大规模收藏品：如 Solana Monkey Business 的 Gen2 系列，适合快速铸造数千至数百万 NFT。
- 空投与会员凭证：如 DRiP 平台的免费 NFT 或社区会员徽章。
- 营销活动：品牌可低成本分发 NFT 作为促销工具。
- 低价值、高数量项目：如虚拟门票、一次性凭证。

5. 成本与效率

Metaplex Core NFT：
- 铸造单个 NFT 成本约 0.01-0.02 SOL（视元数据大小）。
- 1,000 个 NFT 需约 10-20 SOL，10 万个 NFT 成本约 1,000-2,000 SOL。
- 维护成本较高，因每个 NFT 需单独账户租金。
Bubblegum NFT：
- 铸造成本极低，1 SOL 可铸造约 200 万个 cNFTs（因共享 Merkle 树账户）。
- 10 万个 cNFTs 成本仅约 0.05 SOL，百万级成本仍不到 1 SOL。
- 维护成本低，链上存储仅为 Merkle 树根哈希。

6. 生态集成

Metaplex Core NFT：
- 与主流市场（如 Magic Eden、Tensor）完全兼容。
- 支持 Phantom、SolFlare 等钱包，交易体验与传统 NFT 无异。
- 易于集成到游戏、DeFi 或 DAO 项目。
Bubblegum NFT：
- 需市场支持 Bubblegum 协议（如 Magic Eden 已集成）。
- 交易和显示需额外解析 Merkle 树数据，部分早期市场兼容性有限。
- 适合空投平台（如 DRiP）或专用工具。

7. 未来趋势

Metaplex-Core：
- 预计成为高端 NFT 项目的首选标准，因其灵活性和可编程性。
- 将推动动态 NFT 和跨链互操作性的发展。
Bubblegum：
- 将主导大规模、低成本 NFT 市场，尤其在空投和营销领域。
- 随着压缩技术优化，可能支持更多动态功能。

总结

选择 Metaplex Core NFT，如果你的项目需要：
- 高可编程性、动态元数据或复杂规则。
- 强制版税或高级功能。
- 适用于中小规模、高价值的艺术品或游戏资产。
选择 Bubblegum NFT，如果你的项目需要：
- 极低成本铸造和大规模分发。
- 适合空投、收藏品或会员凭证。
- 高扩展性，处理百万级 NFT 集合。

如果你有具体项目需求（如铸造流程、代码示例或市场选择），可以告诉我，我可以提供更详细的指导！

用 Go 监控 PumpSwap 流动性：三步搞定

daog1 — Fri, 04 Apr 2025 11:19:52 +0800

用 Go 监控 PumpSwap 流动性：三步搞定

最近我基于 Pump.fun 的 pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA.json IDL，用我的 solana-anchor-go 项目写了个简单工具，实时监控 PumpSwap 的流动性事件（比如新池子创建），特别适合抢开盘或分析市场。我把过程浓缩成三步，代码清晰又实用。如果觉得不错，欢迎到 solana-anchor-go 点个 star 支持！

前提准备

环境：Go 1.18+，Solana RPC 节点（推荐 helius 申请个免费的账号，或者https://api.mainnet-beta.solana.com）。

依赖：安装我的 solana-anchor-go：

go install github.com/daog1/solana-anchor-go@latest

IDL：PumpSwap 的 IDL 文件，在 github 仓库里面有（假设你已下载为 pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA.json）。

步骤 1：生成 IDL 的 Go 接口

用 solana-anchor-go 把 pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA.json 转换为 Go 代码，生成 PumpSwap 的接口。

运行以下命令：

solana-anchor-go -src=pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA.json

这会生成 generated/pump_amm包,包里面的内容和idl文件中的指令定义、账号、事件一一对应.比如 CreatePoolEventEventData（新池创建事件）。

步骤 2：监听 PumpSwap 事件

PumpSwap 的程序 ID 是 pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA。我们用 Go 订阅它的日志。

代码如下：

package main

import (
    "context"
    "log"

    "github.com/gagliardetto/solana-go"
    "github.com/gagliardetto/solana-go/rpc"
    "github.com/gagliardetto/solana-go/rpc/ws"
)

func main() {
    // 连接 WebSocket
    client, err := ws.Connect(context.Background(), "wss://api.mainnet-beta.solana.com")
    if err != nil {
        log.Fatalf("连接失败: %v", err)
    }
    defer client.Close()

    // PumpSwap 程序 ID
    programID := solana.MustPublicKeyFromBase58("pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA")

    // 订阅日志
    sub, err := client.LogsSubscribeMentions(
        programID,
        rpc.CommitmentRecent,
        )
    if err != nil {
        log.Fatalf("订阅失败: %v", err)
    }
    defer sub.Unsubscribe()

    log.Println("开始监听 PumpSwap 事件...")

    // 接收日志
    for {
        logResult, err := sub.Recv(context.Background())
        if err != nil {
            log.Printf("接收失败: %v", err)
            continue
        }
        for _, logLine := range logResult.Value.Logs {
            log.Printf("新日志: %s", logLine)
        }
    }
}

运行后，它会实时打印 PumpSwap 的日志，比如 PoolCreatedEvent。

步骤 3：解析 PoolCreatedEvent

从 IDL 看，PoolCreatedEvent 是我们要监控的流动性事件，包含字段如 mint（代币地址）和 initial_liquidity（初始流动性）。用生成的 pumpswap.go 解析日志。

更新 for 循环：

for {
    logResult, err := sub.Recv(context.Background())
    if err != nil {
        log.Printf("接收失败: %v", err)
        continue
    }
    evts, err := pump_amm.DecodeEvents(logResult.Value.Logs)
    for _, ev := range evts {
        if ev.Name == "CreatePoolEvent" {
            trEv := ev.Data.(*pump_amm.CreatePoolEventEventData)
            fmt.Printf("creator %s pool %s tx:%s\n", trEv.Creator, trEv.Pool, logResult.Value.Signature)
        }
    }
}

完整代码将生成的 idl 解析代码和监听逻辑结合起来，保存为 app.go，然后：

go run main.go

输出示例：

2025/04/04 10:37:02 开始监听 PumpSwap 事件...
creator HwEfk69xeLu9MnLuqnrJEwn6iAkVg9QLqyVoLPdfSqGP pool Ed88ivvjJc2YqNQmyPXmwCjghhCe5kHa5wYAM5Z4Encs tx:EpytFhamRhk5QDdj85qYJ2yiirsg48gW6XuXrJiRjeqEGfSo1xK11NqL2TzBvXsSdVoJ832Kgx1pA7CyxNBGKHG

需要更多的事件类型和字段解析，可以在这个代码的基础上进行添加修改。

总结

其实写 solana 监听和 evm 监听没多大区别，主要是找对工具。

solana-anchor-go 是一个挺强大的 golang solana 链交互工具，只要是 anchor 开发的 solana 应用有 idl 都可以生成应用代码进行链交互。

这个工具根据我的应用需求进行了修复，发交易，解交易均没问题。目前 anchor 0.30.1 的 idl 都可以使用，anchor 以前的版本，可以按照，solana-anchor-go 的文档进行先转换，再使用。

完整代码放在: https://github.com/daog1/pumpgo

solana-anchor-go 在：

https://github.com/daog1/solana-anchor-go