La llegada del slashing a Solana

Introducción

El slashing es un mecanismo para proteger la seguridad de la red mediante penalizaciones a validadores que actúan de forma maliciosa o negligente. Una vez verificada la conducta indebida, se quema una parte del stake delegado asociado con los validadores infractores.

Esta es una característica distintiva de las redes de prueba de participación (PoS) como Solana, sin equivalente en las redes de prueba de trabajo (PoW), ya que depende de la capacidad del protocolo para imponer penalizaciones financieras directamente mediante la destrucción de activos en staking. En PoW no existe un mecanismo análogo, pues la blockchain no puede confiscar ni destruir el hardware físico de minería de los actores deshonestos.

El slashing ofrece varios beneficios clave:

• Actúa como un desincentivo económico directo contra la actividad maliciosa
• Incentiva a quienes hacen staking a distribuir su stake entre validadores de confianza, lo que mejora la descentralización
• Incentiva a los operadores más grandes a crear infraestructuras heterogéneas que reduzcan el riesgo de fallas compartidas (por ejemplo, dividir su stake entre clientes Firedancer y Agave).
• Proporciona otra métrica para que los validadores se diferencien y consoliden su reputación al evitar infracciones sujetas a slashing y detectar la actividad maliciosa de otros participantes.

A lo largo de su historia, Solana ha dependido de un enfoque de consenso manual impulsado por la comunidad, conocido como slashing social. Bajo este modelo, si un validador actúa de forma maliciosa, por ejemplo, al poner en riesgo la disponibilidad o la seguridad de la red, los participantes honestos pueden coordinarse fuera de la cadena para iniciar un hard fork, reiniciar la red y aplicar slashing al stake del infractor. Aunque este método permite evaluar cada caso con flexibilidad, conlleva una carga de coordinación considerable y es intrínsecamente reactivo.

Hasta la fecha, ningún validador de Solana ha recibido slashing. Lo más parecido a un evento de slashing en Solana ocurrió en mayo de 2020, dos meses después del lanzamiento de mainnet, cuando Solana Foundation quemó voluntariamente 11,36 millones de SOL de su propia asignación en respuesta a las inquietudes de la comunidad sobre préstamos de tokens no divulgados a creadores de mercado. Esto redujo el suministro total de tokens un 2,3 %, de 500 millones a 488,64 millones de SOL. Aunque no fue un evento formal de slashing, la quema funcionó como una penalización autoimpuesta para recuperar la confianza y abordar los problemas de transparencia planteados por la comunidad inicial.

Durante varios años se ha pedido que Solana adopte un mecanismo de slashing más formal, conocido como slashing programático, que se aplique directamente en la cadena mediante un programa integrado. Bajo este sistema, si un validador infringe reglas específicas del protocolo, se puede generar una prueba criptográfica de la infracción y enviarla a un programa dedicado, que activa el slashing automáticamente. Este modelo reduce la dependencia de la coordinación humana y permite aplicar medidas por infracciones menores sin interrumpir las operaciones de la red, lo que abre el camino hacia una rendición de cuentas escalable y descentralizada.

La próxima activación de la feature gate de SIMD-0204: Verificación de eventos sujetos a slashing marca el primer paso importante y significativo de Solana hacia la implementación de slashing programático formal en mainnet. Como veremos más adelante en este informe, los eventos de slashing programático en redes blockchain son, por fortuna, poco frecuentes y las penalizaciones suelen ser menores. Sin embargo, la mera posibilidad de que el protocolo destruya automáticamente el stake de un validador introduce nuevos riesgos que todas las partes interesadas deben evaluar con cuidado. Quedan muchas preguntas abiertas sobre el enfoque óptimo para que Solana aplique el slashing programático. Como sucede con todos los cambios económicos, los parámetros y las penalizaciones asociados con el slashing requerirán un debate amplio en la comunidad y, en última instancia, deberán aprobarse mediante una votación formal de gobernanza.

SIMDs relacionados con el slashing

Varios SIMDs están relacionados con el despliegue del slashing programático en Solana. Está previsto que los dos primeros, SIMD-180 y SIMD-204, entren en funcionamiento en mainnet durante los próximos meses.

El primero es el requisito previo SIMD-0180: Usar la dirección de la cuenta de voto como clave del calendario de líderes. Este SIMD cambia la clave utilizada en el calendario de líderes: deja de usar la dirección de identidad del validador y pasa a usar la dirección de su cuenta de voto. Este cambio es esencial para atribuir con precisión el slashing, pues crea un vínculo directo e inequívoco entre las responsabilidades de producción de bloques de un validador y su stake delegado.

SIMD-0204: Verificación de eventos sujetos a slashing describe un nuevo Slashing Program. Este introduce un mecanismo en cadena que permite a cualquiera enviar y registrar pruebas de conductas sujetas a slashing, lo que crea un registro verificable e inmutable del comportamiento indebido de los validadores.

Por último, SIMD-0212: Slashing describe la implementación del slashing dentro del protocolo de Solana. Se basa en los fundamentos establecidos por SIMD-0204 para aplicar penalizaciones por infracciones verificadas. Esta propuesta sigue abierta y aún se encuentra en debate activo.

Detección y atribución de fallas

El Slashing Program está diseñado como una capa puramente observacional. No modifica el stake ni las recompensas; su única función es verificar y registrar infracciones. Ya hay un prototipo inicial activo en Testnet, con envíos de muestra (por ejemplo, transacciones DuplicateBlockProof) que demuestran cómo pueden registrarse las infracciones.

Producción de bloques duplicados

En su despliegue inicial, el programa se centrará en un solo tipo de comportamiento malicioso: detectar casos de producción de bloques duplicados. Esto ocurre cuando un líder envía dos o más versiones diferentes de un bloque para el mismo slot, lo que constituye una infracción clara y objetiva del consenso. 

En septiembre de 2022, una interrupción de la red fue provocada por un validador que produjo por error bloques duplicados a la misma altura de bloque. Esto ocurrió porque tanto el nodo principal del validador como su nodo de respaldo se activaron al mismo tiempo. Ambos usaron la misma identidad de nodo, pero propusieron bloques diferentes.

Este problema ya se corrigió. Actualmente, incluso cuando un operador ejecuta un nodo de respaldo activo, el cliente del validador incluye protecciones para apagarse si detecta varias instancias. Por lo tanto, sería extremadamente improbable producir bloques duplicados sin modificar deliberadamente el software del validador con fines maliciosos.

La producción de bloques duplicados es un ejemplo de una infracción del protocolo difícil de detectar en tiempo real, pero fácil de verificar posteriormente. Intentar coordinar una respuesta síncrona, en la que la red se detenga para confirmar la observación colectiva del duplicado, introduciría una complejidad considerable. En cambio, gestionar la detección y el slashing de manera retroactiva resulta mucho más práctico.

Las pruebas enviadas de bloques duplicados incluyen dos shreds en conflicto para el mismo slot, ambos firmados por el mismo validador. El Slashing Program verifica la prueba al confirmar que los shreds forman una prueba válida de bloque duplicado, que pertenecen al mismo slot y que el validador infractor los firmó correctamente. Esta lógica refleja el enfoque utilizado en el protocolo gossip de Solana para gestionar pruebas de bloques duplicados durante el proceso de selección de forks.

struct DuplicateBlockProofData {
  shred1_length: u32      // Unaligned four-byte little-endian unsigned integer,
  shred1: &[u8]           // `shred1_length` bytes representing a shred,
  shred2_length: u32      // Unaligned four-byte little-endian unsigned integer,
  shred2: &[u8]           // `shred2_length` bytes representing a shred,
}

El informante crea una prueba y la almacena en una cuenta de búfer en cadena. Después, envía una transacción al Slashing Program en la dirección `S1ashing11111111111111111111111111111111111` que hace referencia a su cuenta de búfer. Una vez que una prueba se verifica correctamente, los resultados se almacenan en una dirección derivada de programa (PDA) `report_account` que pertenece al Slashing Program para futuras consultas. Esto facilita la creación de paneles que muestren datos relacionados con el slashing con solo ejecutar una llamada getProgramAccounts en el Slashing Program. Los validadores pueden usarlos para comprobar si se les ha reportado por infracciones y tomar las medidas correctivas necesarias.

Se espera que Anza publique herramientas para observar estos eventos, crear pruebas y enviar las pruebas en cadena. Es probable que haya varias implementaciones, incluida una versión integrada en el software del validador. Basta con que un solo participante honesto reporte una infracción dentro de una epoch, ya que cada combinación única de infractor y slot solo puede reportarse una vez. El programa verifica si ya existe un reporte para el mismo slot y el mismo infractor. Si encuentra uno que coincide, rechaza el nuevo envío. Los reportes pueden enviarse hasta una epoch después de que ocurra la infracción, según el slot en el que sucedió (es decir, hasta 432.000 slots después, de acuerdo con el sysvar `Clock`).

Recompensas para informantes

Una pregunta frecuente al diseñar el slashing es si quienes reportan infracciones (es decir, los informantes) deben recibir una recompensa. Aunque recompensarlos puede parecer un mecanismo de incentivos sencillo, presenta desafíos importantes.

En Solana, donde los líderes controlan la inclusión de transacciones, una recompensa para informantes genera un riesgo de frontrunning. Supongamos que un validador envía una prueba válida de slashing al líder actual del bloque. En ese caso, el líder puede simplemente copiar la prueba, enviarla por su cuenta y censurar la transacción original para reclamar la recompensa sin hacer el trabajo. Esto debilita el modelo de incentivos y abre la puerta a abusos.

Ethereum ofrece una pequeña recompensa para informantes: 1/512 del saldo efectivo del validador sujeto a slashing. Para un validador con los 32 ETH completos, esto equivale a 0,0625 ETH. La recompensa se acuña como ETH nuevo, pero se compensa con la mayor cantidad quemada del stake del validador penalizado. Su bajo valor es intencional, pues busca promover la integridad y la participación honesta, en lugar de conductas oportunistas motivadas por las ganancias.

Infracciones de voto

Se espera que las versiones futuras del Slashing Program amplíen la compatibilidad con varios tipos de infracciones de voto, como las infracciones de lockout y las infracciones de switching proof.

Una infracción de lockout ocurre cuando un validador vota en dos forks distintos sin esperar el tiempo adecuado para que expire el lockout de su tower. Bajo TowerBFT, el algoritmo de consenso actual de Solana, cuando un validador vota por un fork específico en un slot determinado, queda "bloqueado" y no puede votar en forks competidores durante cierto tiempo. Si posteriormente vota por un fork diferente antes de que termine su periodo de lockout, infringe la regla de lockout.

El bot Votalizer, desarrollado por Michael Vines, cofundador de Solana, opera actualmente en el Discord de Solana Tech y rastrea las infracciones de lockout a medida que ocurren en la red. En la práctica, es poco común que los validadores cometan estas infracciones involuntariamente, pues normalmente se requeriría modificar deliberadamente el cliente del validador. Las protecciones integradas garantizan que el cliente recupere su voto en cadena más reciente e impiden acciones que provocarían una infracción de lockout.

Aunque las infracciones de lockout se mencionan explícitamente en el SIMD de slashing y en la documentación inicial como ejemplo de una infracción de voto que el Slashing Program podría abordar, la actualización de consenso Alpenglow prevista eliminará Tower BFT y, con ello, el concepto de lockout. Por este motivo, se espera que las infracciones de voto se introduzcan solo después del lanzamiento de Alpenglow.

Las nuevas infracciones de voto de Alpenglow que el Slashing Program podría diseñarse para detectar podrían incluir acciones como enviar votos en conflicto para el mismo slot, por ejemplo, emitir tanto un `NotarVote` como un `SkipVote`.

Tipos de infracciones futuras

El slashing programático debe vincularse con casos verificables e inequívocos de conducta indebida. Por desgracia, esto dificulta mucho la aplicación de medidas ante problemas más subjetivos o sistémicos, como la producción deliberadamente lenta de bloques o las formas perjudiciales de extracción de MEV.

En otras redes blockchain, los tipos de comportamiento que suelen provocar slashing varían según el protocolo. Algunos ejemplos comunes son:

• Firma doble: producir dos bloques en conflicto a la misma altura o en el mismo slot.
• Tiempo de inactividad: desconectarse y no participar en el consenso.
• Voto envolvente: emitir votos que entran en conflicto con otros anteriores para intentar manipular o desestabilizar la red.

Una propuesta novedosa de slashing, presentada el año pasado por 0xIchigo de Helius, sugirió penalizar a los validadores de la supermayoría que no participen en votaciones formales de gobernanza, con el objetivo de incentivar una mayor participación. Aunque este enfoque cumple el requisito de ser verificable objetivamente, varios comentaristas expresaron inquietudes. Algunos señalaron que ciertas restricciones legales pueden impedir que determinados validadores voten. Otros argumentaron que el slashing debería limitarse estrictamente a comportamientos que representen una amenaza directa para la seguridad o integridad de la red.

Aplicación de penalizaciones

Una vez que Solana disponga de un mecanismo en cadena confiable para reportar y verificar infracciones sujetas a slashing, la siguiente prioridad será aplicar el slashing económicamente y definir los parámetros exactos y las fórmulas de penalización para los distintos tipos de infracciones.

Las pautas todavía se debaten activamente. El contenido de esta sección refleja las propuestas actuales, cuyo objetivo es informar, fomentar el diálogo y evolucionar según los comentarios de la comunidad. Como estas decisiones afectan directamente la economía de operar un validador de Solana, cualquier cambio se someterá a un debate público en la comunidad y deberá aprobarse mediante un proceso formal de gobernanza.

Al determinar las penalizaciones por slashing, un principio clave es evitar castigar con demasiada severidad los errores aislados y poco frecuentes de los operadores. Lo ideal es que el sistema de penalizaciones incluya un margen de tolerancia para incidentes menores que no afecten al consenso, acompañado de las protecciones adecuadas, en lugar de imponer penalizaciones graves por errores honestos.

La opción que se considera actualmente para este margen es la línea del coeficiente de Nakamoto (NC), establecida en el nivel de stake del validador más pequeño de la superminoría (es decir, aproximadamente el 1 % del stake). 

Según la función propuesta, que determina la cantidad de cada delegación sujeta a slashing por cuenta de voto, no se aplica slashing al stake si el stake total que comete una infracción está por debajo de la línea NC. Por el contrario, si el consenso está en riesgo, lo que significa que más de un tercio del stake total participa en infracciones, el protocolo debe responder con firmeza y aplicar slashing al 100 % del stake infractor.

Para los casos que se encuentran entre estos extremos, la propuesta actual introduce una función de penalización cuadrática con una tasa de crecimiento lenta. La fórmula utilizada para calcular la fracción de stake sujeta a slashing en cada cuenta de voto es la siguiente:

v = cuenta de voto sujeta a slashing

TSS = stake total sujeto a slashing

TS = stake total

Línea NC = línea del coeficiente de Nakamoto

Con esta fórmula, el porcentaje de stake sujeto a slashing del validador infractor puede calcularse así:

• 1,2 % cuando el 4,66 % del stake está en infracción (es decir, (3 * (0.0466 - 0.01) / 1)²)
• 7,3 % cuando el 10 % del stake está en infracción (es decir, (3 * (0.1 - 0.01) / 1)²)

El siguiente gráfico muestra la curva propuesta junto con dos alternativas (agresiva y lineal).

El stake total sujeto a slashing (TSS) se calcula usando una ponderación basada en el tipo de infracción. Las infracciones de voto tienen una ponderación de 1 porque son menos graves. Las infracciones por bloques duplicados tienen una ponderación de 10, pues se consideran más graves.

Una ventaja clave de las penalizaciones de slashing cuadráticas y correlacionadas, como la propuesta actual, es que incentivan a quienes ejecutan varios validadores, como exchanges o proveedores de staking como servicio, a mantener infraestructura independiente y de alta calidad para minimizar el riesgo de fallas generalizadas y correlacionadas.

Alternativas al slashing tradicional

Aplicar slashing al stake delegado plantea preguntas importantes sobre la equidad y la responsabilidad. En el modelo actual de staking, la gran mayoría del stake, si no todo, está delegado en la mayoría de los validadores no privados. Esto significa que, cuando ocurre un slashing, quienes suelen soportar la mayor parte de la penalización son los delegadores, no los operadores de validadores que cometieron la infracción. Incluso quienes hacen staking con diligencia y eligen validadores de confianza podrían sufrir slashing sin tener culpa alguna si un validador actúa de forma maliciosa o configura mal su nodo.

Para abordar este desequilibrio, se han propuesto varios diseños alternativos de slashing. Uno consiste en exigir que todos los validadores mantengan un nivel mínimo de stake propio. Esto garantiza que los operadores arriesguen su propio capital y no puedan trasladar todo el costo del slashing a sus delegadores. Una versión más estricta de este enfoque aplicaría slashing solo al stake propio y retiraría automáticamente del staking a todos los delegadores asociados con un validador penalizado. Los delegadores perderían recompensas, pero conservarían su capital principal, lo que les permitiría reasignar su stake a otro validador con un impacto mínimo a largo plazo.

Otro enfoque consiste en congelar las cuentas durante un periodo definido, en el que no puedan obtener recompensas, cambiar de propietario ni retirar fondos. La duración del bloqueo aumentaría según la gravedad de la infracción. Como alternativa, el protocolo podría aplicar slashing a las recompensas futuras, lo que reduciría los ingresos del validador y sus delegadores durante un periodo establecido sin tocar el stake principal.

Algunos han propuesto redistribuir el stake sujeto a slashing entre los validadores honestos como refuerzo positivo, en lugar de quemarlo. Sin embargo, quemar SOL logra en la práctica un resultado similar, pues reduce el suministro total y aumenta así la participación relativa de cada titular en la propiedad de la red.

Consideraciones

La introducción del slashing en Solana tiene varias implicaciones importantes. En esta sección analizamos dos áreas críticas: los periodos de espera y el riesgo, los seguros y la carga operativa resultantes para los participantes del ecosistema.

Periodos de espera

Una vulnerabilidad clave del modelo actual de staking surge cuando un validador comete una infracción sujeta a slashing, pero retira su stake antes de que la infracción se observe y reporte. Sin un mecanismo que retrase el retiro, los actores maliciosos podrían aprovechar esta brecha temporal para evitar el castigo.

Un periodo de espera durante el cual el stake siga sujeto a slashing incluso después de desactivarse mitigaría este problema. Este periodo debe superar el tiempo máximo necesario para que los validadores u observadores externos detecten la infracción y coordinen una respuesta de slashing, especialmente en condiciones adversas como ataques DDoS a nivel de red o colusión entre validadores maliciosos. En la práctica, esto significa que los periodos de espera deben durar varios días.

La dependencia de Solana de snapshots de stake precalculados agrava este problema. Varios componentes críticos del protocolo, incluidos el calendario de líderes y la regla de selección de forks, dependen de valores de stake calculados por adelantado. Como resultado, el stake desactivado o incluso retirado por completo todavía puede influir en el consenso.

Por ejemplo, el calendario de líderes se obtiene de un snapshot previo del stake tomado con una epoch de antelación en el límite de la epoch. Esto crea una ventana en la que un validador podría cometer una infracción sujeta a slashing después de haber desactivado su stake en la epoch anterior y retirarlo al comienzo de la epoch actual. Para cuando se descubra la infracción, ya no quedará stake activo que penalizar.

Una solución sería introducir un periodo de espera adicional durante el cual el stake siga sujeto a slashing, pero deje de contar para la ponderación de stake del protocolo. Quienes desactiven su stake en la epoch N solo podrán retirarlo al comienzo de la epoch N+3. Aunque esto mejora la seguridad, tal retraso perjudica la experiencia del usuario al obligar a esperar entre ~2 y 4 días adicionales antes de poder retirar por completo el stake. Una forma de abordar este problema sería acortar las epochs para mantener retrasos de retiro del staking en tiempo real similares al estándar actual. Sin embargo, cualquier reducción de la duración de las epochs podría tener consecuencias imprevistas para el protocolo y tendría que evaluarse cuidadosamente.

Riesgo, seguros y carga operativa

La introducción del slashing en Solana tiene implicaciones para muchos participantes del ecosistema, en especial para quienes custodian o gestionan SOL en staking, o crean productos financieros sobre este. Incluso la posibilidad de slashing puede introducir riesgos financieros, complejidad operativa y problemas de reputación, sobre todo para instituciones sujetas a obligaciones fiduciarias o regulatorias. Estos riesgos pueden abordarse mediante protecciones como seguros o bonos.

Las partes interesadas que podrían verse afectadas incluyen:

• Protocolos de liquid staking
• Pools de stake
• Proveedores de staking con custodia
• Protocolos de restaking
• Protocolos DeFi
• ETF de staking

Para algunas de estas entidades, un evento de slashing podría tener consecuencias en cascada. Por ejemplo, los tokens de liquid staking (LST) se respaldan en el supuesto de que los validadores subyacentes operan de forma segura. Si un validador recibe slashing, podría provocar una fuerte revaloración de su LST o, en casos extremos, la pérdida de su paridad si colapsa la confianza en el validador donde se mantiene en staking el SOL subyacente. Esto podría generar liquidaciones si el LST se utiliza como garantía en un protocolo de préstamos.

Es común que los proveedores de staking de otros ecosistemas ofrezcan seguros contra slashing para mitigar estos riesgos. En Ethereum, por ejemplo, muchos proveedores ofrecen coberturas asequibles para proteger frente a pérdidas por slashing. Los niveles de protección varían según el plan de cobertura.

El riesgo de slashing también introduce nuevas responsabilidades operativas en toda la cadena de valor del staking. Entre los afectados se incluyen:

• Operadores de servicios de staking, que ahora deben supervisar el comportamiento de los validadores y mitigar los riesgos de forma proactiva
• Plataformas de custodia y exchanges de criptomonedas, que dependen de operadores externos y podrían tener que evaluar y diversificar sus conjuntos de validadores
• Gestores institucionales de activos, que podrían buscar cobertura por pérdidas propias para protegerse frente a pérdidas relacionadas con el slashing causadas por operadores externos

Comparación con otras redes

Esta sección examina cómo se implementa el slashing en otras redes de prueba de participación, como Ethereum y Cosmos. Estas redes han aplicado slashing programático durante muchos años y ofrecen datos valiosos del mundo real sobre la frecuencia de estos eventos y su impacto en la seguridad de la red y el comportamiento de los validadores.

Ethereum

El protocolo de prueba de participación de Ethereum, introducido con el lanzamiento de Beacon Chain en diciembre de 2020, incluyó el slashing como mecanismo central de aplicación desde el primer día. Ethereum define cuatro infracciones específicas sujetas a slashing, todas centradas en la equivocación:

• Proponer varios bloques para el mismo slot
• Enviar certificaciones en conflicto para el mismo checkpoint objetivo
• Certificar diferentes bloques de cabecera con los mismos checkpoints de origen y destino
• Crear dos certificaciones en las que una “envuelve” a la otra en términos de votos de origen y destino

Todas estas infracciones tienen la misma estructura de penalización. Cuando un validador recibe slashing, se aplica una penalización inmediata de 1/32 de su saldo efectivo, con un límite de 1 ETH debido al saldo efectivo máximo de 32 ETH. Luego, el validador se expulsa forzosamente del conjunto activo y se coloca en la cola de salida durante unos 36 días.

Durante este periodo, el validador permanece inactivo y no puede retirar fondos. Sigue perdiendo las recompensas que habría obtenido si estuviera activo, lo que en la práctica supone un costo de oportunidad constante. Después de 18 días, se aplica una penalización adicional por correlación, diseñada para aumentar en proporción al número de validadores que reciben slashing dentro de un periodo de 36 días. Si solo se penaliza a unos pocos validadores, la penalización es menor. Sin embargo, ante eventos masivos de slashing, ya sea por conducta indebida coordinada o por fallas de infraestructura compartida, las penalizaciones aumentan drásticamente y, en el peor de los casos, podrían provocar la pérdida de casi todo el saldo en staking del validador.

A pesar de su importancia central en el protocolo de Ethereum, el slashing es extremadamente poco frecuente en la práctica. Hasta mayo de 2025, solo 484 validadores, menos del 0,05 % del conjunto total, habían recibido slashing en 131 incidentes. Estos incidentes solían originarse en un único error que afectaba a varios validadores y, por lo general, eran consecuencia de errores de operadores o bugs de software, no de intenciones maliciosas.

El mayor evento de slashing ocurrió en noviembre de 2023, cuando Bitcoin Suisse sufrió el slashing de 100 validadores por infracciones relacionadas con la inactividad, y cada uno perdió 1 ETH.

Hasta la fecha, ningún incidente de slashing en Ethereum ha amenazado la integridad general del protocolo. Esto sugiere que, aunque el slashing es un elemento disuasorio esencial, su aplicación real es poco frecuente y el ecosistema de validadores ha interiorizado en gran medida los comportamientos necesarios para evitar estas penalizaciones.

Cosmos

Cosmos y las cadenas basadas en Cosmos SDK, como Cosmos Hub, implementan el slashing como un mecanismo de seguridad integrado que aborda dos fallas principales: la firma doble y los periodos prolongados de inactividad. Estas reglas de slashing sirven para hacer cumplir tanto las propiedades de seguridad como las de disponibilidad del protocolo.

Un validador que firma dos bloques diferentes a la misma altura recibe un castigo inmediato. Cualquier participante puede enviar en cadena pruebas de la infracción. Una vez verificadas, el validador recibe automáticamente slashing sobre el 5 % de sus tokens en staking y pasa al estado tombstoned, lo que significa que se elimina de forma permanente del conjunto de validadores activos y no puede volver a entrar. Una vez en ese estado, tanto el validador como sus delegadores deben esperar a que termine el periodo de desvinculación antes de poder volver a delegar su stake. Aunque el operador de un validador en estado tombstoned puede relanzarlo con una nueva clave, debe reconstruir desde cero su reputación y sus delegaciones.

Cosmos también garantiza la disponibilidad mediante slashing automático por inactividad prolongada. Si un validador firma menos del 5 % de los últimos 10.000 bloques, se considera inactivo y se lo penaliza aplicando slashing al 0,01 % de su stake. Aunque es una penalización menor en comparación, esta aplicación es estricta y no negociable, lo que garantiza que los validadores mantengan su disponibilidad y una participación confiable en el consenso.

Curiosamente, algunos validadores optan por aceptar esta penalización menor como costo de cerrar voluntariamente sus operaciones, pues consideran insignificante la pérdida.

Aunque las redes de Cosmos SDK comparten parámetros predeterminados estándar de slashing, cada cadena puede modificar o ampliar estas reglas para reflejar sus propios supuestos de seguridad y modelos de riesgo. Esta flexibilidad permite a cada red ajustar su sistema de slashing según el tamaño de su conjunto de validadores, sus objetivos de descentralización o su tolerancia prevista a fallas. La actividad de slashing en 57 mainnets basadas en Cosmos SDK ofrece una visión más amplia de la aplicación en todo el ecosistema:

• 12.143 casos de slashing relacionados con tiempo de inactividad
• 111 casos de slashing por firma doble
• 326 infracciones de otro tipo
• 12.580 incidentes de slashing en total

Estas cifras demuestran que, aunque la firma doble es poco frecuente y recibe fuertes penalizaciones, el slashing por inactividad es más común y se considera principalmente un costo operativo habitual. 

Conclusión

El slashing sigue siendo uno de los temas más debatidos y cargados de emociones en la industria blockchain. Cada vez que surgen nuevas formas de conducta indebida de los validadores o desajustes de incentivos, no tardan en aparecer peticiones de slashing. Es fácil entender por qué: a primera vista, parece ser un potente elemento disuasorio que ofrece un mecanismo directo y en cadena para castigar a los actores maliciosos y preservar la integridad de la red.

Sin embargo, como ha mostrado este artículo, el slashing programático dista mucho de ser una solución universal para la conducta indebida. Su eficacia depende de que las infracciones sean inequívocas y demostrables, condiciones que no siempre son fáciles de cumplir en situaciones complejas del mundo real. Aplicar slashing cuando las pruebas no son claras o están abiertas a interpretación puede castigar a actores honestos, desestabilizar la confianza y causar más daño que las infracciones que busca prevenir.

Podría decirse que el mayor valor de las formas automatizadas de slashing para una red es el impacto psicológico sobre las partes interesadas. La mera posibilidad de sufrir una pérdida económica por cualquier infracción, por poco frecuente que sea, puede bastar para que quienes hacen staking y tienen aversión al riesgo distribuyan sus delegaciones entre varios validadores. También puede motivar a los operadores a invertir en infraestructura diversa e independiente.

Recursos adicionales

• Slashing: ¿panacea o caja de Pandora? - Tim Roughgarden, Accelerate Conference
• Los límites económicos del consenso sin permisos - Eric Budish, Andrew Lewis-Pye, Tim Roughgarden 
• Disponibilidad con rendición de cuentas - Andrew Lewis-Pye, Joachim Neu, Tim Roughgarden, Luca Zanolini