Busca en todas las páginas de la documentación
Los productos de producción de Solana fallan de maneras que parecen similares a los usuarios (carteras atascadas, saldos vacíos, envíos fallidos) pero que requieren movimientos iniciales opuestos por parte de los ingenieros.
Un proveedor de RPC con límite de tasa no es una explotación de bóveda. Un error de programa Custom después de una actualización errónea no es una expiración de bloque. Tratar cada panel rojo como "reintentar con más fuerza" quema minutos y, a veces, fondos.
Esta página es el paraguas de la sección: cómo clasificar incidentes, recopilar evidencia, contener daños, mitigar sin reescribir la historia y cerrar el ciclo con prevención y RCA sin culpa para programas, dApps y backends de Solana.
Los productos de Solana se encuentran entre el estado inmutable de la cadena y los sistemas mutables fuera de la cadena.
En cadena: programas, cuentas, mentas, PDAs de bóveda y autoridad de actualización viven en un clúster bajo el consenso Agave. Una vez que una transacción se finaliza, el ledger no ofrece una API de "deshacer". La mitigación es pausar, congelar, re-desplegar, migrar o compensar.
Fuera de cadena: proveedores de RPC, indexadores, frontends, backends, billeteras y herramientas de operaciones deciden qué pueden ver y enviar los usuarios. La mayoría de las "interrupciones" que reportan los usuarios comienzan aquí.
Un incidente es cualquier degradación inesperada de la seguridad, control de fondos, corrección o disponibilidad que requiere una respuesta coordinada más allá de la depuración normal. La severidad generalmente rastrea los fondos de los usuarios en riesgo, la duración y el radio de explosión:
| Sev | Señal Típica | Ejemplo |
|---|---|---|
| 1 | Pérdida activa de fondos o pausa crítica necesaria | Drenaje por exploit, autoridad comprometida |
| 2 | Ruta de producto principal rota, fondos no drenando activamente | Pico de errores de programa por despliegue erróneo |
| 3 | Degradación parcial con solución alternativa | Latencia de RPC en una sola región, una instrucción fallando |
| 4 | Localizado o cosmético | Desajuste del explorador, UI no crítica |
Los roles superan a los héroes. Nombrar un comandante de incidente (decide la secuencia), un líder de comunicaciones (usuarios y partes interesadas reciben hechos, no especulaciones) y líderes de dominio (programa, cliente, infraestructura). Un canal para decisiones; una línea de tiempo en UTC con firmas y slots.
La evidencia es el pegamento específico de Solana entre las clases de fallas. Capturar temprano:
Sin esa cadena, la gente discute anécdotas mientras el atacante o la tormenta 429 continúan.
Las páginas hermanas de la sección cada una poseen una cara de la máquina:
Esta página mantiene todo el ciclo a la vista.
Los incidentes entran a través de alertas (velocidad de TVL, tasa de error, latencia de slot, 429s), informes de usuarios, mensajes de whitehat o anomalías del explorador. El primer trabajo es clasificar, no arreglar:
Síntoma
|
v
Paquete de evidencia (firma, slot, programa, RPC, ¿fondos?)
|
+-- Tx / sim / Custom / CU / cuentas --> ruta de tx fallida
+-- 429, latencia, caída WS, UI en blanco multi-usuario --> ruta RPC
+-- Flujos de salida inesperados, abuso de CPI, tx de autoridad --> ruta en cadena
+-- Pico de error post-despliegue, id de programa incorrecto --> ruta de despliegue/clienteLas transacciones fallidas dejan logs, salida de simulación y códigos de error nativos o de Anchor. Simular con @solana/kit 7.0.0 (simulateTransaction, logs, unitsConsumed) antes de retransmitir. Actualizar el blockhash; mapear Custom: N al enum del programa; separar el error del usuario del bug del programa del presupuesto de cómputo. Reintentar ciegamente con el mismo mensaje obsoleto multiplica el ruido y las tarifas.
Las interrupciones de RPC e infraestructura se presentan como saldos vacíos, "cuenta no encontrada", confirmaciones atascadas o desconexiones masivas de WebSocket. Acciones primarias: verificar el estado de los proveedores (latencia de slot, hash de génesis, presupuestos de error), hacer failover de lecturas y escrituras, abrir disyuntores para que los reintentos no se cascada, y evitar declarar un exploit en cadena cuando la cadena está bien y tu borde no lo está.
Los incidentes en cadena (exploits, compromiso de autoridad, bugs críticos de lógica) exigen pausas pre-construidas, multisig o autoridad de actualización en frío, y preservación de evidencia. Las transacciones de drenaje no se pueden revertir; la contención es detener la hemorragia, tomar una instantánea de las direcciones y preparar un parche verificado o una rotación de autoridad. Asumir explotación activa hasta que los logs demuestren lo contrario.
Los malos despliegues y desajustes de cliente se sitúan entre el programa y el frontend: entorno de clúster incorrecto, feature flag activado para una instrucción rota, o actualización que pasa las pruebas pero falla bajo las formas de cuenta de mainnet. Los interruptores de apagado del frontend son a menudo más rápidos que el rollback del programa; ambos pueden ser necesarios.
El "rollback" de Solana es una metáfora de producto, no una reversión del ledger. Palancas prácticas:
| Palanca | Velocidad | Alcance | Notas |
|---|---|---|---|
| Feature flag / kill switch del cliente | Rápida | Nuevos flujos de usuario | Detiene nuevos caminos erróneos |
| Failover RPC multi-proveedor | Rápida | Disponibilidad | No soluciona bugs de programa |
| Pausa de programa / flag de modo | Media | Instrucciones mutantes | Debe existir antes de la crisis |
| Rotación de autoridad | Media | Plano de control | Runbooks de "romper cristal" |
| Re-despliegue de binarios verificados anteriores | Medio-lento | Lógica de programa | Hash de compilación verificable |
| Migración de estado / compensación | Lenta | Saldos, reclamos | Requiere diseño y comunicaciones |
Orden de operaciones bajo presión:
La autoridad de actualización y la administración de pausa son características de producción. Si solo viven en una laptop caliente sin runbook, no tienes respuesta a incidentes; tienes esperanza.
Puente interno: marcas de tiempo UTC, hashes de firma, IDs de programa, decisiones y propietarios. Externo: actualizaciones fácticas cortas (impacto, estado de mitigación, acciones del usuario). No publiques teorías de exploit no confirmadas ni claves privadas en capturas de pantalla de "depuración". Para Sev-1, planifica un resumen para el cliente dentro de una ventana fija después de la contención (la página RCA hermana detalla la plantilla).
Construye para la respuesta, no solo para el camino feliz:
GlobalConfig de Anchor 0.32.1 y equivalentes nativos).Los equipos que solo envían trabajo de funciones sin estos controles eventualmente los inventan durante un incidente, al máximo costo.
| Pregunta | Si sí | Playbook principal |
|---|---|---|
| ¿Se están yendo fondos inesperadamente? | Contener Sev-1 | Respuesta a incidentes en cadena |
| ¿Muchos usuarios fallan solo en un proveedor? | Failover | Interrupciones de RPC e infraestructura |
| ¿La simulación muestra Custom / CU / cuentas? | Decodificar | Depuración de transacciones fallidas |
| ¿La tasa de error aumentó justo después del despliegue? | Mitigar | Rollback y mitigación |
| ¿La ruta es inestable solo bajo carga? | Tarifas / aterrizaje / RPC | Páginas de transacciones fallidas + RPC |
Ejecuta la matriz en orden; paraleliza solo después de la clasificación para que ingeniería y seguridad no se pisen mutuamente.
Cuando el puente termina, el trabajo no ha concluido. Un postmortem sin culpa separa la causa próxima de los factores contribuyentes, registra lo que salió bien y asigna elementos de acción con propietarios y fechas de vencimiento. Las listas de verificación de prevención convierten esos elementos en puertas de despliegue de Nivel 1, correcciones de 30 días de Nivel 2 y simulacros trimestrales de Nivel 3 (simulacros de pausa, aterrizaje sintético, monitoreo de autoridad).
La madurez de la respuesta a incidentes es medible: tiempo medio para clasificar, tiempo medio para pausar o hacer failover, fracción de Sev-1 con elementos de acción completados, y tasa de aprobación de simulacros. Las versiones de stack importan para los simulacros también: revalidar scripts contra Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, y @solana/kit 7.0.0 después de las actualizaciones de la cadena de herramientas para que los runbooks no se deterioren.
Los informes de whitehat, las fuerzas del orden, las aseguradoras y los auditores pueden necesitar el mismo paquete de evidencia que usan tus ingenieros. Conserva logs, firmas e historial de autoridad; no "limpies" exploradores ni rotas claves sin registrar qué se comprometió. El diseño de seguridad del programa (verificaciones de cuenta, higiene de CPI) reduce la frecuencia de incidentes; la respuesta a incidentes reduce la severidad cuando el diseño falla. Ambos son necesarios.
Es la práctica coordinada de clasificar fallas en cadena y fuera de cadena, contener daños de fondos y UX con palancas preconstruidas, mitigar hacia adelante sin revertir el ledger, y convertir cada evento en prevención duradera.
Una transacción fallida tiene una firma o resultado de simulación y una clase de error de programa o tiempo de ejecución; una interrupción es a menudo una indisponibilidad para múltiples usuarios causada por RPC, red o infraestructura dependiente sin una única causa raíz del programa.
Clúster, síntoma, firmas y slots, ID de programa, proveedor RPC, si se movieron fondos, y despliegues recientes o cambios de autoridad; luego asignar roles de comandante, ingeniería y comunicaciones.
Pausa cuando los fondos o el estado crítico están en riesgo por lógica en cadena o explotación; haz failover de RPC cuando la evidencia apunte a la salud del proveedor, límites de tasa o latencia de slot con saldos en cadena saludables.
Puedes re-desplegar un binario verificado anterior al mismo ID de programa si posees la autoridad de actualización; no puedes borrar cambios de cuenta finalizados que ya se ejecutaron bajo la versión errónea.
La simulación expone logs y uso de cómputo sin gastar tarifas de mainnet en reintentos ciegos, y separa los bugs detectables por preflight de los problemas de aterrizaje y confirmación.
Permiten enrutar alrededor de 429s, fallas regionales y mantenimiento de un solo proveedor; las verificaciones de estado y los disyuntores evitan reintentos en cascada que empeoran las interrupciones.
Pausa pre-desplegada, claves de administración de "romper cristal" o multisig, procedimiento de autoridad de actualización, captura de evidencia para direcciones de explotadores, plantillas de comunicación y una ruta a un parche verificado bajo presión de auditoría.
Redacta la línea de tiempo mientras la memoria esté fresca (el mismo día cuando sea posible); completa la RCA sin culpa con elementos de acción después de la contención, y publica hechos para el cliente en un SLA fijo de Sev-1.
Explica las condiciones del sistema y del proceso que hicieron probable la falla, sin avergonzar a los individuos, y aún así asigna correcciones concretas con propietarios y fechas.
Cada Sev significativo debería dejar monitores, puertas de CI o simulacros en una lista de verificación para que el próximo lanzamiento demuestre que la brecha está cerrada antes de que los usuarios la redescubran.
Las flags del cliente y del backend deshabilitan rutas de instrucción rotas más rápido que las actualizaciones en cadena; emparejalas con una pausa en cadena cuando los fondos aún puedan moverse a través de otros clientes.
Kit 7.0.0 mejora la tipificación de RPC, la simulación y las rutas de envío, pero la clasificación, el compromiso, el failover y la autoridad de pausa siguen siendo preocupaciones operacionales y de diseño de programas.
Fija scripts y ejemplos a Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, y @solana/kit 7.0.0, y vuelve a simular después de las actualizaciones.
Usa Depuración de Transacciones Fallidas y Interrupciones de RPC e Infraestructura para las dos rutas no de exploit más comunes; abre Respuesta a Incidentes en Cadena y Rollback y Mitigación para eventos de riesgo de fondos; cierra el ciclo con Listas de Verificación de Prevención y Postmortems Sin Culpa y RCA.
Versiones de Stack: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, y @solana/kit 7.0.0.
Revisado por Chris St. John·Última actualización: 15 jul 2026