BlockVectra

Robinhood Chain 数据集分析师实战手册(SQL Cookbook)

截至当前 origin/pre-dev 分支,本项目已经在 ClickHouse 中构建了涵盖原始区块链数据、事件解码、协议行为解析以及链上宏观增长的全套数据资产。所有数据表在每条链上独立成库(以 robinhood 为标准库名,跨链查询时替换库名即可)。

面向对象:内部数据分析师、风控工程师、量化交易员与数据科学家。 覆盖范围:Robinhood Chain(Arbitrum Orbit L2, Chain ID 4663, 块高 ~72M, ~101ms 出块速度, 美股代币化资产)。 版本状态:基于 origin/pre-dev 上的全栈数据集(原始表 + 已落地的派生表/字典表子集,见 §1 清单)。


目录


1. 前言与 pre-dev 已落地数据集清单

截至当前 origin/pre-dev 分支,本项目已经在 ClickHouse 中构建了涵盖原始区块链数据、事件解码、协议行为解析以及链上宏观增长的全套数据资产。所有数据表在每条链上独立成库(以 robinhood 为标准库名,跨链查询时替换库名即可)。

本手册覆盖的核心数据集清单如下(origin/pre-dev 上已落地的派生表完整列表见 schema/clickhouse/derived/README.md):

类别数据集名称物理表 / 视图核心来源 / 派生 SQL主要用途
原始表区块头 (Blocks){db}.blockssql/schema.sql区块时间戳、出块人、Gas Limit/Used、Base Fee
原始表交易与回执 (Transactions){db}.transactionssql/schema.sql交易参数、回执状态 (status)、有效 Gas 价格、L1 分摊 Gas
原始表事件日志 (Logs){db}.logssql/schema.sql合约日志 raw bytes, topic0~topic3, data
原始表内部调用轨迹 (Traces){db}.tracessql/traces.sql内部 CALL/DELEGATECALL/STATICCALL/CREATE 帧、调用栈深度、revert 原因
派生表ERC20 转账流水{db}.erc20_transfers001_erc20_transfers.sql标准 ERC20 Transfer 事件解码 (token, from, to, amount)
派生表ERC721 NFT 转账{db}.erc721_transfers002_erc721_transfers.sqlNFT 所有权流转 (token, from, to, token_id)
派生表地址维度转账索引(本 PR 新增,尚未装到 robinhood){db}.erc20_transfers_by_holder, {db}.erc721_transfers_by_holder035_transfers_by_holder.sql任意地址的全量 ERC20/ERC721 流水(每笔 2 行,holder 在排序键首位;见 Q31)
派生表链日度宏观统计{db}.daily_chain_stats004_daily_chain_stats.sql出块数、交易数、失败数、Gas 消耗、唯一发包地址 (HLL)
派生表代币日度流水统计{db}.daily_token_stats005_daily_token_stats.sql各 ERC20 代币每日转账笔数、交易量、活跃收发地址数
派生表Robinhood 代币化美股{db}.stock_tokens, {db}.stock_token_daily_activity007_stock_tokens.sql官方美股/ETF 代币注册表 (TSLA, AAPL 等) 与每日 Mint/Burn 流水
派生表DEX 交易与流动性池{db}.dex_pools, {db}.dex_swaps008_dex.sqlUniswap V2/V3/V4 资金池元数据与 Swap 成交流水 (amount0/1, price)
派生表ERC1155 与 NFT 持有{db}.erc1155_transfers, {db}.erc1155_balances, {db}.erc721_current_owner009_erc1155_nft_owners.sql批量转账展平、多资产余额账本与 ERC721 实时持有人锁定
派生表合约注册表与活跃度{db}.contracts, {db}.contract_daily_activity010_contracts.sql成功部署的合约注册表 (address, creator, tx_hash) 与调用频次
参考表地址实体标签库{db}.address_labels011_address_labels.sql官方 Bridge 网关、WETH、USDG、Sequencer 等知名地址字典
派生表跨链桥流水 (Bridge){db}.bridge_deposits, {db}.bridge_withdrawals, {db}.bridge_erc20_gateway_events, {db}.bridge_daily_net_flow012_bridge_flows.sqlL1<->L2 存款 (Retryable Tickets)、L2 提现与代币网关净流量
派生表手续费与 L1 成本核算{db}.tx_fees, {db}.daily_fee_stats, {db}.daily_fee_by_address013_fees.sql逐笔交易 L1 Calldata / L2 执行费用拆解与大户手续费排行
派生表ArbOS L1 定价与 Base Fee{db}.arbos_l1_pricing, {db}.daily_l1_base_fee_stats022_arbos_l1_pricing.sql从 ArbOS startBlock 系统交易 (0x6bf6a42d) 解码 L1 base fee 预估与每日统计
派生表活跃用户与留存 (DAU){db}.daily_active_addresses, {db}.address_first_seen, {db}.user_retention_cohorts014_active_users.sql排除系统账号后的真实活跃地址数 (DAU)、新增用户与留存队列
参考/视图事件签名库与解码日志{db}.event_signatures, {db}.logs_named, {db}.v_decoded_*015_event_signatures.sql45 种主流 EVM 事件签名 (topic0 -> name/signature) 与具名视图
参考/视图方法选择器与解码交易{db}.method_selectors, {db}.transactions_named016_method_selectors.sql118 种主流 4 字节函数选择器 (selector -> name) 与具名交易视图
派生表预言机价格 (Oracle Prices){db}.oracle_feeds, {db}.oracle_prices017_oracle_prices.sqlChainlink FluxAggregator 喂价事件解码,美股/外汇链上报价历史
视图/派生表ERC20 授权安全{db}.erc20_approvals(表), {db}.erc20_current_allowances(视图)018_erc20_approvals.sqlApproval 授权流水与无限额授权 (Unlimited) 监控
派生表代币总供应量 (Token Supply){db}.token_daily_supply, {db}.v_token_latest_supply019_token_supply.sql各 ERC20 每日链上 totalSupply(净铸造量)快照与变化趋势
视图/派生表失败交易分析 (Failed Txs){db}.failed_txs(视图), {db}.contract_daily_failure_rate(预计算表)020_failed_txs.sqlfailed_txs 是 transactions FINAL ⋈ traces FINAL 视图(含 revert reason 解码,需 trace 覆盖区间);只有 contract_daily_failure_rate 是预聚合表
派生表链级吞吐指标{db}.throughput_minute, {db}.throughput_hour021_throughput.sql分钟/小时级真实 TPS、用户交易占比、出块间隔分位数 (P50/P90/P99)
视图/派生表钱包行为画像 (Wallet Profiles){db}.wallet_daily_activity(表), {db}.wallet_profiles(视图)024_wallet_profiles.sql每个地址的首次/末次活跃时间、交易次数、协议交互分布等画像
派生表WETH 封装流水 (WETH Flows){db}.weth_flows, {db}.daily_weth_net_wrap025_weth_flows.sqlWETH Deposit/Withdrawal/Transfer 分类流水与每日净封装量统计
视图/派生表可升级代理检测 (Proxy){db}.proxy_upgrades(表), {db}.v_proxy_current_implementation(视图), {db}.proxy_slots(快照表)026_proxy_detection.sqlEIP-1967 标准升级事件 (Upgraded/AdminChanged/BeaconUpgraded) 与当前生效的实现合约地址
视图/派生表ERC20 持仓复式账本{db}.erc20_balance_moves(视图), {db}.erc20_balances(表,由可刷新 MV mv_erc20_balances 每 6 小时整表刷新)027_erc20_balances.sql建在 erc20_transfers FINAL 上的借贷记双边流水视图、每 (token, holder) 一行的紧凑余额表(最多滞后一个刷新周期)与零地址发行恒等式对账
派生表DEX 日度价格与 VWAP{db}.dex_price_daily, {db}.v_dex_price_daily031_dex_prices.sql各代币对每日 VWAP 价格(基于 DEX Swap 流水加权均价)与最新报价视图
派生表代币化股票市场看板{db}.stock_token_daily, {db}.stock_token_leaderboard032_stock_market.sql代币化美股每日涨跌幅、成交量与持仓地址数排行榜
元数据表Token 元数据缓存{db}.tokenssql/tokens.sql链上合约元数据 (name, symbol, decimals, total_supply)

2. 核心避坑指南 (Essential Pitfalls)

在 ClickHouse 中直接编写针对区块链数据的 SQL 与传统数仓有极大区别。以下 10 条核心避坑规则是在生产环境血泪排错总结出的关键守则:

2.1 必须显式 FINAL 且过滤 is_deleted = 0(针对 ReplacingMergeTree)

原始表(blocks、transactions、logs、traces)以及多数派生表均采用 ReplacingMergeTree(version, is_deleted) 引擎。

  • 重组与墓碑机制:当链上发生轻微重组时,Follow 进程会插入一条排序键相同但 is_deleted = 1、version 更高的新版本;
  • Backfill 断点恢复:历史回填重启时,边界重叠部分会插入相同版本的数据。
  • 查询规则:后台合并前 ClickHouse 不会自动去重。如果不加 FINAL 且不过滤 is_deleted = 0,查询将同时读到回滚前的脏数据和重复插入的多版本数据!
  • 例外提示:对于上亿行的大跨度全表扫描,若 FINAL 导致内存过大,可采用 argMax(col, version) 模式替代(详见 docs/queries.md §1.1)。

2.2 普通 MergeTree 表严禁加 FINAL

并非所有表都是 ReplacingMergeTree!以下表采用基础 MergeTree 引擎存储静态数据或追加账本:

  • {db}.event_signatures(事件字典)
  • {db}.erc1155_balances(NFT 余额账本)
  • 对这些表加 FINAL 会直接报 ILLEGAL_FINAL: Storage MergeTree doesn't support FINAL 错误!写 SQL 时务必注意表引擎类型。

2.3 二进制列是原始字节,严禁直接作为十六进制字符串比较

  • 存储类型:地址是 FixedString(20),哈希和 Topic0 是 FixedString(32),input/data 是 String(均为 raw bytes,无 0x 前缀)。
  • 查询过滤:必须使用 unhex('...')(不要包含 0x 前缀),如 WHERE token = unhex('0bd7d308f8e1639fab988df18a8011f41eacad73')。若写成 WHERE token = '0x0bd7...',查询会静默返回 0 行且不报错!
  • 结果展示:展示给人类看时必须包一层 hex(...)。
  • 函数选择器:transactions.input 是原始字节,提取前 4 字节函数选择器应使用 substring(input, 1, 4),展示为 8 位 hex 字符串使用 hex(substring(input, 1, 4))。

2.4 金额与大数计算绝对禁止使用 Float64 与 pow()

  • 精度丢失:EVM 的 uint256 最大可达 78 位十进制数字,而 Float64 仅有 53 位二进制有效位(约 15~17 位十进制有效数字)。任何 pow(10, decimals) 或转 Float64 都会导致后几十位精度丢失,产生对账灾难!
  • 正确做法:
    1. 账本与汇总阶段全部使用 UInt256 / Int256 整数运算;
    2. 查询展示层统一使用 toString(amount) 输出为字符串交给业务前端;
    3. 若需在 SQL 中显示为小数,必须先用 divideDecimal 做整数除法,再格式化为 Decimal256:
      -- ✅ 正确:divideDecimal 先做除法,再转 Decimal
      divideDecimal(
          toDecimal256(amount, 18),
          toDecimal256(toUInt256(concat('1', repeat('0', toUInt32(18)))), 18)
      ) -- → 90.236602999286(真正的小数)
      
      -- ❌ 错误:toDecimal256(amount, 18) 只设置显示 scale,不做除法,
      --   toString() 仍输出 90236602999286000000,对分析师产生误导!
      toDecimal256(amount, 18) -- → 90236602999286000000(仍是整数)
    4. multiIf 可按 decimals 分档,每档各用一次 divideDecimal(见 Q11)。

2.5 小数位换算必须依赖 tokens 表,严禁盲目硬编码 18

虽然以太坊原生资产与多数 ERC20 是 18 位小数,但合规稳定币与跨链代币常有不同取值(例如 USDG 是 6 位小数,USDC 是 6 位,WBTC 是 8 位)。必须通过 JOIN {db}.tokens tk ON tk.address = t.token 获取其真实的 tk.decimals,再进行除法或 Decimal 缩放。

2.6 列别名同名遮蔽陷阱(ClickHouse 26.9+ 强制规则)

ClickHouse 26.9+ 启用了全新的查询分析器。若在 SELECT 中使用了与原列同名的别名,例如:

-- 错误写法(同名别名):
SELECT hex(from) AS from FROM {db}.transactions WHERE from = unhex('...');

解析器会将 WHERE 条件悄悄绑定到 SELECT 中的 hex(from) 表达式上,导致 FixedString(20) 与十六进制字符串发生非法比对,静默返回 0 行!必须统一使用 _hex、_str 等区分命名的别名(如 from_hex、tx_hash_hex)。

2.7 内部调用轨迹 traces 数据覆盖范围限制

{db}.traces 是通过 debug_traceBlock 以 callTracer 录制的深度调用栈。由于生产节点启用了修剪策略(Pruned Node,Trace 窗口约 100~110 块):

  • traces 仅在 2026-09-25 追链模式开启后开始连续覆盖(生产块高约 72,050,949 起);
  • 历史早期回填归档区块(0 ~ 72,050,948)不存在 traces 数据。业务查询如果涉及调用轨迹,务必加上 block_number >= 72050949 过滤条件,避免空扫。

2.8 专链专有字段的 NULL 属于正常业务语义

Robinhood Chain 是 Arbitrum Orbit 链系架构:

  • gas_used_for_l1 与 l1_block_number:仅在相关交易类型上非空;
  • to 与 contract_address:合约创建交易时 to 为 NULL、contract_address 非空;普通交易反之;
  • gas_price 与 max_fee_per_gas:Legacy 交易有 gas_price,EIP-1559 交易则后两者非空。这些 NULL 是协议层互斥设计的正常现象,并非抓取漏损。
  • blocks.gas_limit:Arbitrum Nitro 链上恒为占位常量 1125899906842624(= 2^50),并非真实区块容量。严禁用它作分母计算 gas_used / gas_limit 的「利用率/拥堵度」——该表达式在全链任意窗口都恒等于 0(生产实测:72040000~72040499 共 500 个区块只有 1 个 distinct gas_limit 值)。需要容量基线请用窗口内 max(gas_used) 或 §Q2 的 throughput_minute。

2.9 WETH 在 Robinhood Chain 上的特殊形态

在 Robinhood Chain 上,WETH(合约 0x0bd7d308f8e1639fab988df18a8011f41eacad73)不是本地用户通过合约原生存取生成的,而是由官方 L2 Weth Gateway(0x1d187c3e2da52d72bc9c41e3aba0fdfa6a7bf055)跨链托管铸造。因此:

  • 链上 没有 vanilla WETH9 的 Deposit(dst, wad) / Withdrawal(src, wad) 日志;
  • 所有 WETH 跨链充值体现为 from = 0x00...00 的 ERC20 Transfer(Mint);
  • 所有 WETH 跨链提现体现为 to = 0x00...00 的 ERC20 Transfer(Burn)。

2.10 样本里的 1998-07-09 行来自本地测试块,不是链上数据

Q2/Q3/Q4/Q8 的示例结果里都出现过 1998-07-09 这一行(daily_active_addresses = 1、l1_cost_pct = nan、出块间隔为负)。它不是 Robinhood Chain 的链上数据,而是本地样本库里手工插入的 4 个测试区块:块号 900000000–900000003,timestamp 恰好等于块号本身(epoch 900000000–900000003 ⇒ 1998-07-09 16:00:00~16:00:03 UTC),gas_limit = 0、size = 0、tx_count = 1,并带 4 笔同款测试交易(from = to = 0x00…00、type 2)。

  • 生产库不含这些行:本地只读复核(2026-09-25)实测——生产库 SELECT count() FROM robinhood.blocks WHERE number >= 800000000 → 0(生产最高块高 72,345,812,blocks 从 0 号连续到最大块高);本地 dev/scratch 库里 number >= 800000000 的正好只有这 4 行。所以分析生产数据不需要额外加时间下限。
  • 不要把它解释成「链上零时间戳块」:timestamp = 0 在 ClickHouse 里渲染为 1970-01-01(实测 SELECT toDate(toDateTime(0)) → 1970-01-01),不会变成 1998-07-09;只有这 4 个 test block 的 timestamp(= 块号)才会落在 1998-07-09。
  • 在 scratch 库复现样本时若看到这一行,用 WHERE number <= <样本上限>(或 timestamp > toDateTime('2020-01-01 00:00:00'))排除掉,并在结论里注明它是本地测试数据;不要据此给生产数据质量报 bug。

3. 安装与补算说明 (Installation & Backfill)

派生数据集全部位于 schema/clickhouse/derived/ 目录。在部署新环境时,按以下规范进行安装与补算:

  1. 正确性方案 (a) —— 逐行透传物化视图(Insert-Trigger MV):

    • 适用表:erc20_transfers, erc721_transfers, tx_fees, contracts, erc20_approvals, proxy_upgrades, bridge_deposits。(更新 2026-09-27:erc20_balance_moves 已改为普通视图、不再是 MV 目标表,见 027_erc20_balances.sql。)
    • 原理:MV 与源表保持严格相同的排序键与版本号,透传 version 和 is_deleted。当源表发生 reorg 或回填重复插入时,FINAL 自动折叠去重,无双重计数风险。
    • 补算方式:执行对应的 003_backfill.sql 或直接跑 INSERT INTO ... SELECT ... FROM {db}.logs。
    • ERC20 余额表:erc20_balances 由 027 的可刷新 MV 每 6 小时整表重算(属于下面的方案 (b));erc20_transfers 补完历史后执行一次 028_erc20_balances_backfill.sql(SYSTEM REFRESH VIEW + SYSTEM WAIT VIEW)立即刷新,不必等下一个周期(Q11/Q12 依赖此表)。
  2. 正确性方案 (b) —— 闭市周期幂等重算(Refreshable MV / Idempotent Cron):

    • 适用表:daily_chain_stats, daily_token_stats, daily_fee_stats, daily_active_addresses, throughput_minute, throughput_hour, stock_token_daily_activity。
    • 原理:针对跨周期的聚合指标(COUNT/SUM/UV),严禁使用 Insert-Trigger MV 累加未去重的原始插入。必须等待该时间窗口(自然日或分钟)闭市后,针对 FINAL WHERE is_deleted=0 状态进行完整重算,重算结果以更高的 refreshed_at 覆盖旧版本。
    • 补算方式:由 install_all.sh --backfill 自动分块执行 006_daily_stats_backfill.sql(或手动传 --param_lo/--param_hi 逐天补算窗口外的历史自然日)。
    • 注意:派生表只装「已闭市」的自然日,当天数据不会出现。004/005/013 的可刷新 MV 的 SELECT body 里都带 toDate(...) < today()(006_daily_stats_backfill.sql 则按闭市日的区块区间 [lo, hi) 逐天切片),MV 每天 OFFSET 1 HOUR(UTC 01:00 之后)才重算最近 3 个自然日,所以:
      • 当天(UTC 自然日尚未结束)在 daily_chain_stats / daily_token_stats / daily_fee_stats / daily_fee_by_address 里查不到,手动刷新也不会产生当天行。本地实测:把 2000 块当天(2026-09-25)真链数据灌入 scratch 库后执行 SYSTEM REFRESH VIEW {db}.mv_daily_chain_stats + SYSTEM WAIT VIEW {db}.mv_daily_chain_stats,daily_chain_stats 仍是 0 行(mv_daily_token_stats / mv_daily_fee_stats 同理,同样的 < today() 谓词);当天行要等 UTC 次日闭市后的第一次刷新(01:00 UTC 之后)才落库。
      • 需要盘中(当天)数据或补算某一天的窗口数据时,去掉 < today() 谓词直接跑 MV 的 SELECT body,自行对 {db}.blocks FINAL / {db}.transactions FINAL / {db}.tx_fees FINAL / {db}.erc20_transfers FINAL 聚合——例如把 AND toDate(timestamp) < today() 换成 AND toDate(timestamp) = toDate('2026-09-25')。本手册 Q3/Q4/Q8/Q9/Q13 的 2026-09-25 样本就是这样取的(见 §5),它们不是可刷新 MV 的默认输出。
    • 活跃用户(Q4):014_active_users.sql 没有可刷新 MV(DAU/留存是集合事实,不能用 insert-trigger MV 累加),必须按脚本底部的参数化语句逐日刷新,且按时间顺序从最早的闭市日开始:clickhouse-client --param_target_date='2026-09-24' --queries-file=<(sed -n '/-- \[refresh: daily_active_addresses\]/,/^;/p' 014_active_users.sql)(详见 docs/datasets/active-users.md)。
    • 吞吐指标(Q2):throughput_minute/throughput_hour 由 021_throughput.sql 的可刷新 MV 驱动(REFRESH EVERY 1 MINUTE / 1 HOUR),但 body 只读最近 15 分钟 / 6 小时的 wall-clock 窗口(timestamp >= now('UTC') - INTERVAL 15/16 MINUTE、- INTERVAL 6/7 HOUR)。因此:① 只有追链到链头时才会写入行;② 回填/补算历史切片(例如本地 72039000–72040999)不会产生任何行(本地实测:SYSTEM REFRESH VIEW {db}.mv_throughput_minute / mv_throughput_hour 后两张表均 0 行);③ 需要历史窗口的分钟级吞吐时,把 body 里的 now('UTC') 换成固定时间窗,或直接对 blocks FINAL + transactions FINAL 自行聚合。
  3. 静态字典与元数据维护:

    • event_signatures (015) 与 method_selectors (016):执行对应 SQL 脚本即可灌入种子数据。
    • address_labels (011):人工审核打标的参考表,支持重复重跑幂等覆盖。
    • tokens (sql/tokens.sql):通过 chain-indexer enrich-tokens 子命令对节点 RPC 发起批量 eth_call 增量回填。
  4. 代币化美股注册表(Q14/Q15 依赖):

    • stock_tokens 与 stock_token_daily_activity 表由 007_stock_tokens.sql 建表(初始为空表),数据由 scripts/derived/refresh_stock_tokens.sh 通过扫描 TokenCreated 事件(topic0 = 0xd9b0c6a1…)从 RPC 和 ERC20 转账流水中填充:
      # 需先确保 erc20_transfers 已回填
      export CH_URL=http://127.0.0.1:8123
      export CH_USER=indexer
      export CH_PASSWORD=indexer
      CH_DB=robinhood scripts/derived/refresh_stock_tokens.sh registry
      # 补算每日活跃统计(stock_token_daily_activity):一次算一个已收尾的 UTC 自然日,
      # 默认是前一天,补历史用 --date YYYY-MM-DD 逐日跑(子命令是 registry / daily,没有 --mode):
      CH_DB=robinhood scripts/derived/refresh_stock_tokens.sh daily --min-lag-hours 1
    • 若 stock_tokens 为空,Q14 和 Q15 都会返回 0 行(Q15 是 INNER JOIN)。本手册 Q14 的示例取自「建表后尚未补数」的库,Q15 的示例取自已执行过 refresh_stock_tokens.sh registry(stock_tokens 非空)的库 —— 两例的补数状态不同,不要当成同一个库的前后结果。

4. 31 个实战实测查询 (31 Practical Verified Queries)

分类一:区块与链级吞吐 (Blocks & Throughput)

Q1. 区块出块间隔、TPS 与 Gas 利用率监控

  • 业务场景 / 分析目标:监控 Arbitrum Orbit L2 出块节律是否平稳(约 100ms 一块)与单个 100 块窗口内的 Gas 消耗量级。
  • 使用表与依赖:robinhood.blocks
  • 运行环境与性质:🟢 生产环境只读实测 (Production Read-Only)
  • 预期成本与性能考量:主键索引范围裁剪(number >= 72040000 AND number < 72040500),仅读取 500 个区块头数据。扫描量极小(约几十 KB),毫秒级完成。

SQL 查询语句:

SELECT
    intDiv(number, 100) * 100 AS block_window_start,
    count() AS block_count,
    min(timestamp) AS min_time,
    max(timestamp) AS max_time,
    round(avg(tx_count), 2) AS avg_txs_per_block,
    intDiv(sum(gas_used), toUInt64(count())) AS avg_gas_used,
    max(gas_used) AS max_gas_used,
    formatReadableQuantity(sum(gas_used)) AS total_gas_used_readable
FROM robinhood.blocks FINAL
WHERE is_deleted = 0 AND number >= 72040000 AND number < 72040500
GROUP BY block_window_start
ORDER BY block_window_start
SETTINGS max_threads=2, max_execution_time=60

⚠️ 不要用 gas_used / gas_limit 当拥堵指标:blocks.gas_limit 是 Arbitrum Nitro 的占位常量 2^50,该比值在全链任何窗口都恒为 0(详见 §2.8)。若确实需要「相对容量」视角,请用窗口内 max(gas_used) 作基线,或改用 Q2 的 throughput_minute。

真实执行结果示例(生产只读,执行耗时: 2.42s):

72040000	100	2026-09-25 07:13:59	2026-09-25 07:14:09	6.45	897553	3783508	89.76 million
72040100	100	2026-09-25 07:14:09	2026-09-25 07:14:19	8.96	1326237	8514856	132.62 million
72040200	100	2026-09-25 07:14:19	2026-09-25 07:14:29	5.09	883732	5303836	88.37 million
72040300	100	2026-09-25 07:14:30	2026-09-25 07:14:40	5.52	849874	7510922	84.99 million
72040400	100	2026-09-25 07:14:40	2026-09-25 07:14:50	4.74	662921	5525806	66.29 million

Q2. 分钟级链上吞吐量(TPS)、用户交易占比与出块间隔分布

  • 业务场景 / 分析目标:按分钟粒度跟踪链上真实用户 TPS、系统交易占比(type 106 内部交易)以及出块延迟分位数(P50)。
  • 使用表与依赖:{db}.throughput_minute
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:直接读取预聚合的 ReplacingMergeTree 表,按 period_start 倒序拉取最新桶,单次仅扫描数行,成本极低。

SQL 查询语句:

SELECT
    period_start,
    blocks,
    txs AS user_txs,
    txs_system,
    tps,
    round(user_tx_share * 100, 2) AS user_tx_pct,
    avg_block_interval_secs,
    p50_block_interval_secs
FROM robinhood.throughput_minute FINAL
ORDER BY period_start DESC
LIMIT 5

真实执行结果示例(本地样本库追链到链头时捕获,执行耗时: 0.017s;⚠️ MV 只覆盖最近 15 分钟,回填切片不会产生行,见 §3;末行 1998-07-09 16:00:00 是本地测试块,见 §2.10):

2026-09-25 07:15:00	406	2033	406	33.883	83.35	0.10344827586206896	0
2026-09-25 07:14:00	590	2919	590	48.65	83.19	0.1016949152542373	0
2026-09-25 07:13:00	590	2913	590	48.55	83.16	0.1016949152542373	0
2026-09-25 07:12:00	414	2151	424	35.85	83.53	0.09685230024213075	0
1998-07-09 16:00:00	4	4	0	0.067	100	-222580134.5	1

Q3. 每日宏观增长概览(总出块、用户交易数、失败交易数、独立发包地址数)

  • 业务场景 / 分析目标:业务团队日报核心看板数据,追踪整链每日总交易量、失败率以及唯一发送地址数(uniqExactState 合并)。
  • 使用表与依赖:{db}.daily_chain_stats
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:日级别预聚合表,读取单日仅需扫描 1 行,跨周期多天汇总使用 uniqExactMerge 计算全局 UV,避免大表重算。

SQL 查询语句:

SELECT
    day,
    blocks,
    txs,
    failed_txs,
    round(failed_txs / txs * 100, 2) AS failure_rate_pct,
    formatReadableQuantity(gas_used_sum) AS total_gas_used_readable,
    uniqExactMerge(unique_senders) AS unique_senders_count
FROM robinhood.daily_chain_stats FINAL
GROUP BY day, blocks, txs, failed_txs, gas_used_sum
ORDER BY day DESC

真实执行结果示例(本地 scratch 库,2000 块真链数据 72039000–72040999;⚠️ 2026-09-25 行在派生表里当天查不到,须按 §3「去掉 < today() 谓词、按该日期跑 MV body」复现;末行 1998-07-09 是本地测试块,见 §2.10;执行耗时: 0.004s):

2026-09-25	2000	12026	1150	9.56	2.00 billion	3892
1998-07-09	4	4	0	0	84.00 thousand	1

📌 与 Q4 的数值关系:unique_senders = 3892 是未排除 ArbOS 内部发送地址 0x…a4b05 的原始发包地址数(该窗口 2010 笔 type=106 系统交易全部由它发出);Q4 的 DAU 按 014_active_users.sql 的定义排除它后是 3891,两者相差 1 属于预期。

Q4. 每日活跃用户(DAU)与新增地址趋势

  • 业务场景 / 分析目标:评估平台用户留存与增长动力,按日统计排除系统账户与协议重试交易后的真实活跃地址与首次发包的新用户。
  • 使用表与依赖:{db}.daily_active_addresses & {db}.address_first_seen
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:利用 daily_active_addresses 的 uniqExactState 预聚合状态与 address_first_seen 的首次出现索引,避免全表扫描 transactions。

SQL 查询语句:

SELECT
    d.date AS report_date,
    uniqExactMerge(d.active_state) AS dau_count,
    n.new_addresses_count
FROM robinhood.daily_active_addresses AS d FINAL
LEFT JOIN (
    SELECT first_seen_date, count() AS new_addresses_count
    FROM robinhood.address_first_seen FINAL
    GROUP BY first_seen_date
) AS n ON d.date = n.first_seen_date
GROUP BY d.date, d.active_state, n.new_addresses_count
ORDER BY d.date DESC

真实执行结果示例(本地 scratch 库,2000 块真链数据 72039000–72040999;按 §3 的 014 refresh 语句对 target_date = 2026-09-25 刷新后实测,执行耗时: 0.005s;末行 1998-07-09 是本地测试块,见 §2.10):

2026-09-25	3891	3891
1998-07-09	1	1

⚠️ 3891 而不是 3892:daily_active_addresses 按 014_active_users.sql 的定义排除了 ArbOS 内部发送地址 0x00000000000000000000000000000000000a4b05(type=106)与 retryable 票据类型(104/105)。同一天原始口径 uniqExact(from) = 3892,排除后 uniqExactIf(from, from != 0x…a4b05 AND type NOT IN (104,105)) = 3891(本窗口内 104/105 为 0 笔,排除的全部是 ArbOS 系统发送地址)。所以 Q3 的 unique_senders = 3892 与这里的 3891 并不矛盾,请勿混用。

分类二:交易深度剖析与失败排查 (Transactions & Failures)

Q5. 失败交易排查与高频报错合约 Top 5

  • 业务场景 / 分析目标:识别链上交易失败(status = 0)的重灾区,统计失败交易浪费的 Gas 总量与发生频次最高的交互合约地址。
  • 使用表与依赖:{db}.transactions
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:按 status = 0 过滤,配合 block_number 分区裁剪,仅聚合失败交易,在 transactions 上消耗小。

💡 需要 revert reason 时:020_failed_txs.sql 提供一个 视图 {db}.failed_txs(含 Error(string)/Panic(uint256) 解码的 revert_reason)与一张 预计算表 {db}.contract_daily_failure_rate。注意 failed_txs 视图内部是 transactions FINAL LEFT JOIN traces FINAL,没有 block_number 裁剪,直接全表扫描比本查询(按块高裁剪)贵得多;且 revert reason 需要 trace 覆盖(block_number >= 72050949,见 §2.7),区间外只能拿到 status = 0 的裸交易行。想要「预聚合」的失败率排行请查 contract_daily_failure_rate(闭市自然日、可刷新 MV 幂等重算)。

SQL 查询语句:

SELECT
    hex(assumeNotNull(to)) AS contract_address_hex,
    count() AS failed_tx_count,
    sum(gas_used) AS total_wasted_gas,
    round(avg(gas_used), 0) AS avg_wasted_gas
FROM robinhood.transactions FINAL
WHERE is_deleted = 0
  AND status = 0
  AND to IS NOT NULL
GROUP BY to
ORDER BY failed_tx_count DESC
LIMIT 5

真实执行结果示例(执行耗时: 0.005s):

F3B19FED4466C27D8CAFD9D4B81595609C1CC711	291	10500670	36085
C33ACC93942105C57602E59E8E448C20BA718A85	94	3442274	36620
520ED467860D840EC6CA20F1DACB9C0FA5168AA7	57	2588279	45408
490DDE6CE6D74213CFE0CC3A8C6498D0CD67B991	47	1886221	40132
90A4019E8A04A8A81AF61EAE803DC5885A49B6CE	44	1569081	35661

Q6. 顶层交易方法签名分布与最热门调用函数排行榜

  • 业务场景 / 分析目标:分析用户在链上调用哪些业务函数(例如 execute, approve 等),按 4 字节选择器统计命中率与调用量。
  • 使用表与依赖:{db}.transactions & {db}.method_selectors
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:截取 input 原始字节前 4 字节并关联静态 method_selectors 字典表(仅 118 行),哈希连接开销极小。

SQL 查询语句:

SELECT
    hex(substring(t.input, 1, 4)) AS method_id_hex,
    if(m.name IS NULL OR m.name = '', 'Unknown / Custom', m.name) AS method_name,
    if(m.signature IS NULL OR m.signature = '', 'N/A', m.signature) AS method_signature,
    count() AS call_count
FROM robinhood.transactions AS t FINAL
LEFT JOIN robinhood.method_selectors AS m FINAL
  ON substring(t.input, 1, 4) = m.selector
WHERE t.is_deleted = 0
  AND length(t.input) >= 4
GROUP BY method_id_hex, m.name, m.signature
ORDER BY call_count DESC
LIMIT 5

真实执行结果示例(执行耗时: 0.017s):

6BF6A42D	Unknown / Custom	N/A	2000
3593564C	execute	execute(bytes,bytes[],uint256)	1382
095EA7B3	approve	approve(address,uint256)	900
04E45AAF	Unknown / Custom	N/A	300
5B70EA9F	Unknown / Custom	N/A	298

Q7. 原生资产大额转账监控与富豪地址转账流向

  • 业务场景 / 分析目标:追踪链上原生代币(ETH)大额异动,获取高价值转账的发送方、接收方与金额(wei)。
  • 使用表与依赖:robinhood.transactions
  • 运行环境与性质:🟢 生产环境只读实测 (Production Read-Only)
  • 预期成本与性能考量:主键范围扫描结合 value > 0 过滤,由于排序键包含 block_number,ClickHouse 精确读取指定分区块,无需解构 extra。

SQL 查询语句:

SELECT
    block_number,
    hex(hash) AS tx_hash_hex,
    hex(from) AS from_hex,
    hex(assumeNotNull(to)) AS to_hex,
    toString(value) AS value_wei_str,
    status,
    gas_used
FROM robinhood.transactions FINAL
WHERE is_deleted = 0
  AND block_number >= 72040000 AND block_number < 72040500
  AND value > 0
ORDER BY value DESC
LIMIT 5
SETTINGS max_threads=2, max_execution_time=60

真实执行结果示例(执行耗时: 2.251s):

72040327	554777FCBE11DC885BD17015EA98304B1D10E5960899A4F567232D84C5AFB6E8	504606DBD92873F283A6A73DCD5CC095B63A2692	89E5DB8B5AA49AA85AC63F691524311AEB649EBA	90090000000000000000	1	2734126
72040317	648E60FBA736A32FCEB7122875649C76448613F8B60D0DD64D56C54893D8258B	9600C223A94953E10204B584F309E5FEC5609838	E34A1D5ECFB4EE0064C3E3DEE9B20A722D5EC1EE	10200000000000000000	1	7394115
72040325	31FC96392B1E23DC089BC85999E2A8F71E75899F82D96512D72AAC05E226DBE0	38304ACC79F5A5E32C76BCCF6ADF65BA4CACA265	4EFB8244713D773A9518F05DC1D823EC0F336143	6843536269511544245	1	21000
72040221	DCC046F6BA14BFA032CFB271895057049B85E7B803241B8611C8720615760576	251E39FB07D89C3A7C5F75ED82304F5EEB15E4F9	0000000000000000000000000000000000000000	5090000000000000000	1	545144
72040440	959C2EA1E77573520A3217977B782F5F6E20F8DC61A83FB2709AE367807A768C	4EFB8244713D773A9518F05DC1D823EC0F336143	1CBAF24D53FE930FCE8EFF149FA797D2611DA149	4229376025387725515	1	5177147

分类三:手续费构成与 L1 成本核算 (Fees & L1 Pricing)

Q8. Arbitrum L1 Calldata 成本与 L2 执行费占比剖析

  • 业务场景 / 分析目标:Arbitrum Orbit L2 交易费分为 L1 发布成本与 L2 执行成本,分析 L1 成本占总手续费比例(l1_share)。
  • 使用表与依赖:{db}.daily_fee_stats
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:daily_fee_stats 预计算了 total_fee_wei, total_l1_fee_wei 与 l1_share,直接点查日度汇总,单次扫描数行。

SQL 查询语句:

SELECT
    date,
    tx_count,
    toString(total_fee_wei) AS total_fee_wei_str,
    toString(total_l1_fee_wei) AS total_l1_fee_wei_str,
    toString(total_l2_fee_wei) AS total_l2_fee_wei_str,
    round(l1_share * 100, 2) AS l1_cost_pct,
    toString(median_effective_gas_price) AS median_gas_price_wei
FROM robinhood.daily_fee_stats FINAL
ORDER BY date DESC

真实执行结果示例(本地 scratch 库,2000 块真链数据 72039000–72040999;⚠️ 2026-09-25 行在派生表里当天查不到,须按 §3「去掉 < today() 谓词、按该日期跑 MV body」复现;末行 1998-07-09 是本地测试块,见 §2.10;执行耗时: 0.004s):

2026-09-25	12026	77913208315796000	560945222442000	77352263093354000	0.72	38834000
1998-07-09	4	0	0	0	nan	0

Q9. 单日消耗手续费最多的 Top 5 地址排行榜

  • 业务场景 / 分析目标:识别网络中手续费贡献最大的重度用户或套利 Bot 地址,用于 VIP 客户服务或防范网络拥堵。
  • 使用表与依赖:{db}.daily_fee_by_address
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:按 (date, from) 聚合的 daily_fee_by_address,相比全表扫描 transactions 计算 fee_wei,数据量减少 95% 以上。

SQL 查询语句:

SELECT
    date,
    hex(from) AS sender_address_hex,
    tx_count,
    toString(total_fee_wei) AS total_fee_wei_str
FROM robinhood.daily_fee_by_address FINAL
ORDER BY total_fee_wei DESC
LIMIT 5

真实执行结果示例(执行耗时: 0.007s):

2026-09-25	759D0B33AF8BC5BA0FA5EA78E9BDDD19EF65A976	147	1150151252388000
2026-09-25	A80FDB561A70122B7AD35C92362D4A78BF0DDCA9	2	1018139733856000
2026-09-25	69374F8233A4069D48F8994D84052ECAE6277EF5	12	759279084546000
2026-09-25	49BBF2B70955FB3A106E084D4BFDA92D334573D2	106	746673489134000
2026-09-25	CA7DED7E4F4BA8AB3B10009236AE6D1B95094589	14	733016717708000

分类四:同质化代币 (ERC20) 流水与流通量 (ERC20 & Token Supply)

Q10. 热门代币(以 TSLA 为例)最新转账流水与金额解析

  • 业务场景 / 分析目标:实时监控特定代币资产的最新转移流水,提取转账双方、交易哈希与代币原始金额。
  • 使用表与依赖:robinhood.erc20_transfers
  • 运行环境与性质:🟢 生产环境只读实测 (Production Read-Only)
  • 预期成本与性能考量:token 是排序键的第一列(ORDER BY token, block_number, log_index),查询直接命中主键稀疏索引,精准定位 TSLA 数据段,耗时极短。

SQL 查询语句:

SELECT
    block_number,
    hex(tx_hash) AS tx_hash_hex,
    hex(from) AS from_hex,
    hex(to) AS to_hex,
    toString(amount) AS raw_amount_str
FROM robinhood.erc20_transfers FINAL
WHERE is_deleted = 0
  AND token = unhex('322f0929c4625ed5bad873c95208d54e1c003b2d')
ORDER BY block_number DESC, log_index DESC
LIMIT 5
SETTINGS max_threads=2, max_execution_time=60

真实执行结果示例(执行耗时: 2.399s):

72178334	073086B404882EFAF323EC8F9CC6F49E6FD736C31AC4F8178989E559569E81D9	583F0838CA0254470F293EE128E5C5FC202346AC	352771B68DA27E3BECE96EB2C8532D7FAED1DE1B	313975280110943158
72178334	073086B404882EFAF323EC8F9CC6F49E6FD736C31AC4F8178989E559569E81D9	C4F0172D6AC8DD294DD1137D047D5E1893760236	583F0838CA0254470F293EE128E5C5FC202346AC	313975280110943158
72178287	F2E362CB9AEB3A257223E9B7274E7C65638FAD29A4DDDB6E0C78B86600C79011	1521027B665FA38FA4A642991607AD708376DD7B	8366A39CC670B4001A1121B8F6A443A643E40951	591019880048593450
72178287	F2E362CB9AEB3A257223E9B7274E7C65638FAD29A4DDDB6E0C78B86600C79011	2F4579CA81717D3D61BF8B6F06571877BBE54A07	1521027B665FA38FA4A642991607AD708376DD7B	591019880048593450
72178279	752FDB208FDC8AE6CE5604378A246A6C0C4392114F4907E90EEDA0842FC9BB18	1589327304FECBEB57E035D5CA0BC77AE48B29FA	8366A39CC670B4001A1121B8F6A443A643E40951	816977463322781619

Q11. 单个代币持仓人当前余额分布与 Top 5 大户排行榜

  • 业务场景 / 分析目标:基于借贷记复式记账汇总出的余额表(erc20_balances,每 6 小时整表刷新,最多滞后一个刷新周期),查指定代币各持有者的持仓余额并排出 Top 5 巨鲸。
  • 使用表与依赖:{db}.erc20_balances & {db}.tokens
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:按 token 过滤直接命中 erc20_balances 排序键 (token, holder) 前缀,读的是预先汇总好的每持有人一行,不再对历史流水求和;结合 tokens 元数据安全换算 Decimal。

SQL 查询语句:

SELECT
    hex(b.holder) AS holder_address_hex,
    toString(b.balance) AS balance_wei_str,
    multiIf(
        tk.decimals = 18,
          divideDecimal(toDecimal256(b.balance, 18),
                        toDecimal256(toUInt256(concat('1', repeat('0', toUInt32(18)))), 18)),
        tk.decimals = 6,
          divideDecimal(toDecimal256(b.balance, 6),
                        toDecimal256(toUInt256(concat('1', repeat('0', toUInt32(6)))), 6)),
        toDecimal256(b.balance, 0)
    ) AS formatted_balance,
    tk.symbol
FROM robinhood.erc20_balances AS b
LEFT JOIN robinhood.tokens AS tk FINAL ON tk.address = b.token
WHERE b.token = unhex('0bd7d308f8e1639fab988df18a8011f41eacad73')
  AND b.holder != unhex('0000000000000000000000000000000000000000')
  AND b.balance > 0
ORDER BY b.balance DESC
LIMIT 5

⚠️ 精度陷阱:toDecimal256(amount, 18) 仅设置显示 scale,不进行除法,输出仍是整数值(例如 90236602999286000000,而非 90.24)。必须先用 divideDecimal(...) 除以 10^decimals 才能得到人类可读的小数。详见 §2.4。

真实执行结果示例(执行耗时: 0.015s):

2C56FB7AEBC0FC4DB0D8213E0A0FA712429C3E5A	90236602999286000000	90.236602999286	WETH
7DEC8663BC55F3419A130FAC7A7209B959ED8D90	27185866126536174335	27.185866126536174335	WETH
D2FF78DD27B1DF44FB69E76E1F7502C05A3CF258	21584112343026354113	21.584112343026354113	WETH
A70FC67C9F69DA90B63A0E4C05D229954574E313	18528247652010464263	18.528247652010464263	WETH
8366A39CC670B4001A1121B8F6A443A643E40951	10773313795014629015	10.773313795014629015	WETH

Q12. 代币总流通量动态对账(零地址净铸造恒等式校验)

  • 业务场景 / 分析目标:验证代币流通总量守恒:全网所有非零持仓地址余额之和必须严格等于零地址余额的相反数(即净铸造量 net minted)。
  • 使用表与依赖:{db}.erc20_balances
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:单代币全量持仓汇总,利用复式记账零和不变量(持有者之和 + 零地址 = 0)进行零误差数学检验。

SQL 查询语句:

SELECT
    hex(token) AS token_hex,
    sumIf(balance, holder != unhex('0000000000000000000000000000000000000000')) AS total_holder_balance,
    -sumIf(balance, holder = unhex('0000000000000000000000000000000000000000')) AS net_minted_from_zero,
    total_holder_balance = net_minted_from_zero AS is_invariant_conserved
FROM robinhood.erc20_balances
WHERE token = unhex('0bd7d308f8e1639fab988df18a8011f41eacad73')
GROUP BY token

真实执行结果示例(执行耗时: 0.009s):

0BD7D308F8E1639FAB988DF18A8011F41EACAD73	128040347348517530551	128040347348517530551	1

Q13. 每日热门转账代币排行榜(转账笔数、交易量、活跃用户数)

  • 业务场景 / 分析目标:分析指定自然日内转账最活跃的代币资产排名,获取其转账人次与独立地址数。
  • 使用表与依赖:{db}.daily_token_stats & {db}.tokens
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:日度预聚合表,按 day 过滤仅扫描当天记录,关联 tokens 补充 symbol,单次查询扫描量几百字节。

SQL 查询语句:

SELECT
    s.day,
    hex(s.token) AS token_hex,
    coalesce(tk.symbol, 'Unknown') AS symbol,
    s.transfers AS transfer_count,
    uniqExactMerge(s.unique_senders) AS unique_senders,
    uniqExactMerge(s.unique_receivers) AS unique_receivers
FROM robinhood.daily_token_stats AS s FINAL
LEFT JOIN robinhood.tokens AS tk FINAL ON tk.address = s.token
GROUP BY s.day, s.token, tk.symbol, s.transfers, s.unique_senders, s.unique_receivers
ORDER BY s.transfers DESC
LIMIT 5

真实执行结果示例(执行耗时: 0.004s):

2026-09-25	0BD7D308F8E1639FAB988DF18A8011F41EACAD73	WETH	5390	327	398
2026-09-25	5FC5360D0400A0FD4F2AF552ADD042D716F1D168	USDG	4489	511	522
2026-09-25	D885F14B6715DA7D91E10AAA7110254BA8E4A0E7	VIRTUAL	4003	4	4003
2026-09-25	C0D6457C16CC70D6790DD43521C899C87CE02F35	META	413	35	43
2026-09-25	7FBE55D3284889EC9FA026536444ABE7741A898A	Unknown	357	107	144

分类五:Robinhood 代币化美股专区 (Stock Tokens)

Q14. 代币化美股资产注册清单与工厂合约部署溯源

  • 业务场景 / 分析目标:查询当前已部署的代币化股票/ETF(TSLA, AAPL, NVDA, META 等)元数据、工厂合约地址、创建区块及置信度。
  • 使用表与依赖:{db}.stock_tokens
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:静态注册表极小(行数 = 链上已注册的股票/ETF 代币数,几十行量级),全表扫描开销为微秒级,通过 FINAL 去重折叠至最新元数据版本。

SQL 查询语句:

SELECT
    symbol,
    name,
    hex(address) AS token_address_hex,
    hex(factory) AS factory_hex,
    created_block,
    hex(created_tx_hash) AS created_tx_hex,
    confidence
FROM robinhood.stock_tokens FINAL
ORDER BY symbol

⚠️ 空表提示:stock_tokens 由 007_stock_tokens.sql 建表时为空表,必须先用 scripts/derived/refresh_stock_tokens.sh registry 从 TokenCreated 事件补数(见 §3.4)。补数前本查询返回 0 行 — 这不是 SQL 错误。

真实执行结果示例(本地 scratch 库,该库 stock_tokens 为未补数的空表,执行耗时: 0.004s):

(0 行:本地样本库 stock_tokens 尚未补数;全链补数后每个已注册股票代币返回一行)

Q15. 代币化美股每日铸造 (Mint) 与销毁 (Burn) 净流量统计

  • 业务场景 / 分析目标:跟踪机构/托管方净申购与净赎回规模,衡量代币化美股链上资产净流入流出。
  • 使用表与依赖:{db}.stock_token_daily_activity & {db}.stock_tokens
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:预聚合物理表 stock_token_daily_activity,按 token 和 day 维护净铸造/净销毁总量,JOIN stock_tokens 显示 symbol。

SQL 查询语句:

SELECT
    a.day,
    st.symbol,
    a.mint_count,
    toString(a.mint_volume) AS mint_volume_wei,
    a.burn_count,
    toString(a.burn_volume) AS burn_volume_wei,
    a.transfer_count,
    a.unique_holders
FROM robinhood.stock_token_daily_activity AS a FINAL
JOIN robinhood.stock_tokens AS st FINAL ON st.address = a.token
ORDER BY a.transfer_count DESC

真实执行结果示例(本地 scratch 库;该库 stock_tokens 已由 scripts/derived/refresh_stock_tokens.sh registry 补数、stock_token_daily_activity 已补算当日 —— 与 Q14 示例(未补数、0 行)不是同一个补数状态,见 §3.4;执行耗时: 0.003s):

2026-09-25	META	0	0	1	51279234350000000000	413	43
2026-09-25	TSLA	0	0	0	0	216	31
2026-09-25	NVDA	0	0	1	149082437380000000000	95	46
2026-09-25	AAPL	0	0	0	0	25	15
2026-09-25	GOOGL	0	0	0	0	21	16

分类六:DEX 去中心化交易所与流动性池 (DEX Pools & Swaps)

Q16. Uniswap V3/V4 流动性池创建清单与交易对费率分布

  • 业务场景 / 分析目标:探索链上已部署的 DEX 资金池,按协议版本、代币对、手续费率(fee)统计资金池分布。
  • 使用表与依赖:{db}.dex_pools
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:dex_pools 为 ReplacingMergeTree 表,按 block_number 倒序查询最近创建的池子,全表较小,毫秒级响应。

SQL 查询语句:

SELECT
    hex(pool_key) AS pool_key_hex,
    protocol,
    hex(token0) AS token0_hex,
    hex(token1) AS token1_hex,
    fee,
    block_number
FROM robinhood.dex_pools FINAL
ORDER BY block_number DESC
LIMIT 5

真实执行结果示例(执行耗时: 0.002s):

02F04E5D36F667BC089FFD24DC0E4C2497C1F19EDDD25197B6C2A43F3A7C376B	uniswap_v4	0000000000000000000000000000000000000000	650BF9154EDFB41AD65E316BE31FE489CCC76EB0	2500	72040869
67E083673CBDB4E26FA9D3B386CA446A3622D236CC3E760B1C134CC9DEF14644	uniswap_v4	0BD7D308F8E1639FAB988DF18A8011F41EACAD73	9C10D5D542A7FFCF47D5C7900F152825247C0A3B	8388608	72040792
978792B8E2F01CB74DFC4CEC5AEE602415A34DABB069F7730BDB31E090A56413	uniswap_v4	0000000000000000000000000000000000000000	D34EA74F01342C02A09368D2E563A34D3EE6CC28	810000	72040478
0F5B6757C733F00D7D65B7820CDBA0401D478134B3898F57D2D8AC9B0D0B981D	uniswap_v4	0000000000000000000000000000000000000000	314B0165FF44F08B821519AFE7070C4C4C8D2D9E	10000	72040451
0000000000000000000000002C56FB7AEBC0FC4DB0D8213E0A0FA712429C3E5A	uniswap_v2	0BD7D308F8E1639FAB988DF18A8011F41EACAD73	AE7A4BA92623D4513D0EF71D229D3DA9BC7AF073	0	72040327

Q17. DEX 实时大额 Swap 交易监控与买卖方向分析

  • 业务场景 / 分析目标:监控 DEX 资金池中的大额买卖换币交易,捕获滑点与交易方向(Token0 -> Token1 或 Token1 -> Token0)。
  • 使用表与依赖:{db}.dex_swaps
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:按 block_number 和 log_index 倒序抓取最新 DEX 成交记录,展示原始 Int256 amount0/amount1 符号与数值。

SQL 查询语句:

SELECT
    block_number,
    hex(tx_hash) AS tx_hash_hex,
    hex(pool_key) AS pool_key_hex,
    protocol,
    hex(sender) AS sender_hex,
    toString(amount0) AS amount0_str,
    toString(amount1) AS amount1_str
FROM robinhood.dex_swaps FINAL
ORDER BY block_number DESC, log_index DESC
LIMIT 5

真实执行结果示例(执行耗时: 0.005s):

72040999	88B70F3FEC3DEB870DE778E55503903F9BE64B06D8332124324292ACD669E531	2C9D6DF7DFBE132DE209E61C295860413BB43EC869726B1E7751B9561F34E753	uniswap_v4	8876789976DECBFCBBBE364623C63652DB8C0904	-220000000000000000	7056632526207472959300634
72040998	5CD6581047439A49FE9E97CA4739695A7248102CCF8386A3CDA7EC9B607A4FF3	0000000000000000000000003319CAF98A5C6C947CB7E6EC6D45D0A8CA090668	uniswap_v3	2A7F3D7486641C77600B9B9256132755C8AEBB4F	29734878	-2801756948188204535782
72040997	F90C96A239BFAF992200EB526927FB000171BA81D9BDD0812ADC05D049597760	9ED2C8C087CA6659DFCFE03D514C8938D4D751ACBDC812D4ECD1481EA426F1BD	uniswap_v4	8F10B468B06C6FD214B65F87778827F7D113F996	1354996448940534465064690	-656202083211172810
72040996	3AC4FE75D839D00FC69996EB42FD3CEFAF42BA18691DCCE13F6EBAF83E2A0D73	6AFCABAFA7BEC957568DE2C9265E031E1DEDE25A2B0941FCAB51BC4762AC9A6D	uniswap_v4	E03952268A04AFE16CC1B02C612478BD54D6B7A6	180352672328829853	-25314009531000000000000000
72040996	2A2E9CFAF166BA90C514F5CF75939810AAD76583BF0E8C469AEA99E697DC231E	93CC54EB4E1928E841CB8B2E488BD82E8D97D56E0AAB16CF078EF71C576DCDED	uniswap_v4	BD665831A520182E944AF92B23A317791C5D8EFA	-103819250	685138393258481682051238

Q18. 热门交易对交易频次与流动性池活跃度排行榜

  • 业务场景 / 分析目标:统计链上各个 DEX 交易对的总成交笔数与独立交易者数量,识别最核心的交易流动性池。
  • 使用表与依赖:{db}.dex_swaps
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:GROUP BY pool_key 和 protocol,聚合成交流水,可针对 block_timestamp 施加时间窗口快速筛选热门池。

SQL 查询语句:

SELECT
    hex(s.pool_key) AS pool_key_hex,
    s.protocol,
    count() AS swap_count,
    uniqExact(s.sender) AS unique_traders
FROM robinhood.dex_swaps AS s FINAL
GROUP BY s.pool_key, s.protocol
ORDER BY swap_count DESC
LIMIT 5

真实执行结果示例(执行耗时: 0.004s):

00000000000000000000000052E65B17FB6E5BA00ED806F37AFCD2DAA50271CA	uniswap_v3	536	43
8B0C0CA8C3B45B8F377C7D66A5778B4431FC3AE45390D6E5DFC3B48E482F59C4	uniswap_v4	317	4
0000000000000000000000001F46899AA5BF5911CABEE5B911C450FD709A09E7	uniswap_v3	250	2
99F1143EF8323CC044F6DD8B521D5FE871ABD4E2FB141510D35E955111C05D91	uniswap_v4	177	4
6AFCABAFA7BEC957568DE2C9265E031E1DEDE25A2B0941FCAB51BC4762AC9A6D	uniswap_v4	134	1

分类七:NFT 资产流转与持有权 (ERC721 & ERC1155)

Q19. ERC721 NFT 所有权流转历史与最新持有者追踪

  • 业务场景 / 分析目标:追踪特定 NFT 项目或特定 TokenID 从铸造到流转的完整历史轨迹,实时锁定当前最新持有者。
  • 使用表与依赖:robinhood.erc721_transfers
  • 运行环境与性质:🟢 生产环境只读实测 (Production Read-Only)
  • 预期成本与性能考量:按 block_number 倒序查询最近发生的 NFT 转移,token_id 采用 UInt256 并转为 toString() 输出,无精度截断。

SQL 查询语句:

SELECT
    block_number,
    hex(token) AS token_hex,
    toString(token_id) AS token_id_str,
    hex(from) AS from_hex,
    hex(to) AS to_hex,
    hex(tx_hash) AS tx_hash_hex
FROM robinhood.erc721_transfers FINAL
WHERE is_deleted = 0
ORDER BY block_number DESC, log_index DESC
LIMIT 5
SETTINGS max_threads=2, max_execution_time=60

真实执行结果示例(执行耗时: 4.998s):

72178337	07F44C47743A2F36414A82B9F558ECFCF0EEDCEF	190332	C14BDC429EFBD882AC7CBDF2E36CDEA9FC3941C9	BA618977FE27A4D86663867D258491E953644DA1	CAFCCF62E0F167F945B1947813F989CD5692C974FBD88D15147F3DE384C503F7
72178332	07F44C47743A2F36414A82B9F558ECFCF0EEDCEF	190445	BA003DE9B3F1C5D448E15EC7B637AD8EC943B730	FBB3F4BEF58373FF4C9D72AE309FEB76B3F985D2	9C4FF725A2C9F1167101139B4ED62926FD5713F77E70748568995058C86E421A
72178332	07F44C47743A2F36414A82B9F558ECFCF0EEDCEF	190445	0000000000000000000000000000000000000000	BA003DE9B3F1C5D448E15EC7B637AD8EC943B730	9C4FF725A2C9F1167101139B4ED62926FD5713F77E70748568995058C86E421A
72178332	07F44C47743A2F36414A82B9F558ECFCF0EEDCEF	190329	BA003DE9B3F1C5D448E15EC7B637AD8EC943B730	0000000000000000000000000000000000000000	9C4FF725A2C9F1167101139B4ED62926FD5713F77E70748568995058C86E421A
72178332	07F44C47743A2F36414A82B9F558ECFCF0EEDCEF	190329	FBB3F4BEF58373FF4C9D72AE309FEB76B3F985D2	BA003DE9B3F1C5D448E15EC7B637AD8EC943B730	9C4FF725A2C9F1167101139B4ED62926FD5713F77E70748568995058C86E421A

Q20. ERC1155 批量与单笔转账展开后的 TokenID 持仓账本

  • 业务场景 / 分析目标:ERC1155 TransferBatch 支持单条事件包含多个 TokenID 和多笔数量,展开后统计持仓地址在各 TokenID 上的有效余额。
  • 使用表与依赖:{db}.erc1155_balances
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:注意:erc1155_balances 采用基础 MergeTree 引擎(非 ReplacingMergeTree),严禁使用 FINAL;直接按主键过滤 balance > 0。

SQL 查询语句:

SELECT
    hex(token) AS token_hex,
    toString(id) AS token_id_str,
    hex(holder) AS holder_hex,
    toString(balance) AS balance_str
FROM robinhood.erc1155_balances
WHERE balance > 0
ORDER BY balance DESC
LIMIT 5

真实执行结果示例(执行耗时: 0.005s):

063BDBA5C8C29A57C6530F2668CFD040B1282118	1000	0000000000000000000000000000000000000000	1680
063BDBA5C8C29A57C6530F2668CFD040B1282118	6	EBB5C8D140910402FE68228E37DF8181D2F04FA1	4
063BDBA5C8C29A57C6530F2668CFD040B1282118	5	EBB5C8D140910402FE68228E37DF8181D2F04FA1	4
063BDBA5C8C29A57C6530F2668CFD040B1282118	7	009E27418A7F15623FB36C8958811BC362AFE36B	2
BAEEDDF7ADA7050A1078F27AB9F4A8C1A37AE9EC	22	0000000000000000000000000000000000000000	2

分类八:WETH 封装与跨链桥流量 (WETH & Bridge Flows)

Q21. WETH 跨链充值铸造 (Mint) 与销毁提现 (Burn) 流量分析

  • 业务场景 / 分析目标:分析 Robinhood Chain 上 WETH 的跨链充值(Mint)、提现销毁(Burn)与普通转账的分类流量与金额构成。
  • 使用表与依赖:{db}.erc20_transfers
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:token 命中主键第一列,multiIf 分类高效,使用 Decimal256 进行 18 位高精度金额呈现。

SQL 查询语句:

SELECT
    multiIf(
        from = unhex('0000000000000000000000000000000000000000'), 'Mint (L1->L2 Bridge In)',
        to = unhex('0000000000000000000000000000000000000000'), 'Burn (L2->L1 Bridge Out)',
        'Standard Transfer'
    ) AS transfer_category,
    count() AS transfer_count,
    toString(sum(amount)) AS total_amount_wei_str,
    divideDecimal(
        toDecimal256(sum(amount), 18),
        toDecimal256(toUInt256(concat('1', repeat('0', toUInt32(18)))), 18)
    ) AS total_amount_weth
FROM robinhood.erc20_transfers FINAL
WHERE is_deleted = 0
  AND token = unhex('0bd7d308f8e1639fab988df18a8011f41eacad73')
GROUP BY transfer_category
ORDER BY transfer_count DESC

真实执行结果示例(执行耗时: 0.006s):

Standard Transfer	3243	732460069856959386456	732.460069856959386456
Mint (L1->L2 Bridge In)	1220	224634953961802580164	224.634953961802580164
Burn (L2->L1 Bridge Out)	927	96594606613285049613	96.594606613285049613

Q22. L1→L2 跨链存款生命周期全流程串联(Retryable Ticket 创建至兑现)

  • 业务场景 / 分析目标:串联 L1 充值创建票据(type 105)与 L2 兑现执行(type 104),通过 ticket_id = submit.tx_hash 关联两笔交易,计算跨链充值延迟。
  • 使用表与依赖:{db}.bridge_deposits
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:利用 ticket_id 上的 bloom_filter 索引与 tx_type 快速过滤,两表 JOIN 规模极小。

SQL 查询语句:

SELECT
    redeem.block_number AS redeem_block,
    hex(redeem.tx_hash) AS redeem_tx_hex,
    submit.block_number AS submit_block,
    hex(submit.tx_hash) AS submit_tx_hex,
    hex(assumeNotNull(redeem.ticket_id)) AS ticket_id_hex,
    redeem.block_timestamp AS redeemed_at,
    submit.block_timestamp AS submitted_at,
    dateDiff('second', submit.block_timestamp, redeem.block_timestamp) AS bridge_delay_seconds
FROM robinhood.bridge_deposits AS redeem FINAL
JOIN robinhood.bridge_deposits AS submit FINAL
  ON redeem.ticket_id = submit.tx_hash
WHERE redeem.is_deleted = 0 AND redeem.tx_type = 104
  AND submit.is_deleted = 0 AND submit.tx_type = 105

真实执行结果示例(本地 scratch 库 bridge_deposits,覆盖块高 72039000–72286579 的真链数据;执行耗时: 0.012s,返回 1 对 type 105/104 票据):

72286551	8176F531715612D3EE4E2F4B2B8B1152DD8CB075ABB63CEC062A351E43E10440	72286551	713CF7646CC15EE5A2805456289DE6F9AF7F15B7E4C840431B8876AB5D120811	713CF7646CC15EE5A2805456289DE6F9AF7F15B7E4C840431B8876AB5D120811	2026-09-25 14:08:41	2026-09-25 14:08:41	0

Q23. 跨链桥网关每日资产净流入流出汇总

  • 业务场景 / 分析目标:分析 L2 Token Gateway 每日各类资产(WETH, USDG, 股票代币)通过官方桥存入与提取的净流量与交易笔数。
  • 使用表与依赖:{db}.bridge_daily_net_flow
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:日级别预聚合表,读取单日资产净流量仅需扫描数十字节,Int256 保证正负净流量计算无损。

SQL 查询语句:

SELECT
    day,
    hex(asset) AS asset_address_hex,
    deposits_count,
    toString(deposits_amount) AS deposits_amount_wei,
    withdrawals_count,
    toString(withdrawals_amount) AS withdrawals_amount_wei,
    toString(net_amount) AS net_flow_wei
FROM robinhood.bridge_daily_net_flow FINAL
ORDER BY day DESC

⚠️ 样本提示:bridge_daily_net_flow 只统计 官方 L2 Token Gateway 的 ERC20 存取事件(bridge_erc20_gateway_events),本地样本窗口(72039000–72286579 与 72040000–72040999)内没有该类事件,因此本查询在样本库返回 0 行;同时注意不要照抄以太坊主网的 WETH 地址(0xc02aaa…6cc2)——Robinhood Chain 的 WETH 是 0x0bd7d308…ad73(见 §2.9)。

真实执行结果示例(本地 scratch 库,该窗口内无网关事件,执行耗时: 0.004s):

(0 行:样本库 bridge_erc20_gateway_events 为空;全链范围下每个「日期 × 资产」返回一行)

分类九:合约部署、代理升级与实体标签 (Contracts, Proxies & Labels)

Q24. 新部署合约注册表与高产部署者部署行为聚类

  • 业务场景 / 分析目标:按部署者(creator)聚类统计新合约部署数量,识别链上核心项目方、工厂合约部署者或批量部署脚本。
  • 使用表与依赖:{db}.contracts
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:contracts 仅包含 status = 1 的成功创建交易,数据量小,GROUP BY creator 耗时低于 10ms。

SQL 查询语句:

SELECT
    hex(creator) AS creator_address_hex,
    count() AS deployed_contracts_count,
    min(block_number) AS first_deployment_block,
    max(block_number) AS latest_deployment_block
FROM robinhood.contracts FINAL
WHERE is_deleted = 0
GROUP BY creator
ORDER BY deployed_contracts_count DESC
LIMIT 5

真实执行结果示例(执行耗时: 0.004s):

BD2A30302709F4FBDE18F645D1469D850EAC0B2F	2	72040328	72040871
504606DBD92873F283A6A73DCD5CC095B63A2692	1	72039992	72039992
5473FCD188D4BC727C230C193AC49AAED479FB72	1	72040374	72040374
1D17B44447EA789E6D5ABA7CF88C2C767986BB01	1	72040106	72040106
2E93F678ACEAD0E71FC0A64501D99E584ECB3C8A	1	72039023	72039023

Q25. EIP-1967 可升级代理历史升级记录与当前生效逻辑合约

  • 业务场景 / 分析目标:排查某个代理合约(Proxy)什么时候升级过、由谁升级,以及当前指向的最新逻辑实现合约地址(implementation)。
  • 使用表与依赖:{db}.proxy_upgrades
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:从 proxy_upgrades 中按 proxy_address 过滤,仅扫描符合 EIP-1967 标准事件的历史升级记录。

SQL 查询语句:

SELECT
    hex(proxy_address) AS proxy_address_hex,
    event_type,
    multiIf(
        event_type = 'Upgraded',       hex(assumeNotNull(implementation)),
        event_type = 'AdminChanged',   concat(hex(assumeNotNull(previous_admin)), ' -> ', hex(assumeNotNull(new_admin))),
        event_type = 'BeaconUpgraded', hex(assumeNotNull(beacon)),
        'n/a'
    ) AS new_value_hex,
    block_number,
    block_timestamp,
    hex(tx_hash) AS tx_hash_hex
FROM robinhood.proxy_upgrades FINAL
WHERE is_deleted = 0
ORDER BY block_number DESC
LIMIT 5

⚠️ 三种事件的值列是互斥的:proxy_upgrades 一行只填 implementation(Upgraded)/ previous_admin,new_admin(AdminChanged)/ beacon(BeaconUpgraded)三者之一,另外两列为 NULL。因此不要写 WHERE implementation IS NOT NULL 过滤 — 它会把合法的 BeaconUpgraded(beacon 代理)记录整体丢掉(本链上该类记录恰好是当前唯一一条),也会漏掉 AdminChanged。按 event_type 取值,或改写为 WHERE event_type = 'Upgraded'。

真实执行结果示例(本地 scratch 库 proxy_upgrades 仅 1 条真链记录,执行耗时: 0.005s):

917F9D7D42DFED3D13DFEDA3ACE523FC7F103DFC	BeaconUpgraded	A125492ACA28449D2291F5415A818697345CFA09	72039305	2026-09-25 07:12:49	DED588777A8DAAEE9A48DF55ECF97C6CC947E3BC578BCCAD24A22F72A018B4F8

Q26. 结合地址标签字典对交互对象进行实体画像标注

  • 业务场景 / 分析目标:避免人工对照十六进制地址,通过 JOIN 地址标签字典直接解析交易双方所属官方实体(如 WETH、USDG、官方 Bridge 网关等)。
  • 使用表与依赖:{db}.transactions & {db}.address_labels
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:address_labels 仅几十行,广播字典表 LEFT JOIN,对 transactions 性能几乎无影响。

SQL 查询语句:

SELECT
    t.block_number,
    hex(t.hash) AS tx_hash_hex,
    hex(t.from) AS from_hex,
    if(lbl_from.label = '', 'Unknown EOA/Contract', lbl_from.label) AS from_label,
    hex(assumeNotNull(t.to)) AS to_hex,
    if(lbl_to.label = '', 'Unknown Contract', lbl_to.label) AS to_label,
    if(lbl_to.category = '', 'unknown', lbl_to.category) AS to_category
FROM robinhood.transactions AS t FINAL
LEFT JOIN robinhood.address_labels AS lbl_from FINAL ON t.from = lbl_from.address
LEFT JOIN robinhood.address_labels AS lbl_to FINAL ON t.to = lbl_to.address
WHERE t.is_deleted = 0
  AND t.to IS NOT NULL
  AND lbl_to.label != ''
ORDER BY t.block_number DESC
LIMIT 5

⚠️ ClickHouse 非空 String 陷阱:address_labels.label 是非 Nullable 的 String,LEFT JOIN 不匹配时填充 ''(空串)而非 NULL;IS NOT NULL 条件永远为真(不过滤),coalesce 也不会触发后备值。必须用 != '' 过滤和 if(x = '', 'fallback', x) 提供后备,与 Q6 的模式保持一致。

真实执行结果示例(本地 scratch 库 72040000–72040999 窗口,执行耗时: 0.016s;该窗口内被标注的 to 全部是 ArbOS 系统发送地址):

72040999	B7193E892D042484B29D7AB074DC8AF67D0AFAFF639D9C89CCF50254BC473582	00000000000000000000000000000000000A4B05	ArbOS system sender (internal-tx from/to)	00000000000000000000000000000000000A4B05	ArbOS system sender (internal-tx from/to)	system
72040998	DA0ECF0C21D784C898A4A3D723FAC52220BAC456F6C39931D87724F5FECF51C3	00000000000000000000000000000000000A4B05	ArbOS system sender (internal-tx from/to)	00000000000000000000000000000000000A4B05	ArbOS system sender (internal-tx from/to)	system
72040997	47DBDDA528C75BBC4E3AA945E5C61AB17909DF3856FD1AA2CF8A4FD55E66BCF9	00000000000000000000000000000000000A4B05	ArbOS system sender (internal-tx from/to)	00000000000000000000000000000000000A4B05	ArbOS system sender (internal-tx from/to)	system
72040996	BBF9091C5DDA83FE7147E2A514C5AC145B8F89283899E24500B7B18D4B2038F0	00000000000000000000000000000000000A4B05	ArbOS system sender (internal-tx from/to)	00000000000000000000000000000000000A4B05	ArbOS system sender (internal-tx from/to)	system
72040995	700D0A24FDB72FF5311C223DB2ADBBD7A1EE42769426A03F9EFF1CC6D4AF5D7C	00000000000000000000000000000000000A4B05	ArbOS system sender (internal-tx from/to)	00000000000000000000000000000000000A4B05	ArbOS system sender (internal-tx from/to)	system

分类十:授权安全、事件监控与深层调用轨迹 (Approvals, Events & Traces)

Q27. 高危/无限额 ERC20 授权 (Unlimited Approval) 监控与授权大户排查

  • 业务场景 / 分析目标:监控用户授权给第三方协议(Spender)的无限额授权(value >= 2^255),提示潜在资产暴露风险。
  • 使用表与依赖:{db}.erc20_approvals
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:利用 bitShiftLeft(toUInt256(1), 255) 进行位运算过滤,无需浮点转换,直接筛选高危授权记录。

SQL 查询语句:

SELECT
    hex(token) AS token_hex,
    hex(owner) AS owner_hex,
    hex(spender) AS spender_hex,
    toString(value) AS raw_allowance_str,
    value >= bitShiftLeft(toUInt256(1), 255) AS is_unlimited_or_max,
    block_number,
    hex(tx_hash) AS tx_hash_hex
FROM robinhood.erc20_approvals FINAL
WHERE is_deleted = 0
  AND value >= bitShiftLeft(toUInt256(1), 255)
ORDER BY block_number DESC
LIMIT 5

真实执行结果示例(执行耗时: 0.005s):

ABADAFC3404EE07B78DD8EC4D141F07EBB2654CD	FB5B10615A2008C6507D9FA02A55310159969F1E	7EAF2DB390B7A68FFD6586BDE156138D683E748C	115792089237316195423570985008687907853269984665640564039457584007913129639935	1	72040999	016536A80B8280C4AC66206A445FCF29264342DAAA3C6727FD333AE8629A5575
ABADAFC3404EE07B78DD8EC4D141F07EBB2654CD	FEFE306EB0E5EAF0D6821A1D2935FFC5CFA8CC1B	7EAF2DB390B7A68FFD6586BDE156138D683E748C	115792089237316195423570985008687907853269984665640564039457584007913129639935	1	72040997	9270A0B352CFF581269F887E24FE132A7AC9935A6C1E3730F99B93EC168D1FAA
ABADAFC3404EE07B78DD8EC4D141F07EBB2654CD	E4A727D2CCA580D95E52D55930F6AAC12EC61075	7EAF2DB390B7A68FFD6586BDE156138D683E748C	115792089237316195423570985008687907853269984665640564039457584007913129639935	1	72040997	93FE70F32F709BF865797C829191EB4469CE71A75F614E1B5B156E47F1CE0CA8
73C2E594371F11AD5C057EDAD727D5273B3499CA	7642F1837F5347B157883322713FFCBCC60AA311	000000000022D473030F116DDEE9F6B43AC78BA3	115792089237316195423570985008687907853269984665640564039457584007913129639935	1	72040994	B078FE9F861714EBA2DF6486ACACC3AB8B97E93CE624F248118E5BB3738E2474
34C00991F46B21D5CF5EAC72F612A390A1C5E01F	48AD7AEA7A5365CC89EE4E075246B4D6349BFB2F	CA651C9232FB2C9F3DCBCAD1043B29B2B5833106	115792089237316195423570985008687907853269984665640564039457584007913129639935	1	72040988	33A8BDA5529440FD2B7E5A7FE37B4A26200AD8FA6C10747B1FEA3A5D8CCFB1B2

Q28. 全链最活跃事件签名 Top 5 及其可读 ABI 定义

  • 业务场景 / 分析目标:统计链上发生频次最高的 Topic0,关联事件签名参考字典获取具名事件名称与参数结构,快速定位链上热点活动。
  • 使用表与依赖:{db}.logs & {db}.event_signatures
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:注意:event_signatures 是普通 MergeTree 静态字典,禁止加 FINAL;logs FINAL 聚合后关联字典,开销仅在 logs 聚合端。

SQL 查询语句:

SELECT
    hex(l.topic0) AS topic0_hex,
    if(e.name = '', 'Unknown Event', e.name) AS event_name,
    if(e.signature = '', 'N/A', e.signature) AS event_signature,
    if(e.source = '', 'custom', e.source) AS event_source,
    count() AS event_occurrences
FROM robinhood.logs AS l FINAL
LEFT JOIN robinhood.event_signatures AS e ON l.topic0 = e.topic0
WHERE l.is_deleted = 0 AND l.topic0 IS NOT NULL
GROUP BY l.topic0, e.name, e.signature, e.source
ORDER BY event_occurrences DESC
LIMIT 5

⚠️ ClickHouse 非空 String 陷阱:event_signatures.name/signature/source 均为非 Nullable String;LEFT JOIN 不匹配时填 '' 而非 NULL,coalesce 不会触发后备值。必须用 if(x = '', 'fallback', x) 模式,与 Q6 对 method_selectors 的处理保持一致。

真实执行结果示例(执行耗时: 0.01s):

DDF252AD1BE2C89B69C2B068FC378DAA952BA7F163C4A11628F55A4DF523B3EF	Transfer	Transfer(address,address,uint256)	ERC20/ERC721	24035
8C5BE1E5EBEC7D5BD14F71427D1E84F3DD0314C0F7B2291E5B200AC8C7C3B925	Approval	Approval(address,address,uint256)	ERC20/ERC721	3431
40E9CECB9F5F1F1C5B9C97DEC2917B7EE92E57BA5563708DACA94DD84AD7112F	Swap	Swap(bytes32,address,int128,int128,uint160,uint128,int24,uint24)	UniswapV4	2773
C42079F94A6350D7E6235F29174924F928CC2AC818EB64FED8004E115FBCCA67	Swap	Swap(address,address,int256,int256,uint160,uint128,int24)	UniswapV3	2451
37E7F0DB430EDC9DD31BC66F25F8449353AA0818F503B906747DD8F286CD3802	Unknown Event	N/A	custom	1484

Q29. 内部调用轨迹 (Traces) 深度异常调用排查与失败 Revert 定位

  • 业务场景 / 分析目标:透过顶层交易回执查看内部子调用(call / delegatecall / staticcall),定位深层调用中的 revert 原因与调用栈深度。
  • 使用表与依赖:robinhood.traces
  • 运行环境与性质:🟢 生产环境只读实测 (Production Read-Only)
  • 预期成本与性能考量:主键范围扫描(ORDER BY block_number, tx_index, trace_address),仅读取指定区块段内部帧,精确命中 Delta+ZSTD 压缩块。

SQL 查询语句:

SELECT
    block_number,
    hex(tx_hash) AS tx_hash_hex,
    depth,
    call_type,
    hex(from) AS from_hex,
    hex(assumeNotNull(to)) AS to_hex,
    toString(value) AS value_wei_str,
    gas_used,
    error
FROM robinhood.traces FINAL
WHERE is_deleted = 0
  AND block_number >= 72051000 AND block_number < 72051010
ORDER BY block_number, tx_index, depth
LIMIT 5
SETTINGS max_threads=2, max_execution_time=60

真实执行结果示例(执行耗时: 2.145s):

72051000	0446A34EF60A30F8F6BEC8718E8497AF7717BFB1427119BEB9AD5C37B36AB65D	0	CALL	00000000000000000000000000000000000A4B05	00000000000000000000000000000000000A4B05	0	0	
72051000	0446A34EF60A30F8F6BEC8718E8497AF7717BFB1427119BEB9AD5C37B36AB65D	1	CALL	FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE	0000F90827F1C53A10CB7A02335B175320002935	0	8492	
72051000	0446A34EF60A30F8F6BEC8718E8497AF7717BFB1427119BEB9AD5C37B36AB65D	2	STATICCALL	0000F90827F1C53A10CB7A02335B175320002935	0000000000000000000000000000000000000064	0	803	
72051000	FE2BFA6F280F7FCBFD94F1D15DA0069FE0C9834879149FCA16ED278D93CC3983	0	CALL	20AA7E1E24B87E2EBB5C8487157044AC07E33B91	E03952268A04AFE16CC1B02C612478BD54D6B7A6	0	130407	
72051000	FE2BFA6F280F7FCBFD94F1D15DA0069FE0C9834879149FCA16ED278D93CC3983	1	STATICCALL	E03952268A04AFE16CC1B02C612478BD54D6B7A6	0BD7D308F8E1639FAB988DF18A8011F41EACAD73	0	9787

Q30. 新合约部署溯源(包含部署交易哈希与初始化代码长度)

  • 业务场景 / 分析目标:溯源新合约的部署过程,提取部署者、初始化字节码长度(input 长度)以及部署交易哈希。
  • 使用表与依赖:{db}.contracts & {db}.transactions
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)
  • 预期成本与性能考量:contracts 与 transactions 通过 hash 关联,仅涉及少量部署交易,轻量快速。

SQL 查询语句:

SELECT
    c.block_number,
    hex(c.address) AS deployed_contract_hex,
    hex(c.creator) AS creator_hex,
    hex(c.creation_tx_hash) AS creation_tx_hex,
    c.via,
    length(t.input) AS init_code_length_bytes
FROM robinhood.contracts AS c FINAL
LEFT JOIN robinhood.transactions AS t FINAL ON c.creation_tx_hash = t.hash
WHERE c.is_deleted = 0
ORDER BY c.block_number DESC
LIMIT 5

真实执行结果示例(执行耗时: 0.016s):

72040871	B5F0612EFC5D5EF0E16E3BA1ED6AFB6B7E67429B	BD2A30302709F4FBDE18F645D1469D850EAC0B2F	0DA3BD480A619E41B30B9186B7E597F6EEF5A387B2E4BB29FE67E8B04C6C1D21	tx	16809
72040374	611CB250B831C791765A864AE690E83C031D3FB7	5473FCD188D4BC727C230C193AC49AAED479FB72	CE358A89D21937AEFDFEA85D27F34442DE186D7190D95F39B480FD159114C9BC	tx	23421
72040328	F59580BE27AB1A8041A8053351F5D42622D2A462	BD2A30302709F4FBDE18F645D1469D850EAC0B2F	B2491E3016667822AA5EC61254927C9C8E39456C090F19A2F8893AB50693FD22	tx	8609
72040221	FCB2963337AE428FE40B4A0D96C8DD6115CE1AD7	251E39FB07D89C3A7C5F75ED82304F5EEB15E4F9	DCC046F6BA14BFA032CFB271895057049B85E7B803241B8611C8720615760576	tx	3717
72040106	64446BDDEEFCB2A7B73A491BB0EFD81DC2271D9F	1D17B44447EA789E6D5ABA7CF88C2C767986BB01	40E66C1F11C166EECD2EF49FF168675251B319400A3E16FC029CD3C9A72C18BA	tx	7439

分类十一:地址维度转账流水 (Address-Centric Transfers)

Q31. 任意地址的 ERC20 / ERC721 全量转账流水(holder 派生表)

  • 业务场景 / 分析目标:给定任意地址(EOA / 池子 / 路由 / 市场做市商),拉取它参与过的全部转账(作为 from 或 to),输出方向、对手方、token、原始金额、交易哈希与时间;用于资金追踪、风控调查、客服对账。地址规模从十几行到上亿行都要能查。
  • 使用表与依赖:{db}.erc20_transfers_by_holder / {db}.erc721_transfers_by_holder(035_transfers_by_holder.sql,每笔转账落 2 行:direction = 0 表示该地址是 from(转出),direction = 1 表示是 to(转入);自转两行都在)。
  • 运行环境与性质:🔵 本地 Scratch 验证实测 (Local Verified)——表尚未安装到 robinhood(安装入口 scripts/derived/install_all.sh <db> [--backfill],见 §3)。
  • 预期成本与性能考量:holder 是 ORDER BY 首位,查询是一次键范围读;必须 FINAL + is_deleted = 0(ReplacingMergeTree,reorg/tombstone 与原表逐行同步)。dev 服务器(CH 26.9.1,max_threads=4)实测五个全历史地址:count() 0.05-2.60 s、最新 50 条(含 payload)0.07-0.13 s;同一批查询直接打 erc20_transfers FINAL,在 289.6M 行(18.9%)样本上是 8.6-15.0 s/次(该表的 from/to bloom_filter 在 FINAL 下不剪枝,等价全表扫描),在全表(robinhood 2.78B 物理行 / 72.97 GiB,2026-09-26 复测)上是 115-137 s/次——这正是本派生表存在的理由。分页建议再带 block_number 游标下界(实测 0.02-0.04 s)。

SQL 查询语句(ERC20:最新 5 条 + 全量计数):

-- {db} 替换为实际库名(生产是 robinhood;035 尚未安装到 robinhood,示例输出来自 scratch 库 holder_bench)
-- ① 最新 5 条(分页时把 block_number 游标下界放进 WHERE,并 ORDER BY block_number DESC, log_index DESC)
SELECT
    block_number,
    log_index,
    if(direction = 0, 'out', 'in') AS direction,
    hex(counterparty) AS counterparty_hex,
    hex(token) AS token_hex,
    toString(amount) AS raw_amount_str,
    hex(tx_hash) AS tx_hash_hex,
    block_timestamp
FROM {db}.erc20_transfers_by_holder FINAL
WHERE is_deleted = 0
  AND holder = unhex('caf681a66d020601342297493863e78c959e5cb2')
ORDER BY block_number DESC, log_index DESC
LIMIT 5
SETTINGS max_threads=4;

-- ② 全量计数(+ 首末区块,用同一个键范围)
SELECT count() AS transfers, min(block_number) AS first_block, max(block_number) AS last_block
FROM {db}.erc20_transfers_by_holder FINAL
WHERE is_deleted = 0
  AND holder = unhex('caf681a66d020601342297493863e78c959e5cb2')
SETTINGS max_threads=4;

真实执行结果示例(scratch 库 holder_bench,与 robinhood 同结构;地址 caf681a6…5cb2 全历史 1.15 亿笔,执行耗时: 0.13s / 2.60s):

72853165	2	out	8A207F8A985B7996D9CD4AF6469EB1768BC920C3	0BD7D308F8E1639FAB988DF18A8011F41EACAD73	29700000000000000	63B2EE477994FDA95151DE8E959947B762DBC127D1ED0C13E01CF606A696918A	2026-09-26 06:01:06
72853165	1	in	0000000000000000000000000000000000000000	0BD7D308F8E1639FAB988DF18A8011F41EACAD73	29700000000000000	63B2EE477994FDA95151DE8E959947B762DBC127D1ED0C13E01CF606A696918A	2026-09-26 06:01:06
72853163	15	out	94BBE853481F40D049D98EB830C57276D9727E5B	0BD7D308F8E1639FAB988DF18A8011F41EACAD73	199000000000000000	EE6B569BA49B189EDE2AC68049DA5814ECA71B369CDFF65BCC2B40945CA15A3D	2026-09-26 06:01:06
72853163	14	in	0000000000000000000000000000000000000000	0BD7D308F8E1639FAB988DF18A8011F41EACAD73	199000000000000000	EE6B569BA49B189EDE2AC68049DA5814ECA71B369CDFF65BCC2B40945CA15A3D	2026-09-26 06:01:06
72853157	10	out	5CF061D6CCFF58E95D219D26295B73207ED38B66	0BD7D308F8E1639FAB988DF18A8011F41EACAD73	225525079999428180	9A5FBCFC9BCA7E84077FFD5B877DBBDF2D6E4BDCDAD60E7B5D6582518F8A4EFC	2026-09-26 06:01:05
115405086	58821	72853165

SQL 查询语句(ERC721:NFT 流转,token_id 替代 amount):

-- {db} 同上(生产 robinhood 尚未安装;示例输出来自 scratch 库 holder_bench)
SELECT
    block_number,
    log_index,
    if(direction = 0, 'out', 'in') AS direction,
    hex(counterparty) AS counterparty_hex,
    hex(token) AS token_hex,
    toString(token_id) AS token_id_str,
    hex(tx_hash) AS tx_hash_hex
FROM {db}.erc721_transfers_by_holder FINAL
WHERE is_deleted = 0
  AND holder = unhex('2b5b35ac5a2d5c1224337ba86bf3816abee69da3')
ORDER BY block_number DESC, log_index DESC
LIMIT 5
SETTINGS max_threads=4;

SELECT count() AS transfers FROM {db}.erc721_transfers_by_holder FINAL
WHERE is_deleted = 0
  AND holder = unhex('2b5b35ac5a2d5c1224337ba86bf3816abee69da3')
SETTINGS max_threads=4;

真实执行结果示例(执行耗时: 0.06s / 0.04s):

72842703	35	in	0000000000000000000000000000000000000000	F3DB4C7E01135B65FF1171481AFE3F6D099A8548	738	483C4E0614945E5C64639DC07C0604777A2F080C63F7CAE88B208BECE72F6F79
72842703	34	in	0000000000000000000000000000000000000000	F3DB4C7E01135B65FF1171481AFE3F6D099A8548	737	483C4E0614945E5C64639DC07C0604777A2F080C63F7CAE88B208BECE72F6F79
72842703	33	in	0000000000000000000000000000000000000000	F3DB4C7E01135B65FF1171481AFE3F6D099A8548	736	483C4E0614945E5C64639DC07C0604777A2F080C63F7CAE88B208BECE72F6F79
72842703	32	in	0000000000000000000000000000000000000000	F3DB4C7E01135B65FF1171481AFE3F6D099A8548	735	483C4E0614945E5C64639DC07C0604777A2F080C63F7CAE88B208BECE72F6F79
72842703	31	in	0000000000000000000000000000000000000000	F3DB4C7E01135B65FF1171481AFE3F6D099A8548	734	483C4E0614945E5C64639DC07C0604777A2F080C63F7CAE88B208BECE72F6F79
488942

为什么不能直接用 erc20_transfers:该表 ORDER BY (token, block_number, log_index),from/to 只有 bloom_filter 跳数索引,而 CH 26.9 下只要查询带 FINAL 就完全不做 granule 剪枝(实测同一地址:不带 FINAL 读 928/35,395 granule、44 ms;带 FINAL 读满 35,395/35,395、9.7 s),所以任何地址(哪怕只有 15 行)都是一次全表扫描。holder 派生表把地址放在排序键首位,才是"地址维度"查询的正解;全量磁盘代价约 92-94 GiB(ERC20)+ 2.61 GiB(ERC721,merge 收敛后口径;源表重建窗口镜像瞬时峰值 165-185 GiB,历史回填按 5,000,000 区块分段执行、可续跑),实测见 docs/perf/2026-09-26-holder-lookup.md。


5. 验证基线与执行总结

本手册包含的全部 31 个查询均在真实数据上执行通过(Q31 用本地 scratch 库的 holder 派生表实测,表尚未安装到生产 robinhood,安装入口见 §3),示例输出逐字粘贴自实际运行结果;样本区间内确实为空的表,示例处已显式标注「0 行」并给出补数路径,而不是伪造行。其中 Q1/Q22/Q25/Q26 的示例已用本地 scratch 库(或生产只读)重新执行并逐字替换为当前输出,Q14/Q23 因样本库为空改为如实标注 0 行。本轮(2026-09-25)复核另修正了 4 处解释性文字与 1 个数值:§2.10 的 1998-07-09 归因(本地测试块,不是链上零时间戳块)、§3 的「当天数据」说明(派生表只装已闭市自然日,刷新不出当天行)、Q4 的 DAU 数值(3892 → 3891,排除 ArbOS 系统发送地址后的口径)以及本节下面的样本库区间/行数与 Q14/Q15 补数状态:

  • 生产只读环境(5 个代表性查询:Q1, Q7, Q10, Q19, Q29):
    • 严格遵守 SETTINGS max_threads=2, max_execution_time=60 资源配额;
    • 涵盖区块微观节律、超大额原生转账、TSLA 股票代币流水、NFT 所有权流转以及深度 Traces 异常调用帧。
  • 本地 Scratch 环境(其余 25 个衍生集查询):
    • 在独立的 scratch 库中加载真链数据后执行:主样本库覆盖块高 72039000–72040999(按 FINAL + is_deleted = 0 实测:blocks 2000 行 / transactions 12026 行 / erc20_transfers 23599 行)并应用派生 SQL,跨链与代理类查询使用覆盖 72039000–72286579 的补充 scratch 库;
    • 该主样本库另外手工插入过 4 个本地测试块 900000000–900000003(timestamp = 块号),它们就是各示例里 1998-07-09 那两行的来源(见 §2.10;生产库 number >= 800000000 实测 0 行,不存在这些数据);
    • 因此示例里的 2000 块 / 12026 笔 / 3892 个发包地址等数值对应的是整段 72039000–72040999,而不是 72040000–72040999 的子区间(后者实测只有 1000 块 / 5973 笔 / 13333 笔 ERC20 转账)——照抄子区间会得到一半量级的数字;
    • Q14 与 Q15 依赖 stock_tokens 的补数状态:Q14 的示例取自已建表但未补数的库(0 行),Q15 的示例取自已跑过 scripts/derived/refresh_stock_tokens.sh registry 的库(见 §3.4);
    • 涵盖吞吐监控、DAU/留存、失败交易排查、方法选择器字典、L1/L2 费用分摊、持仓复式账本与零和不变量校验、代币化股票注册与流量、DEX 资金池/Swap 流水、ERC1155 展平账本、WETH 流量、跨链桥票据兑现链路、代理升级识别与高危授权监控;
    • 所有金额与 Gas 计算保持无损整数与 Decimal256,所有地址与哈希使用 raw bytes,完全遵循 Cardinal Rules。
    • 已知空表样本:stock_tokens(未补数时 Q14/Q15 均为 0 行,需先跑 scripts/derived/refresh_stock_tokens.sh,见 §3.4)、bridge_erc20_gateway_events / bridge_daily_net_flow(Q23,样本窗口内无官方网关事件)在样本库中为 0 行,示例已如实标注;
    • 当天/近期窗口的说明:Q2 的分钟桶须在追链到链头时捕获(吞吐 MV 只覆盖最近 15 分钟/6 小时,回填切片为 0 行);Q3/Q4/Q8/Q9/Q13 的 2026-09-25 样本由「去掉 < today() 谓词、按固定日期跑 MV body / 014 refresh 语句」得到,派生表本身要到 UTC 闭市(01:00 UTC 之后)才有当天行 —— 详见 §3。

6. 生产库性能基线与改写建议(2026-09-26 实测)

全量库实测(72.7M 区块 / 828M 交易 / 3.43B 日志,dev 5.9.43.222)见 docs/perf/2026-09-26-query-baseline.md(含逐条 server_ms / read_rows / read_bytes、慢查询清单与磁盘估算)。四条硬结论:

  1. sql/indexes.sql 的 6 个 bloom_filter GRANULARITY 1 索引已于 2026-09-26 03:32–03:34 UTC 在生产/dev 全量库落地(实测总占用 1.79 GiB、全程 87 s,MATERIALIZE INDEX 只新增索引文件、不需要维护窗口)。但点查并未因此变成"点查":索引生效后按 hash 查一笔交易仍要 16.5s(5,596 万行),按 tx_hash 查日志 5.8s(2.40 亿行)——bloom 对近似唯一列只有 ~15x 行剪枝(granule 口径 42–43x);要亚秒级必须再加窄派生表:(hash, block_number, tx_index) ≈27 GB、(tx_hash, block_number, log_index) ≈18–38 GB(均全历史口径,或先做热窗口 2.6 GB / 0.16–0.35 GB 每天,见基线文档 §7.2)。
  2. 大表查询一律带 block_number 范围/下界——block_timestamp 不在 transactions/logs/erc20_transfers 的排序键里,按时间过滤 = 全表扫描。实测"按时间查 1 小时区块" 2,307 ms → 改按块号 8 ms;"某地址交易 LIMIT 50" 17,757 ms → 加 24h 块号下界 74 ms。
  3. bloom_filter 对稠密值无效:热点合约地址、Transfer(占全表 46.6%)、V3/V4 Swap(5% 上下)这类值在每个 granule 都有命中,剪枝率为 0(本机实测:稀疏地址少读 4.6–16x,稠密地址 0%)。实测最忙 EOA 的 from OR to 只剪掉 35% granule、count() 反而从 7.2s 变成 9.3s。这类查询只能靠"限定区块范围"或按该列排序的窄派生表/projection。
  4. ⚠️ erc20_transfers/erc721_transfers 已被全量重建(2026-09-26,window 2 步骤 1):从 1,267 万 / 64 万行涨到 15.35 亿行 / 40.55 GiB 和 7,236 万行 / 1.25 GiB。重建前那些"秒级/毫秒级"的读数全部作废——现在:某 holder 的 from/to 全量转账 120 s 超时(E159)、Q21 WETH 全历史 36.0 s、单代币单日按 block_timestamp 过滤 58.1 s、Q19 erc721_transfers 无过滤取 5 行 2.8 s;加 block_number 范围/下界后回到 0.4–3.1 s(实测:holder 近 5.7–5.9 h 3.1 s、真 24h 0.8–1.1 s、ERC721 加块号下界 0.44 s、Q21 限 1 天 1.85 s)。按 token 前缀查仍然快(Q10 0.16 s、单代币单日按块号 1.47 s)。见基线文档 §5/§11.2。

⚠️ 派生表可跑性(这条是移动靶,务必看时间戳):04:02 UTC 时 23/30 条查询在 dev 全量库跑不了(daily_* / throughput_* / dex_* / stock_* / bridge_* / contracts 等派生表未安装,报 UNKNOWN_TABLE);05:17 UTC install_all.sh --backfill(window 2 步骤 4)开始落地,05:58 / 06:03 UTC 两次复核:26/30 可解析,仍缺 throughput_minute(Q2)、erc20_balances(Q11/Q12)、proxy_upgrades(Q25);但已建出的表里 daily_fee_*/bridge_*/daily_active_addresses/stock_* 仍是 0 行(回填未完成;步骤 4 在 05:53:59 短暂暂停、05:57:25 UTC 已恢复)——现在既不能说"跑不了",也不能说"已就绪"。安装入口:scripts/derived/install_all.sh <db> [--backfill],应放维护窗口执行;补测清单见基线文档 §9/§11.3。

6.1 改写版查询(0 磁盘成本,可直接用)

时间↔块号映射(blocks 是全库唯一的时间索引;一次 0.6s,可缓存或物化成小时/天级小表):

-- ① 先求时间窗对应的块号范围(示例:2026-09-26 02:00–03:00 UTC)
SELECT min(number) AS min_block, max(number) AS max_block
FROM robinhood.blocks FINAL
WHERE is_deleted = 0
  AND timestamp >= toDateTime('2026-09-26 02:00:00', 'UTC')
  AND timestamp <  toDateTime('2026-09-26 03:00:00', 'UTC');
-- → 72710510 / 72746055(闭区间、含两端;2026-09-25 UTC 全天 = 71782334..72639310)
-- ② 按时间查区块:不要按 timestamp 过滤(实测 2.31s / 7,022 万行),改用块号范围(8ms / 6.8 万行)
SELECT number, timestamp, tx_count FROM robinhood.blocks FINAL
WHERE is_deleted = 0 AND number >= 72710510 AND number <= 72746055   -- = ① 的 min_block .. max_block
ORDER BY number DESC
LIMIT 100;
-- ③ 某地址的交易(docs/queries.md 例1 改写版):加"最近 24h"块号下界
--    实测 17,757ms(2.21 亿行)→ 74ms(53 万行);"全部交易 count()" 8,993ms → 173ms
--    ⚠️ 下界用 ① 现场算出的 min_block,不要写死:71782334 是 2026-09-25 UTC 00:00 起点,
--       窗口 B(09-26 03:55 UTC)实测时它实际覆盖 ≈27.9 h;日期一变它就不再是"最近 24h"(会越查越多),这里只是示例值
SELECT block_number, hex(hash) AS tx_hash_hex, hex(`from`) AS from_hex, hex(`to`) AS to_hex,
       toString(value) AS value_str, status
FROM robinhood.transactions FINAL
WHERE (`from` = unhex('<addr>') OR `to` = unhex('<addr>'))
  AND is_deleted = 0
  AND block_number >= 71782334          -- ← 只加这一行:最近 N 天/小时的块号下界
ORDER BY block_number DESC
LIMIT 50;
-- ④ 某代币单日转账:token 前缀 + 块号范围(排序键 (token, block_number, log_index) 对齐)
SELECT count() AS n
FROM robinhood.erc20_transfers FINAL
WHERE is_deleted = 0
  AND token = unhex('0bd7d308f8e1639fab988df18a8011f41eacad73')
  AND block_number >= 71782334 AND block_number < 72639311   -- 2026-09-25 UTC
-- ⑤ 某合约在时间窗内的日志:同样先转成块号范围(1 小时窗实测 7ms)
SELECT count() AS n
FROM robinhood.logs FINAL
WHERE is_deleted = 0
  AND address = unhex('0bd7d308f8e1639fab988df18a8011f41eacad73')
  AND block_number >= 72710510 AND block_number < 72746056
-- ⑥ 按哈希查交易 / 按 tx_hash 查日志
--    现状(`sql/indexes.sql` 已落地):bloom 只有 ~15x 行剪枝(granule 口径 42–43x),仍未到点查量级——
--    实测:按 hash 查交易 16.5s / 5,596 万行;按 tx_hash 查日志 5.8s / 2.40 亿行(max_threads=4)
--    ✅ 实用做法:先拿到(已知的)块高,再叠加 block_number 下界收窄。实测(窗口 B,索引生效,
--       样本 hash `3734cfe2…` 真实块高 71,903,499,下界取 71,000,000):
--         transactions count() 0.040s / 126 万行;SELECT * 0.45s / 126 万行 / 1.50 GB
--         logs         count() 0.073s / 478 万行;取 5 行日志 0.11s / 268 MB
--       下界越贴近真实块高越省。要稳定亚秒级仍需窄派生表(见基线文档 §7.2)
--    ⚠️ 下界必须 ≤ 交易真实块高:下界猜大了会返回 0 行,那是"范围不对"而不是"交易不存在";
--       (实测反例:同一样本用下界 72,000,000 → 0.024s 返回 0 行,而它其实存在)
--       不确定块高时先按 ① 缩小时间窗,或接受一次全表扫描
SELECT * FROM robinhood.transactions FINAL
WHERE hash = unhex('<tx_hash>') AND is_deleted = 0
  AND block_number >= 71000000;                -- ← 用已知(非估计)且 ≤ 真实块高的下界收窄;示例 hash 真实块高 71,903,499
-- ⑦ 某地址(holder)的 ERC20 转账:表已被全量重建为 15.35 亿行,**全历史** from/to 过滤会跑满 120s
--    (E159 超时,读 10 亿行 / 82 GB 仍未扫完);加"最近 N 天"块号下界后实测 3.1s(read 1,469 万行 / 1.29 GB)
--    ⚠️ 下界必须用 ① 现场算出的 min_block,不要写死;示例值 72,639,311 是 **2026-09-26 00:00 UTC** 的起点,
--       只覆盖到 2026-09-26 05:53 UTC 那次测量的 ~5.9 小时(该窗口只有该 holder 24h 转账量的 ~35%)。
--       真 24h(下界 71,983,710 = 2026-09-25 05:39 UTC)实测 1.05s / 2,351 万行 / 1.75 GiB(返回 424,034 笔)。
SELECT block_number, hex(tx_hash) AS tx_hash_hex, hex(token) AS token_hex,
       toString(amount) AS amount_str, hex(`from`) AS from_hex, hex(`to`) AS to_hex
FROM robinhood.erc20_transfers FINAL
WHERE is_deleted = 0
  AND (`from` = unhex('<addr>') OR `to` = unhex('<addr>'))
  AND block_number >= 72639311                 -- ← 只加这一行:最近 N 天/小时的块号下界(示例 = 09-26 00:00 UTC,不是"昨天全天")
ORDER BY block_number DESC
LIMIT 50;

6.2 例外:派生表查询

Q2–Q4、Q6、Q8/Q9、Q11–Q18、Q20、Q22–Q28、Q30 依赖派生表,不要为了"优化"把它们的逻辑改回原始表全扫(实测见 docs/perf/2026-09-26-query-baseline.md §4/§10:全历史 topic0 排行 67s→静默 16s、全历史 Swap 日志 32s→8.8s、单日方法选择器分布 2.7s→2.0s 且要读 6.9 GB 的 input 列)。正确姿势仍是:

  • daily_* / throughput_*:闭市后由可刷新 MV 幂等重算(见 §3.2),查询直接读结果表;
  • 地址/合约维度的重查询:等 scripts/derived/install_all.sh 补齐后再评估是否新增窄派生表(按 (address, block_number) / (holder, block_number) 只存 3–6 列),不要急着在全量库上建 projection——磁盘口径要按现测值算:2026-09-26 05:54 UTC 磁盘余量 313.8 GiB / 65.3% 已用(04:00 UTC 的 76 GB / 92% 是节点裁剪历史之前的值,已作废;06:27 UTC 复核 df -h / 已降到 276 G 可用 / 70%,回填仍在跑),但 install_all.sh --backfill 的 Phase 2 还没跑完(window 2 预算 +172 GB),扣掉回填预留后 ≈140 GiB。据此:logs 侧 projection ≈80 GB(预留后 57%)、transactions 单方向 ≈30 GB、hash 窄派生表 ≈27 GB(预留后 19%,或先做热窗口 ≈2.6 GB)、logs 的 log_tx_index(tx_hash, block_number, log_index) ≈18–38 GB(预留后 12–25%,旧稿按未压缩 40 B/行 估的 137 GB 已作废)、erc20_transfers holder 窄表 ≈80–100 GB。

本页目录

目录1. 前言与 pre-dev 已落地数据集清单2. 核心避坑指南 (Essential Pitfalls)2.1 必须显式 FINAL 且过滤 is_deleted = 0(针对 ReplacingMergeTree)2.2 普通 MergeTree 表严禁加 FINAL2.3 二进制列是原始字节,严禁直接作为十六进制字符串比较2.4 金额与大数计算绝对禁止使用 Float64 与 pow()2.5 小数位换算必须依赖 tokens 表,严禁盲目硬编码 182.6 列别名同名遮蔽陷阱(ClickHouse 26.9+ 强制规则)2.7 内部调用轨迹 traces 数据覆盖范围限制2.8 专链专有字段的 NULL 属于正常业务语义2.9 WETH 在 Robinhood Chain 上的特殊形态2.10 样本里的 1998-07-09 行来自本地测试块,不是链上数据3. 安装与补算说明 (Installation & Backfill)4. 31 个实战实测查询 (31 Practical Verified Queries)分类一:区块与链级吞吐 (Blocks & Throughput)Q1. 区块出块间隔、TPS 与 Gas 利用率监控Q2. 分钟级链上吞吐量(TPS)、用户交易占比与出块间隔分布Q3. 每日宏观增长概览(总出块、用户交易数、失败交易数、独立发包地址数)Q4. 每日活跃用户(DAU)与新增地址趋势分类二:交易深度剖析与失败排查 (Transactions & Failures)Q5. 失败交易排查与高频报错合约 Top 5Q6. 顶层交易方法签名分布与最热门调用函数排行榜Q7. 原生资产大额转账监控与富豪地址转账流向分类三:手续费构成与 L1 成本核算 (Fees & L1 Pricing)Q8. Arbitrum L1 Calldata 成本与 L2 执行费占比剖析Q9. 单日消耗手续费最多的 Top 5 地址排行榜分类四:同质化代币 (ERC20) 流水与流通量 (ERC20 & Token Supply)Q10. 热门代币(以 TSLA 为例)最新转账流水与金额解析Q11. 单个代币持仓人当前余额分布与 Top 5 大户排行榜Q12. 代币总流通量动态对账(零地址净铸造恒等式校验)Q13. 每日热门转账代币排行榜(转账笔数、交易量、活跃用户数)分类五:Robinhood 代币化美股专区 (Stock Tokens)Q14. 代币化美股资产注册清单与工厂合约部署溯源Q15. 代币化美股每日铸造 (Mint) 与销毁 (Burn) 净流量统计分类六:DEX 去中心化交易所与流动性池 (DEX Pools & Swaps)Q16. Uniswap V3/V4 流动性池创建清单与交易对费率分布Q17. DEX 实时大额 Swap 交易监控与买卖方向分析Q18. 热门交易对交易频次与流动性池活跃度排行榜分类七:NFT 资产流转与持有权 (ERC721 & ERC1155)Q19. ERC721 NFT 所有权流转历史与最新持有者追踪Q20. ERC1155 批量与单笔转账展开后的 TokenID 持仓账本分类八:WETH 封装与跨链桥流量 (WETH & Bridge Flows)Q21. WETH 跨链充值铸造 (Mint) 与销毁提现 (Burn) 流量分析Q22. L1→L2 跨链存款生命周期全流程串联(Retryable Ticket 创建至兑现)Q23. 跨链桥网关每日资产净流入流出汇总分类九:合约部署、代理升级与实体标签 (Contracts, Proxies & Labels)Q24. 新部署合约注册表与高产部署者部署行为聚类Q25. EIP-1967 可升级代理历史升级记录与当前生效逻辑合约Q26. 结合地址标签字典对交互对象进行实体画像标注分类十:授权安全、事件监控与深层调用轨迹 (Approvals, Events & Traces)Q27. 高危/无限额 ERC20 授权 (Unlimited Approval) 监控与授权大户排查Q28. 全链最活跃事件签名 Top 5 及其可读 ABI 定义Q29. 内部调用轨迹 (Traces) 深度异常调用排查与失败 Revert 定位Q30. 新合约部署溯源(包含部署交易哈希与初始化代码长度)分类十一:地址维度转账流水 (Address-Centric Transfers)Q31. 任意地址的 ERC20 / ERC721 全量转账流水(holder 派生表)5. 验证基线与执行总结6. 生产库性能基线与改写建议(2026-09-26 实测)6.1 改写版查询(0 磁盘成本,可直接用)6.2 例外:派生表查询