Analyse inter-chaînes
(Section : Écosystème et réseau)
1) Qu'est-ce que l'analyse inter-chaînes et pourquoi il est nécessaire
L'analyse inter-chaînes (cross-chain analytics) est une méthodologie et un stack qui combine la télémétrie et les événements de plusieurs circuits, ponts, fournisseurs et applications en un seul modèle de données. Objectifs :- Comptabilité unique de la valeur et de l'activité : volumes, liquidités, commissions, rétentions.
- Observabilité des ponts et des liens P2P : finalisation, lagune, reorg/challenge events.
- Attribution du trafic et des conversions : cheyn→cheyn, kanal→produkt.
- Risque et conformité : AML, sanctions, frondes comportementales, identification des entités.
- Prise de décision : OKR/budgets, limites, règlements de renouvellement et liquidités.
2) Sources de données et événements (liste canonique)
1. Circuits/registres : blocs, transactions, logs d'événements, états des contrats intelligents.
2. Ponts : demandes, reçus, preuves (light/optimistic/ZK), statuts de finalisation.
3. Fournisseurs de paiement/CUS : passage des contrôles, limites, statuts de paiement.
4. Événements alimentaires : onbording, dépôts/paris/retraits, mesures du jeu et du comportement.
5. Transport P2P : reçus Pub/Sub, succès RPC, latency.
6. Guides : réseaux, actifs, decimals, chainId, adresses des contrats, versions SDK.
3) Architecture des données (flux et stockage)
Ingest (streaming) : connecteurs aux nodes/indexeurs, webhooks des ponts, CDC des bases de données opérationnelles.
Couches brutes (Bronze/Raw) : lots immuables avec l'étiquette "observed _ at'et les métadonnées source.
Nettoyage/normalisation (Silver) : dedup, enrichissement sémantique, alignement du timzon, mapping des actifs.
Modèles de noyau (Gold/Core) : faits unifiés 'transfers', 'bridges', 'onchain _ events', 'kyc _ status', 'payouts'.
Vitrines (Marts) : Finances (GTV/TVL/Take Rate), produit (Retensh/Entonnoir), risque (scorings), exploitation (SLO).
Cache/Serve : OLAP/HTAP pour dashboards et API, et recherche séparée par adresse/tx.
Transport : Kafka/Pulsar (exactly-once semantics au-dessus de l'idempotence), stockage d'objets pour les matières premières, parquet/formats de colonne pour l'analyse.
4) Finalisation, réorgues et idempotence
États des événements : 'observed' → 'confirmed (k)' → 'finalized' → 'invalidated (reorg)'.
Règle de confirmation (K-confirmations) : Configurée selon le réseau/type d'actif.
Fenêtre Optimistic/Challenge : soutien au statut « contesté » pour les ponts.
Idempotence : 'idempotency _ key = chainId'block 'tx' logIndex 'topic' (ou hachage de charge utile).
Jeu de plumes (replay) : backfill planifié et récupération lors du changement d'index.
5) Modèle d'identité et d'entité (résolution d'entity)
L'adresse → l'Acteur : les adresses, les clés, les bourses ↔ le compte/organisation/provider.
Graphe croisé : liens d'adresses par un seul propriétaire (heuristiques, signatures, données d'onbording).
Niveaux de confiance : hard-link (KYC, signature en ligne), soft-link (corrélations comportementales).
Pseudonyme : Stockez des identifiants stables (PID) au lieu de PII dans l'analyse.
6) Schéma unifié des événements (simplifié)
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) Normalisation des actifs et des prix
Répertoire canonique des actifs : symbole, décimales, mapping de chaine, adresses contractuelles.
Normalisation FX : cours historiques et prix des actifs selon le temps « observé _ at ».
Bandles multi-actifs : regroupez les actifs « enveloppés » et natifs.
8) Métriques et vitrines clés
8. 1 Finances et liquidité
GTV (Gross Transaction Volume) sur les réseaux/actifs/ponts.
TVL et Net Flow sur les ponts et les piscines.
Take Rate/commission de volume ; Cost-to-Serve pour le transfert.
Payout SLA Hit Rate, Finality p50/p95, Pending Backlog.
8. 2 Produit et utilisateur
Cross-chain MAU/DAU (dedup по PID),
Retraite D1/D7/D30 compte tenu de l'activité multiple,
Funnel : réseau d'entrée → pont → produit cible → action.
QoT (qualité du trafic) : valide du trafic après anti-frod.
8. 3 Risque et conformité
Fraud/Dispute Rate, High-Risk Score%, Sanctions Hit%.
Taux d'anomalie sur les modèles de traduction, velocity-chèque, clustering.
KYB/KYC Pass % et timings.
8. 4 Opération et SLO
Bridge Success-Rate, p95 Finality, Relay Availability,
Reorg/Challenge events, Error budget burn.
9) Exemples de SQL/pseudo-requêtes
GTV par paires de circuits
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;
Vitrine pour le pont 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) Attribution et chemin multi-canal
Modèle last-touch/position-based avec balances pour la source du réseau, du pont et du produit.
UTM→On -chain : associez les clics/renvois à l'adresse onchain lors de l'onbording (avec le consentement).
Modèles associatifs : Shapley/Markov pour les chemins complexes de « set→most→produkt ».
11) Antifrod et signaux comportementaux
Caractéristiques graphiques : contreparties générales, traductions circulaires, enroulement rapide.
Limites et anomalies de Velocity : surtensions, « écrasement » des montants, clusters nocturnes.
Schémas de fraude sur les ponts : réapprovisionnement, tentatives de contournement de KYC, schémas sandwich avec liquidité.
Modèles : gradient boosting/graph-embeddings ; Former sur le marquage des incidents.
12) Intimité et conformité (privacy-by-design)
Minimisation PII : PID au lieu d'identifiants directs, tokenisation.
Data residency : répartition par région, cryptage « au repos/en transit ».
Droit de suppression : tombstone/redaction-events avec preuve.
Accès et vérification : ACL de rôle, journaux de lecture, rapports signés pour les vérifications.
13) SLI/SLO pour les piplines analytiques
SLI (exemple) :- Freshness (la lagune médiane de 'observed _ at' à l'apparition dans Gold),
- Completeness (% des événements sans trous selon les attentes de K-confirmations),
- Correctness (% des événements ayant subi des validations de schémas/règles),
- Reorg handling success (% d'invalidités/de rejoues correctes),
- Serve latency (p95 demandes de vitrines/dashboards).
- Freshness p95 ≤ 3 min (streaming), ≤ 15 min (batch).
- Completeness ≥ 99. 7%, Correctness ≥ 99. 9%.
- Reorg handling success ≥ 99. 9%.
- Serve p95 ≤ 500 ms (vitrines principales).
14) Observabilité des données et lignage
Data Lineage : du dashboard à l'événement brut (column-level).
Signaux de qualité : completeness, uniqueness, integrity referential, schema drift.
Alert : « pannes silencieuses » (pas de nouvelles données), surtensions des distributions, croissance des champs 'unknown'.
15) Dashboards (modèles)
A. Cross-Chain Ops (temps réel/heure) :- Success-Rate, p95 Finality, Relay Availability, Challenge/Reorg, backlog, error budget burn.
- TVL, Net Flow per chain, cost-per-transfer, utilisation, fonds d'assurance.
- MAU/DAU (dedup), retraite cross-chain, entonnoirs de canal, QoT.
- Fraud/Dispute Rate, santé hits, high-risk share, rapidité des procédures.
16) Règlements opérationnels et playbook
Incident : fraicheur> SLO
Vérifiez les connecteurs/indexeurs, passez à la réserve, activez le mode dégradé (les vitrines montrent « dernier finalisé »), eskalate au propriétaire de la source.
Incident : sursaut de réorg/challenge
Augmenter K-confirmations/fenêtre de litige, inclure « finalisation delayed » pour les sommes importantes, alerter le pont/opérateurs.
Incident : divergence des monnaies/actifs
Geler les couples touchés, faire tomber le manuel, relire la normalisation USD, publier le rapport.
Incident : saut Fraud/Dispute
Resserrer les limites/scoring, activer la rhubarbe manuelle high-risk, terminer le modèle sur un modèle frais.
17) Exemple de configuration (pseudo-YAML)
Fenêtres de finalisation réseau
yaml finality:
eth-mainnet: 12 # блоков polygon: 256 solana: "optimistic: 32 slots"
optimistic-bridge: { challenge_minutes: 20 }
zk-bridge: { proof_time_sla: 180 }
Règles d'idempotence et de dédoublement
yaml dedup:
key_template: "${chain_id} ${block_height} ${tx_hash} ${log_index} ${event_type}"
ttl_hours: 48
SLO des piplines
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) Chèque de mise en œuvre
1. Enregistrez les sources, les schémas, les fenêtres de finalisation et les propriétaires.
2. Activez l'idempotence et le reorg-handling (states + replay).
3. Construisez le noyau des modèles (transfers/bridges/onchain_events/kyc/payouts).
4. Personnalisez les guides d'actifs et la normalisation FX.
5. Identifiez les SLI/SLO des pipelines et des dashboards.
6. Réalisez la résolution d'entity et privacy-by-design.
7. Activez les scores anti-froid et le règlement des incidents.
8. Effectuez des backfill et des tests sur des cas historiques de reorg/challenge.
9. Révisez régulièrement les schémas, le poids des métriques et les sources.
19) Glossaire
Finality - irréversibilité de l'état/événement.
Reorg est un réassemblage de la chaîne qui entraîne l'annulation d'une partie des blocs.
Challenge period est une fenêtre de contestation dans les modèles optimistes.
Entity resolution - mappage des adresses/comptes d'une entité unique.
GTV/TVL - volume des transactions/valeur bloquée.
Completeness/Freshness/Correctness sont des mesures de base de la qualité des données.
Résultat : l'analyse inter-chaînes n'est pas seulement un résumé des mesures, mais une discipline gérable : un schéma unique des événements, une finalisation correcte, des piplines durables, la vie privée, l'anti-fred et des vitrines compréhensibles. En suivant ce cadre, l'écosystème obtient une vision vraiment « de bout en bout » de la valeur, des risques et de la croissance - du bloc brut à la décision d'affaires.