Fusione dei dati da catene diverse

(Sezione Ecosistema e Rete)

1) Perché è necessaria una fusione

• Un'unica fonte di verità (canonical facts), se si dispone di un tubo diviso.
• Resistenza a riorghi e ritardi: finalizzazione e ricollocamenti corretti.
• La mappatura delle metriche tra reti e risorse.
• Lineage trasparente e controllo qualità per i controlli e i regolatori.

2) Origini e classi di dati

1. Onchain: blocchi, transazioni, fogli contrattuali, intestazioni, stati.
2. Ponti/relatori: richieste, ricevute, prove, statali di finalizzazione.
3. I livelli L2/DA sono batch, pubblicazioni, laghetti, finestre di contestazione.
4. PSP/KYC/KYB/AML: stati di pagamento, controlli, successi sanzionatori.
5. Eventi alimentari: onboarding, depositi/pagamenti, eventi di gioco e comportamento.
6. Le guide sono reti, risorse, decimals, chainId, indirizzi, versioni SDK.

Per ciascuna sorgente viene registrato il proprietario, lo schema, la squadra di aggiornamento, la finestra di finalizzazione, il formato delle prove e il SLO.

3) Architettura di fusione pipline

Ingest (agenti/indicizzatori/webhook) Raw/Bronze (materia prima invariata) Clean/Silver (normalizzazione e deduzione) Merge/Core/Gold (fatti e comunicazioni canoniche) Marts (finanza/prodotto/rischio/operatore)) Ricerca).
Proprietà chiave: idempotenza, versioning degli schemi, replay/backfill, late data handling.

4) Schemi canonici (semplificato)

4. 1 Eventi (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 Traduzioni e ponti (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 Elenco risorse/reti (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) Finalizzazione, riorghi e states

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

• Conferme K per rete/asset/rischio.
• Delayed Finalization per importi importanti.
• Reorg handling: disabilità automatica e replay.
• Proof coverage - Percentuale di record con prugne/interrogatori di destinazione SLO.

6) Normalizzazione del tempo e delle valute

Ora: tutti i timestampts di UTC, memorizzare «observed _ at» e «event _ at».
FX/prezzi degli asset: ricalcolò usd _ value ', in linea con «observed _ at» (o «event _ at» - per i rapporti definiti dal criterio).
Decimals/scale: canonizzazione rigorosa delle quantità per la comparabilità.
I fusi orari nei report vengono tagliati durante la selezione (vetrina), non in core.

7) Idampotenza e deduplicazione

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

• Ripetizioni di più indici - upsert per idempotency _ key.
• In caso di conflitto payload - attiva policy of truth (priorità sorgente/versione/ora).
• La finestra di deduplicazione è ≥ 48-72 ore per ripetizioni vaganti.

8) Entity Resolution (mappatura entità)

Gli indirizzi degli attori sono portafogli/contratti, utente/organizzazione/ruolo.
I collegamenti tra catene crociate sono hard-link (firma/kyc), soft-link (comportamento/conte).
Alias: PID/ORG _ ID stabile; PII è memorizzato in un controller di dati.

9) Regole di fusione e priorità (Policy)

1. La fonte della verità sulla traduzione è l'evento onchain finalization + stagno.
2. La fonte di verità per aggregazione è core tabelle "transfers" bridge _ transfers ", non" materie prime ".
3. Conflitto di tempo (event _ at vs observed _ at) - Per criteri di report (finanza - event _ at; operazione- observed _ at).
4. Conflitto di somme/beni - Interrompere il merge e la quarantena fino a verificare il catalogo degli asset.
5. Legamenti ponte - Sono necessarie ricevute di entrambi i lati (src/dst) + receipt pairing.

10) Pseudo-richieste e algoritmi

10. 1 Riassunto degli eventi in un'operazione canonica "

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 matching vapore ponte (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 Trattamento dei riorghi

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) Gestione degli schemi e dell'evoluzione

Versioning: 'schema _ version'nel cappello del dataset, le migrazioni vengono registrate.
Criterio di compatibilità: «BACKWARD» per gli eventi (solo aggiunta di campi).
Data Contracts con sorgenti - Test contrattuali CI, Linter diagrammi.

12) Qualità dei dati: SLI/SLO

• Freshness p95: lega di ingest→Gold (min).
• Completeness% - Percentuale di record che hanno raggiunto finalizzato'finalizzato'all'interno della finestra.
• Correctness%: schemi validi/firme/laghetti.
• Proof Coverage% - Percentuale di registrazioni canoniche con laghetti/interrogatori.
• Dedup Efficiency - Percentuale di riprese assorbite in modo idropotente.
• Reorg Handling Success%: disabilità e replays corrette.

SLO (punti di riferimento): Freshness 3 min (strame )/15 min (batch); Completeness ≥ 99. 7%; Correctness ≥ 99. 9%; Proof Coverage ≥ 99. 0%; Reorg Success ≥ 99. 9%; Merge MTTR (incidente) ≤ 30 minuti

13) Dashboard (layout)

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: discrepanze di mapping di asset, decimals, versioni SDK.
Quality & Drift: completeness/correctness, schema drift, late data.
Finance Lens: GTV, Net Flow, TVL per catene/ponti (solo «finalization»).

14) Configurazioni (YAML)

Finestre di finalizzazione

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

Criteri merge e priorità

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

Idempotenza/Deducibilità

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

15) Privacy e compliance

Riduzioni PII: PID/ORG _ ID, divieto di PII nelle metriche/etichette.
Data residency: segregazione regionale (EU/ROW), crittografia a riposo/viaggio.
Diritto di eliminazione: tombstone/redaction evento con applicazione provata.
Controllo: registri invariati, raccoglitore hash, controllo di accesso ai ruoli.

16) Regolamenti operativi

Ogni giorno: scorciatoia proof coverage, finalizzazione catene, registro ponti e deriva config.
Ogni settimana: revisione del catalogo degli asset/decimals, correttezza della normalizzazione FX.
Ogni mese: test di reorg/replay, test SLO e test di stress delle prestazioni.
Cambio Management: timelock sulle modifiche alle regole merge, registro delle soluzioni.

17) Playbook incidenti

A. Rassincrone asset/decimals

Stop agli asset appropriati, recupero del catalogo, rivalutazione delle vetrine, rapporto 24 ore su 24.

B. Caduta di Proof Coverage

Riavviare il prodotto/ankering, aumentare il livello di loging, campionare manualmente 100 valigette, report.

C. Picchi Reorg/Challenge

Aumentare «k »/la finestra del contenzioso, attivare delayed finalization per gli importi maggiori, informare gli interessati.

D. Esplosione di riprese/ripetizioni

Stringere il dashboard TTL/chiave, limitare le sorgenti «rumorose» e attivare il tracciato di quarantena.

E. Deriva del tempo (time skew)

Sincronizza NTP/PTP, ricalca le finestre, sposta temporaneamente il criterio prefer: observed _ at.

18) Assegno foglio di implementazione

1. Fissate le fonti, le finestre e le prove.
2. Implementare uno schema di eventi canonico e una chiave di idampotenza.
3. Configurare il dashboard e le regole merge con il tracciato quarantine.
4. Alzare il registro delle risorse/reti e la normalizzazione FX.
5. Implementare replay/backfill e elaborare late data.
6. Definire SLI/SLO e dashboard di qualità.
7. Eseguire l'anchering regolare e i registri di controllo.
8. Condurre un pilota con simulazioni di ritardi/ritardi di ponte e fissare un MTTR.

19) Glossario

Finality - Irreversibilità dello stato/evento.
Reorg è l'intersezione di una catena con l'annullamento di una parte dei blocchi.
Idempotency - Resistenza alla ricarica.
Proof Coverage è una quota di record con prove valide.
Entity Resolution - Mappatura indirizzi/account di un'unica entità.
Delayed Finalization - Accezione posticipata per aggregazioni ad alto rischio.
Quarantine è un flusso isolato per i record di conflitto/sospetto.

Il risultato è che la corretta fusione dei dati intercorrenti è una disciplina controllata: sistema canonico, finalizzazione e laghetti, idampotenza rigorosa, politica di fusione trasparente e osservabilità della qualità. Seguendo questo framework, l'ecosistema ottiene un unico livello di dati, verificabile e sostenibile, che è la base per l'analisi, l'analisi e la scalabilità sicura dei prodotti.