GH GambleHub

Analiza între lanțuri

(Secțiunea: Ecosistem și rețea)

1) Ce este analiza inter-lanț și de ce este necesar

Cross-chain analytics este o metodologie și stivă care combină telemetria și evenimentele din mai multe lanțuri, punți, furnizori și aplicații într-un singur model de date. Obiective:
  • Contabilitate unificată a valorii și activității: volume, lichidități, comisioane, retenție.
  • Observabilitatea podurilor și conexiunilor P2P: finalizare, lag-uri, reorg/provocare evenimente.
  • Atribuirea traficului și a conversiei: cheyn→cheyn, kanal→produkt.
  • Risc și conformitate: LMA, sancțiuni, fraudă comportamentală, identificarea entității.
  • Luarea deciziilor: OKR/bugete, limite, actualizare și reglementări privind lichiditățile.

2) Surse de date și evenimente (listă canonică)

1. Lanțuri/registre: blocuri, tranzacții, jurnale de evenimente, stări de contracte inteligente.
2. Punți: aplicații, chitanțe, dovezi (ușoare/optimiste/ZK), statusuri de finalizare.
3. Prestatori de plăți/CSC: cecuri de trecere, limite, statusuri de plată.
4. Evenimente de produs: onboarding, depozite/pariuri/concluzii, jocuri și valori comportamentale.
5. Transport P2P: încasări Pub/Sub, succes RPC, latență.
6. Cărți de referință: rețele, active, zecimale, lanțID, adrese de contract, versiuni SDK.

💡 Pentru fiecare sursă, fixați: schemă, jurnal de actualizare, „fereastră de finalizare”, proprietar, SLO.

3) Arhitectura datelor (fluxuri și stocări)

Ingera (streaming): conectori la noduri/indici, punți pentru cărți web, CDC din bazele de date de operare.
Raw (Bronze/Raw): loturi imuabile etichetate "observed _ at' cu metadate sursă.
Compensare/normalizare (argint): dedup, îmbogățire semantică, aliniere fus orar, cartografiere active.
Modele de kernel (Aur/Core): fapte unificate "transferuri", "punți", "onchain _ events'," kyc _ status "," plăți ".
Marte: finanțe (GTV/TVL/Take Rate), produs (retenție/pâlnii), risc (scoring), sistem de operare (SLO).
Cache/Servire: OLAP/HTAP pentru tablouri de bord și API-uri și o căutare separată de adrese/tx.

Transport: Kafka/Pulsar (exact o dată semantica peste idempotency), depozit obiect pentru materii prime, parchet/formate coloană pentru analiză.

4) Finalizare, reorgs și idempotence

Stările de eveniment sunt „observate” → „confirmate (k)” → „finalizate” → „invalidate (reorg)”.
Regula K-confirmări - Configurat de tip rețea/activ.
Ferestre optimiste/Challenge: Suport pentru starea „contestată” pentru poduri.
Idempotency: 'idempotency _ key = chainId' block' tx 'logIndex' topic '(sau sarcină utilă hash).
Reluare: restituire programată și recuperare schimbare index.

5) Modelul de rezoluție a entității

Adresa → Actor: adrese, chei, portofele ↔ cont/organizare/furnizor.
Grafic cu lanț încrucișat: relațiile de adresă de către un singur proprietar (euristică, semnături, date despre îmbarcare).
Niveluri de încredere: hard-link (KYC, semnătură on-chain), soft-link (corelații comportamentale).
Aliasing: Stocați identificatori stabili (PID) în loc de PII în analytics.

6) Diagrama evenimentului unificat (simplificată)

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) Normalizarea activelor și prețurilor

Directorul de active canonice: simbol, zecimale, cartografiere în lanț, adrese de contract.
Normalizarea FX: ratele istorice și prețurile activelor la marcajul temporal "observed _ at'.
Pachete multi-active: Grupul „înfășurat” și activele native.

8) Măsurători și vitrine cheie

8. 1 Finanţe şi lichidităţi

GTV (Volumul brut al tranzacției) asupra rețelelor/activelor/punților.
TVL și Net Flow peste poduri și piscine.
Ia Rata/Taxa de volum; Cost-to-Serve pentru transfer.
Plata SLA Rata de succes, Finalitate p50/p95, în așteptare Backlog.

8. 2 Produs și utilizator

Lanț încrucișat MAU/DA (dedup по PID),

retenție D1/D7/D30 luând în considerare activitatea multi-lanț,

Pâlnie: rețea de intrare → punte → produs țintă → acțiune.
QoT (calitatea traficului): validarea traficului după antifraudă.

8. 3 Risc și conformitate

Rata de fraudă/litigii, Scor de risc ridicat%, Sancțiuni lovit%.
Rata de anomalie prin modele de traducere, verificarea vitezei, gruparea.
KYB/KYC Pass% și temporizări.

8. 4 Sistem de operare și SLO

Bridge Success-Rate, p95 Finalitate, Releu Disponibilitate,

Reorg/Provocare evenimente, Eroare buget arde.

9) Exemple de interogare SQL/Pseudo

GTV de perechi de circuite

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;

Retenție încrucișată 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;

SLO Bridge Showcase

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) Atribuire și cale multi-canal

modelul bazat pe ultima atingere/poziție, cu greutăți pentru sursa de rețea, punte și produs.
UTM→On -chain: asociați clicurile/trimiterile cu adresa onchain la îmbarcare (cu consimțământul).
Modele asociative: Shapley/Markov pentru căi complexe de set→most→produkt.

11) Semnale antifraudă și comportamentale

Caracteristici grafice: contrapărți comune, transferuri circulare, cifră de afaceri rapidă.
Limite de viteză și anomalii: explozii, „împărțirea” cantităților, clustere de noapte.
Scheme de fraudă punte: retransmisie, încercări de by-pass KYC, modele sandwich cu lichiditate.
Modele: impulsionarea gradientului/încorporarea graficului; preda pe marcaj incident.

12) Confidențialitate și conformitate (confidențialitate prin design)

Minimizare PII: PID în loc de identificatori direcți, tokenizare.
Rezidența datelor: partiționarea pe regiuni, criptarea „în repaus/pe drum”.
Dreptul de a șterge: evenimente de piatră funerară/redactare cu provabilitate.
Acces și audit: ACL-uri de rol, jurnale de citire, rapoarte semnate pentru verificări.

13) SLI/SLO pentru conducte analitice

SLI (exemplu):
  • Prospeţime (lag median de la 'observed _ at' la apariţia în Gold),
  • caracterul complet (% din evenimentele fără găuri, conform așteptărilor confirmărilor K)
  • Corectitudinea (% din evenimentele validate prin scheme/reguli)
  • Reorg de manipulare succes
  • Serviți latența (cereri p95 la storefronturi/tablouri de bord).
SLO (repere):
  • Prospețime p95 ≤ 3 min (streaming), ≤ 15 min (lot).
  • Integralitatea ≥ 99. 7%, Corectitudine ≥ 99. 9%.
  • Reorg manipulare succes ≥ 99. 9%.
  • Serviți p95 ≤ 500 ms (vitrine principale).

14) Observabilitate și descendență

Lineage de date: de la tabloul de bord la eveniment brut (nivel de coloană).
Semnale de calitate: integritate, unicitate, integritate referențială, derivă schemă.
Alerte: „eșecuri silențioase” (fără date noi), salturi de distribuție, creșterea câmpurilor „necunoscute”.

15) Tablouri de bord (șabloane)

A. Cross-Chain Ops (timp real/oră):
  • Rata de succes, finalitatea p95, disponibilitatea releului, provocarea/reorg, restanțe, arderea bugetului de eroare.
B. Lichiditate și cost (zi/săptămână):
  • TVL, Net Flow per lanț, cost-per-transfer, utilizare, fond de asigurare.
C. Produs & Creștere (săptămână/lună):
  • MAU/DA (dedup), retenție în lanț încrucișat, canal pâlnii, QoT.
D. Risc și conformitate (săptămână):
  • Rata fraudei/litigiilor, lovituri de sancțiuni, cota de risc ridicat, viteza procedurilor.

16) Reglementări de funcționare și playbook

Incident: Lag de prospețime> SLO

Verificați conectori/indexori, treceți la backup, activați modul de degradare (vitrinele arată „ultimul finalizat”), eskalatați la proprietarul sursei.

Incident: reorg/provocare val

Măriți K-confirmări/fereastra de litigii, permiteți „finalizarea întârziată” pentru sume mari, notificați bridge/operatorii.

Incident Moneda/Divergența activelor

Înghețați perechile afectate, întoarceți directorul, recalculați normalizarea USD, publicați un raport.

Incident: Fraudă/Salt în dispută

Strângeți limitele/punctajul, activați revizuirea manuală cu risc ridicat, terminați instruirea modelului pe un model proaspăt.

17) Exemplu de configurare (Pseudo-YAML)

Ferestre de finalizare prin rețele

yaml finality:
eth-mainnet: 12  # блоков polygon: 256 solana: "optimistic: 32 slots"
optimistic-bridge: { challenge_minutes: 20 }
zk-bridge: { proof_time_sla: 180 }

Reguli de idempotență și deduplicare

yaml dedup:
key_template: "${chain_id}    ${block_height}    ${tx_hash}    ${log_index}    ${event_type}"
ttl_hours: 48

Conducte SLO

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) Lista de verificare a implementării

1. Captura surse, scheme, ferestre de finalizare și proprietarii.
2. Activați idempotența și reorg-handling (state + reluare).
3. Construiți un sâmbure de modele (transfers/bridges/onchain_events/kyc/payouts).
4. Configurați directoare de active și normalizarea FX.
5. Definiți conducta SLI/SLO și tablouri de bord.
6. Implementați rezoluția entității și confidențialitatea prin proiectare.
7. Includeți scorurile antifraudă și reglementările privind incidentele.
8. Rula backfill și teste pe cazuri istorice reorg/provocare.
9. Scheme de revizuire regulată, greutăți metrice și surse.

19) Glosar

Finalitatea - ireversibilitatea statului/evenimentului.
Reorg - reasamblarea lanțului, ceea ce duce la anularea unei părți a blocurilor.
Perioada de provocare - o fereastră de provocare în modele optimiste.
Rezoluția entității - cartografierea adreselor/conturilor unei singure entități.
GTV/TVL - volumul tranzacției/valoarea blocată.
Exhaustivitate/prospețime/corectitudine - măsurători de bază ale calității datelor.

Concluzie: analiza între lanțuri nu este doar un rezumat al măsurătorilor, ci o disciplină ușor de gestionat: o singură schemă de evenimente, finalizarea corectă, conducte stabile, confidențialitate, antifraudă și vitrine ușor de înțeles. Urmând acest cadru, ecosistemul primește o viziune cu adevărat "end-to-end' asupra valorii, riscului și creșterii - de la bloc brut la soluție de afaceri.

Contact

Contactați-ne

Scrieți-ne pentru orice întrebare sau solicitare de suport.Suntem mereu gata să ajutăm!

Telegram
@Gamble_GC
Pornește integrarea

Email-ul este obligatoriu. Telegram sau WhatsApp sunt opționale.

Numele dumneavoastră opțional
Email opțional
Subiect opțional
Mesaj opțional
Telegram opțional
@
Dacă indicați Telegram — vă vom răspunde și acolo, pe lângă Email.
WhatsApp opțional
Format: cod de țară și număr (de exemplu, +40XXXXXXXXX).

Apăsând butonul, sunteți de acord cu prelucrarea datelor dumneavoastră.