Fusión de datos de diferentes circuitos

(Sección: Ecosistema y Red)

1) Por qué se necesita una fusión

• Fuente única de la verdad (hechos canónicos) cuando hay registros de varios caracteres.
• Resistencia a las réordas y retrasos: finalización y reencarnación correctas.
• Comparabilidad de métricas entre redes y activos.
• Lineaje transparente y control de calidad para auditorías y reguladores.

2) Fuentes y clases de datos

1. Onchain: bloques, transacciones, registros de contratos, títulos, estados.
2. Puentes/relés: solicitudes, recibos, pruebas, estados de finalización.
3. L2/DA capas: batches, publicaciones, prufas, ventanas de disputa.
4. PSP/KYC/KYB/AML: estados de pago, auditorías, éxitos sancionadores.
5. Eventos de productos: onboarding, depósitos/pagos, juegos y eventos de comportamiento.
6. Referencias: redes, activos, decimals, chainId, direcciones, versiones SDK.

Para cada fuente se fijan: propietario, esquema, valor de actualización, ventana de finalización, formato de prueba y SLO.

3) Arquitectura de fusión de pipeline

Ingest (agentes/indexadores/webhook) → Raw/Bronze (materias primas inmutables) → Clean/Silver (normalización y dedoup) → Merge/Core/Gold (hechos canónicos y comunicaciones) → Marts (finanzas/producto/riesgo/operación) → Serve OLAP/API/búsqueda).
Propiedades clave: idempotencia, versionamiento de esquemas, replay/backfill, late data handling.

4) Esquemas canónicos (simplificado)

4. 1 Eventos (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 Traducciones y puentes (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 Directorio de activos/redes (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) Finalización, reorgía y estados

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

• K-confirmaciones por red/activo/riesgo.
• Finalización Delayed para grandes cantidades.
• Reorg handling: discapacidad automática y replay.
• Cobertura Proof: proporción de registros con ranuras/anclajes ≥ SLO objetivo.

6) Normalización del tiempo y las monedas

Tiempo: todos los timestampts en UTC, almacenar 'observed _ at' y 'event _ at'.
FX/precios de activos: conversión de 'usd _ value' al tipo de cambio de 'observed _ at' (o 'event _ at' - para informar, determinado por la política).
Decimals/scale: canonización estricta de las cantidades para la comparabilidad.
Zonas horarias en los informes: resolviéndose en la selección (escaparate), no en el núcleo.

7) Idempotencia y deduplicación

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

• Repeticiones de varios índices - upsert por idempotency_key.
• En un conflicto de payload: se activa la política de la verdad (prioridad de origen/versión/tiempo).
• La ventana del dedoop se almacena ≥ 48-72 h para repeticiones «vagabundas».

8) Solución de entidad (asignación de entidades)

Direcciones → actores: monedero/contrato → usuario/organización/rol.
Enlaces cruzados: hard-link (firma/kyc), soft-link (comportamiento/grafo).
Pseudonimización: PID/ORG_ID estable; El PII se almacena en el controlador de datos.

9) Reglas de fusión y prioridades (Política)

1. La fuente de la verdad sobre el hecho de la traducción es el evento onchain 'finalizado' + pruff.
2. La fuente de la verdad por agregados es el núcleo de la tabla 'transfers' bridge _ transfers', no «materia prima».
3. Conflicto de tiempo (event_at vs observed_at) - por política de informe (finanzas - event_at; operación - observed_at).
4. Conflicto de montos/activos: detenga el valor y la cuarentena antes de conciliar el catálogo de activos.
5. Ligamentos de puente: se requieren recibos de ambos lados (src/dst) + receipt pairing.

10) Pseudo-consultas y algoritmos

10. 1 Reducción de eventos en una «operación» canónica

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 Juegos de pares de puentes (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 Tratamiento de reorgas

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) Gestión de esquemas y evolución

Versioning: 'schema _ version' en la tapa del conjunto de datos, las migraciones se registran en el registro.
Política de compatibilidad: 'BACKWARD' para eventos (sólo agregar campos).
Contratos de datos con fuentes: pruebas de contratos en CI, linternas de circuitos.

12) Calidad de los datos: SLI/SLO

• Freshness p95: lag ingest→Gold (min).
• Completeness%: porcentaje de entradas que han alcanzado 'finalizado' dentro de la ventana.
• Correctness%: esquemas válidos/firmas/prufas.
• Cobertura de prueba%: proporción de registros canónicos con prufas/anclajes.
• Dedup Efficiency: proporción de tomas absorbidas de forma idempotente.
• Reorg Handling Éxito%: válido para discapacitados y respuestas.

SLO (puntos de referencia): Freshness ≤ 3 min (stream )/15 min (batch); Completeness ≥ 99. 7%; Correctness ≥ 99. 9%; Proof Coverage ≥ 99. 0%; Reorg Success ≥ 99. 9%; Merge MTTR (incidente) ≤ 30 minutos.

13) Dashboards (diseños)

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: discrepancias de mappings de activos, decimals, versiones de SDK.
Quality & Drift: completeness/correctness, schema drift, late data.
Finance Lens: GTV, Net Flow, TVL por circuitos/puentes (solo 'finalizados').

14) Configuraciones (YAML)

Ventanas de finalización

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

Políticas y prioridades 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"]

Idempotencia/dedoup

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

15) Privacidad y cumplimiento

PII-minimización: PID/ORG_ID, prohibición de PII en métricas/etiquetas.
Residencia de datos: segregación de regiones (EU/ROW), cifrado «en reposo/en tránsito».
Derecho de eliminación: tombstone/redaction evento con aplicación probada.
Auditoría: registros inmutables, anclaje de hashes, comprobación de acceso por roles.

16) Normas de funcionamiento

Diariamente: comprobación de coverage proof, finalización de circuitos, registro de puentes y derivación.
Semanalmente: revisión del catálogo de activos/decimals, corrección de la normalización FX.
Mensualmente: pruebas de reorg/replay, prueba de SLO y prueba de rendimiento de estrés.
Change Management: timelock sobre cambios de políticas merge, registro de soluciones.

17) Incidentes de Playbook

A. Rassinchron activos/decimals

Detener los activos relevantes, revertir el catálogo, volver a calcular los escaparates, informe ≤ 24 horas

B. Caída de Proof Coverage

Reinicio de Merclization/Ankering, aumento del nivel de lógica, muestra manual de 100 casos, informe.

C. Picky Reorg/Challenge

Aumentar 'k '/ventana de disputa, habilitar la finalización delayed para grandes cantidades, notificar a los interesados.

D. Explosión de tomas/repeticiones

Apriete el dedoup TTL/clave, limite las fuentes «ruidosas», habilite el circuito de cuarentena.

E. Deriva del tiempo (time skew)

Sincronización NTP/PTP, recuento de ventanas, cambio temporal de política 'prefer: observed_at'.

18) Lista de verificación de implementación

1. Fije las fuentes, las ventanas de la finalización y la evidencia.
2. Implemente un esquema canónico de eventos y una clave de idempotencia.
3. Configure la política de dedoup y merge con un contorno quarantine.
4. Levante el registro de activos/redes y la normalización FX.
5. Implemente replay/backfill y procesamiento de datos late.
6. Identificar SLI/SLO y dashboards de calidad.
7. Inicie el anclaje y los registros de auditoría regulares.
8. Conduzca el piloto con simulaciones de retardo de reorgas/puentes y fije el MTTR.

19) Glosario

Finalidad - irreversibilidad del estado/evento.
Reorg - Reconfiguración de la cadena con anulación de parte de los bloques.
Idempotency - resistencia a la re-entrega.
Proof Coverage es una fracción de los registros con evidencia válida.
Solución de entidad: correlación de direcciones/cuentas de una sola entidad.
Delayed Finalization - Aceptación diferida en unidades para cantidades de alto riesgo.
Quarantine es un flujo aislado para registros de conflictos/sospechas.

En pocas palabras: la correcta fusión de datos entre cadenas es una disciplina manejable: esquema canónico, finalización y prufas, idempotencia estricta, política de fusión transparente y observabilidad de calidad. Siguiendo este marco, el ecosistema obtiene una capa de datos única, verificable y sostenible, una base para la auditoría, la analítica y la escala segura de los productos.