Logo
新用户订阅 RPC,首月享 6.5 折优惠查看优惠
OnFinality Learn
集成与开发阅读约 11 分钟

UniWhales 与链上巨鲸监控:架构、数据管道与 RPC 需求

一份技术指南,深入解析 UniWhales 风格的巨鲸监控在底层如何运作,从 RPC 数据摄取、事件解码到告警,以及如何构建并验证你自己的数据管道。

TL;DR

UniWhales 是一个 DeFi 分析平台和代币门控 DAO,它监控去中心化交易所上的巨鲸钱包动向,并通过仪表盘和实时告警呈现出来。真正有趣的工程问题不是会员模式,而是数据管道:原始链上数据如何变成解码后的 swap 事件、钱包归属和低延迟通知。本文以心智模型的方式解释这条管道,提供一个可运行、可改编的实现,并展示如何验证结果、诊断导致巨鲸告警错误或延迟的故障模式。文章还涵盖了 RPC 质量和节点基础设施在何处决定管道是否可信。

UniWhales 是什么以及本指南涵盖的内容

最好将 UniWhales 理解为两层叠加的事物。第一层是 DeFi 分析产品:一个 Web 仪表盘和告警系统,追踪代币、巨鲸地址及其在去中心化交易所、跨链桥和借贷市场中的动向。第二层是代币门控社区和 DAO,其中实用型代币(UWL)授予 Pro 和 Whale 等会员等级以及对分析界面的访问权限。公开资料将其描述为一个 DeFi 分析社区,监控 Uniswap、SushiSwap、1inch 和 PancakeSwap 等场所上的巨鲸仓位变动,并且是加密领域运行时间较长的代币门控社区之一。

本指南不是会员操作指南,也不是价格或融资摘要。它聚焦于让任何巨鲸监控产品变得有用的工程层:链上数据如何被摄取、解码、归属到钱包并转化为告警,以及哪些基础设施属性决定这些告警是否正确和及时。如果你正在构建类似的仪表盘、Telegram 机器人或内部研究工具,同样的管道也适用。

范围假设你可以针对 EVM JSON-RPC 端点运行代码,并且对日志、事件和 ERC-20 转账有基本了解。当文章需要具体端点时,它使用 RPC_URL 等占位符,而不是特定的提供商 URL。

  • 产品层:仪表盘、告警、会员等级、社区策展。
  • 数据层:RPC 摄取、事件解码、钱包归属、存储、告警。
  • 基础设施层:节点可靠性、延迟、归档访问、速率限制。

先决条件与假设

在构建任何东西之前,明确你要监控什么以及为什么。一个监控每条链上每笔转账的巨鲸追踪器会产生噪音;一个针对特定事件类型监控精选地址集的追踪器会产生信号。确定你的地址范围、事件类型(swap、流动性变化、跨链桥存款、大额 ERC-20 转账)以及延迟目标(秒级还是分钟级)。

你需要一个 EVM JSON-RPC 端点,支持在你关心的区块范围内调用 eth_getLogs,以及用于链进度的 eth_blockNumber 和 eth_getBlockByNumber。如果你需要超出近期窗口的历史回填,你需要具备归档能力的访问权限。对于生产告警系统,你还需要 websocket 或订阅路径,或者根据出块时间调整的轮询循环。

最后,决定端点来自哪里。本文专注于方法论;关于具体端点和提供商选择,请使用 多链 RPC 端点 上的 RPC Assistant 指南,并在 RPC 定价页面 上比较套餐。

心智模型:从区块到巨鲸告警

将管道视为五个阶段。摄取拉取新区块和日志。解码将原始日志转换为类型化事件(swap、流动性添加、跨链桥存款)。归属将这些事件映射到已标记的钱包。丰富添加代币元数据、美元价值和场所等上下文。交付将结果推送到仪表盘、数据库或聊天告警。

关键洞察是,大多数错误的巨鲸告警来自第二阶段和第三阶段,而不是节点。使用错误 ABI 解码的 swap 事件会产生无意义的数据。因单笔大额转账而被标记为巨鲸的钱包实际上可能是跨链桥合约或交易所热钱包。归属是分析产品赢得声誉的地方,也是你应该投入大部分工程精力的地方。

延迟是一个独立的维度。一条管道即使完全正确,如果在交易后十分钟才发出告警,仍然毫无用处。延迟主要由轮询间隔、RPC 响应时间和你自己的处理队列决定,按此顺序。

  • 摄取:区块和日志检索。
  • 解码:基于 ABI 的事件解析。
  • 归属:地址标记和实体解析。
  • 丰富:价格、代币元数据、场所上下文。
  • 交付:存储、仪表盘、告警。

可运行的摄取:使用 curl 拉取 Swap 日志

查看原始材料的最简单方法是在区块范围内查询已知事件主题的日志。下面的代码片段获取你提供的主题的日志,通常你会将其设置为所追踪 DEX 的 Swap 事件签名的 keccak256 哈希。将 RPC_URL、TOPIC0 和区块范围替换为适合你的链和场所的值。

在公共端点上保持区块范围适中;许多提供商限制每次 eth_getLogs 调用的区块数或结果数。如果你收到范围错误,请拆分查询,而不是假设端点已损坏。

curl -s RPC_URL \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_getLogs",
    "params": [{
      "fromBlock": "0x1300000",
      "toBlock": "0x1300064",
      "topics": ["TOPIC0"]
    }]
  }'

使用 Python 进行解码和归属

一旦你有了日志,根据正确的 ABI 解码它们并归属发送者。下面的示例使用 web3.py 读取转账风格的日志并打印 from/to/value 字段。它有意保持通用:来自不同 DEX 分叉的 swap 事件具有不同的字段顺序,因此你必须确认每个场所的 ABI,而不是假设一种布局。

归属显示为简单的标签查找。在实践中,你会维护一个精选的地址注册表,从公共标签来源刷新它,并标记行为像合约的地址(例如,那些发出日志但从不发起交易的地址),以免它们被误认为是巨鲸。

from web3 import Web3

w3 = Web3(Web3.HTTPProvider("RPC_URL"))

LABELS = {
    "0x0000000000000000000000000000000000000000": "burn",
    # add curated whale, exchange, and bridge labels here
}

def decode_transfer(log):
    topics = log["topics"]
    data = log["data"]
    from_addr = "0x" + topics[1].hex()[-40:]
    to_addr = "0x" + topics[2].hex()[-40:]
    value = int(data, 16) if isinstance(data, str) else int.from_bytes(data, "big")
    return from_addr, to_addr, value

def label(addr):
    return LABELS.get(addr.lower(), "unlabeled")

latest = w3.eth.block_number
logs = w3.eth.get_logs({
    "fromBlock": latest - 50,
    "toBlock": latest,
    "topics": ["TOPIC0"],
})

for log in logs:
    frm, to, value = decode_transfer(log)
    print(f"{label(frm)} -> {label(to)} value={value}")

验证:确认你的管道是正确的

在信任任何告警之前,对照基准事实验证管道。选择一小组你可以在区块浏览器上手动检查的交易,让它们通过你的解码器,并将解码后的金额和地址与浏览器显示的内容进行比较。如果它们不同,则 ABI 或主题过滤器有误。

一个有用的验证表记录每个测试交易的预期发送者、接收者和金额,以及你的管道产生的值。不要凭记忆填写测量数字;运行管道并记录实际输出。下表是一个模板,你用自己运行的结果填写。

测试交易预期发送方预期接收方预期金额管道发送方管道接收方管道金额匹配
交易 A
交易 B
交易 C

第二个验证检查延迟。记录区块在你的节点上可用的时刻和告警触发的时刻。差值就是你的端到端延迟。跟踪一天而不是单个样本,因为 RPC 延迟是突发性的。

排查常见故障模式

大多数问题属于几个可识别的类别。缺失事件通常意味着主题过滤器或区块范围问题。金额错误通常意味着 ABI 或小数位不匹配。重复告警通常意味着你的游标在重启后没有持久化。延迟告警通常意味着轮询太慢或队列积压。

如果 eth_getLogs 返回范围错误,请减少区块跨度。如果它对你已知包含活动的范围返回空结果,请确认主题哈希以及你查询的是正确的链。如果多次运行之间结果不一致,请检查你是否访问的是负载均衡端点,其中不同后端处于不同高度;专用节点消除了这个变量,如 专用节点概述 中所述。

  • 空日志:主题错误、链错误或范围太窄。
  • 值错误:ABI 不匹配或未应用代币小数位。
  • 重复:游标未持久化;重启时重新处理。
  • 延迟告警:轮询间隔太长或队列饱和。
  • 高度不一致:负载均衡后端不同步。

基础设施权衡:公共、共享和专用 RPC

公共端点适合探索,但不适合告警。它们会积极限流,可能不支持宽泛的日志查询,并且不提供延迟保证。共享提供商端点提高了可靠性和速率限制,但仍与其他租户共享容量。专用节点为你提供可预测的吞吐量和一致的链头,当你的产品承诺是实时性时,这一点很重要。

权衡是成本和运营开销。一个在多个链上对 swap 发出告警的巨鲸监控产品需要在每条链上保持一致访问,成本随链数和查询量而扩展。关于在这些层级之间选择的方法论,请参阅 区块链节点托管指南。关于特定链的端点考虑,网络目录 列出了可用的内容。

一条实用规则:如果你的告警延迟目标低于几秒,请为你要告警的链预算专用或高 tier 访问,并将共享访问用于回填和研究查询。

局限性以及巨鲸数据无法告诉你的事情

巨鲸监控观察的是交易,而不是意图。一笔大额转账可能是卖出、抵押品移动、内部资金调整或跨链桥跳转。归属标签是启发式的,可能会过时。地址聚类可能合并不同实体或将一个实体拆分到多个地址。

跨链活动加剧了这个问题。在一个链上开仓并在另一个链上对冲,看起来像是两个不相关的事件,除非你按实体将它们连接起来。任何将巨鲸动向呈现为清晰信号的产品,都是将大量不确定性压缩成一个简单的告警。

将巨鲸告警视为多个输入之一。将它们与场所流动性、资金费率和你自己的风险限额结合起来,而不是仅凭单个通知采取行动。

后续步骤:构建和运营你的管道

从一条链和一个场所开始。在一小组地址上正确完成摄取、解码和归属,对照区块浏览器验证,然后扩展。持久化你的游标,这样重启不会重复告警。在添加更多链之前添加延迟跟踪。

当你准备投入生产时,有意识地选择端点。API 服务概述 解释了托管访问的结构,RPC Assistant 可以帮助你为你的链和工作负载选择具体端点。如果你正在比较多链部署的方法,多链 RPC 指南 涵盖了运营模式。

最后,记录你的标签注册表并定期审查。巨鲸追踪器的质量受限于其归属的质量,这是一项维护承诺,而不是一次性设置。

永远不用担心基础设施

OnFinality 消除了 DevOps 的繁重工作,让您能够更聪明、更快地构建。

开始