Fusão de dados de diferentes correntes

(Secção: Ecossistema e Rede)

1) Por que precisa de uma fusão

• Uma única fonte de verdade (canonical facts) quando há logs distribuídos.
• Resistência a reorgias e atrasos: finalização correta e translação.
• Comparabilidade de métricas entre redes e ativos.
• Lineage transparente e controle de qualidade para auditorias e reguladores.

2) Fontes e classes de dados

1. Onchain: blocos, transações, logs de contratos, títulos, estados.
2. Pontes/releituras: pedidos, recibos, provas, estatais de finalização.
3. Camadas L2/DA: batches, publicações, proxes, janelas de contestação.
4. PSP/KYC/KYB/AML: estados de pagamento, verificações, sucessos de sanções.
5. Eventos alimentares: onboarding, depósitos/pagamentos, eventos de jogo e comportamento.
6. Guias: redes, ativos, decimals, chainId, endereços, versões SDK.

Cada fonte registra o dono, o esquema, a linha de atualização, a janela de finalização, o formato de prova e o SLO.

3) Arquitetura de fusão de pipline

Ingest (agentes/indexadores/webhook) Raw/Bronze (matérias-primas imutáveis) Clean/Silver (normalização e dedução) Merge/Core/Gold (factos e comunicações canônicos) Marts (finanças/produto/risco/operação) pesquisa).
Propriedades-chave: idempotidade, versionização de circuitos, replay/backfill, late data handling.

4) Esquemas canónicos (simplificado)

4. 1 Eventos (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 Traduções e pontes (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 Guia de Ativos/Redes (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) Finalização, reorgues e estatais

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

• Confirmações K por rede/ativo/risco.
• Delayed Finalization para grandes quantias.
• Reorg handling: deficiência automática e replay.
• Proof coverage: proporção de registros com loops/questionários ≥ SLO alvo.

6) Normalização do tempo e das moedas

Tempo: todos os timestamps em UTC, armazenar 'observed _ at' e 'event _ at'.
FX/preços de ativos: repassa 'usd _ value' para 'observed _ at' (ou 'event _ at' - para relatórios definidos pela política).
Decimals/scale: canonização rigorosa de quantidades para a comparabilidade.
Fusos horários nos relatórios: cortados na seleção (vitrine), não core.

7) Idempotidade e dedução

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

• Repetições de vários indexadores - upsert por idempotency _ key.
• No conflito payload - ativa policy of truth (prioridade fonte/versão/tempo).
• A janela de dedução é armazenada ≥ 48-72 h para repetições errantes.

8) Entity Resolution (mapeamento de entidades)

Os endereços → os atores são carteira/contrato → usuário/organização/papel.
Ligações de circuito cruzado: hard-link (assinatura/kyc), soft-link (comportamento/conde).
Pseudônimo: PID/ORG _ ID estável; O PII está armazenado em um controlador de dados.

9) Regras de fusão e prioridades (Policy)

1. A fonte da verdade sobre a tradução é o evento onchain 'finalized' + lago.
2. A origem da verdade é o core da tabela 'transfers' bridge _ transfers ', não «matéria-prima».
3. Conflito de tempo (event _ at vs observed _ at) - por política de relatório (finanças - event _ at; operação - observed _ at).
4. Conflito de somas/ativos - paragem de merja e quarentena até a verificação do catálogo de ativos.
5. Laços de ponte - os recibos de ambos os lados são exigidos (src/dst) + receipt pairing.

10) Pseudo-pedidos e algoritmos

10. 1 Combinação de eventos em «operação canônica»

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 Pares de ponte matching (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 Processamento de regas

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) Gerenciamento de esquemas e evolução

Versioning: 'schema _ version' no chapéu do conjunto de dados, as migrações são registradas.
Política de compatibilidade: 'BACKWARD' para eventos (somente adição de campos).
Data Contracts com fontes: testes de contrato CI, linteres de esquema.

12) Qualidade de dados: SLI/SLO

• Freshness p95: ingest→Gold (min).
• Completeness%: proporção de registros que atingem 'finalized' dentro da janela.
• Cortness%: esquemas de validade/assinaturas/proxes.
• Proof Coverage%: proporção de registros canônicos com loofs/questionários.
• Dedup Efficiency: Proporção de dublagens absorvidas de forma idumpotente.
• Reorg Handling Sucess%: inválidos e replays corretos.

SLO (referências): Freshness ≤ 3 min (versões )/15 min (batch); Completeness ≥ 99. 7%; Correctness ≥ 99. 9%; Proof Coverage ≥ 99. 0%; Reorg Success ≥ 99. 9%; Merge MTTR (incidente) ≤ 30 min.

13) Dashboards (layouts)

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: divergências de mappings de ativos, decimals, versões SDK.
Quality & Drift: completeness/correctness, schema drift, late data.
Finance Lens: GTV, Net Flow, TVL por correntes/pontes (somente 'finalized').

14) Configurações (YAML)

Janelas de finalização

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

Políticas de merja e prioridades

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"]

Idempotidade/Dedução

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

15) Privacidade e complacência

PII-Minimização: PID/ORG _ ID, proibição do PII em métricas/editoras.
Data residency: segregação regional (EU/ROW), criptografia em paz/viagem.
Direito de eliminação: tombstone/redation evento com aplicação comprovada.
Auditoria: registos imutáveis, anistia, verificação de acesso por papel.

16) Regulamentos operacionais

Todos os dias: proof coverage, finalização por circuito, registro de pontes e deriva config.
Semanalmente: revisão do catálogo de ativos/decimals, correção da normalização FX.
Mensalmente: testes de reorg/replay, teste de SLO e teste de estresse de desempenho.
Mudar Management: timelock para mudanças de política merge, registro de soluções.

17) Playbook incidentes

A. Russinhron de ativos/decimals

Parem para os ativos apropriados, reversão de catálogo, revezamento de vitrines, relatório ≤ 24 h.

B. Queda do Proof Coverage

Reiniciar/ankering, melhorar o nível de loging, amostra manual de 100 malas, relatório.

C. Picos de Reorg/Challenge

Aumentar 'k '/janela de disputa, incluir delayed finalization para grandes quantias, notificar os interessados.

D. Explosão de duplicações/repetições

Endurecer o deadup TTL/chave, limitar fontes «ruidosas», ativar o caminho de quarentena.

E. À deriva do tempo (time skew)

Sincronizar NTP/PTP, recontratar janelas, mudar temporariamente a política 'preferer: observed _ at'.

18) Folha de cheque de implementação

1. Fixe as fontes, janelas de finalização e provas.
2. Implemente o padrão de eventos canônicos e a chave de idempotação.
3. Configure o duto e a política merge com o circuito quarantine.
4. Eleve o registro de ativos/redes e a normalização FX.
5. Implore replay/backfill e processe late data.
6. Defina o SLI/SLO e os dashboards de qualidade.
7. Execute o questionário regular e os registros de auditoria.
8. Realize o piloto com simulações de retardo/ponte e regule o MTTR.

19) Glossário

Finality - irreversibilidade de estado/evento.
Reorg é o cruzamento da cadeia com a anulação de parte dos blocos.
Idempotency - resistência à reaproveitamento.
Proof Coverage - proporção de registros com provas validadas.
Entity Resolution - Mapeamento de endereços/contas de uma única entidade.
Delayed Finalization - adoção adiada em unidades de alto risco.
Quarantine é um fluxo isolado para registros de conflito/suspeita.

Resultado: a fusão correta de dados entre cadeias é uma disciplina controlada: esquema canônico, finalização e proxes, idemotidade rigorosa, política de fusão transparente e observabilidade da qualidade. Seguindo este quadro, o ecossistema recebe uma camada de dados unificada, verificável e sustentável, uma base de auditoria, análise e escalonamento seguro dos produtos.