Saltar al contenido
Financial Context Wiki

Slashing

Slashing es una reducción de participación susceptible de ser sancionada definida por el protocolo tras una conducta indebida atribuible a un validador u operador. Analice la ofensa exacta, las pruebas, la base de participación, la fórmula de penalización, el momento, la delegación y la exposición al retiro en lugar de asumir que cada deber incumplido o porcentaje indicado tiene el mismo efecto.

Actualizado

Solo con fines educativos; no es un consejo de inversión. Invertir puede resultar en pérdidas.

Respuesta directa

El slashing es una reducción de stake definida por el protocolo tras una infracción atribuible a un validador, operador u otro participante vinculado. Una regla completa identifica la infracción sancionable, la evidencia o el contador que la demuestra, el stake expuesto, el cálculo de la penalización y el período durante el que aún puede aplicarse. Puede ir acompañado de suspensión, deshabilitación, salida forzada, pérdida de recompensas o una recompensa por reporte, pero son transiciones de estado distintas salvo que el protocolo las defina conjuntamente.

No existe una regla universal de penalización. Ethereum penaliza propuestas y atestaciones conflictivas, pero trata las obligaciones ordinarias incumplidas y la fuga por inactividad por separado. Una cadena Cosmos SDK puede configurar penalizaciones tanto por doble firma como por inactividad. Polkadot distingue delitos, penalizaciones, deshabilitación y cambios de reputación. Un servicio de reestacado puede agregar otro compromiso susceptible de penalización cuyos contratos, conjunto de operadores y ventana de retiro difieren de la cadena base. Lea las reglas activas para la red, bifurcación, runtime o despliegue de contrato exacto.

Slashing demuestra un predicado de protocolo, no intención maliciosa. Una clave de validador duplicada, un failover de cerebro dividido, una copia de seguridad restaurada, una carrera de firmante remoto o una base de datos de protección contra slashing corrupta pueden producir dos firmas válidas que entran en conflicto incluso cuando el operador no tenía la intención de realizar un ataque. Por el contrario, un mal tiempo de actividad no es automáticamente sancionable en todas las redes, y un mensaje inválido o tardío no es sancionable a menos que cumpla con una regla de infracción definida.

Mantén estos conceptos separados:

  • Recompensa perdida o penalización ordinaria: una obligación estaba ausente, retrasada o incorrecta, pero no se demostró ninguna infracción sancionable.
  • Mecanismo de inactividad: Las penalizaciones de aumentan o el peso de voto cambia durante la no-finalidad prolongada; la fuga de inactividad de Ethereum no constituye en sí misma una reducción.
  • Slashing: una transición de estado en la cadena o reconocida por el protocolo reduce la participación vinculada a una infracción comprobada.
  • Encarcelamiento, deshabilitación, expulsión o sellado: La participación de está suspendida o finalizada; la acción puede ocurrir con o sin una reducción adicional de la participación.
  • Penalización social o contractual: La gobernanza , un acuerdo de servicios, una póliza de seguro o un fork coordinado impone una consecuencia fuera de la función automática de reducción del protocolo base.

La parte que opera la clave no es necesariamente la única parte que soporta la pérdida. Las reglas del protocolo y los contratos de servicio pueden exponer la participación propia, la participación delegada, la participación del nominador, las asignaciones re-invertidas, los retiros en cola o las reclamaciones agrupadas. El seguro y el reembolso son promesas de crédito separadas, no reversiones del evento del protocolo.

Cómo analizar el slashing

1. Fija el conjunto de reglas y el punto de observación

Registra el network, chain ID, fork version activo o en tiempo de ejecución, bloque o época, versión del cliente/especificación y las direcciones de contrato relevantes. Separa las reglas de consenso de los términos de un proveedor de staking y de la interfaz de usuario. Una consulta de parámetros actual y un estado finalizado son evidencia más sólida que una página de ayuda sin fecha.

2. Escribe el predicado exacto de la infracción

Nombra la regla en términos ejecutables: dos propuestas distintas por un mismo validador para el mismo espacio, un double vote, un surround vote, un voto inválido reconocido por el protocolo, o missed > max_missed dentro de una ventana de disponibilidad. No reemplaces el predicado con etiquetas como “mal comportamiento”, “fuera de línea” o “ataque”.

3. Valida la atribución y la evidencia

Verifique la identidad del validador o del operador, las firmas, signing root, la separación de dominios, el contexto del fork, alturas o épocas, y la antigüedad de la evidencia. Para las ofensas por mensajes conflictivos, preserve ambos objetos firmados. Para las reglas de actividad, reproduzca el contador y la ventana del protocolo. La inclusión de evidencia puede ocurrir después de la ofensa, así que distinga infraction time, detection time y application time.

4. Identifique cada saldo expuesto

Determine si la base es effective balance, participación vinculada a la altura de la infracción, participación actual, participación propia, participación delegada, una asignación de ranura de validador, o participación asignada a un operator set. Verifique los límites máximos, mínimos, incrementos de redondeo, denominación, sanciones previas, redelegaciones y si los retiros en cola siguen siendo susceptibles de sanción.

5. Recalcula cada componente de la penalización

Divide el resultado en initial penalty, correlation penalty, penalizaciones por deber continuado, recompensas perdidas, efectos de salida forzada y recompensas por denuncia o de alertadores. Una regla fija simple puede usar slash_amount = slashable_stake * slash_fraction; muchos protocolos activos usan en su lugar funciones dependientes del estado. Nunca aplique un porcentaje principal al saldo de la billetera sin confirmar la base.

6. Traza toda la cronología e identifica quién asume la pérdida

Infracción de rastreo, propagación de evidencia, inclusión, contabilidad de slash, período de cárcel o inhabilitación, ventana de apelación o cancelación, salida, desvinculación y finalización del retiro. Luego, asignar la pérdida entre operador, delegadores, nominadores, titulares de tokens del pool y re-stakers bajo el protocolo y el contrato de servicio. Incluir efectos de precio del token y liquidez por separado de las unidades quemadas.

7. Verificar controles y conciliar el estado

Revise la custodia clave, la exclusividad del firmante, la durabilidad de slashing protection database, el aislamiento por fallos, la restauración de copias de seguridad, la monitorización del reloj y la red, la diversidad de clientes y los procedimientos de incidentes. Recalcule el evento desde el estado finalizado, los parámetros, las pruebas y los deltas de balance; reconcilie con las etiquetas del explorador, las declaraciones del proveedor, los asientos contables y cualquier pago de seguro sin tratar ninguna fuente como concluyente.

Ejemplos resueltos

Firmas conflictivas al estilo Ethereum

Supongamos que el validador V firma el encabezado de bloque A y un encabezado diferente B para slot = 8, con firmas válidas bajo el mismo contexto de bifurcación aplicable. El par satisface la forma de doble proposición del proponente Ethereum; una propuesta perdida en el intervalo 9 no lo hace. Para las atestaciones, sean A = (source = 120, target = 125) y B = (source = 118, target = 127). Debido a que B rodea a A, el par tiene la forma de voto-surround. Solo las etiquetas no son suficientes: los datos realmente firmados, los dominios, el índice del validador y las verificaciones del periodo sancionable deben cumplir la especificación activa.

Este ejemplo también muestra por qué la intención no es una entrada. Dos máquinas que usan la misma clave pueden crear la evidencia. Una captura de pantalla que dice “doble firma” no puede; el protocolo necesita objetos firmados conflictivos válidos.

Cálculo de pérdida proporcional de participación

Considere un protocolo ilustrativo con tokens slashable_stake = 12,500 y un slash_fraction = 0.015 fijo. La pérdida del protocolo es:

12,500 * 0.015 = 187.5 tokens.

Si la regla cobra toda la participación de respaldo de manera proporcional, los tokens 2,500 de la auto-participación del operador pierden 37.5, mientras que los tokens delegados 10,000 pierden 150. Si el contrato de servicio reembolsa a los delegadores pero no al operador, ese pago es una cuenta por cobrar separada y una exposición de crédito. No cambia el corte en la cadena, y esta asignación no debe transferirse a un protocolo que proteja a los delegadores o use una base de participación diferente.

Ventana de actividad estilo Cosmos

Supongamos que una cadena basada en Cosmos SDK ha consultado los parámetros window = 1,000 y min_signed = 0.95. Sus fallos máximos permitidos son:

max_missed = 1,000 - (0.95 * 1,000) = 50.

Si la regla activa se dispara cuando missed > max_missed, exactamente 50 no alcanza el umbral, mientras que 51 sí lo hace. La fracción resultante de sanción, la duración de la cárcel, el reinicio del contador y la capacidad de liberarse provienen de los parámetros activos de esa cadena y de la versión del módulo. Este es un ejemplo de cadena configurada, no una regla universal de prueba de participación y no el tratamiento de inactividad de Ethereum.

Fórmula de infracción correlacionada

La documentación revisada de Polkadot proporciona la fracción de equivocación min((3 * x / n)^2, 1), donde x es el número de infractores y n el recuento de validadores activos. Con x = 5 y n = 100:

min((3 * 5 / 100)^2, 1) = 0.0225 = 2.25%.

Aplicado a unidades 40,000 de participación en la ranura del validador, es decir, 900 unidades. Con x = 20, la misma fórmula da 36%, no cuatro veces 2.25%. Esto demuestra el riesgo de correlación; no autoriza usar esa fórmula en Ethereum, una cadena de Cosmos, una parachain o un runtime Polkadot diferente sin verificar las reglas actuales.

Riesgos y fallos de revisión

  • Conjunto de reglas incorrecto: otra cadena, bifurcación, tiempo de ejecución, red de prueba o implementación de contrato puede tener diferentes infracciones y sanciones.
  • Confusión entre infracción y penalización: las recompensas perdidas, las penalizaciones por inactividad, el encarcelamiento, la desactivación, la expulsión y la reducción no son etiquetas intercambiables.
  • Parámetros obsoletos: La gobernanza y las actualizaciones de pueden cambiar ventanas, fracciones, límites, retrasos y saldos protegidos.
  • Confusión de dominio: Las firmas de diferentes contextos de bifurcación o dominio pueden no formar evidencia susceptible de ser castigada.
  • Evidencia inválida: La evidencia malformada, duplicada, expirada, indexada incorrectamente o no autenticada puede ser rechazada.
  • Descubrimiento retrasado: La evidencia puede llegar después de la redelegación o la iniciación de la salida, por lo que los estados de infracción y aplicación difieren.
  • Instantánea de participación incorrecta: El saldo actual de puede no ser el saldo, poder de voto o participación efectiva utilizada por la regla.
  • Amplificación de la correlación: un cliente compartido, nube, firmante o procedimiento puede convertir un fallo en una penalización masiva dependiente del estado.
  • Claves duplicadas: copió los almacenes de claves y las copias de seguridad activas simultáneamente pueden generar firmas en conflicto.
  • Fallo del firmante remoto: Los reintentos , los bloqueos obsoletos, las bases de datos inconsistentes o los reconocimientos ambiguos pueden causar doble firma.
  • Conmutación por error por cerebro dividido: dos sitios pueden creer que ambos son primarios a menos que la conmutación por error esté protegida criptográficamente.
  • Pérdida de la base de datos de protección: Restaurar claves sin un historial completo de firmas puede hacer que un validador aparentemente limpio sea inseguro.
  • Concentración del operador: muchos validadores bajo un mismo plano de control comparten exposición operativa y de correlación.
  • Delegación de paso: Los delegadores o nominadores de pueden sufrir pérdidas causadas por un operador que no pueden controlar directamente.
  • Superposición de re-staking: un activo puede respaldar múltiples compromisos con autoridades de penalización y reglas de asignación distintas.
  • Exposición a la abstinencia: el desanclaje o la retirada en cola puede seguir siendo punible por infracciones anteriores o recién atribuibles.
  • Incertidumbre en la gobernanza: las apelaciones, los períodos de cancelación, las actualizaciones o la recuperación social pueden cambiar el tiempo, pero no son remedios garantizados.
  • Contabilidad y redondeo: Los incrementos de saldo efectivo , las conversiones de acciones, los límites y los decimales de tokens pueden derrotar la multiplicación del saldo de la cartera.
  • Brechas de observabilidad: Las etiquetas del explorador pueden omitir el par de evidencias, la instantánea de parámetros, las delegaciones afectadas o las sanciones posteriores.
  • Riesgo de contrato y contraparte: Las promesas de la piscina , custodia, seguro y reembolso pueden fallar independientemente de la corrección del consenso.

Conceptos erróneos comunes

¿Se sanciona a todos los validadores que están desconectados?

No. Ethereum aplica penalizaciones por deberes incumplidos e inactividad, pero no clasifica el tiempo de inactividad ordinario como una ofensa sancionable. Las cadenas Cosmos SDK pueden configurar la penalización por tiempo de inactividad. Otros protocolos pueden deshabilitar, encarcelar, reducir recompensas o no hacer nada. Consulta la regla exacta en lugar de generalizar a partir de una red.

¿Requiere el slashing prueba de intención maliciosa?

Usualmente la regla automática evalúa mensajes firmados, evidencia, contadores y estado, no el motivo. Un accidente operativo puede satisfacer el mismo predicado que una equivocación deliberada. La intención puede importar para la gobernanza, el seguro, el litigio o un contrato de servicio, pero no para la transición de estado determinista.

¿Es la pérdida máxima el porcentaje de reducción anunciado?

No necesariamente. El porcentaje puede aplicarse a la participación efectiva, vinculada, asignada, delegada o histórica; la correlación y las penalizaciones continuas pueden aumentar la pérdida; la salida forzada implica la pérdida de recompensas futuras; y el precio del token o los descuentos por participación líquida pueden cambiar el valor económico. Por el contrario, un límite o saldo protegido puede reducir la base cobrada.

¿Iniciar una salida termina la exposición a slashing inmediatamente?

No existe una regla universal que lo diga. La evidencia puede retrasarse, el desbloqueo parcial existe en parte para preservar la responsabilidad, y algunos retiros de re-staking siguen siendo sancionables durante una cola. Verifique el último momento sancionable de cada compromiso, no solo la transacción que solicitó la salida.

¿El delegado, el seguro o la recuperación social eliminan el riesgo de penalización?

No. Redistribuyen o prometen reembolsar una pérdida bajo reglas adicionales. La cobertura puede excluir fallas correlacionadas, expirar, limitar reclamaciones, depender de la gobernanza o crear riesgo de contraparte. La reducción del protocolo sigue siendo un evento separado que debe reconciliarse de forma independiente.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...