Escala de nodos de red

(Sección: Ecosistema y Red)

1) Roles de nodo y trazados de tráfico

Validación/producción (consensus/block/rollup-sequencer): vía crítica de finalización.
Lector/indexador (read-only/API/archivo): atiende las solicitudes de aplicaciones y análisis.
Releer/bridge (cross-domain): transfiere mensajes/activos entre dominios.
Gateway/edge (ingress/gRPC/WebSocket/QUIC): recepción de solicitudes de cliente, rate-limit, caché.
Métrica/observabilidad del cuerpo: recolección de métricas/registros/tracks, muestras sintéticas.

Para cada función, sus propios SLOs, presupuesto de errores y política de zoom.

2) Modelos de escala

2. 1 Vertical (escala-arriba)

Aumento de la CPU/RAM/SSD/NIC. Rápido para los picos, pero limitado al hierro y puede aumentar el costo unitario del tráfico.

2. 2 Horizontal (scale-out)

Agrega réplicas detrás de balanceadores/colas. Requiere idempotencia, políticas sticky, quórum y cachés acordados (o su discapacidad).

2. 3 Separación funcional

Separación de responsabilidades: los nodos de consensus se aíslan; RPC/API - por separado; indexador/archivo - por separado; bridge/relayer - por separado.

2. 4 Geo-skale

Agrupaciones regionales (EU/US/AP) + anycast/GeoDNS/Latency Aware LB; replicación con finalización/latencia y cachés locales.

2. 5 Charding/lote

División por claves (chainId, shard, topic) para colas/indexadores y almacenes de columnas.

3) Ruta de consulta: equilibrio, almacenamiento en caché, QoS

Equilibrio L4/L7: health-checks, sticky por token/trace-id, circuit-breaker, outlier-ejection.

• en edge (short-TTL para RPCs de lectura frecuente);
• dentro del procesador (read-through, write-around para índices);
• caché negativa (no se encontró).
• Clases QoS: P0 (finalización/puente/pagos), P1 (productos), P2 (bulk/archivo).
• Backpressure: tokens/créditos, restricción de solicitudes concur, colas con DLQ.
• Admisiones: pre-filtro (auth, límites, geo/sanciones), rechazo temprano de solicitudes «caras».

4) Control de la condición: apretones, pruning, archivo

Full/Pruned: nodos pruned para RPC; Archivo: para consultas retrospectivas en un grupo separado.
Snapshots/fast-sync: snapshots regulares, bootstrap rápido de nuevas réplicas.
Hot/Warm/Cold almacenamiento: estado caliente en NVMe, bloques históricos - S3/objeto con índices.
Garbadge-collect/compaction: ventanas planificadas, no durante los picos.
Buffers DA/Batch (para L2/puentes): garantía de entrega y período de limpieza con recibos pruf.

5) Colas y procesamiento de streaming

Ingress: Kafka/Pulsar/NATS с partition-key = `chainId|shard|topic`.
Grupos de consumo: escala por lotes, manejador idempotente (outbox/inbox).
DLQ y retraídas: retroceso exponencial, cuarentena de mensajes.
Orden acordado: dentro del partido para el determinismo.

6) Optimizaciones de transporte y red

QUIC/HTTP/2: multiplexación, corrección head-of-line.
Afinación TCP: BBR/CUBIC, búferes ampliados, 'SO _ REUSEPORT'.
Kernel/eBPF: pila de red acelerada, hash consistente para equilibrar.
NIC offload и pinning IRQ к NUMA.
gRPC: parámetros keepalive/ping, restricciones max-inflight.
WebSocket: grupos de conexiones, ping/pong, limitación de suscripciones al cliente.

7) Confiabilidad: quórum, degradación, pruebas de caos

Quórum de lectura/escritura (si corresponde), líder de la formación.
Modos de degradación: readonly, «sólo finalizados», apagando métodos pesados.
Chaos-engineering: retrasos/pérdidas, reinicios, fallas de disco/red, scripts de «alta velocidad».

8) SLI/SLO y objetivos

• p95 RPC latencia por clases de métodos;
• Success-rate; Queue-lag p95;
• Time-to-finality p95 (para relés/puentes);
• Snapshot bootstrap time;
• State growth/day; CPU/IO saturation.

• P0 RPC p95 ≤ 400 ms; Availability ≥ 99. 95%;
• Finality relay p95 ≤ 3 min;
• Queue-lag P0 p95 ≤ 2 с;
• Bootstrap new reader ≤ 30 мин (fast-sync+snapshot);
• Error budget burn por ventana de 2 horas ≤ 2 ×.

9) Observabilidad y alerting

Métricas: latency (histograma), RPS, errors (por clases), queue-lag, GC/heap, disk-io, p2p peers, gossip-rate.
Tracks: end-to-end 'trace _ id' a través de edge→RPC→indeksator→khraneniye→most.
Logs: estructurado, correlación por 'request _ id'.
Alertas: burn-rate P0, queue-lag, peer-count por debajo del umbral, reorg spikes, snapshot-drift.

10) Patrones de patinaje automático

HPA/VPA (K8s): по CPU/latency/RPS/queue-lag; KEDA en longitud de topics.
Paso a paso: perfiles de picos diurnos; Predictivo por ML/estacionalidad.
Warm-spares: réplicas calientes sin tráfico (promoción graceful).
Safe rollout: canary + outlier-ejection + SLO-гейты.

11) Seguridad y aislamiento

mTLS/pinning de claves; RBAC/ABAC sobre métodos; Límites de QoS per org/tenant.
Rate-limit y DoS-shield: tokens, capchi para RPCs públicos, anomalía-detecto.
Gestión de secretos: fichas de vida corta, rotación.
Sandbox: pools separados para archivos/clientes públicos.

12) Configuraciones de referencia

12. 1 K8s: Puerta de enlace RPC (escala horizontal)

yaml apiVersion: apps/v1 kind: Deployment metadata: { name: rpc-gateway }
spec:
replicas: 6 strategy: { type: RollingUpdate, rollingUpdate: { maxSurge: 2, maxUnavailable: 0 } }
selector: { matchLabels: { app: rpc-gateway } }
template:
metadata: { labels: { app: rpc-gateway, qos: P0 } }
spec:
containers:
- name: gateway image: org/rpc-gateway:2. 4. 1 ports: [{ containerPort: 443 }]
resources:
requests: { cpu: "1", memory: "2Gi" }
limits:  { cpu: "4", memory: "6Gi" }
env:
- { name: MAX_CONCURRENCY, value: "400" }
- { name: CACHE_TTL_MS, value: "200" }
readinessProbe: { httpGet: { path: /healthz, port: 443 }, initialDelaySeconds: 5, periodSeconds: 5 }
livenessProbe: { httpGet: { path: /livez, port: 443 }, initialDelaySeconds: 10, periodSeconds: 10 }
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: { name: rpc-gateway-hpa }
spec:
scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: rpc-gateway }
minReplicas: 6 maxReplicas: 36 metrics:
- type: Pods pods:
metric:
name: request_latency_p95_ms target:
type: AverageValue averageValue: 350m  # 350 мс

12. 2 Envoy: priorización y outlier-ejection

yaml clusters:
- name: readers type: EDS lb_policy: LEAST_REQUEST outlier_detection:
consecutive_5xx: 5 interval: 2s base_ejection_time: 30s circuit_breakers:
thresholds:
- priority: DEFAULT max_connections: 20000 max_pending_requests: 5000 max_requests: 20000 health_checks:
- timeout: 1s interval: 3s http_health_check: { path: /healthz }
route_config:
request_headers_to_add:
- header: { key: x-trace-id, value: "%REQ(X-TRACE-ID)%" }
weighted_clusters:
clusters:
- name: readers weight: 100

12. 3 Kafka: partición por dominios

yaml topic: "rpc. events"
partitions: 48 replicationFactor: 3 config:
retention. ms:  604800000 # 7 days max. message. bytes: 1048576 min. insync. replicas: 2 cleanup. policy: delete

12. 4 Políticas y límites de QoS

yaml qos:
P0:
rps_limit_per_org: 1500 queue_lag_p95_ms: 2000 retry: { attempts: 3, backoff_ms: [100,400,800] }
P1:
rps_limit_per_org: 800
P2:
rps_limit_per_org: 200 admissions:
denylist_methods: ["eth_getLogs(>10k blocks)"]
heavy_query_guard: { max_range_blocks: 5000, require_token: true }

13) Diagramas de datos y consultas de ejemplo

13. 1 Métricas de nodos (directorio)

sql
CREATE TABLE node_metrics (
ts TIMESTAMPTZ,
node_id TEXT, role TEXT, region TEXT,
rps INT, latency_p95_ms INT, errors_5xx INT,
queue_lag_ms INT, cpu NUMERIC, mem NUMERIC, io_wait NUMERIC
);

13. 2 Control de SLO y burn-rate

sql
SELECT date_trunc('hour', ts) AS h, role,
AVG(latency_p95_ms) AS p95,
100. 0 SUM(CASE WHEN latency_p95_ms <= 400 THEN 1 ELSE 0 END)/COUNT() AS slo_hit_pct
FROM node_metrics
WHERE ts >= now() - INTERVAL '24 hours'
GROUP BY 1,2;

13. 3 Planificación de carga

sql
SELECT region, role,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY rps) AS rps_p95,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY queue_lag_ms) AS lag_p95
FROM node_metrics
WHERE ts >= now() - INTERVAL '7 days'
GROUP BY region, role;

14) Normas de funcionamiento

Diariamente: informe sobre SLO, Capacity Delta, Estado de los Snapshots, peer-health.
Semanalmente: revisión de límites/QoS, prueba de DR (bootstrap de snapshot), verificación de prunning y compaxes.
Antes del lanzamiento: rollout canario, gates SLO y métricas observadas, plan de retroceso.
Contabilidad de costos: CTS per 1k solicitudes, TPS_per_$ (eficiencia por dólar).

15) Incidentes de Playbook

A. Explosión de latencia RPC p95

1. Habilitar P2-throttle y bajar sampling; 2) aumentar las réplicas gateway/reader;

2. traducir parte del tráfico a caché solamente; 4) abrir el análisis de métodos calientes, si es necesario - deny-rules.

B. Queue-lag en el bus> SLO

1. Auto scale consumers (KEDA), 2) redistribuir lotes, 3) detener temporalmente bulk-jobs.

C. Caída del peer-count en el validador/releeve

1. Reiniciar módulos p2p, 2) cambio de asientos, 3) validación de ACL/NAT de red, 4) cambio a reserva.

D. Larga bootstrap de la nueva réplica

1. Cambiar a snapshot fresco, 2) aumentar el ancho de banda IO, 3) eliminar temporalmente los índices de archivo.

E. Spike reorg/retrasos en el puente

1. Aumentar K-confirmaciones/ventana, 2) habilitar el modo «finalizado-solo», 3) informar a los consumidores.

16) Lista de verificación de implementación

1. Identificar los roles de los nodos y sus presupuestos de error/SLO.
2. Llevar las funciones: consensus / RPC / el indexador / el archivo / el puente / edge.
3. Habilitar equilibrio, QoS, backpressure y cola con DLQ.
4. Configurar snapshots/fast-sync, pruning y almacenamiento en niveles.
5. Conectar métricas/tracks/logs, dashboards y alertas burn-rate.
6. Configurar Autocaravana (HPA/KEDA) y lanzamientos canarios.
7. Realizar pruebas de caos y ejercicios regulares de RD.
8. Introducir regulaciones operativas y controles de valor.

17) Glosario

Backpressure: mecanismos para controlar el flujo de entrada en caso de sobrecarga.
DLQ es una «cola muerta» para mensajes problemáticos.
Pruning: elimina el estado histórico fuera de la ventana actual.
Fast-sync/Snapshot es una forma acelerada de sincronizar una nueva réplica.
Outlier-ejection: elimina las instancias degradadas de la agrupación.
Burn-rate - tasa de gasto del presupuesto de errores con respecto a SLO.

En pocas palabras: la escala de nodos de red no es sólo «agregar réplica», sino también la disciplina de sistema de arquitectura, QoS, administración de estado y rigor operativo. Siguiendo este marco (separación de roles, colas, cachés, scale automático, observabilidad y nítidos SLO), el ecosistema obtiene un rendimiento predecible, resistencia a picos y un coste controlado por unidad de tráfico.