来自不同电路的数据融合

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

1）为什么需要合并

• 当存在杂项日志时，单一的真相来源（canonical事实）。
• 对流变和延迟的抵抗力：正确的压制和翻转。
• 网络与资产之间指标的可比性。
• 为审计和监管机构提供透明的线性和质量控制。

2）数据源和类别

1.Onchein：块、交易、合同日志、标题、状态。
2.桥梁/接收者：申请，收据，证据，最终状态。
3.L2/DA层：batchi，出版物，prufs，挑战窗口。
4.PSP/KYC/KYB/AML：支付状态，支票，制裁打击。
5.杂货店活动：讨价还价，存款/付款，游戏和行为活动。
6.参考：网络,资产,decimals, chainId,地址,SDK版本。

对于每个来源，都会捕获：所有者，电路，更新时间，最终化窗口，证据格式和SLO。

3）合并管线架构

Ingest（代理商/索引商/webhook）→ Raw/Bronze（不变原材料）→ Clean/Silver（规范化和去除性）→ Merge/Core/Gold（规范事实和联系）→ Marts（财务/产品/风险/运营）→ Serve（OLAP/API/搜索）。
关键属性：等效性,电路转换,replay/backfill, late data handling。

4）规范方案（简化）

4.1个事件（YAML）

yaml event:
id: uuid observed_at: timestamp # when saw event_at: timestamp # when happened (by source)
chain_id: string       # 'eth-mainnet'    'polygon'...
block_height: long tx_hash: string log_index: int type: string         # transfer    bridge. lock    bridge. mint...
status: string        # observed    confirmed    finalized    invalid src: string # address/peer-id/org _ id dst: string asset: string # canonical character (USDC)
amount: decimal usd_value: decimal # normalization at the rate on the meta observed_at: object # gas, fee, contract, sdk_version...
idempotency_key: string    # chainId    block    tx    logIndex    type proof_ref: string # proof/anchor reference

4.2翻译和桥梁（SQL）

sql
CREATE TABLE bridge_transfers (
id TEXT PRIMARY KEY,
src_chain TEXT, dst_chain TEXT,
asset TEXT, amount NUMERIC,
created_at TIMESTAMPTZ,
finalized_at TIMESTAMPTZ,
status TEXT,          -- requested    inflight    finalized    failed    reversed src_tx TEXT, dst_tx TEXT,
proof_ref TEXT, meta JSONB
);

4.3资产/网络目录（YAML）

yaml catalog:
assets:
- symbol: USDC decimals: { eth-mainnet: 6, polygon: 6 }
contracts: { eth-mainnet: "0xA0b8...", polygon: "0x2791..." }
networks:
- id: eth-mainnet k_confirmations: 12
- id: polygon k_confirmations: 256

5）最终化，重组和状态

Состояния: `observed → confirmed(K) → finalized → invalidated(reorg)` (+ `challenged` для optimistic).

• 通过网络/资产/风险进行K确认。
• 大额的延迟最终化。
• Reorg handling：自动残疾和重播。
• 证明覆盖：具有目标SLO的普鲁士/锚≥记录的比例。

6）时间和货币正常化

时间：UTC中的所有时间表，存储"observed_at"和"event_at"。
FX/资产价格：以"observed_at"（或"event_at"）的汇率重新计算"usd_value"，用于报告，由政策决定）。
Decimals/Scale：可比性的严格量化。
报告中的时区：在选择（店面）时反射，不在核心。

7）相似性和重复数据消除

• `idempotency_key = chainId|block_height|tx_hash|log_index|type`

• 多个索引的重播是idempotency_key的upsert。
• 当发生冲突时,payload-触发真相策略（源优先级/版本/时间）。
• 对于"流浪"重复,重复数据消除窗口存储≥ 48-72小时。

8）企业解决（实体匹配）

地址→演员：钱包/合同→用户/组织/角色。
跨链链接：硬链接（签名/kyc），软链接（行为/图形）。
别名：稳定的PID/ORG_ID；PII存储在数据控制器上。

9）合并规则和优先事项（政策）

1.关于翻译事实的真相来源是"最终化"+虚假事件。
2.按集合划分的真相来源是"转移者"bridge_transfers"表的核心而不是"原材料"。
3.时间冲突（event_at vs observed_at）-根据报告政策（财务-event_at；操作员是observed_at)。
4.金额/资产冲突-在对资产目录进行对账之前停止行驶和隔离。
5.桥接-需要双方的收据（src/dst）+receipt配对。

10）伪查询和算法

10.1将事件简化为规范的"操作"

sql
WITH base AS (
SELECT e.,
CONCAT(e. chain_id,'    ',e. block_height,'    ',e. tx_hash,'    ',e. log_index,'    ',e. type) AS idem
FROM raw_events e
)
INSERT INTO core_events AS c (id, observed_at, event_at, chain_id, block_height,
tx_hash, log_index, type, status, src, dst, asset, amount, usd_value, meta, idempotency_key, proof_ref)
SELECT gen_random_uuid(), observed_at, event_at, chain_id, block_height,
tx_hash, log_index, type, status, src, dst, asset, amount, usd_value, meta, idem, proof_ref
FROM base
ON CONFLICT (idempotency_key) DO UPDATE
SET status = EXCLUDED. status,
usd_value = COALESCE(EXCLUDED. usd_value, core_events. usd_value),
proof_ref = COALESCE(EXCLUDED. proof_ref, core_events. proof_ref),
meta   = core_events. meta          EXCLUDED. meta;

10.2桥对对对决（istochnik↔tsel）

sql
INSERT INTO bridge_transfers (id, src_chain, dst_chain, asset, amount, created_at, status, src_tx, proof_ref)
SELECT
CONCAT('br:', e. tx_hash) AS id,
e. chain_id, b. dst_chain, e. asset, e. amount, e. event_at, 'inflight', e. tx_hash, e. proof_ref
FROM core_events e
JOIN bridge_book b ON e. type='bridge. lock' AND e. asset=b. asset AND e. chain_id=b. src_chain
ON CONFLICT (id) DO NOTHING;

UPDATE bridge_transfers bt
SET finalized_at = e. event_at,
dst_tx    = e. tx_hash,
status    = 'finalized'
FROM core_events e
WHERE e. type='bridge. mint'
AND bt. status='inflight'
AND bt. asset=e. asset
AND bt. src_chain=bridge_book. src_chain
AND bt. dst_chain=bridge_book. dst_chain
AND abs(e. amount - bt. amount) < 1e-9;

10.3 Reorgas处理

sql
UPDATE core_events
SET status='invalidated'
WHERE chain_id=$1 AND block_height BETWEEN $2 AND $3
AND status IN ('observed','confirmed','finalized');

-- Reassembly of aggregates (example)
CALL recompute_materialized_views($1, $2, $3);

11）方桉与演变管理

转化：数据集上限中的"schema_version"，迁移记录在日志中。
兼容性策略：事件的"BACKWARD"（仅添加字段）。

数据合同与来源： 合同测试在CI, linters.

12）数据质量： SLI/SLO

• Freshness p95：l ingest→Gold ag（min）。
• 完成%：在窗口内达到"最终化"的条目的比例。
• Correctness%：有效电路/签名/prufs。
• Proof Coverage%：具有普鲁士/锚点的规范记录的比例。
• Dedup Efficiency：偶数吸收的倍数比例。
• Reorg Handling Success%：正确的残疾和重播。

SLO（地标）：Freshness ≤ 3分钟（流）/15分钟（蹦床）；Completeness ≥ 99.7%;Correctness ≥ 99.9%;Proof Coverage ≥ 99.0%;Reorg Success ≥ 99.9%;Merge MTTR（事件）≤ 30分钟。

13）Dashbords（布局）

Merge Ops (реал-тайм/час): Freshness, Queue lag, Dedup rate, Finalized %, Reorg spikes, Error-budget burn.

Proof & Finality: proof coverage, p95 finality per chain, challenge/reorg события.

Catalog Health：资产映射、decimals、SDK版本的差异。

Quality & Drift: completeness/correctness, schema drift, late data.

Finance Lens：GTV，Net Flow，TVL在链条/桥上（仅限于"最终化"）。

14）配置（YAML）

最终化窗口

yaml finality:
eth-mainnet: { k: 12, delayed_for_usd_gt: 100000 }
polygon:   { k: 256 }
optimistic-L2:
k: 0 challenge_minutes: 20 delayed_for_usd_gt: 50000

默奇和优先级政策

yaml merge_policy:
source_priority: [onchain, bridge, psp, product]
conflict:
time: { prefer: "event_at" }
amount: { action: "quarantine" }
proof_required_for: ["bridge_transfers", "payouts"]
quarantine_topics: ["asset_mismatch", "decimals_mismatch", "time_skew_gt_5m"]

异位性/异位性

yaml dedup:
key_template: "${chain_id}    ${block_height}    ${tx_hash}    ${log_index}    ${type}"
ttl_hours: 72

15）隐私和合规性

PII最小化：PID/ORG_ID，在度量/标签中禁止PII。
数据驻留：区域隔离（EU/ROW），静止/途中加密。
删除权：tombstone/redaction事件,具有可证明的应用。
审计：不变的日志，哈希锚定，按角色检查访问。

16）运营法规

每天：验证覆盖，链条决赛，桥梁注册和config漂移。
每周：修订资产/衰减目录，正确的FX正常化。
每月：reorg/replay测试、SLO检查和性能压力测试。

更改管理： 时间表对更改的交易策略,决策日志.

17）事件剧本

A. Rassinchron资产/资产

停止相关资产，回滚目录，重新计算店面，报告24小时≤。

B. Proof Coverage的下降

重新启动mercilization/Ankering,提高拼写水平,手动采样100个桉例,报告。

C. Peaky Reorg/挑战赛

增加"k"/争议窗口，为大笔款项启用延迟最终化，通知感兴趣的人。

D.爆炸

收紧TTL/Key的前提，限制"嘈杂"的来源，启用检疫回路。

E. Drafe时间（时间跳跃）

NTP/PTP同步，窗口重新计票，临时策略'prefer： observed_at'移位。

18）实施支票

1.记录来源、最终窗口和证据。
2.引入规范事件模式和幂等键。
3.使用quarantine轮廓配置dedup和merge策略。
4.提高资产/网络注册和FX正常化。
5.实现replay/backfill和处理延迟数据。
6.确定SLI/SLO和质量码。
7.运行定期的锚定和审计日志。
8.对飞行员进行重播/桥延误模拟,并记录MTTR。

19）词汇表

最终状态-状态/事件的不可逆性。
Reorg是电路的重组，其中部分块被取消。
Idempotency-对重新交付的抵抗力。
Proof Coverage-具有有效证据的条目比例。
Entity Resolution-映射单个实体的地址/帐户。
Delayed Finalization-延迟接受高风险金额的聚合。
Quarantine是冲突/可疑记录的孤立流。

总而言之：正确的链间数据融合是一门可管理的学科：规范方案，最终化和prufs，严格的幂等，透明的融合政策和质量可观察性。遵循此框架,生态系统将获得一个单一、可验证和可持续的数据层-审计、分析和安全产品扩展的基础。