4、地址标签系统：构建聪明钱地址库、标签分类（巨鲸/机构/做市商）、标签存储方案

做链上数据分析，最头疼的是什么？

不是数据量太大，也不是SQL写不出来。而是你盯着一个地址，完全不知道它是谁。是散户？是巨鲸？还是某个做市商的归集钱包？

没有标签的地址，就像没有名字的路人。你只能看到它转了多少笔，却看不懂它背后的意图。

所以这一章，我们来聊聊怎么给地址「上户口」。说白了，就是构建一套聪明钱地址库，把巨鲸、机构、做市商这些角色分门别类存好。我自己的经验是，标签系统建得好不好，直接决定了你的信号质量。

4.1 为什么要建地址标签系统？

你可能觉得，不就是给地址打个标签嘛，有什么难的？

嗯，刚开始我也这么想。直到有一次，我追踪一个「疑似聪明钱」的地址，发现它频繁在Uniswap上做波段，收益还不错。我差点就把它加入信号源了。结果一查链上历史，发现这个地址其实是某个CEX的热钱包归集地址——那些交易全是用户的普通操作，根本不是聪明钱行为。

你看，没有标签，你就会被数据骗。

地址标签系统的核心价值，我总结为三点：

  • 过滤噪音：把交易所、矿池、合约地址这些「非人类行为」剔除掉
  • 识别角色：知道谁是巨鲸、谁是做市商、谁是机构，行为模式完全不同
  • 追踪关联：通过标签把同一实体的多个地址串起来，看清全貌

核心观点：没有标签的地址分析，就像盲人摸象。你只能摸到局部，永远看不到全貌。

4.2 标签分类：巨鲸、机构、做市商

标签怎么分？我个人习惯按「行为角色」来分，而不是按「地址类型」。因为同一个地址可能既是巨鲸又是做市商，但它的行为模式是唯一的。

我常用的分类体系是这样的：

标签大类 标签子类 识别依据 示例
巨鲸 长期持有鲸、波段鲸、DeFi鲸 持仓量>1%流通量，或单笔交易>100万美元 0x123...abc（持有10万ETH）
机构 基金、VC、做市商、对冲基金 公开披露地址、链上行为模式（如定期调仓） 0x456...def（三箭资本地址）
做市商 MM主地址、MM归集地址、MM套利地址 高频小额交易、与CEX频繁交互、流动性池操作 0x789...ghi（Wintermute地址）
交易所 热钱包、冷钱包、归集地址、提币地址 公开API、链上模式（大额归集+分散提币） 0xaaa...bbb（Binance热钱包）
合约 DEX、借贷、桥、NFT市场 EVM字节码、公开ABI 0xccc...ddd（Uniswap V3 Router）
聪明钱 早期买家、波段高手、空投猎人 历史胜率>60%、早期参与项目、低买高卖 0xeee...fff（某知名交易员）

你可能会问：这些标签怎么来的？

嗯，主要有三个来源：

  1. 公开数据源：Etherscan标签、Nansen标签、Arkham Intelligence等
  2. 链上行为推断：通过交易模式、交互合约、时间规律来打标签
  3. 人工标注：社区贡献、项目方披露、自己分析发现

我的经验：不要完全依赖公开标签。Etherscan上很多标签是用户自己提交的，不一定准确。我一般会把公开标签作为「候选」，然后用自己的规则去验证一遍。

4.3 标签存储方案：从SQLite到PostgreSQL

标签存哪里？这取决于你的数据规模。

如果你只是个人研究，几千个地址，SQLite完全够用。但如果你要跑生产环境，每天处理几百万个地址，那必须上PostgreSQL或者ClickHouse。

我推荐一个通用的表结构设计：

-- 地址标签主表
CREATE TABLE address_labels (
    id BIGSERIAL PRIMARY KEY,
    address VARCHAR(42) NOT NULL,        -- 以太坊地址
    chain_id INTEGER NOT NULL,           -- 链ID（1=以太坊，56=BSC）
    label_type VARCHAR(50) NOT NULL,     -- 标签大类：whale/institution/mm/exchange/contract/smart_money
    label_subtype VARCHAR(100),          -- 标签子类：long_term_whale/dex_trader
    label_source VARCHAR(50),            -- 标签来源：etherscan/nansen/manual
    confidence FLOAT DEFAULT 0.5,        -- 置信度：0-1
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP DEFAULT NOW(),
    UNIQUE(address, chain_id, label_type)
);

-- 地址别名表（一个地址可以有多个别名）
CREATE TABLE address_aliases (
    id BIGSERIAL PRIMARY KEY,
    address VARCHAR(42) NOT NULL,
    alias_name VARCHAR(200) NOT NULL,    -- 别名：如"三箭资本主地址"
    alias_type VARCHAR(50),              -- 别名类型：official/community/inferred
    created_at TIMESTAMP DEFAULT NOW()
);

-- 地址关联表（同一实体的多个地址）
CREATE TABLE address_clusters (
    id BIGSERIAL PRIMARY KEY,
    cluster_id VARCHAR(100) NOT NULL,    -- 实体ID
    address VARCHAR(42) NOT NULL,
    cluster_name VARCHAR(200),           -- 实体名称：如"Alameda Research"
    created_at TIMESTAMP DEFAULT NOW()
);

这个结构看起来简单，但实际用起来很灵活。我解释一下几个关键点：

  • chain_id：同一个地址在不同链上可能角色不同。比如一个地址在以太坊上是巨鲸，在Polygon上可能只是普通用户
  • confidence：置信度很重要。公开标签我给0.7，链上推断我给0.5，人工标注我给0.9。这样后续分析时可以按置信度过滤
  • address_clusters：这是最容易被忽略的。一个实体可能有几十个地址，不聚类的话，你看到的只是碎片

避坑指南：我曾经犯过一个错误——把所有标签都放在一张表里，没有区分来源。结果后来发现，同一个地址被不同来源打了冲突的标签（比如Etherscan说是交易所，Nansen说是做市商）。从那以后，我强制要求每个标签必须带source字段，并且用UNIQUE约束防止重复。

4.4 标签更新策略：增量更新 vs 全量重建

标签不是一成不变的。一个地址今天可能是散户，明天可能就成了巨鲸。所以标签系统必须支持更新。

我常用的策略是：

  1. 每日增量更新：每天跑一次脚本，检查新地址、更新置信度、修正错误标签
  2. 每周全量重建：每周日重新跑一次全量标签生成流程，确保数据一致性
  3. 人工审核队列：置信度低于0.3的标签，自动进入人工审核队列

代码实现上，我一般用Python的psycopg2或者asyncpg来操作数据库。下面是一个简单的更新脚本示例：

import psycopg2
from datetime import datetime

def update_address_label(address, chain_id, label_type, confidence, source):
    """更新或插入地址标签"""
    conn = psycopg2.connect("dbname=labels user=admin password=xxx")
    cur = conn.cursor()
    
    # 使用UPSERT（INSERT ON CONFLICT UPDATE）
    cur.execute("""
        INSERT INTO address_labels (address, chain_id, label_type, confidence, label_source, updated_at)
        VALUES (%s, %s, %s, %s, %s, NOW())
        ON CONFLICT (address, chain_id, label_type) 
        DO UPDATE SET 
            confidence = EXCLUDED.confidence,
            label_source = EXCLUDED.label_source,
            updated_at = NOW()
    """, (address, chain_id, label_type, confidence, source))
    
    conn.commit()
    cur.close()
    conn.close()

# 使用示例
update_address_label(
    address="0x123...abc",
    chain_id=1,
    label_type="whale",
    confidence=0.85,
    source="manual"
)

我的习惯：更新标签时，我会保留历史版本。不是直接覆盖，而是把旧版本存到address_labels_history表里。这样万一标签错了，可以回滚。你想想看，如果因为一个错误标签导致你追错了信号，那损失可不小。

4.5 标签系统的架构设计

最后，我用一张图来总结整个标签系统的架构。这张图是我自己项目里实际在用的，你可以参考：

地址标签系统架构图 数据源层 公开API（Etherscan） 链上数据（RPC节点） 社区贡献 人工标注 处理层 标签推断引擎 置信度计算 地址聚类 存储层 PostgreSQL（主库） Redis（缓存） 历史归档（S3） 应用层 信号生成 风控过滤 数据看板

这张图展示了从数据采集到最终应用的完整链路。你可能会注意到，我特意把Redis放在了存储层。为什么？因为标签查询是高频操作，每次分析都要查地址标签，如果每次都查PostgreSQL，性能扛不住。用Redis做缓存，查询速度能提升10倍以上。

好了，关于地址标签系统，核心内容就这些。从分类到存储，从更新到架构，每一步都有坑，但也都有解法。我个人觉得，标签系统是链上数据分析的「基础设施」，值得花时间好好打磨。

记住一句话：标签越准，信号越强。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →