GH GambleHub

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.

💡 Pour chaque source, fixez : schéma, mise à jour, « fenêtre de finalisation », propriétaire, SLO.

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).
SLO (repères) :
  • 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.
B. Liquidité & Cost (jour/semaine) :
  • TVL, Net Flow per chain, cost-per-transfer, utilisation, fonds d'assurance.
C. Product & Growth (semaine/mois) :
  • MAU/DAU (dedup), retraite cross-chain, entonnoirs de canal, QoT.
D. Risque et conformité (semaine) :
  • 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.

Contact

Prendre contact

Contactez-nous pour toute question ou demande d’assistance.Nous sommes toujours prêts à vous aider !

Telegram
@Gamble_GC
Commencer l’intégration

L’Email est obligatoire. Telegram ou WhatsApp — optionnels.

Votre nom optionnel
Email optionnel
Objet optionnel
Message optionnel
Telegram optionnel
@
Si vous indiquez Telegram — nous vous répondrons aussi là-bas.
WhatsApp optionnel
Format : +code pays et numéro (ex. +33XXXXXXXXX).

En cliquant sur ce bouton, vous acceptez le traitement de vos données.