鏈間分析

（部分： 生態系統和網絡）

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是數據質量的基本指標。

底線：鏈間分析不僅僅是指標的摘要，而是可管理的學科：一個單一的事件模式，正確的決賽，可持續的管道，隱私，反欺詐和可理解的展示。通過遵循這一框架，生態系統獲得了價值、風險和增長的「端到端」視角--從原始塊到業務解決方案。