Recorte de Validadores de Solana: ¿Lo tiene SOL?

El recorte de validadores de Solana no estaba activo a nivel de protocolo en la última revisión de la fuente en junio de 2025. Este artículo conserva ese hallazgo fechado e identifica lo que los lectores deben verificar antes de confiar en él.

Este contenido es solo para fines informativos y no constituye asesoramiento financiero. La participación (staking) en criptomonedas implica riesgos, incluida la posible pérdida de activos en participación. Consulta a un asesor financiero cualificado antes de tomar decisiones de inversión.

Última actualización: Junio de 2025

Si participas en staking con SOL y recientemente te has encontrado con la frase "recorte de validadores de Solana", aquí tienes la respuesta directa: a junio de 2025, Solana no implementa el recorte de validadores a nivel de protocolo. Tu SOL delegado no puede ser reducido automáticamente por el protocolo debido al comportamiento de tu validador. Este artículo cubre qué significa el recorte, el estado actual de Solana, cómo Tower BFT maneja la mala conducta en su lugar, qué riesgos existen realmente para los delegadores hoy, cómo Marinade Finance y Jito encajan, y cómo se compara Solana con Ethereum, Cosmos y Polkadot.

Puntos Clave

• A junio de 2025, Solana no implementa el recorte de validadores a nivel de protocolo
• Tu SOL delegado no puede ser reducido automáticamente por el protocolo debido a la mala conducta de tu validador hoy
• Solana utiliza mecanismos de bloqueo de Tower BFT para disuadir la mala conducta de los validadores en lugar de penalizaciones directas de tokens
• Existen propuestas de gobernanza llamadas Documentos de Mejora de Solana (SIMD) para introducir el recorte, pero no se han implementado
• Los protocolos de staking líquido como Marinade Finance y Jito distribuyen la participación (stake) entre muchos validadores, reduciendo la exposición a un único validador

Contenidos

• ¿Qué es el Recorte de Validadores?
• Recorte de Validadores de Solana: ¿Lo tiene Solana actualmente?
• Cómo Solana Maneja la Mala Conducta de los Validadores: Tower BFT y Mecanismos de Bloqueo
• Qué significa el Estado de Recorte de Solana para los Stakers y Delegadores
• Staking Líquido y Riesgo de Recorte: Marinade Finance y Jito
• Solana vs. Ethereum, Cosmos y Polkadot: Comparación del Recorte
• Mejores Prácticas para Validadores: Cómo Evitar Condiciones de Recorte en Solana
• Gobernanza de Recorte de Solana: Propuestas SIMD y su Significado
• Preguntas Frecuentes sobre el Recorte de Validadores de Solana
• Conclusión: ¿Está el Staking de Solana Seguro de Recorte Hoy?
• Glosario

¿Qué es el Recorte de Validadores?

Definición: El recorte de validadores es un mecanismo de penalización a nivel de protocolo en blockchains Proof of Stake (PoS) que reduce automáticamente los tokens en participación (staked) de un validador como castigo por mala conducta demostrable. Está diseñado para hacer que el comportamiento deshonesto sea financieramente irracional al asegurar que los validadores pierdan más de lo que podrían ganar manipulando la red.

En una blockchain como Solana, los validadores son los nodos responsables de procesar transacciones y alcanzar consenso sobre el estado de la red. El recorte de validadores es fundamentalmente un mecanismo de seguridad de la red: al hacer que el comportamiento deshonesto sea costoso financieramente, disuade a los validadores de intentar manipular la blockchain. En sistemas basados en Proof of Stake (PoS), los validadores depositan tokens como garantía para participar. A diferencia de Bitcoin, que utiliza Prueba de Trabajo donde los mineros compiten para resolver acertijos matemáticos, los sistemas de consenso basados en participación responsabilizan financieramente a los validadores a través de su capital bloqueado. El recorte es lo que sucede cuando infringen las reglas. Para un contexto de red más amplio, consulta qué es un validador de Solana.

Dos condiciones activan el recorte en la mayoría de las redes PoS. La equivocación (comúnmente llamada doble voto) ocurre cuando un validador firma dos votos o bloques conflictivos para la misma ranura (slot), intentando apoyar dos versiones diferentes de la blockchain al mismo tiempo. La votación envolvente es la segunda condición: un validador firma atestaciones que contradicen atestaciones firmadas previamente. Ambos comportamientos socavan la finalidad del consenso y, a gran escala, podrían permitir ataques de doble gasto.

La Lógica Económica Detrás del Recorte

El recorte existe porque los validadores depositan tokens en participación como garantía. Un validador que está a punto de perder más al comportarse mal de lo que podría ganar al hacer trampa no tiene ningún incentivo racional para hacer trampa. La Tolerancia a Fallos Bizantinos (BFT) es el marco teórico de la ciencia de la computación subyacente a los sistemas de consenso distribuido, que lleva el nombre del Problema de los Generales Bizantinos, un experimento mental sobre la coordinación de actores que pueden ser traidores. Tower BFT es la implementación específica de Solana de consenso de clase BFT. El recorte garantiza las propiedades BFT al convertir la equivocación de un riesgo teórico en un acto financieramente irracional. En redes como Ethereum, los delegadores que prestan su participación a los validadores también comparten proporcionalmente las penalizaciones por recorte, lo que plantea la pregunta de si los delegadores de SOL enfrentan la misma exposición en Solana.

Recorte de Validadores de Solana: ¿Lo tiene Solana Actualmente?

Última actualización: Junio de 2025

A junio de 2025, Solana no implementa el recorte de validadores a nivel de protocolo. Solana actualmente no tiene ningún mecanismo que queme o reduzca automáticamente los SOL en participación de un validador como penalización por mala conducta. Los validadores no pueden ser recortados a nivel de protocolo bajo el código activo de Solana.

Esta es una característica de diseño deliberada, no un descuido. La arquitectura de Solana proporciona disuasión a través del mecanismo de bloqueo de Tower BFT, y la comunidad de desarrolladores ha debatido activamente si añadir penalizaciones financieras por recorte vale la pena la complejidad operativa que introduce en un entorno de alto rendimiento. Ese debate ahora tiene una vía formal: las Propuestas de Mejora de Solana (SIMD) han propuesto introducir el recorte, pero ninguna ha sido implementada. Para un seguimiento completo de la gobernanza, consulta la sección Gobernanza SIMD a continuación.

Existen tres categorías de consecuencias para los validadores en Solana:

1. Recorte a nivel de protocolo (no existe en Solana a junio de 2025): reducción automática de tokens en participación (staked).
2. Penalizaciones sociales y económicas (activas): los validadores que se comportan mal pierden delegaciones a medida que los delegadores retiran su participación.
3. Recorte propuesto por gobernanza (propuesto vía SIMD, aún no implementado): lo que existiría si se acepta una SIMD relevante.

La arquitectura de Solana proporciona disuasión contra la equivocación a través del mecanismo de bloqueo de Tower BFT, pero la implementación de penalizaciones financieras en un entorno de alto rendimiento introduce riesgos operativos que la comunidad ha sopesado activamente. Los validadores en sistemas de alto rendimiento enfrentan una mayor exposición a condiciones de recorte de falsos positivos debido a la latencia de la red, reinicios de software o fallos de infraestructura. La discusión de gobernanza ha considerado si estos riesgos operativos superan los beneficios de seguridad del recorte, y a junio de 2025 la cuestión permanece sin resolver a través de los canales formales de gobernanza.

Cómo Solana Maneja el Mal Comportamiento de los Validadores: Tower BFT y Mecánicas de Bloqueo

El enfoque de Solana ante el mal comportamiento de los validadores pasa por Tower BFT, y comprender ese mecanismo explica tanto por qué la equivocación es estructuralmente difícil en esta red como por qué actualmente no acompaña ninguna penalización financiera a su detección.

Prueba de Historia: El Reloj Criptográfico de Solana

Proof of History (PoH) es un mecanismo criptográfico de registro de tiempo creado por Anatoly Yakovenko, cofundador de Solana. Funciona como un reloj verificable para la red, no como un Mecanismo de Consenso. PoH crea un registro histórico que demuestra que una secuencia específica de eventos ocurrió en un momento específico, permitiendo a los validadores acordar el orden sin comunicación constante de ida y vuelta. Tower BFT, el Mecanismo de Consenso, se basa en este reloj. Solana utiliza una arquitectura híbrida que combina Prueba de Historia como su capa de registro de tiempo con Tower BFT como su capa de consenso, en lugar del Proof of Stake estándar.

Tower BFT es el protocolo de consenso de Solana, el sistema que los validadores utilizan para acordar el estado de la Blockchain. Basado en Prueba de Historia, utiliza ventanas de bloqueo de duración exponencialmente creciente para hacer que votar en múltiples versiones de Blockchain competidoras sea económicamente irracional. Las ventanas de bloqueo son el mecanismo de Tower BFT que impide a un validador votar en bifurcaciones competidoras después de comprometerse con una.

El mecanismo de bloqueo funciona de la siguiente manera:

1. Un validador emite un voto en Fork A de la Blockchain
2. Ese voto conlleva una ventana de bloqueo, inicialmente de 2 slots, durante la cual el validador no puede votar en una bifurcación competidora
3. Cada voto subsiguiente en la misma bifurcación duplica el bloqueo: 4 slots, luego 8, luego 16, continuando exponencialmente
4. Abandonar Fork A para votar en Fork B antes de que expire el bloqueo es una violación del bloqueo

Cuanto más profunda es la torre de votos de un validador en una bifurcación dada, más tiempo debe esperar antes de cambiar. Este mecanismo de compromiso hace que revertir un voto previo sea progresivamente más costoso en tiempo, no solo en reputación.

Los validadores ganan créditos de voto por votos oportunos y precisos. Perder votos reduce los créditos y, por lo tanto, reduce las recompensas de participar en staking proporcionalmente. Este sistema de créditos de voto es el mecanismo de penalización suave activo de Solana, que afecta las recompensas sin tocar el principal invertido.

El mecanismo de bloqueo Tower BFT: cada voto de un validador en una bifurcación conlleva una ventana de bloqueo exponencialmente creciente. Una violación del bloqueo constituye equivocación.

Equivocación y Violaciones del Bloqueo

La equivocación (comúnmente llamada doble voto) ocurre cuando un validador firma dos votos o bloques conflictivos para el mismo slot, intentando respaldar dos versiones diferentes de la Blockchain al mismo tiempo. Una violación del bloqueo se refiere específicamente a un validador que vota en una bifurcación competidora antes de que expire la ventana de bloqueo de Tower BFT.

La secuencia de detección a consecuencia bajo el protocolo actual:

1. El validador emite votos en Fork A, construyendo un bloqueo exponencialmente creciente
2. El validador firma un voto en Fork B antes de que expire el bloqueo
3. Las marcas de tiempo de PoH hacen que ambos votos sean criptográficamente probables
4. El protocolo detecta las firmas conflictivas como equivocación
5. El validador pierde créditos de voto por el período afectado; el SOL apostado no se reduce

Esta es la brecha arquitectónica que las propuestas de slashing de SIMD buscan cerrar. Bajo las implementaciones de slashing propuestas, el paso 5 añadiría quema automática de tokens tanto del stake del propio validador como proporcionalmente del stake delegado.

Una cuenta de stake es un registro on-chain específico de Solana que mantiene el SOL apostado de un delegador y rastrea su delegación a un validador específico. Bajo una implementación de slashing, la cuenta de stake sería debitada directamente si se penaliza a un validador.

Lo que el Estado del Slashing de Solana Significa para Stakers y Delegadores

A junio de 2025, su SOL apostado no corre riesgo de reducción a través del slashing. Solana no implementa este mecanismo. Para los asignadores institucionales, el slashing actualmente no representa ningún riesgo financiero material para las posiciones de staking de SOL. Su saldo principal no puede ser quemado automáticamente por el protocolo debido al comportamiento de su validador. Ese panorama cambiaría si se aceptan las propuestas de slashing de SIMD: bajo los borradores actuales, los delegadores se enfrentarían a una exposición principal proporcional junto con los validadores.

El rendimiento del validador afecta sus recompensas de participar en staking. Un validador de bajo rendimiento o moroso (uno que pierde votos debido a tiempo de inactividad) gana menos créditos de voto, lo que reduce el aproximadamente 5–8% que su stake gana en APY. La distinción entre riesgo de recompensa y riesgo de principal es la clave para evaluar el staking de Solana con precisión. Los delegadores pueden aplicar la lista de verificación en cómo elegir un validador de Solana.

La mayoría de los poseedores de SOL que participan en staking son técnicamente delegadores. El perfil de exposición difiere según el rol. Los validadores se enfrentan a penalizaciones directas del protocolo bajo cualquier marco de slashing; los delegadores se enfrentan a una exposición derivada proporcional a su cuota de stake. En redes con slashing activo, ambas categorías asumen riesgo financiero. En Solana hoy, ninguna lo hace a nivel de protocolo.

Un validador es la entidad que ejecuta el nodo y emite votos de consenso. Bajo cualquier implementación de slashing, el validador sería la entidad principal penalizada. Un delegador presta su SOL al pool de ese validador y gana recompensas en proporción a su cuota de stake. Bajo la mayoría de las implementaciones de slashing propuestas, los delegadores se verían afectados proporcionalmente junto con el stake del propio validador. Si un validador fuera penalizado con un 5% de su pool de stake total, y usted tuviera 100 SOL delegados, podría perder aproximadamente 5 SOL.

Bajo las implementaciones de slashing propuestas para Solana, los delegadores se verían afectados proporcionalmente. Si un validador es penalizado con un porcentaje de su pool de stake total, los delegadores pierden el mismo porcentaje de su SOL delegado.

Riesgos Reales que Existen Hoy para los Delegadores

Varios riesgos financieros existen para los delegadores hoy en día, incluso sin slashing. Afectan las recompensas de participar en staking en lugar de su saldo principal:

1. Morosidad del validador: un validador que pierde votos gana menos créditos de voto, lo que reduce su APY para la época afectada (una época es aproximadamente 2-3 días en el protocolo de Solana)
2. Período de desvinculación: el SOL apostado no se puede retirar inmediatamente; el período de desvinculación de Solana es de aproximadamente 2-3 días, durante los cuales sus tokens permanecen bloqueados en su cuenta de stake
3. Tasa de comisión: la comisión del validador es el porcentaje de las recompensas de participar en staking que el validador retiene antes de pasar el resto a los delegadores; una comisión del 10% significa el 10% de las recompensas obtenidas, no el 10% del principal
4. Riesgo del programa de Solana: participar en staking se rige por un programa on-chain (equivalente a un Contrato inteligente en otras redes); los errores de protocolo, aunque históricamente raros, representan un riesgo teórico para los activos apostados (las plataformas de intercambio que ofrecen productos de staking de SOL también enfrentan consideraciones de exposición a slashing en su selección de validadores y diseño de custodia).

Actualmente, la ausencia de slashing es en sí misma una protección tanto para delegadores institucionales como minoristas. Seleccionar validadores de reputación y diversificar a través de protocolos de liquid staking son los principales enfoques de mitigación de riesgos disponibles hoy en día.

Para una comparación de cómo el perfil de riesgo de Solana se compara con Ethereum y Cosmos, consulte cómo se compara Solana en las redes PoS.

Cómo evaluar y elegir un validador de Solana seguro

Al evaluar un validador de Solana, seis criterios ofrecen la imagen más clara de fiabilidad y riesgo:

1. Compruebe la tasa de tiempo de actividad y de incumplimiento: diríjase a validadores con más del 95 % de tiempo de actividad utilizando Stakewiz, Solana Beach, o Validators.app
2. Revise los créditos de voto por época: créditos de voto altos y consistentes señalan una participación fiable en el consenso
3. Compare las tasas de comisión: 0–10 % es el rango estándar; tenga esto en cuenta junto con las métricas de rendimiento, no de forma independiente
4. Compruebe la concentración de stake: evite delegar a validadores que posean más del 10 % del stake total de la red, ya que esto aumenta el riesgo de centralización de la red
5. Revise el historial del validador: busque un historial limpio sin períodos de incumplimiento prolongados
6. Considere el staking líquido a través de Marinade Finance o Jito para la diversificación automática entre muchos validadores simultáneamente

Riesgo de staking líquido y recorte: Cómo lo manejan Marinade Finance y Jito

Los protocolos de staking líquido agrupan SOL delegados en muchos validadores y emiten un token de staking líquido (LST) negociable que representa su stake subyacente. Marinade Finance emite mSOL; Jito emite jitoSOL. En lugar de bloquear su SOL con un solo validador, estos protocolos distribuyen automáticamente su stake en sus grupos de validadores.

Cómo la diversificación del staking líquido reduce la exposición a un solo validador

Marinade Finance y Jito distribuyen el stake en grandes grupos de validadores. Un solo mal comportamiento del validador afecta solo a una pequeña fracción del stake total agrupado en lugar de a toda su posición. Si un validador en un grupo de 100 fuera recortado un 5 % de su propio stake, solo se vería afectada la 1/100 parte de la exposición del grupo en ese validador. Esta diversificación estructural reduce el riesgo de concentración en comparación con delegar todo a un solo validador.

A junio de 2025, sin recorte activo en Solana, esta diversificación opera principalmente como un mecanismo de protección prospectivo. Tanto Marinade Finance como Jito emplean criterios de selección y monitoreo de validadores para evitar validadores morosos o de bajo rendimiento, lo que protege sus recompensas de staking hoy independientemente del estado del recorte.

Marinade Finance (mSOL) y Jito (jitoSOL): Cobertura específica del protocolo

Marinade Finance y Jito abordan el riesgo de recorte de manera diferente según sus metodologías de selección de validadores y composiciones de grupo.

Marinade Finance utiliza una estrategia automatizada de delegación de stake que puntúa a los validadores según métricas de rendimiento, como la tasa de créditos de voto, la comisión y la concentración de stake. Según la documentación de Marinade Finance, el protocolo distribuye el stake entre un gran conjunto de validadores y aplica criterios de puntuación para minimizar la exposición a validadores de bajo rendimiento. Los poseedores de mSOL se verían afectados proporcionalmente si cualquier validador del grupo sufriera un recorte, pero el impacto por poseedor sería una fracción de lo que enfrentaría un delegador de un solo validador.

El grupo de validadores de Jito se enfoca en la infraestructura de MEV (valor extraíble máximo), con validadores que ejecutan la pila de software de Jito. Según la documentación de staking de Jito, los poseedores de jitoSOL se benefician de la diversificación del grupo. La composición de validadores de Jito centrada en MEV tiene características únicas: el conjunto de validadores puede diferir de los grupos de validadores generales de Solana en su composición y perfil operativo.

El staking directo y el staking líquido representan perfiles de riesgo diferentes, no una jerarquía clara de seguridad. Ni Marinade ni Jito eliminan la exposición futura al recorte, y ambos introducen un riesgo de programa de Solana que el staking directo no conlleva. Un error de protocolo o una vulnerabilidad de gobernanza representarían una categoría de riesgo separada. Los lectores que prefieren un producto de ganancias de custodia también pueden revisar Bybit Earn,) donde esté disponible; compare los términos actuales, las condiciones de retiro y los riesgos de custodia antes de decidir.

Solana vs. Ethereum, Cosmos y Polkadot: Cómo se compara el recorte en las redes PoS

Tres de las cinco redes PoS principales comparadas a continuación tienen recorte activo. Solana y Cardano no lo tienen, a junio de 2025. Este único hecho estructural explica la principal diferencia en la exposición al riesgo del principal para los delegadores en estas redes.

Beacon Chain de Ethereum: Recorte activo desde The Merge (2022)

La Beacon Chain de Ethereum es la capa de consenso PoS introducida con The Merge en septiembre de 2022. Solana no implementa el recorte; Ethereum lo tiene activo desde The Merge. En la Beacon Chain, dos condiciones activan el recorte: propuestas dobles (un validador propone dos bloques diferentes para la misma ranura) y votaciones envolventes (un validador firma una atestación que contradice una previamente firmada). La penalización inicial mínima es 1/32 del saldo efectivo del validador, y las penalizaciones por correlación aumentan cuando muchos validadores cometen la misma ofensa en el mismo período. Los validadores recortados enfrentan un retraso en la cola de retiro antes de que se retire su stake restante. Consulte la documentación de penalizaciones de Ethereum Beacon Chain) para obtener detalles completos de la especificación.

Ethereum requiere un mínimo de 32 ETH para ejecutar un validador directamente; Solana no tiene requisito mínimo de stake. Para una comparación más amplia de estas dos redes, consulte Solana vs Ethereum.

Comparación de recorte multicanal | Datos actuales a junio de 2025. Verifique contra la documentación del protocolo actual antes de tomar decisiones de staking.

Para obtener antecedentes sobre el modelo de staking y consenso de Polkadot, consulte ¿Qué es Polkadot?)

Cinco redes PoS, dos enfoques de slashing: aquellas con penalizaciones financieras activas (Ethereum, Cosmos, Polkadot) y aquellas sin ellas (Solana, Cardano). La ausencia de slashing en el nivel de protocolo de Solana significa que los delegadores no se enfrentan a una reducción del capital por el mal comportamiento de los validadores hoy en día. Los defensores de la arquitectura actual sostienen que el mecanismo de bloqueo de Tower BFT proporciona una disuasión suficiente; los críticos argumentan que las penalizaciones económicas son necesarias para la rendición de cuentas de los validadores a escala.

Mejores prácticas para validadores: cómo evitar las condiciones de slashing en Solana

La delincuencia de los validadores, el encarcelamiento (jailing) y el slashing son tres tipos distintos de penalizaciones en Solana. Solo la delincuencia y el encarcelamiento conllevan consecuencias activas bajo el protocolo actual. Los delegadores que lean esta sección pueden usarla para entender qué buscar en el historial de un validador; para la lista de verificación de selección de validadores, consulte Cómo evaluar y elegir un validador de Solana seguro.

Delincuencia vs. Slashing vs. Encarcelamiento: Entendiendo la diferencia

El slashing y el encarcelamiento son penalizaciones de validadores distintas con consecuencias fundamentalmente diferentes para los tokens en staking.

El slashing y el encarcelamiento son dos penalizaciones de validadores distintas. El slashing (propuesto en Solana) implica una reducción forzada de los tokens en staking como castigo por mal comportamiento como la equivocación. El encarcelamiento es una exclusión temporal del conjunto de validadores activos debido a un tiempo de inactividad prolongado; no reduce los tokens en staking. El encarcelamiento afecta a las recompensas; el slashing afecta al capital.

Un validador que se desconecta durante un periodo prolongado puede ser eliminado temporalmente del conjunto activo, lo que a veces se denomina estar encarcelado o excluido del programa de líderes. Esto difiere del slashing y no resulta en la pérdida de tokens para los delegadores.

Salvaguardas operativas para operadores de validadores de Solana

Siete salvaguardas operativas reducen el riesgo de condiciones de equivocación accidentales, el principal activador del slashing bajo las implementaciones SIMD propuestas. Para el contexto de aprovisionamiento y seguridad de la cuenta, revise también los requisitos del validador de Solana:

1. Ejecute una única clave de firma activa en cualquier momento dado. Nunca tenga dos nodos compartiendo la misma identidad de validador simultáneamente, ya que esta es la causa principal de la equivocación accidental.
2. Implemente copias de seguridad del estado de la torre (tower state). Un nodo reiniciado debe recuperar su último estado de bloqueo confirmado en lugar de comenzar de nuevo desde una Posición potencialmente conflictiva.
3. Use módulos de seguridad de hardware (HSM) para la custodia de las claves del validador donde sea operativamente factible, reduciendo el riesgo de compromiso de las claves.
4. Monitoree la tasa de crédito de voto con alertas automatizadas. Las caídas bruscas en la tasa de crédito de voto señalan problemas antes de que escalen a una delincuencia prolongada o exposición a la equivocación.
5. Siga las notas de lanzamiento de los clientes de Solana Labs y Anza y actualice en los plazos recomendados para evitar errores que alteren el consenso y que podrían causar un comportamiento no deseado.
6. Mantenga la redundancia de la infraestructura a través de nodos de reserva (fail-over), pero nunca ejecute dos nodos de firma activos simultáneamente. La redundancia y la firma activa dual son requisitos mutuamente excluyentes.
7. Participe en los ciclos de actualización de la testnet antes de la exposición a la Mainnet para detectar cambios en el comportamiento del consenso que podrían crear condiciones de equivocación a escala.

Incluso sin un slashing activo, los validadores que acumulan una mala reputación se enfrentan a consecuencias económicas a través del retiro de los delegadores. Los delegadores supervisan los datos de rendimiento a través de Stakewiz, Solana Beach y Validators.app y retiran su stake de los operadores con bajo rendimiento.

Gobernanza del slashing en Solana: propuestas SIMD y qué significan para el futuro

Última actualización: Junio de 2025

Un Documento de Mejora de Solana (SIMD) es el mecanismo formal de gobernanza de Solana para proponer cambios a nivel de protocolo, análogo a los EIP de Ethereum. Los SIMD son la forma en que la comunidad de desarrolladores de Solana propone, debate y ratifica formalmente cambios en el protocolo. La Fundación Solana, una organización sin fines de lucro con sede en Suiza que apoya el ecosistema de Solana, desempeña un papel en la gestión de las discusiones de los SIMD junto con validadores, desarrolladores y otras partes interesadas de la comunidad.

Los miembros de la comunidad de desarrolladores de Solana han presentado propuestas de SIMD relacionadas con el slashing de validadores. Estas propuestas buscan introducir penalizaciones financieras por equivocación (específicamente, violaciones de bloqueo detectadas por Tower BFT) por primera vez a nivel de protocolo. Los lectores deben verificar el estado actual de los SIMD relevantes directamente en el repositorio de Documentos de Mejora de Solana (SIMD)) en GitHub, ya que los estados de las propuestas cambian a medida que avanza la revisión de la comunidad.

El debate sobre la gobernanza se centra en dos posiciones. Los defensores sostienen que las penalizaciones económicas son necesarias para alinear los incentivos de los validadores a escala y que la ausencia de slashing representa una brecha de seguridad en comparación con Ethereum y Cosmos. Aquellos que advierten contra una implementación rápida señalan los riesgos de slashing por falsos positivos en el entorno de alto rendimiento de Solana, donde la latencia de la red o los errores del cliente podrían desencadenar condiciones de equivocación en validadores honestos.

Si se acepta e implementa un SIMD que proponga el slashing, las consecuencias para los validadores y delegadores incluirían:

• La equivocación se convertiría en una infracción penalizable con slashing por primera vez en Solana
• Se quemaría automáticamente un porcentaje definido del SOL total en staking del validador
• Los delegadores probablemente se enfrentarían a una reducción proporcional del capital, dependiendo del SIMD específico aceptado
• Los validadores tendrían que implementar las salvaguardas operativas descritas en la sección anterior antes de que el cambio entre en vigor

A partir de junio de 2025, no se ha implementado ningún SIMD de slashing. Los lectores que sigan este tema deben monitorear el repositorio de SIMD directamente, ya que las discusiones de gobernanza evolucionan fuera del ciclo de publicación de este artículo.

Preguntas frecuentes sobre el slashing de validadores en Solana

¿Tiene Solana slashing de validadores?

No. A partir de junio de 2025, Solana no implementa el slashing de validadores a nivel de protocolo. Solana no tiene ningún mecanismo que queme o reduzca automáticamente el SOL en staking de un validador como penalización por mal comportamiento. El slashing se ha propuesto formalmente a través de los Documentos de Mejora de Solana (SIMD) pero sigue sin implementarse. Los validadores se enfrentan a penalizaciones que afectan a las recompensas (delincuencia, reducción de créditos de voto) pero no a la reducción de tokens.

¿Puede perder su SOL en staking debido al mal comportamiento de un validador en Solana?

A partir de junio de 2025, el capital de su SOL delegado no puede ser reducido automáticamente por el protocolo debido al mal comportamiento de su validador. Lo que sí puede afectarle es el rendimiento del validador: un validador delincuente o con bajo rendimiento obtiene menos créditos de voto, lo que reduce sus recompensas de participar en staking para ese periodo. Si el slashing por SIMD se implementa en el futuro, los delegadores se enfrentarían a un riesgo proporcional del capital.

La equivocación ocurre cuando un validador firma dos votos o bloques en conflicto para el mismo slot, intentando respaldar dos versiones diferentes de la Blockchain a la vez. En Tower BFT, esto constituye una violación de bloqueo. La equivocación es el principal mal comportamiento al que se dirigen las implementaciones de slashing propuestas. El protocolo de Solana puede detectar la equivocación, pero actualmente no la penaliza con la reducción de tokens.

La morosidad significa que un validador pierde votos debido a tiempo de inactividad. Afecta solo a las recompensas de staking a través de la reducción de créditos de voto y no reduce tu Balance principal de SOL. El slashing (propuesto en Solana) implicaría la quema automática de tokens stakeados como castigo por mal comportamiento deliberado como la equivocación. La morosidad afecta a los rendimientos; el slashing afecta al principal. Un validador expulsado ha sido eliminado temporalmente del conjunto activo debido a morosidad prolongada y tampoco afecta al principal del delegador.

¿Es el staking en Solana más seguro que el staking en Ethereum con respecto al slashing?

A junio de 2025, los delegadores de Solana no enfrentan ningún riesgo de slashing a su principal porque el slashing no existe a nivel de protocolo de Solana. La Beacon Chain de Ethereum ha implementado el slashing desde The Merge en 2022, lo que significa que los delegadores de Ethereum que utilizan protocolos de liquid staking soportan una exposición proporcional al slashing si sus validadores cometen violaciones. Los eventos de slashing en Ethereum han sido relativamente raros en la práctica. El riesgo principal actual de Solana proviene de fuentes distintas del slashing.

¿Cuáles son las propuestas SIMD para el slashing en Solana?

Los Documentos de Mejora de Solana (SIMD) son propuestas formales de gobernanza para cambios a nivel de protocolo. A junio de 2025, se han presentado propuestas SIMD para introducir penalizaciones financieras por equivocación en Solana. El estado actual de las propuestas específicas debe verificarse en el repositorio de Documentos de Mejora de Solana (SIMD), ya que los estados cambian durante la revisión comunitaria.

¿Protegen Marinade Finance o Jito contra el slashing?

Tanto Marinade Finance como Jito distribuyen el SOL stakeado entre muchos validadores, reduciendo tu exposición a cualquier mal comportamiento de un solo validador. Si un validador en un grupo grande es penalizado con slashing, solo se ve afectada una pequeña fracción del stake total del grupo. Ninguno de los protocolos elimina por completo el riesgo de slashing, y ambos introducen un riesgo de programa de Solana que el staking directo no conlleva. Consulta la documentación de Marinade Finance y la documentación de staking de Jito para obtener detalles actuales.

¿Cómo funcionaría el slashing en Solana si se implementara?

Bajo las implementaciones de slashing SIMD propuestas, el mecanismo operaría a través de la detección de equivocación existente de Tower BFT. Si un validador comete equivocación (una violación de bloqueo), el protocolo quemaría automáticamente un porcentaje definido del SOL stakeado total del validador. Los delegadores probablemente perderían el mismo porcentaje de su stake delegado proporcionalmente. Los montos de penalización se proponen en las discusiones SIMD pero no están finalizados. Para una explicación completa del mecanismo, consulta Cómo Solana Maneja el Mal Comportamiento del Validador (Tower BFT y Mecánicas de Bloqueo).

¿Qué es una cuenta de stake de Solana?

Una cuenta de stake de Solana es un registro On-Chain que contiene tu SOL stakeado y rastrea tu delegación a un validador específico. Registra la cantidad stakeada, el validador al que está delegada y el estado actual del stake (activo, desactivando o inactivo). Bajo una implementación de slashing, tu cuenta de stake sería el objetivo directo de cualquier penalización aplicada a tu validador. Una cuenta de stake es distinta de tu billetera SOL principal.

¿Qué es Tower BFT?

Tower BFT es el protocolo de consenso de Solana, el sistema que los validadores utilizan para acordar el estado de la Blockchain. Construido sobre Proof of History, utiliza ventanas de bloqueo que aumentan exponencialmente, haciendo que votar en múltiples versiones de Blockchain competidoras sea económicamente irracional. Tower BFT puede detectar la equivocación pero actualmente no activa penalizaciones financieras por ella. Es la base arquitectónica a través de la cual operaría cualquier futuro mecanismo de slashing en Solana.

Conclusión: ¿Es seguro el staking en Solana frente al slashing hoy?

A junio de 2025, el staking en Solana no conlleva riesgo de slashing a nivel de protocolo. Tus SOL delegados no pueden ser reducidos automáticamente por el protocolo debido al mal comportamiento de tu validador. Los riesgos que existen hoy para los delegadores afectan a las recompensas de staking a través de la morosidad del validador y la estructura de comisiones, no a tu Balance principal.

La perspectiva a futuro es diferente. Las propuestas de gobernanza SIMD para introducir el slashing están activas en la comunidad de Solana y, si se aceptan, los delegadores se enfrentarían a un riesgo proporcional de principal. Monitorizar el estado de SIMD es ahora una parte importante del seguimiento de tu perfil de riesgo de staking.

Para los stakers: Revisa la tasa de créditos de voto y el tiempo de actividad de tu validador utilizando Solana Beach o Validators.app. Para una diversificación automática, el liquid staking a través de Marinade Finance o Jito distribuye tu stake sin necesidad de gestión manual del validador. Consulta los criterios de selección de validadores anteriores antes de delegar.

Para los validadores: Revisa las propuestas SIMD actuales en el repositorio de Solana Improvement Documents (SIMD) e implementa las salvaguardas operativas de Tower BFT ahora, antes de que se ratifiquen los cambios en el protocolo.

Para investigadores y analistas: Rastrea el estado de la gobernanza SIMD en el repositorio SIMD y compara el modelo de penalización de validadores de Solana con el historial de incidentes de slashing de Ethereum para modelado de seguridad comparativo.

Glosario

Beacon Chain: Capa de consenso de prueba de participación de Ethereum, introducida con The Merge en septiembre de 2022. El slashing se implementa en la Beacon Chain, no en Ethereum pre-Merge.

Byzantine Fault Tolerance (BFT): Propiedad de los sistemas distribuidos que permite que la red continúe operando correctamente incluso cuando algunos participantes actúan de manera maliciosa o fallan. Recibe su nombre del Problema de los Generales Bizantinos. Tower BFT es la implementación específica de Solana de un consenso de clase BFT.

Morosidad (Delinquency): Un validador de Solana que pierde votos debido a tiempo de inactividad o problemas de rendimiento. La morosidad reduce los créditos de voto y, por lo tanto, las recompensas de staking, pero no reduce el Balance principal.

Delegador: Un poseedor de SOL que asigna su stake a un validador sin ejecutar un nodo propio. Los delegadores obtienen recompensas de staking proporcionales a su parte del pool de stake del validador. La mayoría de los stakers minoristas de SOL son técnicamente delegadores, no validadores.

Época (Epoch): Un período de tiempo fijo en el protocolo de Solana, de aproximadamente 2-3 días de duración. Las recompensas de staking se distribuyen por época. El período de desvinculación (unbonding) de Solana para retirar SOL stakeado abarca aproximadamente una época.

Equivocación (Equivocation): Cuando un validador firma dos votos o bloques conflictivos para el mismo slot, comúnmente llamado doble firma. En Tower BFT, esto constituye una violación de bloqueo (lockout violation). La equivocación es el comportamiento principal que las implementaciones de slashing propuestas tienen como objetivo.

Expulsión (Jailing): Exclusión temporal de un validador del conjunto de consenso activo, típicamente debido a morosidad prolongada. La expulsión no reduce los tokens stakeados. Solo afecta la capacidad del validador para ganar recompensas durante el período de expulsión. Distinto del slashing.

Liquid Staking Token (LST): Un token negociable que representa SOL stakeado mantenido dentro de un protocolo de liquid staking. mSOL es el LST de Marinade Finance; jitoSOL es el LST de Jito. Los LST son instrumentos financieros distintos del SOL stakeado regular.

Bloqueo (Lockout): Un mecanismo de Tower BFT que impide que un validador vote en forks competidores después de comprometerse con uno. Las ventanas de bloqueo aumentan exponencialmente con cada voto subsiguiente. Violar un bloqueo constituye equivocación.

Proof of History (PoH): Un mecanismo criptográfico de cronometraje, no un Mecanismo de Consenso. PoH crea un registro verificable de la secuencia de eventos en la red, funcionando como un reloj criptográfico. Tower BFT, el Mecanismo de Consenso de Solana, se construye sobre PoH.

Proof of Stake (PoS): Un marco de consenso en el que los validadores depositan tokens como garantía para participar en la producción de bloques y la votación. El slashing es el mecanismo de penalización que garantiza el comportamiento honesto en los sistemas PoS. Solana utiliza una arquitectura híbrida (PoH más Tower BFT) en lugar de PoS estándar.

SIMD (Solana Improvement Document): El mecanismo formal de gobernanza de Solana para proponer cambios a nivel de protocolo, análogo a los EIP de Ethereum. Los SIMD son la forma en que se ha propuesto el slashing, aunque aún no se ha implementado en Solana.

Slashing: Una penalización a nivel de protocolo en las blockchains Proof of Stake que reduce automáticamente los tokens en staking de un validador como castigo por un comportamiento indebido demostrable, como la equivocación. A fecha de junio de 2025, el slashing no está implementado en Solana.

Stake Account: Una estructura de datos On-Chain específica de Solana que contiene el SOL en staking de un delegador. Registra la cantidad por la que se va a participar en staking, el validador en el que se delega y el estado actual del stake. Es distinta de una billetera de SOL principal.

Tower BFT: El protocolo de consenso de tolerancia a faltas bizantinas (Byzantine Fault Tolerant) de Solana, basado en Proof of History. Los validadores votan sobre los forks, y cada voto conlleva una ventana de bloqueo que aumenta exponencialmente. Tower BFT puede detectar la equivocación, pero actualmente no la penaliza con la reducción de tokens.

Validador: Un operador de nodo que ejecuta la infraestructura de validación de Solana, emite votos de consenso a través de Tower BFT y participa en la producción de bloques. Los validadores son distintos de los delegadores. El validador es la entidad que sería penalizada directamente bajo cualquier implementación de slashing.

Comisión del validador: El porcentaje de recompensas de staking que retiene un validador antes de distribuir el resto a los delegadores. La comisión es un porcentaje de las recompensas, no del principal por el que se va a participar en staking. Una comisión del 10% significa que el validador se queda con el 10% de las recompensas obtenidas.

Lectura relacionada

• Solana vs. Ethereum: cuál comprar ahora
• ¿Qué es Polkadot? Explicación de las Parachains