<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Blockchain on Yu's Space</title><link>https://code-agree.github.io/tags/blockchain/</link><description>Recent content in Blockchain on Yu's Space</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Fri, 20 Dec 2024 03:08:38 +0800</lastBuildDate><atom:link href="https://code-agree.github.io/tags/blockchain/index.xml" rel="self" type="application/rss+xml"/><item><title>Solana链上交易监控最佳实践：从logsSubscribe到全方位监控</title><link>https://code-agree.github.io/blog/2025-06-24-solana_monitoring_system/</link><pubDate>Fri, 20 Dec 2024 03:08:38 +0800</pubDate><guid>https://code-agree.github.io/blog/2025-06-24-solana_monitoring_system/</guid><description>Solana链上交易监控最佳实践：从logsSubscribe到全方位监控 #背景介绍 #在Solana链上开发中，实时监控特定账户的交易活动是一个常见需求，特别是在构建跟单机器人这类对时效性要求较高的应用场景中。最初，我们可能会想到使用Solana提供的logsSubscribe WebSocket API来实现这个功能，因为它看起来是最直接的解决方案。然而，在实际应用中，我们发现这种方案存在一些限制和问题。
问题发现 #在使用logsSubscribe进行账户监控时，我们发现一个关键问题：某些确实发生的交易并没有被我们的监控系统捕获到。这个问题的发现促使我们深入研究Solana的交易日志机制，并最终设计了一个更全面的监控方案。
为什么会遗漏交易？ # 日志记录机制的局限性
程序可能不会在日志中明确记录所有涉及的账户地址 交易可能使用了PDA(Program Derived Address)或其他派生地址 某些DEX采用内部账户映射，而不是直接记录用户地址 mentions过滤器的限制
mentions匹配的是交易账户列表（accountKeys）中包含目标地址的交易，而非日志文本中出现的地址，因此只有当目标地址作为交易的显式参与账户时才会被捕获 无法捕获通过间接方式（如CPI调用中未在顶层accountKeys中列出）影响目标账户的交易 解决方案 #针对上述问题，我们设计了一个多维度监控方案，通过组合多种订阅方式来确保不会遗漏任何相关交易。
1. 三重订阅机制 #pub struct EnhancedTradeWatcher { target_account: Pubkey, ws_client: WebSocketClient, } impl EnhancedTradeWatcher { async fn setup_comprehensive_monitoring(&amp;amp;mut self) -&amp;gt; Result&amp;lt;()&amp;gt; { // 1. logsSubscribe - 捕获显式提及 let logs_sub = json!({ &amp;#34;jsonrpc&amp;#34;: &amp;#34;2.0&amp;#34;, &amp;#34;method&amp;#34;: &amp;#34;logsSubscribe&amp;#34;, &amp;#34;params&amp;#34;: [ { &amp;#34;mentions&amp;#34;: [self.target_account.to_string()], }, { &amp;#34;commitment&amp;#34;: &amp;#34;processed&amp;#34; } ] }); // 2. programSubscribe - 监控DEX程序 let dex_program_sub = json!</description></item><item><title>Solana链上交易监控技术分析</title><link>https://code-agree.github.io/blog/2025-06-24-solana_blockchain_analysis/</link><pubDate>Thu, 19 Dec 2024 01:32:32 +0800</pubDate><guid>https://code-agree.github.io/blog/2025-06-24-solana_blockchain_analysis/</guid><description>Solana链上交易监控技术分析 #1. Solana DEX 交易形式 #1.1 直接 DEX 交易 #用户直接与 DEX 合约交互，交易流程简单直接。
用户钱包 -&amp;gt; DEX程序 (如Raydium/Orca) -&amp;gt; Token Program 特点：
交易日志简洁，主要包含单个 DEX 程序的调用 容易识别交易平台和交易对 Token Program 的 transfer 指令较少 1.2 聚合器交易（Jupiter） #通过聚合器路由到单个或多个 DEX。
用户钱包 -&amp;gt; Jupiter -&amp;gt; DEX1/DEX2/... -&amp;gt; Token Program 特点：
包含 Jupiter 合约调用 可能涉及多个 DEX 交易日志较长，包含多个内部指令 可能有复杂的代币交换路径 1.3 智能路由交易 #一笔交易通过多个 DEX 串联完成。
用户钱包 -&amp;gt; 聚合器 -&amp;gt; DEX1 -&amp;gt; DEX2 -&amp;gt; DEX3 -&amp;gt; Token Program 特点：
交易路径最复杂 涉及多次代币交换 目的是获得最优价格 包含多个 Token Program 的 transfer 指令 2.</description></item></channel></rss>