链间分析

（部分： 生态系统和网络）

1）什么是链间分析，为什么需要

• 价值和活动的统一核算：量，流动性，佣金，重建。
• 桥梁和P2P链接的可观察性：事件的最终化，滞后，重组/挑战。
• 交通和转换归属：cheyn→cheyn，kanal→produkt。
• 风险和合规性：AML，制裁，行为欺骗和实体识别。
• 决策：OKR/预算，限制，更新和流动性法规。

2）数据源和事件（规范列表）

1.链/注册表：块、交易、事件日志、智能合同状态。
2.桥梁：申请，收据，证据（光/optimistic/ZK），最终状态。
3.支付提供商/KUS：通过检查，限制，支付状态。
4.产品事件：讨价还价，存款/利率/结论，游戏和行为指标。
5.P2P运输：Pub/Sub收据，RPC成功，后退。
6.目录：网络，资产，决定，chainId，合同地址，SDK版本。

3）数据体系结构（线程和存储）

Ingest（流媒体）：连接到nods/indexer, webhooks brides, CDC from operation DB。
原始层（Bronze/Raw）：带有"observed_at"标签和源元数据的不可变批次。
清理/正常（Silver）：去除，语义丰富，时间区对齐，资产映射。
内核模型（Gold/Core）：统一事实"转移"，"桥梁"，"onchain_events"，"kyc_status"，"payouts"。
店面（Marts）：财务（GTV/TVL/Take Rate），产品（重组/漏斗），风险（得分），运营商（SLO）。
Kesh/Serve：用于dashbords和API的OLAP/HTAP，以及单独的/tx地址搜索。

运输：Kafka/Pulsar（在相容性之上只有半导体），原材料对象存储，用于分析的地板/柱形格式。

4）最终化，重生和幂等

事件状态：'observed' → 'confirmed （k）' → 'finalized' → 'invalidated （reorg）'。
确认规则（K-confirmations）：通过网络/资产类型进行配置。
Optimistic/Challenge窗口：支持桥梁的"有争议"状态。
相似性：'idempotency_key=chainId 'block' tx'logIndex 'topic'（或有效载荷哈希）。
Pere Player （replay）：计划中的后退和索引器更改时的恢复。

5）身份和实体模型（实体解决方桉）

地址→演员：地址、钥匙、钱包↔帐户/组织/提供商。
跨链图：单一所有者地址链接（启发式数据，签名，盘边数据）。
信心级别：硬链接（KYC，链签名），软链接（行为相关性）。
别名化：在分析中存储稳定标识符（PID）而不是PII。

6）统一事件图（简化）

yaml event:
id: string # global UUID observed_at: timestamp # when they saw chain_id: string # 'eth-mainnet', 'solana-mainnet',...
block_height: long tx_hash: string log_index: int event_type: string    # transfer    bridge. lock    bridge. mint    kyc. pass    payout. done...
status: string      # observed    confirmed    finalized    invalid actor_src: string # address/peer-id/source organization actor_dst: string # address/peer-id/destination organization asset: string # canonical symbol (e. g., USDC), + decimals amount: decimal usd_value: decimal # rate normalization at the observed_at bridge_ref: string # link with the application/receipt of the metadata bridge: object # network/contract/version/gac/fee, etc.
idempotency_key: string

7）资产和价格正常化

规范资产目录：符号，决定，链映射，合同地址。
FX正常化：历史汇率和"observed_at"时间表的资产价格。
多活动乐队：分组"包裹"和本地资产。

8）关键指标和店面

8.1财务和流动性

GTV（格罗斯交易卷）通过网络/资产/桥梁。
TVL和Net Flow跨桥梁和池。
收费率/收费率；转乘服务费用。

Payout SLA Hit Rate, Finality p50/p95, Pending Backlog.

8.2产品和用户

Cross-chain MAU/DAU (dedup по PID),

Retention D1/D7/D30考虑多重活动，

Funnel：输入网络→桥梁→目标产品→操作。
QoT（流量质量）：反流量的流量过多。

8.3风险和合规性

Fraud/Dispute Rate, High-Risk Score%, Sanctions Hit%.

Anomaly按翻译模式，velocity支票，clustering。
KYB/KYC Pass％和计时。

8.4操作员和SLO

Bridge Success-Rate, p95 Finality, Relay Availability,

Reorg/Challenge events, Error budget burn.

9） SQL/伪查询示例

GTV在链条对上

sql
SELECT src. chain_id AS src_chain,
dst. chain_id AS dst_chain,
date_trunc('day', e. observed_at) AS d,
SUM(e. usd_value) AS gtv_usd
FROM events e
JOIN bridges b ON e. bridge_ref = b. id
JOIN networks src ON b. src_chain_id = src. id
JOIN networks dst ON b. dst_chain_id = dst. id
WHERE e. status = 'finalized' AND e. event_type IN ('bridge. lock','bridge. mint','transfer')
GROUP BY 1,2,3;

Cross-chain retention D7

sql
WITH first_touch AS (
SELECT pid, MIN(observed_at) AS t0
FROM product_events
WHERE event IN ('signup','first_deposit')
GROUP BY pid
),
week_activity AS (
SELECT DISTINCT pid
FROM product_events pe
JOIN first_touch ft USING(pid)
WHERE pe. observed_at BETWEEN ft.t0 + INTERVAL '1 day'
AND ft.t0 + INTERVAL '7 day'
)
SELECT 100. 0 COUNT() / (SELECT COUNT() FROM first_touch) AS d7_retention_pct
FROM week_activity;

用于桥梁SLO的展示柜

sql
SELECT date_trunc('hour', observed_at) AS h,
100. 0 SUM(CASE WHEN status='finalized' THEN 1 END)/COUNT() AS success_rate,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY (finalized_at - observed_at)) AS p95_finality_min,
SUM(CASE WHEN challenge_event THEN 1 END) AS challenges
FROM bridge_events
WHERE observed_at >= now() - INTERVAL '7 days'
GROUP BY 1;

10）归属和多通道路径

基于网络源，桥接和产品的权重的最后touch/位置模型。
UTM→On-chain：将点击/推荐链接到onchein地址（经同意）。
关联模型：用于复杂的"set→most→produkt"路径的Shapley/Markov。

11）反欺诈和行为信号

图形特征：共享交易对手，循环转移，快速周转。
Velocity限制和异常：尖峰，"粉碎"总和，夜间聚类。
桥梁欺诈计划：重新提交，尝试绕过KYC，具有流动性的三明治模式。
模型：梯度增强/图形嵌入；在事件标记上进行培训。

12）隐私和合规性（privacy-by-by-design）

PII最小化：PID代替直接ID，令牌化。
数据驻留：按地区分期,"静止/途中"加密。
删除权：可证明的tombstone/redaction事件。
访问和审核：角色ACL,阅读日志,签名报告进行检查。

13）用于分析管道的SLI/SLO

• Freshness（从"observed_at"到出现在Gold中），
• 完整性（根据K-confirmations的期望，无漏洞事件的百分比），
• Correctness（通过方案/规则验证的事件的百分比），
• Reorg handling success（%正确残疾或重播），
• 服务后退（对店面/行车记录仪的p95查询）。

• Freshness p95 ≤ 3分钟（流媒体），≤ 15分钟（蹦床）。
• Completeness ≥ 99.7%, Correctness ≥ 99.9%.
• Reorg handling success ≥ 99.9%.
• Serve p95 ≤ 500毫秒（主要店面）。

14）数据可观察性和线性

数据线：从行车记录仪到原始事件（专栏级别）。
质量信号：完整性,独特性,referent integrity, schema drift。
Alerts："安静中断"（没有新数据）、分布激增、"未知"领域的增长。

15） Dashbords（模板）

• Success-Rate, p95 Finality, Relay Availability, Challenge/Reorg, backlog, error budget burn.

• TVL，Net Flow per chain，cost-per-transfer，utilization，保险基金。

• MAU/DAU（dedup），跨链检索，通道漏斗，QoT。

• Fraud/Dispute Rate，sanctions命中，高风险分享，诉讼速度。

16）运营法规和剧本

事件： 新鲜度>SLO

检查连接器/索引器，切换到储备，启用降级模式（店面显示"最后最终化"），eskalate源的所有者。

事件： 争夺/挑战激增

增加K-confirmations/争议窗口,为大笔金额启用"延迟最终化",通知桥梁/操作员。

事件： 货币/资产差异

冻结受影响的配对，回滚手册，重新计算USD正常化，发布报告。

事件： Fraud/Dispute飞跃

收紧极限/得分，包括高风险的手动咆哮，在新鲜模式下重新训练模型。

17）示例配置（伪YAML）

通过网络完成窗口

yaml finality:
eth-mainnet: 12  # блоков polygon: 256 solana: "optimistic: 32 slots"
optimistic-bridge: { challenge_minutes: 20 }
zk-bridge: { proof_time_sla: 180 }

等效性和重复数据消除规则

yaml dedup:
key_template: "${chain_id}    ${block_height}    ${tx_hash}    ${log_index}    ${event_type}"
ttl_hours: 48

yaml pipelines:
ingest_stream:
freshness_p95_min: 3 completeness_min_pct: 99. 7 gold_build:
correctness_min_pct: 99. 9 reorg_success_min_pct: 99. 9

18）实施支票

1.确定来源、方桉、最终窗口和所有者。
2.启用idementity和reorg-handling （states+replay）。
3.构建模型核心（transfers/bridges/onchain_events/kyc/payouts)。
4.配置资产目录和FX正常化。
5.定义piplines和dashbords的SLI/SLO。
6.实现entity resolution和privacy-by设计。
7.包括反欺诈得分和事件法规。
8.对历史记录/挑战桉例进行背景调查和测试。
9.定期审核方桉、指标权重和来源。

19）词汇表

最终状态-状态/事件的不可逆性。
Reorg是链条重组，导致部分块失效。
挑战期是优化模型中的挑战窗口。
Entity resolution-映射单个实体的地址/帐户。
GTV/TVL-交易量/锁定价值。
Completeness/Freshness/Correctness是数据质量的基本指标。

底线：链间分析不仅仅是指标的摘要，而是可管理的学科：一个单一的事件模式，正确的决赛，可持续的管道，隐私，反欺诈和可理解的展示。通过遵循这一框架，生态系统获得了价值、风险和增长的"端到端"视角--从原始块到业务解决方桉。