Fusion de données de chaînes différentes

(Section : Écosystème et réseau)

1) Pourquoi une fusion est nécessaire

• Une source unique de vérité (canonical facts) avec des logs différents.
• Résistance aux réorgues et aux retards : finalisation et digestion correctes.
• Comparabilité des métriques entre réseaux et actifs.
• Lineage transparent et contrôle qualité pour l'audit et les régulateurs.

2) Sources et classes de données

1. Onchein : blocs, transactions, logs de contrat, titres, états.
2. Ponts/relais : demandes, reçus, preuves, statuts de finalisation.
3. Couches L2/DA : batchi, publications, proufs, fenêtres de contestation.
4. PSP/KYC/KYB/AML : statuts de paiement, vérifications, succès de sanctions.
5. Événements alimentaires : onbording, dépôts/paiements, jeux et événements comportementaux.
6. Guides : réseaux, actifs, decimals, chainId, adresses, versions SDK.

Pour chaque source sont enregistrés : propriétaire, schéma, mise à jour, fenêtre de finalisation, format de preuve et SLO.

3) Architecture de fusion pipline

Ingest (agents/indexeurs/webhook) → Raw/Bronze (matière première immuable) → Clean/Silver (normalisation et déduplication) → Merge/Core/Gold (faits et liens canoniques) → Marts (finances/produit/risque/exploitation) → Serve (OLAP/API/recherche).
Propriétés clés : idempotence, versioning des schémas, replay/backfill, late data handling.

4) Schémas canoniques (simplifiés)

4. 1 Événements (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 Traductions et ponts (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 Répertoire des actifs/réseaux (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) Finalisation, reorgs et statuts

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

• K-confirmations par réseau/actif/risque.
• Finalisation délaissée pour les sommes importantes.
• Reorg handling : invalidité automatique et replay.
• Couverture Proof : proportion d'entrées avec des prufs/ancres ≥ un SLO cible.

6) Normaliser le temps et les devises

Temps : tous les timestampts dans UTC, stocker 'observed _ at' et 'event _ at'.
FX/prix des actifs : recalculer 'usd _ value' au taux de change de 'observed _ at' (ou 'event _ at' - pour la déclaration, définie par la politique).
Decimals/scale : canonisation rigoureuse des quantités pour la comparabilité.
Fuseaux horaires dans les rapports : Résonance lors de la sélection (vitrine), pas dans le core.

7) Idempotence et déduplication

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

• Les répétitions de plusieurs index sont upsert par idempotency_key.
• En cas de conflit payload - la politique de confiance (priorité source/version/heure) est activée.
• La fenêtre du grand-père est stockée ≥ 48-72 h pour les répétitions « errant ».

8) Entity Resolution (mappage d'entités)

Adresses → acteurs : portefeuille/contrat → utilisateur/organisation/rôle.
Liens croisés : hard-link (signé/kyc), soft-link (comportement/graphe).
Pseudonyme : PID/ORG_ID stable ; PII est stocké par le contrôleur de données.

9) Règles et priorités en matière de fusion (Politique)

1. La source de la vérité sur le fait de la traduction est l'événement « finalized » + prouf.
2. La source de la vérité par agrégat est le core de la table "transfers" bridge _ transfers ", pas la" matière première ".
3. Conflit de temps (event_at vs observed_at) - sur la politique du rapport (finances - event_at ; l'opération est observed_at).
4. Conflit de montants/actifs - Arrêt de Merge et quarantaine jusqu'au rapprochement du catalogue d'actifs.
5. Ligaments de pont - les reçus des deux côtés (src/dst) + receipt pairing sont requis.

10) Pseudo-requêtes et algorithmes

10. 1 Compiler les événements en une « opération » canonique

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 paires de ponts (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 Traitement des réorgues

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) Gestion des schémas et de l'évolution

Versioning : 'schema _ version' dans le chapeau du jeu de données, les migrations sont enregistrées dans le journal.
Stratégie de compatibilité : 'BACKWARD' pour les événements (ajout de champs uniquement).
Contrats de données avec sources : tests de contrats en IC, linters de circuits.

12) Qualité des données : SLI/SLO

• Freshness p95 : lag ingest→Gold (min).
• Completeness %: proportion d'enregistrements ayant atteint « finalized » dans la fenêtre.
• Correctness %: schémas/signatures/proufs valides.
• Proof Coverage %: proportion d'enregistrements canoniques avec prufs/ancres.
• Dedup Efficacité : proportion de prises absorbées idempotent.
• Reorg Handling Success %: handicaps et replays corrects.

SLO (repères) : Freshness ≤ 3 min (stream )/15 min (batch) ; Completeness ≥ 99. 7%; Correctness ≥ 99. 9%; Proof Coverage ≥ 99. 0%; Reorg Success ≥ 99. 9%; Merge MTTR (incident) ≤ 30 min.

13) Dashboards (maquettes)

Merge Ops (реал-тайм/час): Freshness, Queue lag, Dedup rate, Finalized %, Reorg spikes, Error-budget burn.
Proof & Finality: proof coverage, p95 finality per chain, challenge/reorg события.
Catalogue Health : divergences de mappings d'actifs, decimals, versions SDK.
Quality & Drift: completeness/correctness, schema drift, late data.
Finances Lens : GTV, Net Flow, TVL par chaînes/ponts (seulement « finalized »).

14) Configurations (YAML)

Fenêtres de finalisation

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

Politique et priorités de Merge

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

Idempotence/dedup

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

15) Vie privée et conformité

Minimisation des PII : PID/ORG_ID, interdiction des PII dans les métriques/labels.
Résidence de données : ségrégation des régions (EU/ROW), cryptage « au repos/en transit ».
Droit de suppression : tombstone/redaction événement avec application prouvable.
Audit : journaux immuables, ancrage des hachages, vérification de l'accès par rôle.

16) Règlements opérationnels

Au quotidien : rapprochement proof coverage, finalisation par chaînes, registre des ponts et config-drive.
Hebdomadaire : révision du catalogue des actifs/décimals, correction de la normalisation FX.
Tous les mois : tests reorg/replay, test SLO et test de stress de performance.
Gestion du changement : timelock sur les changements de politique merge, journal des solutions.

17) Playbook des incidents

A. Rassinchron des actifs/decimals

Stop aux actifs correspondants, recalculer le catalogue, recalculer les vitrines, rapport ≤ 24 h.

B. Chute du revêtement Proof

Redémarrage de la mercantilisation/ancrage, augmentation du niveau de logage, échantillonnage manuel de 100 cas, rapport.

C. Piki Reorg/Challenge

Agrandir 'k '/la fenêtre de litige, activer la finalisation delayed pour les sommes importantes, informer les intéressés.

D. Explosion des prises/répétitions

Serrer le dedup TTL/clé, limiter les sources « bruyantes », activer la quarantaine-boucle.

E. Dérive temporelle (time skew)

Synchronisation NTP/PTP, recalculage des fenêtres, décalage temporaire de la stratégie 'prefer : observed_at'.

18) Chèque de mise en œuvre

1. Enregistrez les sources, les fenêtres de finalisation et les preuves.
2. Insérez le schéma canonique des événements et la clé d'idempotence.
3. Configurez le dedup et la politique merge avec un contour quarantine.
4. Soulevez le registre des actifs/réseaux et la normalisation FX.
5. Implémentez replay/backfill et le traitement des données late.
6. Identifiez les SLI/SLO et les dashboards de qualité.
7. Lancez l'ancrage régulier et les journaux d'audit.
8. Effectuer le pilote avec des simulations de réorgues/retards de pont et enregistrer le MTTR.

19) Glossaire

Finality - irréversibilité de l'état/événement.
Reorg - recalage d'une chaîne avec annulation d'une partie des blocs.
Idempotency - résistance à la réintroduction.
Proof Coverage - Proportion de documents contenant des preuves probantes.
Entity Resolution - Association des adresses/comptes d'une entité unique.
Delayed Finalization - acceptation différée dans les agrégats pour les montants à haut risque.
Quarantine est un flux isolé pour les entrées en conflit/suspectes.

Résultat : la fusion correcte des données inter-chaînes est une discipline gérée : canonique, finalisation et proufes, idempotence stricte, politique transparente de fusion et observabilité de la qualité. En suivant ce cadre, l'écosystème obtient une couche de données unique, vérifiable et durable - la base pour l'audit, l'analyse et la mise à l'échelle sûre des produits.