Ir para o conteúdo
Financial Context Wiki

Slashing

Slashing é uma redução do stake sujeita a penalidade definida pelo protocolo após má conduta atribuível ao validador ou operador. Analise a ofensa exata, evidências, base de stake, fórmula de penalidade, cronograma, delegação e exposição à retirada, em vez de presumir que toda obrigação não cumprida ou percentual declarado tenha o mesmo efeito.

Atualizado

Para fins educacionais apenas; não é um conselho de investimento. Investir pode resultar em perda.

Resposta direta

Slashing é a redução de stake definida pelo protocolo após uma infração atribuível a um validador, operador ou outro participante vinculado. Uma regra completa identifica a infração sujeita a slashing, a evidência ou o contador que a comprova, o stake exposto, o cálculo da penalidade e o período em que ela ainda pode ser aplicada. Pode vir acompanhado de suspensão, desativação, saída forçada, perda de recompensa ou recompensa por denúncia, mas são transições de estado distintas salvo quando o protocolo as define em conjunto.

Não existe uma regra universal de penalização. Ethereum penaliza propostas e atestações conflitantes, mas trata deveres ordinários perdidos e o vazamento de inatividade separadamente. Uma cadeia Cosmos SDK pode configurar penalizações tanto para dupla assinatura quanto para tempo de inatividade. Polkadot distingue infrações, penalizações, desativação e mudanças de reputação. Um serviço de restake pode adicionar outro compromisso passível de penalização cujos contratos, conjunto de operadores e janela de retirada diferem da cadeia base. Leia as regras ativas para a rede, fork, runtime ou implantação de contrato exata.

Slashing prova um predicado de protocolo, não intenção maliciosa. Uma chave de validador duplicada, failover de split-brain, backup restaurado, corrida de assinador remoto ou banco de dados de proteção contra slashing corrompido podem produzir duas assinaturas válidas que entram em conflito mesmo quando o operador não tinha intenção de atacar. Por outro lado, baixa disponibilidade não é automaticamente passível de slashing em todas as redes, e uma mensagem inválida ou atrasada não é passível de slashing a menos que satisfaça uma regra de infração definida.

Mantenha esses conceitos separados:

  • Recompensa perdida ou penalidade comum: um dever estava ausente, atrasado ou incorreto, mas nenhuma infração passível de penalidade foi comprovada.
  • Mecanismo de inatividade: As penalidades do aumentam ou o peso do voto muda durante a não-finalidade prolongada; o vazamento de inatividade do Ethereum não é, por si só, uma redução.
  • Slashing: uma transição de estado on-chain ou reconhecida pelo protocolo reduz a aposta vinculada a uma infração comprovada.
  • Encarceramento, desativação, ejeção ou tombamento: A participação está suspensa ou encerrada; a ação pode ocorrer com ou sem uma redução adicional da participação.
  • Penalidade social ou contratual: A governança , um contrato de serviço, apólice de seguro ou fork coordenado impõe uma consequência fora da função automática de penalização do protocolo base.

A parte que opera a chave não é necessariamente a única parte que arca com a perda. As regras do protocolo e os contratos de serviço podem expor stake próprio, stake delegado, stake do nominador, alocações reinvestidas, retiradas enfileiradas ou reivindicações agrupadas. Seguro e reembolso são promessas de crédito separadas, não reversões do evento do protocolo.

Como analisar slashing

1. Fixe o conjunto de regras e o ponto de observação

Registre o network, chain ID, fork version ativo ou tempo de execução, bloco ou época, versão do cliente/especificação e endereços de contrato relevantes. Separe as regras de consenso dos termos de um provedor de staking e da interface do usuário. Uma consulta de parâmetro atual e o estado finalizado são evidências mais fortes do que uma página de ajuda sem data.

2. Escreva o predicado exato da infração

Nomeie a regra em termos executáveis: duas propostas distintas por um validador para o mesmo slot, um double vote, um surround vote, um voto inválido reconhecido pelo protocolo, ou missed > max_missed dentro de uma janela de vivacidade. Não substitua o predicado por rótulos como “comportamento ruim”, “offline” ou “ataque”.

3. Valide a atribuição e a evidência

Verifique a identidade do validador ou operador, assinaturas, signing root, separação de domínio, contexto de fork, alturas ou épocas, e idade da evidência. Para infrações de mensagens conflitantes, preserve ambos os objetos assinados. Para regras de disponibilidade, reproduza o contador e a janela do protocolo. A inclusão de evidências pode ocorrer após a infração, então diferencie infraction time, detection time e application time.

4. Identifique todo saldo exposto

Determine se a base é effective balance, participação vinculada na altura da infração, participação atual, auto-participação, participação delegada, uma alocação de slot de validador ou participação atribuída a um operator set. Verifique limites máximos, mínimos, incrementos de arredondamento, denominação, penalidades anteriores, reimplantações e se retiradas em fila permanecem passíveis de penalidade.

5. Reproduza cada componente de penalidade

Divida o resultado em initial penalty, correlation penalty, penalidades de continuidade de dever, recompensas perdidas, efeitos de saída forçada e recompensas por relatório ou denúncia. Uma regra fixa simples pode usar slash_amount = slashable_stake * slash_fraction; muitos protocolos ativos usam funções dependentes do estado em vez disso. Nunca aplique uma porcentagem de destaque ao saldo da carteira sem confirmar a base.

6. Mapeie toda a linha do tempo e quem suporta a perda

Infração de rastreamento, propagação de provas, inclusão, contabilidade de corte, período de prisão ou desativação, janela de apelação ou cancelamento, saída, desobrigação e conclusão do saque. Em seguida, aloque a perda entre operador, delegadores, nominadores, detentores de tokens do pool e reestakers de acordo com o protocolo e o contrato de serviço. Inclua efeitos do preço do token e da liquidez separadamente das unidades queimadas.

7. Verifique os controles e reconcilie o estado

Revise a custódia chave, exclusividade de signatário, durabilidade slashing protection database, isolamento em caso de falha, restauração de backup, monitoramento de relógio e rede, diversidade de clientes e procedimentos de incidentes. Recalcule o evento a partir do estado finalizado, parâmetros, evidências e deltas de saldo; reconcilie-o com os rótulos do explorador, declarações do provedor, lançamentos contábeis e qualquer pagamento de seguro sem tratar uma fonte como conclusiva.

Exemplos resolvidos

assinaturas conflitantes no estilo Ethereum

Suponha que o validador V assine o cabeçalho de bloco A e um cabeçalho diferente B para slot = 8, com assinaturas válidas sob o mesmo contexto de fork aplicável. O par satisfaz o formato de proposição-equívoco Ethereum; uma proposta perdida no slot 9 não satisfaz. Para atestações, seja A = (source = 120, target = 125) e B = (source = 118, target = 127). Como B envolve A, o par tem o formato de voto-que-cerca. Somente os rótulos não são suficientes: os dados efetivamente assinados, domínios, índice de validador e verificações do período sujeitos a penalização devem passar pela especificação ativa.

Este exemplo também mostra por que a intenção não é uma entrada. Duas máquinas usando a mesma chave podem criar a evidência. Uma captura de tela dizendo “assinatura dupla” não pode; o protocolo precisa de objetos assinados conflitantes válidos.

Cálculo de perda proporcional de participação

Considere um protocolo ilustrativo com tokens slashable_stake = 12,500 e um slash_fraction = 0.015 fixo. A perda do protocolo é:

12,500 * 0.015 = 187.5 tokens.

Se a regra cobrar toda a participação de apoio proporcionalmente, os tokens 2,500 do stake próprio do operador perdem 37.5, enquanto os tokens delegados 10,000 perdem 150. Se o contrato de serviço reembolsar os delegadores, mas não o operador, esse pagamento é um recebível separado e uma exposição de crédito. Isso não altera o corte on-chain, e essa alocação não deve ser transferida para um protocolo que proteja os delegadores ou use uma base de stake diferente.

Janela de atividade no estilo Cosmos

Suponha que uma cadeia baseada em Cosmos SDK tenha consultado os parâmetros window = 1,000 e min_signed = 0.95. Seus erros máximos permitidos são:

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

Se a regra ativa disparar quando missed > max_missed, exatamente 50 não atingir o limite, enquanto 51 sim. A fração de corte resultante, a duração da prisão, o reset do contador e a capacidade de liberar vêm dos parâmetros ativos e da versão do módulo dessa cadeia. Este é um exemplo de cadeia configurada, não uma regra universal de proof-of-stake e não o tratamento de inatividade de Ethereum.

Fórmula de infração correlacionada

A documentação revisada de Polkadot fornece a fração de ambiguidade min((3 * x / n)^2, 1), onde x é o número de infratores e n a contagem de validadores ativos. Com x = 5 e n = 100:

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

Aplicado às unidades 40,000 de participação no slot do validador, ou seja, 900 unidades. Com x = 20, a mesma fórmula fornece 36%, e não quatro vezes 2.25%. Isso demonstra risco de correlação; não autoriza o uso dessa fórmula em Ethereum, uma cadeia Cosmos, uma parachain ou um runtime Polkadot diferente sem verificar as regras atuais.

Riscos e falhas na revisão

  • Conjunto de regras errado: outra cadeia, fork, runtime, testnet ou implantação de contrato pode ter diferentes infrações e penalidades.
  • Confusão entre infração e penalidade: As recompensas perdidas, penalidades por inatividade, prisão, desativação, expulsão e corte de não são rótulos intercambiáveis.
  • Parâmetros desatualizados: A governança e as atualizações do podem alterar janelas, frações, limites, atrasos e saldos protegidos.
  • Confusão de domínio: Assinaturas de diferentes bifurcações ou contextos de domínio podem não constituir provas passíveis de penalização.
  • Evidência inválida: Evidências malformadas, duplicadas, expiradas, indexadas incorretamente ou não autenticadas podem ser rejeitadas.
  • Descoberta tardia: A evidência pode chegar após a redelegação ou início da saída, portanto, os estados de infração e aplicação diferem.
  • Snapshot de aposta incorreta: O saldo atual do pode não ser o saldo, poder de voto ou participação efetiva usado pela regra.
  • Amplificação da correlação: um cliente, nuvem, signatário ou procedimento compartilhado pode transformar uma falha em uma penalidade em massa dependente do estado.
  • Chaves duplicadas: copiou keystores e backups ativos simultaneamente podem gerar assinaturas conflitantes.
  • Falha do assinante remoto: Tentativas repetidas do , bloqueios obsoletos, bancos de dados inconsistentes ou confirmações ambíguas podem causar dupla assinatura.
  • Falha de failover por divisão de cérebro: dois sites podem ambos acreditar que são primários, a menos que a alternância de falha seja isolada criptograficamente.
  • Perda do banco de dados de proteção: Restaurar chaves sem um histórico completo de assinaturas pode tornar um validador aparentemente limpo inseguro.
  • Concentração do operador: muitos validadores sob um único plano de controle compartilham exposição operacional e de correlação.
  • Repasse de delegação: Delegadores ou nomeadores podem sofrer perdas causadas por um operador que não podem controlar diretamente.
  • Sobreposição de restaking: um ativo pode suportar múltiplos compromissos com autoridades de penalidade distintas e regras de alocação.
  • Exposição à retirada: O desassociação ou retirada em fila do pode continuar sujeito a penalidades por infrações anteriores ou recém-atribuíveis.
  • Incerteza na governança: apelações, períodos de cancelamento, atualizações ou recuperação social podem alterar o tempo, mas não são soluções garantidas.
  • Contabilidade e arredondamento: Incrementos de saldo efetivo , conversões de ações, limites e casas decimais de token podem derrotar a multiplicação de saldo da carteira.
  • Lacunas de observabilidade: As etiquetas do explorador podem omitir o par de evidências, a captura do parâmetro, as delegações afetadas ou penalidades posteriores.
  • Risco de contrato e contraparte: As promessas de piscina, custódia, seguro e reembolso podem falhar independentemente da correção do consenso.

Equívocos comuns

Todo validador offline é punido?

Não. Ethereum aplica penalidades por deveres não cumpridos e inatividade, mas não classifica o tempo ocioso ordinário como uma infração passível de punição. As cadeias Cosmos SDK podem configurar a penalização por tempo ocioso. Outros protocolos podem desativar, aprisionar, reduzir recompensas ou não fazer nada. Consulte a regra exata em vez de generalizar a partir de uma rede.

O slashing exige prova de intenção maliciosa?

Normalmente, a regra automática avalia mensagens assinadas, evidências, contadores e estado, não o motivo. Um acidente operacional pode satisfazer o mesmo predicado que uma ambiguidade deliberada. A intenção pode importar para governança, seguros, litígios ou um contrato de serviço, mas não para a transição de estado determinística.

A perda máxima é a porcentagem de slashing anunciada?

Não necessariamente. A porcentagem pode se aplicar a stake efetiva, vinculada, alocada, delegada ou histórica; correlação e penalidades contínuas podem aumentar a perda; saída forçada implica na perda de recompensas futuras; e o preço do token ou descontos de liquid-staking podem alterar o valor econômico. Por outro lado, um limite ou saldo protegido pode reduzir a base cobrada.

Iniciar uma saída encerra imediatamente a exposição a slashing?

Não existe uma regra universal que diga isso. As evidências podem ser atrasadas, o desvinculamento existe em parte para preservar a responsabilização, e algumas retiradas de reestacagem ainda podem ser punidas durante uma fila. Verifique o último momento em que a penalização é possível para cada compromisso, não apenas a transação que solicitou a saída.

Delegação, seguro ou recuperação social eliminam o risco de slashing?

Não. Eles redistribuem ou prometem reembolsar uma perda sob regras adicionais. A cobertura pode excluir falhas correlacionadas, expirar, limitar reivindicações, depender da governança ou criar risco de contraparte. O corte do protocolo continua sendo um evento separado que deve ser reconciliado de forma independente.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...