Profilul lui 潇楠 Web3哨兵

PINNED

·

--

Articol

Vedeți traducerea

Web3多功能监控软件 V10 ：从代码层面深度剖析一款商业级双链监控系统的实现艺术！作为一名独立开发者，我耗时一个半月，从零构建了一套名为“潇楠 Web3 哨兵”的 Web3 双链资产监控与智能分析桌面应用。它支持 EVM 全系兼容链与 Solana 链，集成了 AI 交易解读、多渠道推送、链上数据聚合等高级功能，并已稳定运行数月。此前我发布过一篇技术概述，但总觉得对核心实现的剖析还不够“解渴”。因此，我决定撰写这篇深度技术复盘，从进程架构、I/O 模型、数据一致性、AI 工程化等维度，毫无保留地分享那些藏在代码深处的设计决策与实现细节。希望本文能为同样在 Web3 领域探索的开发者提供一些有价值的参考。一、进程架构：为什么选择“主进程 + 多子进程”？市面上许多 Python 监控脚本采用单进程 asyncio 一把梭，但我在设计之初就果断采用了 “主进程（GUI） + 独立子进程（EVM/SOL）” 的微内核架构。 1.1 隔离性与稳定性压倒一切 WebSocket 长连接在网络波动时极易触发异常重连，甚至底层库的 C 扩展可能因未知原因崩溃。如果将 GUI 与监控逻辑混在一个进程，任何未捕获的异常或内存访问违规都可能导致整个桌面应用闪退。通过 subprocess.Popen 将 EVM 和 Solana 监控逻辑独立为子进程，我实现了物理级隔离：Evm.py 崩溃或被强制 Kill，主窗口依然正常运行，托盘图标不消失，用户可以点击“启动”重新拉起来。日志透传：主进程通过管道捕获子进程的 stdout，利用 forwardoutput 线程逐行读取、清洗 ANSI 颜色码，再通过 window.evaluate_js 注入前端 DOM，实现日志实时刷新的同时保持了 UI 线程的轻量。 1.2 生命周期管理的细节在 core_process.py 中，停止子进程并非简单的 terminate()。我实现了一套强杀兜底机制： python proc.terminate() proc.wait(timeout=3) if proc.poll() is None: proc.kill() proc.wait(timeout=2) if proc.poll() is None: os.system(f'taskkill /F /PID {proc.pid}') 这套组合拳确保了即使 Python 解释器卡死，Windows 底层也能彻底清理进程树，避免残留进程占用端口或数据库锁，导致下次启动失败。二、 I/O 模型与高可用连接：不止是 asyncio 2.1 混合监控模式：WSS 实时 + RPC 补偿对于 EVM 链的原生币，由于没有标准的 Transfer 事件日志，无法通过 WSS 订阅。我设计了一个轮询补偿器：每 60 秒通过 RPC 获取 eth_getBalance，与内存快照对比，差值超过 1e-18 即触发推送。这个看似简单的机制，实际上是 WSS 订阅失活时的最后一道防线。对于代币和 NFT，系统订阅 logs，并精细处理了 ERC1155 的 TransferSingle 和 TransferBatch 事件。特别是 TransferBatch，其 data 字段包含动态数组，我实现了基于 ABI 规范的手动偏移量解析，而非依赖重型库，极大降低了解析开销。 2.2 WSS 的指数退避与节点热切换在生产环境中，公共 RPC/WSS 节点随时可能限流或宕机。我在 chain_wss_monitor_direction 中实现了节点轮换与重连策略：节点池：配置文件中为每条链配置多个 WSS_NODES，启动时随机或顺序选择一个。退避算法：连接断开后，重试间隔从 5 秒开始，每次翻倍直至 60 秒，避免在节点恢复前造成 DDoS 式的重连风暴。国内网络环境适配：系统支持配置本地代理软件的 HTTP 地址，通过 websockets_proxy 库将 WSS 流量转发至代理，恢复与境外节点的稳定通信。 2.3 Solana 的异步解析流水线 Solana 的出块速度极快，且交易结构复杂。为了避免 Helius API 调用阻塞 WSS 消息接收，我设计了一个生产者-消费者解耦模型：生产者：WSS logsSubscribe 收到签名后，立即将其扔进 asyncio.Queue 或直接触发一个后台 asyncio.create_task。消费者：独立的异步任务负责调用 Helius /v0/transactions 接口，解析 nativeTransfers、tokenTransfers、events.nft 等字段。这保证了 WSS 连接的 recv() 循环永远不会被慢速 HTTP 请求卡住，确保了超高 TPS 环境下消息的实时性。三、数据一致性：从内存去重到 SQLite 约束 3.1 EVM 侧：数据库唯一索引 EVM 监控中，同一笔交易可能因 WSS 重连、轮询补偿等原因被多次处理。单纯依赖内存 set 无法应对进程重启。因此，我设计了 tx_history 表的复合唯一约束： sql UNIQUE(tx_hash, log_index, address) 任何重复插入都会被 SQLite 的 ON CONFLICT IGNORE 静默丢弃，从数据库内核层面保证了幂等性。对于没有 log_index 的原生币转账，则降级使用 tx_hash + address 作为组合键。 3.2 Solana 侧：时间窗口内的签名去重 Solana 交易没有 log_index 概念，且 Helius 解析可能产生多条记录。我使用了内存 set 存储最近处理的签名，并利用 LimitedSizeDict 的变体思想，在签名集合超过 1000 个时，自动清空一半（或利用 OrderedDict 弹出最旧条目）。这种滑动窗口去重在性能和准确性之间取得了良好平衡。四、 AI 工程化：多提供商容错与 JSON 解析的艺术 4.1 特征驱动的动态调度 MultiAIClient 是 AI 模块的核心。它并非简单的 if-else 分支，而是一个基于特征标志的调度器。配置文件中定义了每个提供商支持的功能（如 transaction_insight、daily_report 等）。当请求解读时，系统会筛选出支持该特征的提供商列表，按优先级发起请求，超时或失败则自动降级到下一个。 4.2 LLM 输出的防御性解析大模型输出 JSON 不稳定是常态。我的处理流程远比 json.loads 复杂：清洗：移除 Markdown 代码块标记 json` 和。正则提取：若解析失败，直接使用正则表达式 r'"insight"\s*:\s*"([^"]*)"' 暴力提取字段，这是最后一道防线。字段映射：兼容 insight / Insight / 解读等多种 Key 命名。这套机制确保了即使 Moonshot 或 DeepSeek 返回了“半个 JSON”，前端依然能展示有效解读，而不会抛出 JSONDecodeError 导致白屏。五、内存与性能：LimitedSizeDict 与异步队列 5.1 自定义有限容量字典 Python 标准库没有内置 LRU 且限制大小的字典。我基于 collections.OrderedDict 实现了 LimitedSizeDict： python def setitem(self, key, value): if len(self) >= self.max_size: self.popitem(last=False) # 淘汰最早插入的项 super().__setitem__(key, value) 这个简单的数据结构被用于 Token 信息缓存、价格缓存、NFT 元数据缓存。它确保了长时间运行时，内存占用不会随着监控地址增多而线性膨胀，而是稳定在一个极低水平。 5.2 Solana 日志的异步串行写入 Solana 的详细交易日志需要写入 JSON 文件。如果多个协程同时 json.dump，极易导致文件格式损坏。我引入了 asyncio.Queue：所有写日志请求将数据 put 进队列。唯一的一个后台协程 filewriter 阻塞等待队列，取出数据后执行文件 I/O。这既避免了复杂的线程锁，又利用异步特性保证了高并发下的数据安全。六、前端与后端的双向通信：pywebview 的深度集成 6.1 JS API 注入 pywebview 允许将 Python 对象的方法直接暴露给前端 JavaScript。我的 Api 类继承自多个 Mixin，所有以 def 开头的公有方法均自动成为 window.pywebview.api 的成员。这让我能以极低成本实现前后端分离，前端只需关注 UI 交互。 6.2 悬浮窗的独立实例与通信悬浮窗并非主窗口的子 DIV，而是 pywebview 创建的第二个独立窗口。我通过 FloatingWindowManager 管理其生命周期，并利用主进程的 js_api 实例向悬浮窗注入 JS 代码（evaluate_js），实现了主窗口日志向悬浮窗的实时推送。这种设计保证了悬浮窗即使被关闭，也不会影响主监控任务的运行。七、桌面应用打包：PyInstaller 的深坑与工程化实践将 Python 项目交付给没有技术背景的最终用户，打包成独立 EXE 是必经之路。PyInstaller 看似一条命令搞定，但在复杂项目中，其背后隐藏着无数足以让开发者崩溃的细节。本节分享我在打包“潇楠 Web3 哨兵”过程中遇到的几个典型深坑及解决方案。 7.1 隐式导入与 --hidden-import PyInstaller 通过静态分析入口文件的 import 语句来构建依赖树。然而，许多库（如 pystray、websockets）使用了 importlib.import_module 或 import 动态加载子模块，导致打包后的 EXE 运行时抛出 ModuleNotFoundError。解决此问题的关键在于根据报错信息反向定位缺失模块，并在打包命令中显式声明 --hidden-import。例如，本项目中托盘图标功能必须添加： bash --hidden-import pystray._win32 --hidden-import pystray._util --hidden-import win32event --hidden-import win32api 这要求开发者对依赖库的内部结构有一定了解，通常需要结合源码阅读和反复试错才能完整列出所有隐式依赖。 7.2 --collect-all 与资源文件陷阱 pywebview 库不仅包含 Python 代码，还依赖前端 HTML/JS 以及 Edge WebView2 运行时文件。PyInstaller 的默认分析无法感知这些非代码资源。若不加处理，打包后程序会因找不到 index.html 或 webview.js 而白屏。正确的处理方式是使用 --collect-all pywebview，该参数强制 PyInstaller 将 pywebview 包目录下的所有文件（包括二进制和静态资源）完整复制到打包目录。这是处理此类“重型”GUI 库的标准操作。 7.3 二进制依赖与 UPX 压缩项目依赖的 pywin32、Pillow 等库包含 .pyd 和 .dll 二进制文件。这些文件体积较大，且在 PyInstaller 打包后不会被自动压缩。通过集成 UPX 工具并在打包命令中指定 --upx-dir，可以对最终 EXE 内的二进制文件进行高比率压缩（通常可缩减 30%-50% 体积）。需要注意的是，极少数老旧杀毒软件可能对 UPX 加壳的程序产生误报，但对于技术型用户群体，这种概率极低且可通过提交样本解除。 7.4 路径“冻结”与 sys._MEIPASS 这是 PyInstaller 打包中最核心的概念。开发阶段，程序通过 file 或相对路径访问配置文件、图片资源。打包成单文件 EXE 后，所有资源被解压到一个临时目录，该目录的路径存储在 sys._MEIPASS 变量中。开发者必须在代码中全局替换所有文件访问逻辑，典型范式如下： python def get_resource_path(relative_path): if getattr(sys, 'frozen', False): base = sys._MEIPASS else: base = os.path.abspath(".") return os.path.join(base, relative_path) 忽略此适配将导致程序运行时找不到任何外部文件，这是新手打包时遇到最多的“路径地狱”。我的做法是将此函数封装在 utils.py 中，全项目统一调用，确保打包前后路径行为一致。 7.5 子进程的特殊处理本系统采用主进程启动子进程的架构。在打包后，子进程脚本 Evm.py 和 Sol.py 也被封装在 EXE 内部。若主进程仍尝试用 python.exe Evm.py 启动，会因找不到文件而失败。我的解决方案是在主进程启动子进程时，动态检测是否处于打包模式，并传递正确的 --main-exe-dir 参数，使子进程能定位到配置文件所在的外部目录。这部分逻辑细节已在进程架构章节中阐述，此处不再赘述。八、结语回顾整个开发历程，从单脚本到多进程架构，从裸 WebSocket 到高可用节点池，从简单的 print 日志到结构化 SQLite 存储，每一步都是对工程化理解的深化。打包环节的探索更是让我深刻体会到：能让软件稳定跑起来只是第一步，能让用户轻松用起来才是真正的交付。这不仅是一个监控工具，更是我在异步编程、进程管理、AI 集成、桌面软件开发等领域实践经验的集大成者。如果您对文中的任何技术细节感兴趣，欢迎访问我的GITHUB： [https://github.com/pingdj/Web3](https://github.com/pingdj/Web3) 获取软件及更多技术文档。也期待在币安广场与各位技术好交流探讨。作者简介：潇楠，全栈 & Web3 独立开发者，专注于 Python 桌面应用、区块链数据分析和 AI 工程化落地。 $BNB {spot}(BNBUSDT)

Web3多功能监控软件 V10 ：从代码层面深度剖析一款商业级双链监控系统的实现艺术！

作为一名独立开发者，我耗时一个半月，从零构建了一套名为“潇楠 Web3 哨兵”的 Web3 双链资产监控与智能分析桌面应用。它支持 EVM 全系兼容链与 Solana 链，集成了 AI 交易解读、多渠道推送、链上数据聚合等高级功能，并已稳定运行数月。

此前我发布过一篇技术概述，但总觉得对核心实现的剖析还不够“解渴”。因此，我决定撰写这篇深度技术复盘，从进程架构、I/O 模型、数据一致性、AI 工程化等维度，毫无保留地分享那些藏在代码深处的设计决策与实现细节。希望本文能为同样在 Web3 领域探索的开发者提供一些有价值的参考。
一、进程架构：为什么选择“主进程 + 多子进程”？
市面上许多 Python 监控脚本采用单进程 asyncio 一把梭，但我在设计之初就果断采用了 “主进程（GUI） + 独立子进程（EVM/SOL）” 的微内核架构。
1.1 隔离性与稳定性压倒一切
WebSocket 长连接在网络波动时极易触发异常重连，甚至底层库的 C 扩展可能因未知原因崩溃。如果将 GUI 与监控逻辑混在一个进程，任何未捕获的异常或内存访问违规都可能导致整个桌面应用闪退。通过 subprocess.Popen 将 EVM 和 Solana 监控逻辑独立为子进程，我实现了物理级隔离：Evm.py 崩溃或被强制 Kill，主窗口依然正常运行，托盘图标不消失，用户可以点击“启动”重新拉起来。
日志透传：主进程通过管道捕获子进程的 stdout，利用 forwardoutput 线程逐行读取、清洗 ANSI 颜色码，再通过 window.evaluate_js 注入前端 DOM，实现日志实时刷新的同时保持了 UI 线程的轻量。
1.2 生命周期管理的细节
在 core_process.py 中，停止子进程并非简单的 terminate()。我实现了一套强杀兜底机制：
python
proc.terminate()
proc.wait(timeout=3)
if proc.poll() is None:
proc.kill()
proc.wait(timeout=2)
if proc.poll() is None:
os.system(f'taskkill /F /PID {proc.pid}')
这套组合拳确保了即使 Python 解释器卡死，Windows 底层也能彻底清理进程树，避免残留进程占用端口或数据库锁，导致下次启动失败。
二、 I/O 模型与高可用连接：不止是 asyncio
2.1 混合监控模式：WSS 实时 + RPC 补偿
对于 EVM 链的原生币，由于没有标准的 Transfer 事件日志，无法通过 WSS 订阅。我设计了一个轮询补偿器：每 60 秒通过 RPC 获取 eth_getBalance，与内存快照对比，差值超过 1e-18 即触发推送。这个看似简单的机制，实际上是 WSS 订阅失活时的最后一道防线。
对于代币和 NFT，系统订阅 logs，并精细处理了 ERC1155 的 TransferSingle 和 TransferBatch 事件。特别是 TransferBatch，其 data 字段包含动态数组，我实现了基于 ABI 规范的手动偏移量解析，而非依赖重型库，极大降低了解析开销。
2.2 WSS 的指数退避与节点热切换
在生产环境中，公共 RPC/WSS 节点随时可能限流或宕机。我在 chain_wss_monitor_direction 中实现了节点轮换与重连策略：
节点池：配置文件中为每条链配置多个 WSS_NODES，启动时随机或顺序选择一个。
退避算法：连接断开后，重试间隔从 5 秒开始，每次翻倍直至 60 秒，避免在节点恢复前造成 DDoS 式的重连风暴。
国内网络环境适配：系统支持配置本地代理软件的 HTTP 地址，通过 websockets_proxy 库将 WSS 流量转发至代理，恢复与境外节点的稳定通信。
2.3 Solana 的异步解析流水线
Solana 的出块速度极快，且交易结构复杂。为了避免 Helius API 调用阻塞 WSS 消息接收，我设计了一个生产者-消费者解耦模型：
生产者：WSS logsSubscribe 收到签名后，立即将其扔进 asyncio.Queue 或直接触发一个后台 asyncio.create_task。
消费者：独立的异步任务负责调用 Helius /v0/transactions 接口，解析 nativeTransfers、tokenTransfers、events.nft 等字段。
这保证了 WSS 连接的 recv() 循环永远不会被慢速 HTTP 请求卡住，确保了超高 TPS 环境下消息的实时性。
三、数据一致性：从内存去重到 SQLite 约束
3.1 EVM 侧：数据库唯一索引
EVM 监控中，同一笔交易可能因 WSS 重连、轮询补偿等原因被多次处理。单纯依赖内存 set 无法应对进程重启。因此，我设计了 tx_history 表的复合唯一约束：
sql
UNIQUE(tx_hash, log_index, address)
任何重复插入都会被 SQLite 的 ON CONFLICT IGNORE 静默丢弃，从数据库内核层面保证了幂等性。对于没有 log_index 的原生币转账，则降级使用 tx_hash + address 作为组合键。
3.2 Solana 侧：时间窗口内的签名去重
Solana 交易没有 log_index 概念，且 Helius 解析可能产生多条记录。我使用了内存 set 存储最近处理的签名，并利用 LimitedSizeDict 的变体思想，在签名集合超过 1000 个时，自动清空一半（或利用 OrderedDict 弹出最旧条目）。这种滑动窗口去重在性能和准确性之间取得了良好平衡。
四、 AI 工程化：多提供商容错与 JSON 解析的艺术
4.1 特征驱动的动态调度
MultiAIClient 是 AI 模块的核心。它并非简单的 if-else 分支，而是一个基于特征标志的调度器。配置文件中定义了每个提供商支持的功能（如 transaction_insight、daily_report 等）。当请求解读时，系统会筛选出支持该特征的提供商列表，按优先级发起请求，超时或失败则自动降级到下一个。
4.2 LLM 输出的防御性解析
大模型输出 JSON 不稳定是常态。我的处理流程远比 json.loads 复杂：
清洗：移除 Markdown 代码块标记 json` 和。
正则提取：若解析失败，直接使用正则表达式 r'"insight"\s*:\s*"([^"]*)"' 暴力提取字段，这是最后一道防线。
字段映射：兼容 insight / Insight / 解读等多种 Key 命名。
这套机制确保了即使 Moonshot 或 DeepSeek 返回了“半个 JSON”，前端依然能展示有效解读，而不会抛出 JSONDecodeError 导致白屏。
五、内存与性能：LimitedSizeDict 与异步队列
5.1 自定义有限容量字典
Python 标准库没有内置 LRU 且限制大小的字典。我基于 collections.OrderedDict 实现了 LimitedSizeDict：
python
def setitem(self, key, value):
if len(self) >= self.max_size:
self.popitem(last=False) # 淘汰最早插入的项
super().__setitem__(key, value)
这个简单的数据结构被用于 Token 信息缓存、价格缓存、NFT 元数据缓存。它确保了长时间运行时，内存占用不会随着监控地址增多而线性膨胀，而是稳定在一个极低水平。
5.2 Solana 日志的异步串行写入
Solana 的详细交易日志需要写入 JSON 文件。如果多个协程同时 json.dump，极易导致文件格式损坏。我引入了 asyncio.Queue：
所有写日志请求将数据 put 进队列。
唯一的一个后台协程 filewriter 阻塞等待队列，取出数据后执行文件 I/O。
这既避免了复杂的线程锁，又利用异步特性保证了高并发下的数据安全。
六、前端与后端的双向通信：pywebview 的深度集成
6.1 JS API 注入
pywebview 允许将 Python 对象的方法直接暴露给前端 JavaScript。我的 Api 类继承自多个 Mixin，所有以 def 开头的公有方法均自动成为 window.pywebview.api 的成员。这让我能以极低成本实现前后端分离，前端只需关注 UI 交互。
6.2 悬浮窗的独立实例与通信
悬浮窗并非主窗口的子 DIV，而是 pywebview 创建的第二个独立窗口。我通过 FloatingWindowManager 管理其生命周期，并利用主进程的 js_api 实例向悬浮窗注入 JS 代码（evaluate_js），实现了主窗口日志向悬浮窗的实时推送。这种设计保证了悬浮窗即使被关闭，也不会影响主监控任务的运行。
七、桌面应用打包：PyInstaller 的深坑与工程化实践
将 Python 项目交付给没有技术背景的最终用户，打包成独立 EXE 是必经之路。PyInstaller 看似一条命令搞定，但在复杂项目中，其背后隐藏着无数足以让开发者崩溃的细节。本节分享我在打包“潇楠 Web3 哨兵”过程中遇到的几个典型深坑及解决方案。
7.1 隐式导入与 --hidden-import
PyInstaller 通过静态分析入口文件的 import 语句来构建依赖树。然而，许多库（如 pystray、websockets）使用了 importlib.import_module 或 import 动态加载子模块，导致打包后的 EXE 运行时抛出 ModuleNotFoundError。
解决此问题的关键在于根据报错信息反向定位缺失模块，并在打包命令中显式声明 --hidden-import。例如，本项目中托盘图标功能必须添加：
bash
--hidden-import pystray._win32
--hidden-import pystray._util
--hidden-import win32event
--hidden-import win32api
这要求开发者对依赖库的内部结构有一定了解，通常需要结合源码阅读和反复试错才能完整列出所有隐式依赖。
7.2 --collect-all 与资源文件陷阱
pywebview 库不仅包含 Python 代码，还依赖前端 HTML/JS 以及 Edge WebView2 运行时文件。PyInstaller 的默认分析无法感知这些非代码资源。若不加处理，打包后程序会因找不到 index.html 或 webview.js 而白屏。
正确的处理方式是使用 --collect-all pywebview，该参数强制 PyInstaller 将 pywebview 包目录下的所有文件（包括二进制和静态资源）完整复制到打包目录。这是处理此类“重型”GUI 库的标准操作。
7.3 二进制依赖与 UPX 压缩
项目依赖的 pywin32、Pillow 等库包含 .pyd 和 .dll 二进制文件。这些文件体积较大，且在 PyInstaller 打包后不会被自动压缩。通过集成 UPX 工具并在打包命令中指定 --upx-dir，可以对最终 EXE 内的二进制文件进行高比率压缩（通常可缩减 30%-50% 体积）。需要注意的是，极少数老旧杀毒软件可能对 UPX 加壳的程序产生误报，但对于技术型用户群体，这种概率极低且可通过提交样本解除。
7.4 路径“冻结”与 sys._MEIPASS
这是 PyInstaller 打包中最核心的概念。开发阶段，程序通过 file 或相对路径访问配置文件、图片资源。打包成单文件 EXE 后，所有资源被解压到一个临时目录，该目录的路径存储在 sys._MEIPASS 变量中。
开发者必须在代码中全局替换所有文件访问逻辑，典型范式如下：
python
def get_resource_path(relative_path):
if getattr(sys, 'frozen', False):
base = sys._MEIPASS
else:
base = os.path.abspath(".")
return os.path.join(base, relative_path)
忽略此适配将导致程序运行时找不到任何外部文件，这是新手打包时遇到最多的“路径地狱”。我的做法是将此函数封装在 utils.py 中，全项目统一调用，确保打包前后路径行为一致。
7.5 子进程的特殊处理
本系统采用主进程启动子进程的架构。在打包后，子进程脚本 Evm.py 和 Sol.py 也被封装在 EXE 内部。若主进程仍尝试用 python.exe Evm.py 启动，会因找不到文件而失败。我的解决方案是在主进程启动子进程时，动态检测是否处于打包模式，并传递正确的 --main-exe-dir 参数，使子进程能定位到配置文件所在的外部目录。这部分逻辑细节已在进程架构章节中阐述，此处不再赘述。
八、结语
回顾整个开发历程，从单脚本到多进程架构，从裸 WebSocket 到高可用节点池，从简单的 print 日志到结构化 SQLite 存储，每一步都是对工程化理解的深化。打包环节的探索更是让我深刻体会到：能让软件稳定跑起来只是第一步，能让用户轻松用起来才是真正的交付。
这不仅是一个监控工具，更是我在异步编程、进程管理、AI 集成、桌面软件开发等领域实践经验的集大成者。
如果您对文中的任何技术细节感兴趣，欢迎访问我的GITHUB：
https://github.com/pingdj/Web3
获取软件及更多技术文档。也期待在币安广场与各位技术好交流探讨。
作者简介：潇楠，全栈 & Web3 独立开发者，专注于 Python 桌面应用、区块链数据分析和 AI 工程化落地。
$BNB

BNB-0,95%

PINNED

潇 楠 Web3哨兵

Web3多功能监控软件 V10 ：从代码层面深度剖析一款商业级双链监控系统的实现艺术！

Web3 多链智能监控系统

Proiect cu finanțare de 20 de milioane de dolari, grăbiți-vă să profitați!

Protocolul de antrenament de date AI Perle, care nu a emis monede, a fost lansat oficial activitatea S1

Proiecte obligatorii: Activitatea de airdrop a Metamask vulpei mici a început

Subiecte în tendințe

潇楠 Web3哨兵