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 已落地数据集清单
- 2. 核心避坑指南 (Essential Pitfalls)
- 3. 安装与补算说明 (Installation & Backfill)
- 4. 31 个实战实测查询 (31 Practical Verified Queries)
- 分类一:区块与链级吞吐 (Blocks & Throughput)
- 分类二:交易深度剖析与失败排查 (Transactions & Failures)
- 分类三:手续费构成与 L1 成本核算 (Fees & L1 Pricing)
- 分类四:同质化代币 (ERC20) 流水与流通量 (ERC20 & Token Supply)
- 分类五:Robinhood 代币化美股专区 (Stock Tokens)
- 分类六:DEX 去中心化交易所与流动性池 (DEX Pools & Swaps)
- 分类七:NFT 资产流转与持有权 (ERC721 & ERC1155)
- 分类八:WETH 封装与跨链桥流量 (WETH & Bridge Flows)
- 分类九:合约部署、代理升级与实体标签 (Contracts, Proxies & Labels)
- 分类十:授权安全、事件监控与深层调用轨迹 (Approvals, Events & Traces)
- 分类十一:地址维度转账流水 (Address-Centric Transfers)
- 5. 验证基线与执行总结
- 6. 生产库性能基线与改写建议(2026-09-26 实测)
1. 前言与 pre-dev 已落地数据集清单
截至当前 origin/pre-dev 分支,本项目已经在 ClickHouse 中构建了涵盖原始区块链数据、事件解码、协议行为解析以及链上宏观增长的全套数据资产。所有数据表在每条链上独立成库(以 robinhood 为标准库名,跨链查询时替换库名即可)。
本手册覆盖的核心数据集清单如下(origin/pre-dev 上已落地的派生表完整列表见 schema/clickhouse/derived/README.md):
| 类别 | 数据集名称 | 物理表 / 视图 | 核心来源 / 派生 SQL | 主要用途 |
|---|---|---|---|---|
| 原始表 | 区块头 (Blocks) | {db}.blocks | sql/schema.sql | 区块时间戳、出块人、Gas Limit/Used、Base Fee |
| 原始表 | 交易与回执 (Transactions) | {db}.transactions | sql/schema.sql | 交易参数、回执状态 (status)、有效 Gas 价格、L1 分摊 Gas |
| 原始表 | 事件日志 (Logs) | {db}.logs | sql/schema.sql | 合约日志 raw bytes, topic0~topic3, data |
| 原始表 | 内部调用轨迹 (Traces) | {db}.traces | sql/traces.sql | 内部 CALL/DELEGATECALL/STATICCALL/CREATE 帧、调用栈深度、revert 原因 |
| 派生表 | ERC20 转账流水 | {db}.erc20_transfers | 001_erc20_transfers.sql | 标准 ERC20 Transfer 事件解码 (token, from, to, amount) |
| 派生表 | ERC721 NFT 转账 | {db}.erc721_transfers | 002_erc721_transfers.sql | NFT 所有权流转 (token, from, to, token_id) |
| 派生表 | 地址维度转账索引(本 PR 新增,尚未装到 robinhood) | {db}.erc20_transfers_by_holder, {db}.erc721_transfers_by_holder | 035_transfers_by_holder.sql | 任意地址的全量 ERC20/ERC721 流水(每笔 2 行,holder 在排序键首位;见 Q31) |
| 派生表 | 链日度宏观统计 | {db}.daily_chain_stats | 004_daily_chain_stats.sql | 出块数、交易数、失败数、Gas 消耗、唯一发包地址 (HLL) |
| 派生表 | 代币日度流水统计 | {db}.daily_token_stats | 005_daily_token_stats.sql | 各 ERC20 代币每日转账笔数、交易量、活跃收发地址数 |
| 派生表 | Robinhood 代币化美股 | {db}.stock_tokens, {db}.stock_token_daily_activity | 007_stock_tokens.sql | 官方美股/ETF 代币注册表 (TSLA, AAPL 等) 与每日 Mint/Burn 流水 |
| 派生表 | DEX 交易与流动性池 | {db}.dex_pools, {db}.dex_swaps | 008_dex.sql | Uniswap V2/V3/V4 资金池元数据与 Swap 成交流水 (amount0/1, price) |
| 派生表 | ERC1155 与 NFT 持有 | {db}.erc1155_transfers, {db}.erc1155_balances, {db}.erc721_current_owner | 009_erc1155_nft_owners.sql | 批量转账展平、多资产余额账本与 ERC721 实时持有人锁定 |
| 派生表 | 合约注册表与活跃度 | {db}.contracts, {db}.contract_daily_activity | 010_contracts.sql | 成功部署的合约注册表 (address, creator, tx_hash) 与调用频次 |
| 参考表 | 地址实体标签库 | {db}.address_labels | 011_address_labels.sql | 官方 Bridge 网关、WETH、USDG、Sequencer 等知名地址字典 |
| 派生表 | 跨链桥流水 (Bridge) | {db}.bridge_deposits, {db}.bridge_withdrawals, {db}.bridge_erc20_gateway_events, {db}.bridge_daily_net_flow | 012_bridge_flows.sql | L1<->L2 存款 (Retryable Tickets)、L2 提现与代币网关净流量 |
| 派生表 | 手续费与 L1 成本核算 | {db}.tx_fees, {db}.daily_fee_stats, {db}.daily_fee_by_address | 013_fees.sql | 逐笔交易 L1 Calldata / L2 执行费用拆解与大户手续费排行 |
| 派生表 | ArbOS L1 定价与 Base Fee | {db}.arbos_l1_pricing, {db}.daily_l1_base_fee_stats | 022_arbos_l1_pricing.sql | 从 ArbOS startBlock 系统交易 (0x6bf6a42d) 解码 L1 base fee 预估与每日统计 |
| 派生表 | 活跃用户与留存 (DAU) | {db}.daily_active_addresses, {db}.address_first_seen, {db}.user_retention_cohorts | 014_active_users.sql | 排除系统账号后的真实活跃地址数 (DAU)、新增用户与留存队列 |
| 参考/视图 | 事件签名库与解码日志 | {db}.event_signatures, {db}.logs_named, {db}.v_decoded_* | 015_event_signatures.sql | 45 种主流 EVM 事件签名 (topic0 -> name/signature) 与具名视图 |
| 参考/视图 | 方法选择器与解码交易 | {db}.method_selectors, {db}.transactions_named | 016_method_selectors.sql | 118 种主流 4 字节函数选择器 (selector -> name) 与具名交易视图 |
| 派生表 | 预言机价格 (Oracle Prices) | {db}.oracle_feeds, {db}.oracle_prices | 017_oracle_prices.sql | Chainlink FluxAggregator 喂价事件解码,美股/外汇链上报价历史 |
| 视图/派生表 | ERC20 授权安全 | {db}.erc20_approvals(表), {db}.erc20_current_allowances(视图) | 018_erc20_approvals.sql | Approval 授权流水与无限额授权 (Unlimited) 监控 |
| 派生表 | 代币总供应量 (Token Supply) | {db}.token_daily_supply, {db}.v_token_latest_supply | 019_token_supply.sql | 各 ERC20 每日链上 totalSupply(净铸造量)快照与变化趋势 |
| 视图/派生表 | 失败交易分析 (Failed Txs) | {db}.failed_txs(视图), {db}.contract_daily_failure_rate(预计算表) | 020_failed_txs.sql | failed_txs 是 transactions FINAL ⋈ traces FINAL 视图(含 revert reason 解码,需 trace 覆盖区间);只有 contract_daily_failure_rate 是预聚合表 |
| 派生表 | 链级吞吐指标 | {db}.throughput_minute, {db}.throughput_hour | 021_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_wrap | 025_weth_flows.sql | WETH Deposit/Withdrawal/Transfer 分类流水与每日净封装量统计 |
| 视图/派生表 | 可升级代理检测 (Proxy) | {db}.proxy_upgrades(表), {db}.v_proxy_current_implementation(视图), {db}.proxy_slots(快照表) | 026_proxy_detection.sql | EIP-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_daily | 031_dex_prices.sql | 各代币对每日 VWAP 价格(基于 DEX Swap 流水加权均价)与最新报价视图 |
| 派生表 | 代币化股票市场看板 | {db}.stock_token_daily, {db}.stock_token_leaderboard | 032_stock_market.sql | 代币化美股每日涨跌幅、成交量与持仓地址数排行榜 |
| 元数据表 | Token 元数据缓存 | {db}.tokens | sql/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 都会导致后几十位精度丢失,产生对账灾难! - 正确做法:
- 账本与汇总阶段全部使用
UInt256/Int256整数运算; - 查询展示层统一使用
toString(amount)输出为字符串交给业务前端; - 若需在 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(仍是整数) 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的 ERC20Transfer(Mint); - 所有 WETH 跨链提现体现为
to = 0x00...00的 ERC20Transfer(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/ 目录。在部署新环境时,按以下规范进行安装与补算:
-
正确性方案 (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 依赖此表)。
- 适用表:
-
正确性方案 (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 的默认输出。
- 当天(UTC 自然日尚未结束)在
- 活跃用户(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自行聚合。
- 适用表:
-
静态字典与元数据维护:
event_signatures(015) 与method_selectors(016):执行对应 SQL 脚本即可灌入种子数据。address_labels(011):人工审核打标的参考表,支持重复重跑幂等覆盖。tokens(sql/tokens.sql):通过chain-indexer enrich-tokens子命令对节点 RPC 发起批量eth_call增量回填。
-
代币化美股注册表(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 millionQ2. 分钟级链上吞吐量(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 1Q3. 每日宏观增长概览(总出块、用户交易数、失败交易数、独立发包地址数)
- 业务场景 / 分析目标:业务团队日报核心看板数据,追踪整链每日总交易量、失败率以及唯一发送地址数(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 35661Q6. 顶层交易方法签名分布与最热门调用函数排行榜
- 业务场景 / 分析目标:分析用户在链上调用哪些业务函数(例如 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 298Q7. 原生资产大额转账监控与富豪地址转账流向
- 业务场景 / 分析目标:追踪链上原生代币(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 0Q9. 单日消耗手续费最多的 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 816977463322781619Q11. 单个代币持仓人当前余额分布与 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 WETHQ12. 代币总流通量动态对账(零地址净铸造恒等式校验)
- 业务场景 / 分析目标:验证代币流通总量守恒:全网所有非零持仓地址余额之和必须严格等于零地址余额的相反数(即净铸造量 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 1Q13. 每日热门转账代币排行榜(转账笔数、交易量、活跃用户数)
- 业务场景 / 分析目标:分析指定自然日内转账最活跃的代币资产排名,获取其转账人次与独立地址数。
- 使用表与依赖:
{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 72040327Q17. 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 685138393258481682051238Q18. 热门交易对交易频次与流动性池活跃度排行榜
- 业务场景 / 分析目标:统计链上各个 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 9C4FF725A2C9F1167101139B4ED62926FD5713F77E70748568995058C86E421AQ20. 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.594606613285049613Q22. 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 0Q23. 跨链桥网关每日资产净流入流出汇总
- 业务场景 / 分析目标:分析 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 72039023Q25. 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 DED588777A8DAAEE9A48DF55ECF97C6CC947E3BC578BCCAD24A22F72A018B4F8Q26. 结合地址标签字典对交互对象进行实体画像标注
- 业务场景 / 分析目标:避免人工对照十六进制地址,通过 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 33A8BDA5529440FD2B7E5A7FE37B4A26200AD8FA6C10747B1FEA3A5D8CCFB1B2Q28. 全链最活跃事件签名 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均为非 NullableString;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 1484Q29. 内部调用轨迹 (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 9787Q30. 新合约部署溯源(包含部署交易哈希与初始化代码长度)
- 业务场景 / 分析目标:溯源新合约的部署过程,提取部署者、初始化字节码长度(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/tobloom_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:05115405086 58821 72853165SQL 查询语句(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 483C4E0614945E5C64639DC07C0604777A2F080C63F7CAE88B208BECE72F6F79488942为什么不能直接用
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实测:blocks2000 行 /transactions12026 行 /erc20_transfers23599 行)并应用派生 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。
- 在独立的 scratch 库中加载真链数据后执行:主样本库覆盖块高 72039000–72040999(按
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、慢查询清单与磁盘估算)。四条硬结论:
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)。- 大表查询一律带
block_number范围/下界——block_timestamp不在transactions/logs/erc20_transfers的排序键里,按时间过滤 = 全表扫描。实测"按时间查 1 小时区块" 2,307 ms → 改按块号 8 ms;"某地址交易 LIMIT 50" 17,757 ms → 加 24h 块号下界 74 ms。 bloom_filter对稠密值无效:热点合约地址、Transfer(占全表 46.6%)、V3/V4Swap(5% 上下)这类值在每个 granule 都有命中,剪枝率为 0(本机实测:稀疏地址少读 4.6–16x,稠密地址 0%)。实测最忙 EOA 的from OR to只剪掉 35% granule、count()反而从 7.2s 变成 9.3s。这类查询只能靠"限定区块范围"或按该列排序的窄派生表/projection。- ⚠️
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、Q19erc721_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 UTCinstall_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_transfersholder 窄表 ≈80–100 GB。