Trazendo o slashing para a Solana

Introdução

Slashing é um mecanismo para garantir a segurança da rede por meio da penalização de comportamentos maliciosos ou negligentes de validadores. Quando a conduta indevida é confirmada, uma parte do stake delegado associado aos validadores infratores é queimada.

Esse é um recurso característico de redes Proof of Stake (PoS), como a Solana, sem equivalente em Proof of Work (PoW), pois depende da capacidade do protocolo de aplicar penalidades financeiras diretamente por meio da destruição dos ativos em staking. Em PoW, não existe um mecanismo semelhante, já que a blockchain não pode confiscar nem destruir o hardware físico de mineração de agentes desonestos.

O slashing oferece vários benefícios importantes:

• Atua como um desincentivo econômico direto contra atividades maliciosas
• Incentiva os stakers a distribuir seu stake entre validadores confiáveis, melhorando a descentralização
• Incentiva operadores maiores a criar infraestruturas heterogêneas que reduzam o risco de falhas compartilhadas (por exemplo, dividindo seu stake entre os clientes Firedancer e Agave).
• Oferece outra métrica para os validadores se diferenciarem e construírem reputação ao evitar violações sujeitas a slashing e detectar atividades maliciosas de outros participantes.

Ao longo de sua história, a Solana adotou uma abordagem de consenso manual e orientada pela comunidade, conhecida como slashing social. Nesse modelo, se um validador agir de forma maliciosa, por exemplo, comprometendo a disponibilidade ou a segurança da rede, os participantes honestos podem se coordenar off-chain para iniciar um hard fork, reiniciar a rede e aplicar slashing ao stake do infrator. Embora esse método permita uma avaliação flexível caso a caso, ele exige um esforço significativo de coordenação e é inerentemente reativo.

Até hoje, nenhum validador da Solana sofreu slashing. O mais próximo que a Solana chegou de um evento semelhante ocorreu em maio de 2020, dois meses após o lançamento da mainnet, quando a Solana Foundation queimou voluntariamente 11,36 milhões de SOL de sua própria alocação em resposta às preocupações da comunidade sobre empréstimos de tokens não divulgados a formadores de mercado. Isso reduziu a oferta total de tokens em 2,3%, de 500 milhões para 488,64 milhões de SOL. Embora não tenha sido um evento formal de slashing, a queima funcionou como uma penalidade autoimposta para restaurar a confiança e tratar das questões de transparência levantadas pela comunidade inicial.

Há vários anos, existem pedidos para que a Solana adote um mecanismo de slashing mais formal, frequentemente chamado de slashing programático, aplicado diretamente on-chain por meio de um programa incorporado ao protocolo. Nesse sistema, se um validador violar regras específicas do protocolo, uma prova criptográfica da infração poderá ser gerada e enviada a um programa dedicado, que então acionará o slashing automaticamente. Esse modelo reduz a dependência da coordenação humana e permite aplicar penalidades a infrações menores sem interromper as operações da rede, abrindo caminho para uma responsabilização descentralizada e escalável.

A próxima ativação do feature gate de SIMD-0204: Verificação de Eventos Sujeitos a Slashing representa o primeiro passo grande e significativo da Solana para implementar o slashing programático formal na mainnet. Como veremos mais adiante neste relatório, felizmente, eventos de slashing programático em redes blockchain são raros, e as penalidades costumam ser pequenas. No entanto, até a mera possibilidade de o stake de um validador ser destruído automaticamente pelo protocolo introduz novos riscos que todas as partes interessadas devem avaliar com cuidado. Há muitas questões em aberto sobre a abordagem ideal para a Solana aplicar o slashing programático. Assim como todas as mudanças econômicas, os parâmetros e as penalidades associados ao slashing exigirão ampla discussão da comunidade e precisarão ser aprovados por uma votação formal de governança.

SIMDs relacionados ao slashing

Vários SIMDs estão relacionados à implementação do slashing programático na Solana. Os dois primeiros, SIMD-180 e SIMD-204, devem entrar em operação na mainnet nos próximos meses.

O primeiro é o pré-requisito SIMD-0180: Usar o endereço da conta de voto como chave da programação de líderes. Esse SIMD altera a chave usada na programação de líderes, substituindo o endereço de identidade do validador pelo endereço de sua conta de voto. Essa mudança é essencial para atribuir o slashing com precisão, pois cria uma relação direta e inequívoca entre as responsabilidades de produção de blocos de um validador e seu stake delegado.

O SIMD-0204: Verificação de Eventos Sujeitos a Slashing descreve um novo Programa de Slashing. Ele introduz um mecanismo on-chain que permite a qualquer pessoa enviar e registrar evidências de comportamentos sujeitos a slashing, criando um registro verificável e imutável da conduta indevida de validadores.

Por fim, o SIMD-0212: Slashing descreve a implementação do slashing no protocolo Solana. Ele se baseia nos fundamentos estabelecidos pelo SIMD-0204 para aplicar penalidades a violações verificadas. Essa proposta permanece aberta e ainda está em discussão ativa.

Detecção e atribuição de falhas

O Programa de Slashing foi projetado como uma camada puramente observacional. Ele não modifica stakes nem recompensas; sua única função é verificar e registrar infrações. Um protótipo inicial já está ativo na Testnet, com envios de exemplo (como transações DuplicateBlockProof) demonstrando como as violações podem ser registradas.

Produção de blocos duplicados

Em sua implementação inicial, o programa se concentrará em um único tipo de comportamento malicioso: detectar ocorrências de produção de blocos duplicados. Isso acontece quando um líder envia duas ou mais versões diferentes de um bloco para o mesmo slot, o que constitui uma violação clara e objetiva do consenso. 

Anteriormente, em setembro de 2022, uma interrupção da rede foi causada por um validador que produziu por engano blocos duplicados na mesma altura de bloco. Isso aconteceu porque o node principal e o node de reserva do validador ficaram ativos simultaneamente, usando a mesma identidade de node, mas propondo blocos diferentes.

Desde então, esse problema foi corrigido e, hoje, mesmo quando um operador mantém uma instância de reserva ativa, o cliente do validador inclui proteções que o desligam caso várias instâncias sejam detectadas. Portanto, a produção de blocos duplicados seria extremamente improvável sem uma modificação deliberada e maliciosa do software do validador.

A produção de blocos duplicados é um exemplo de violação de protocolo difícil de detectar em tempo real, mas simples de verificar posteriormente. Tentar coordenar uma resposta síncrona, na qual a rede para para confirmar a observação coletiva da duplicação, introduziria uma complexidade significativa. Em vez disso, é muito mais prático lidar com a detecção e o slashing retroativamente.

As provas enviadas de blocos duplicados incluem dois shreds conflitantes para o mesmo slot, ambos assinados pelo mesmo validador. O programa de slashing verifica a prova confirmando que os shreds formam uma prova válida de bloco duplicado, pertencem ao mesmo slot e foram assinados corretamente pelo validador infrator. Essa lógica reflete a abordagem usada no protocolo gossip da Solana para processar provas de blocos duplicados no processo de escolha de fork.

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,
}

O denunciante cria uma prova e a armazena em uma conta de buffer on-chain. Em seguida, envia uma transação ao programa de slashing no endereço `S1ashing11111111111111111111111111111111111`, referenciando sua conta de buffer. Quando uma prova é verificada com sucesso, os resultados são armazenados em um Program Derived Address (PDA) `report_account` pertencente ao programa de Slashing para referência futura. Isso facilita a criação de dashboards que exibem dados relacionados ao slashing: basta executar uma chamada getProgramAccounts no programa de slashing. Os validadores podem usá-los para verificar se foram denunciados por violações e tomar as medidas corretivas necessárias.

Espera-se que a Anza disponibilize ferramentas para observar esses eventos, criar provas e enviá-las on-chain. Provavelmente haverá várias implementações, incluindo uma versão incorporada ao software do validador. Basta que um único participante honesto denuncie uma violação dentro de uma época, pois cada combinação única de infrator e slot só pode ser denunciada uma vez. O programa verifica se já existe uma denúncia para o mesmo slot e infrator. Se uma denúncia correspondente for encontrada, o novo envio será rejeitado. As denúncias podem ser enviadas até uma época após a ocorrência da violação, com base no slot em que ela aconteceu (ou seja, até 432.000 slots depois, conforme monitorado pela sysvar `Clock`).

Recompensas para denunciantes

Uma questão comum no design de slashing é se aqueles que denunciam violações devem ser recompensados. Embora recompensar denunciantes possa parecer um mecanismo de incentivo simples, isso traz desafios importantes.

Na Solana, onde os líderes controlam a inclusão de transações, uma recompensa ao denunciante cria o risco de frontrunning. Suponha que um validador envie uma prova válida de slashing ao líder do bloco atual. Nesse caso, o líder pode simplesmente copiar a prova, enviá-la por conta própria e censurar a transação original, reivindicando a recompensa sem realizar o trabalho. Isso enfraquece o modelo de incentivos e abre espaço para abusos.

A Ethereum oferece uma pequena recompensa ao denunciante: 1/512 do saldo efetivo do validador que sofreu slashing. Para um validador com os 32 ETH completos, isso equivale a 0,0625 ETH. A recompensa é emitida como novos ETH, mas é compensada pelo valor maior queimado do stake do validador penalizado. O valor baixo é intencional: busca promover a integridade e a participação honesta, em vez de comportamentos oportunistas motivados pelo lucro.

Violações de votação

Espera-se que versões futuras do Programa de Slashing ampliem o suporte a vários tipos de violações de votação, como violações de lockout e de provas de troca.

Uma violação de lockout ocorre quando um validador vota em dois forks diferentes sem aguardar o tempo adequado para que o lockout de sua tower expire. No algoritmo de consenso atual da Solana, o TowerBFT, depois que um validador vota em um fork específico em determinado slot, ele fica impedido de votar em forks concorrentes por certo período. Se esse validador votar posteriormente em outro fork antes do fim do período de lockout, ele violará a regra de lockout.

O bot Votalizer, desenvolvido pelo cofundador da Solana Michael Vines, opera atualmente no Discord da Solana Tech e monitora violações de lockout à medida que ocorrem na rede. Na prática, é raro que validadores cometam essas violações de forma não intencional, pois isso normalmente exigiria uma modificação deliberada do cliente do validador. As proteções integradas garantem que o cliente recupere seu voto on-chain mais recente e impeça ações que resultariam em uma violação de lockout.

Embora as violações de lockout sejam mencionadas explicitamente no SIMD de Slashing e na documentação inicial como exemplo de violação de votação que o programa de slashing pode abordar, a atualização planejada do consenso Alpenglow removerá o Tower BFT, eliminando o conceito de lockouts. Por esse motivo, espera-se que as violações de votação sejam introduzidas somente após o lançamento do Alpenglow.

As novas violações de votação do Alpenglow que o programa de slashing poderia ser projetado para detectar podem incluir ações como enviar votos conflitantes para o mesmo slot, por exemplo, emitir tanto um `NotarVote` quanto um `SkipVote`.

Tipos futuros de violação

O slashing programático deve estar associado a ocorrências verificáveis e inequívocas de conduta indevida. Infelizmente, isso torna muito mais difícil aplicar penalidades a problemas mais subjetivos ou sistêmicos, como a produção deliberadamente lenta de blocos ou formas prejudiciais de extração de MEV.

Entre redes blockchain semelhantes, os tipos de comportamento que normalmente resultam em slashing variam conforme o protocolo. Alguns exemplos comuns são:

• Assinatura dupla: produzir dois blocos conflitantes na mesma altura ou no mesmo slot.
• Indisponibilidade: ficar offline e deixar de participar do consenso.
• Votação envolvente: emitir votos que entrem em conflito com votos anteriores na tentativa de manipular ou desestabilizar a rede.

Uma nova proposta de slashing, apresentada no ano passado por 0xIchigo, da própria Helius, sugeriu penalizar validadores da supermaioria que não participassem de votações formais de governança, com o objetivo de incentivar maior envolvimento. Embora essa abordagem atenda ao requisito de ser objetivamente verificável, vários participantes levantaram preocupações. Alguns observaram que restrições legais podem impedir determinados validadores de votar. Outros argumentaram que o slashing deveria se limitar estritamente a comportamentos que representem uma ameaça direta à segurança ou à integridade da rede.

Aplicação das penalidades

Quando a Solana tiver um mecanismo on-chain confiável para denunciar e verificar infrações sujeitas a slashing, a próxima prioridade será a aplicação econômica do slashing, com a definição dos parâmetros exatos e das fórmulas de penalidade para os diferentes tipos de violação.

As diretrizes ainda estão sendo discutidas ativamente, e o conteúdo apresentado nesta seção reflete propostas atuais destinadas a informar, incentivar o diálogo e evoluir com base no feedback da comunidade. Como essas decisões afetam diretamente a economia da operação de um validador da Solana, qualquer mudança será submetida ao debate público da comunidade e precisará ser aprovada por um processo formal de governança.

Ao determinar as penalidades de slashing, um princípio fundamental é evitar punir com rigor excessivo erros operacionais raros e isolados. O ideal é que o sistema de penalidades tenha uma margem de tolerância para incidentes menores que não afetem o consenso e conte com as proteções adequadas, em vez de impor penalidades severas por erros honestos.

A opção considerada atualmente para essa margem é a linha do Coeficiente de Nakamoto (NC), definida no nível de stake do menor validador da superminoria (ou seja, aproximadamente 1% do stake). 

Segundo a função proposta, que determina o valor de cada delegação sujeito a slashing por conta de voto, se o stake total envolvido em uma violação ficar abaixo da linha do NC, nenhum stake sofrerá slashing. Por outro lado, se o consenso estiver em risco, ou seja, se mais de um terço do stake total estiver envolvido em violações, o protocolo deverá responder de forma decisiva, aplicando slashing a 100% do stake infrator.

Para casos entre esses extremos, a proposta atual introduz uma função de penalidade quadrática com crescimento lento. A fórmula usada para calcular a fração do stake a sofrer slashing em cada conta de voto é:

v = conta de voto sujeita a slashing

TSS = Stake Total Sujeito a Slashing

TS = Stake Total

Linha do NC = Linha do Coeficiente de Nakamoto

Com essa fórmula, a porcentagem do stake do validador infrator sujeita a slashing pode ser calculada da seguinte forma:

• 1,2% quando 4,66% do stake está em violação (ou seja, (3 * (0,0466 - 0,01) / 1)²)
• 7,3% quando 10% do stake está em violação (ou seja, (3 * (0,1 - 0,01) / 1)²)

O gráfico abaixo ilustra a curva proposta com duas alternativas (agressiva e linear).

O stake total sujeito a slashing (TSS) é calculado usando um peso baseado no tipo de violação. As violações de votação recebem peso 1, pois são menos graves. As violações de blocos duplicados recebem peso 10, pois são consideradas mais graves.

Uma das principais vantagens das penalidades de slashing quadráticas e correlacionadas, como a proposta atual, é incentivar quem opera vários validadores, como corretoras ou provedores de staking como serviço, a manter uma infraestrutura independente e de alta qualidade para minimizar o risco de falhas generalizadas e correlacionadas.

Alternativas ao slashing tradicional

Aplicar slashing ao stake delegado levanta questões importantes de justiça e responsabilização. No modelo atual de staking, a grande maioria, senão a totalidade, do stake da maioria dos validadores não privados é delegada. Isso significa que, quando ocorre slashing, normalmente são os delegadores, e não os operadores dos validadores que cometeram a violação, que arcam com a maior parte da penalidade. Mesmo stakers cuidadosos que escolhem validadores confiáveis podem sofrer slashing sem culpa própria caso um validador aja de forma maliciosa ou configure seu node incorretamente.

Para corrigir esse desequilíbrio, vários designs alternativos de slashing foram propostos. Uma abordagem é exigir que todos os validadores mantenham um nível mínimo de stake próprio. Isso garante que os operadores tenham algo a perder e não possam transferir todo o custo do slashing para seus delegadores. Uma versão mais rígida dessa abordagem aplicaria slashing apenas ao stake próprio e removeria automaticamente do staking todos os delegadores associados ao validador penalizado. Os delegadores perderiam as recompensas, mas manteriam o principal, o que permitiria realocar seu stake para outro validador com impacto mínimo no longo prazo.

Outra abordagem é congelar as contas por um período definido, durante o qual elas não poderiam receber recompensas, mudar de proprietário nem retirar fundos. A duração do congelamento aumentaria conforme a gravidade da infração. Como alternativa, o protocolo poderia aplicar slashing às recompensas futuras, reduzindo os ganhos do validador e de seus delegadores durante um período definido sem afetar o stake principal.

Alguns propuseram redistribuir o stake penalizado para validadores honestos como forma de reforço positivo, em vez de queimá-lo. No entanto, queimar SOL produz efetivamente um resultado semelhante, pois reduz a oferta total e, assim, aumenta a participação relativa de cada detentor na propriedade da rede.

Considerações

A introdução do slashing na Solana traz várias implicações importantes. Nesta seção, analisamos duas áreas críticas: os períodos de cooldown e os riscos, seguros e encargos operacionais resultantes para os participantes do ecossistema.

Períodos de cooldown

Uma vulnerabilidade importante do modelo atual de staking surge quando um validador comete uma infração sujeita a slashing, mas retira seu stake antes que a violação seja observada e denunciada. Sem um mecanismo para atrasar a retirada, agentes maliciosos poderiam explorar essa diferença de tempo para escapar da punição.

Um período de cooldown em que o stake continuasse sujeito a slashing mesmo após a desativação reduziria esse risco. Esse cooldown deve exceder o pior tempo possível necessário para que validadores ou observadores externos detectem e coordenem uma resposta de slashing, especialmente sob condições adversas, como ataques DDoS no nível da rede ou conluio entre validadores maliciosos. Na prática, isso significa que os períodos de cooldown devem durar vários dias.

A dependência da Solana de snapshots de stake pré-calculados agrava o problema. Vários componentes críticos do protocolo, incluindo a programação de líderes e a regra de escolha de fork, dependem de valores de stake calculados antecipadamente. Como resultado, um stake desativado ou até totalmente retirado ainda pode influenciar o consenso.

Por exemplo, a programação de líderes é derivada de um snapshot anterior do stake, obtido com uma época de antecedência no limite da época. Isso cria uma janela na qual um validador poderia cometer uma infração sujeita a slashing após já ter desativado seu stake na época anterior e retirado os fundos no início da época atual. Quando a violação fosse descoberta, já não haveria stake ativo para penalizar.

Uma solução seria introduzir um período adicional de cooldown no qual o stake continuaria sujeito a slashing, mas deixaria de contar para o peso de stake do protocolo. Os stakers desativariam seu stake na época N, mas só poderiam retirá-lo no início da época N+3. Embora isso melhore a segurança, tal atraso prejudica a experiência do usuário ao obrigar os stakers a esperar cerca de ~2 a 4 dias adicionais antes de retirar completamente seu stake. Uma forma de resolver isso seria encurtar as épocas para preservar atrasos reais de retirada semelhantes ao padrão atual. No entanto, qualquer redução na duração das épocas poderia ter implicações imprevistas para o protocolo e precisaria ser avaliada com cuidado.

Risco, seguro e encargo operacional

A introdução do slashing na Solana traz implicações para uma ampla variedade de participantes do ecossistema, especialmente aqueles que custodiam, administram ou criam produtos financeiros sobre SOL em staking. Até mesmo a possibilidade de slashing pode introduzir riscos financeiros, complexidade operacional e preocupações reputacionais, sobretudo para instituições sujeitas a restrições fiduciárias ou regulatórias. Esses riscos podem ser tratados por meio de proteções como seguros ou garantias.

As partes potencialmente afetadas incluem:

• Protocolos de staking líquido
• Pools de stake
• Provedores de staking com custódia
• Protocolos de restaking
• Protocolos DeFi
• ETFs de staking

Para algumas dessas entidades, um evento de slashing pode gerar consequências em cascata. Por exemplo, tokens de staking líquido (LSTs) são respaldados pela premissa de que os validadores subjacentes operam com segurança. Se um validador sofrer slashing, isso poderá provocar uma forte reprecificação de seu LST ou, em casos extremos, a perda da paridade caso a confiança no validador em que o SOL subjacente está em staking desapareça. Isso pode levar a liquidações se o LST estiver sendo usado como garantia em um protocolo de empréstimos.

É comum que provedores de staking em outros ecossistemas ofereçam seguro contra slashing para mitigar esses riscos. Na Ethereum, por exemplo, muitos provedores disponibilizam cobertura acessível contra perdas decorrentes de slashing, com níveis de proteção que variam conforme o plano de cobertura.

O risco de slashing também introduz novas responsabilidades operacionais em toda a cadeia de valor do staking. Entre os afetados estão:

• Operadores de serviços de staking, que agora precisam monitorar o comportamento dos validadores e mitigar riscos proativamente
• Plataformas de custódia e corretoras de criptoativos, que dependem de operadores terceirizados e podem precisar avaliar e diversificar seus conjuntos de validadores
• Gestores de ativos institucionais, que podem buscar cobertura para perdas próprias a fim de se proteger contra prejuízos relacionados ao slashing causados por operadores externos

Comparação com redes semelhantes

Esta seção examina como o slashing é implementado em redes Proof of Stake semelhantes, como Ethereum e Cosmos. Essas redes aplicam slashing programático há muitos anos e oferecem dados reais valiosos sobre a frequência desses eventos e seu impacto na segurança da rede e no comportamento dos validadores.

Ethereum

O protocolo Proof of Stake da Ethereum, introduzido com o lançamento da Beacon Chain em dezembro de 2020, inclui o slashing como mecanismo central de aplicação desde o primeiro dia. A Ethereum define quatro infrações específicas sujeitas a slashing, todas relacionadas à equivocação:

• Propor vários blocos para o mesmo slot
• Enviar atestações conflitantes para o mesmo checkpoint de destino
• Atestar blocos de topo diferentes com os mesmos checkpoints de origem e destino
• Criar duas atestações em que uma “envolve” a outra em termos dos votos de origem e destino

Todas essas infrações seguem a mesma estrutura de penalidade. Quando um validador sofre slashing, uma penalidade imediata de 1/32 de seu saldo efetivo é aplicada, limitada a 1 ETH devido ao saldo efetivo máximo de 32 ETH. Em seguida, o validador é removido à força do conjunto ativo e colocado na fila de saída por aproximadamente 36 dias.

Durante esse período, o validador permanece inativo e não pode retirar fundos. Ele continua perdendo as recompensas que receberia se estivesse ativo, incorrendo efetivamente em um custo de oportunidade contínuo. Após 18 dias, uma penalidade adicional de correlação é aplicada, projetada para aumentar proporcionalmente ao número de validadores que sofreram slashing em uma janela de 36 dias. Se apenas alguns validadores forem penalizados, a perda será pequena. Porém, em eventos de slashing em massa, seja por conduta indevida coordenada ou por falhas de infraestrutura compartilhada, as penalidades aumentam drasticamente e, no pior cenário, podem resultar na perda de quase todo o saldo em staking do validador.

Apesar de sua importância central no protocolo da Ethereum, o slashing é extremamente raro na prática. Até maio de 2025, apenas 484 validadores, menos de 0,05% do conjunto total, haviam sofrido slashing em 131 incidentes. Esses incidentes frequentemente surgiram de um único erro que afetou vários validadores e, em geral, resultaram de falhas dos operadores ou bugs de software, não de intenção maliciosa.

O maior evento de slashing ocorreu em novembro de 2023, quando a Bitcoin Suisse teve 100 validadores penalizados por infrações relacionadas à inatividade, com cada um perdendo 1 ETH.

Até hoje, nenhum incidente de slashing na Ethereum ameaçou a integridade geral do protocolo. Isso sugere que, embora o slashing seja um mecanismo de dissuasão essencial, sua aplicação efetiva é pouco frequente, e o ecossistema de validadores assimilou amplamente os comportamentos necessários para evitar essas penalidades.

Cosmos

A Cosmos e as chains baseadas no Cosmos SDK, como a Cosmos Hub, implementam o slashing como um mecanismo de segurança integrado que trata de duas falhas principais: assinatura dupla e indisponibilidade prolongada. Essas regras de slashing garantem tanto a segurança quanto a disponibilidade do protocolo.

Um validador que assina dois blocos diferentes na mesma altura é punido imediatamente. Qualquer participante pode enviar evidências on-chain da violação e, após a verificação, o validador sofre automaticamente slashing de 5% de seus tokens em staking e é colocado em estado tombstoned, o que significa que é removido permanentemente do conjunto ativo de validadores e não pode retornar. Depois disso, tanto o validador quanto seus delegadores precisam aguardar o período de desvinculação antes que o stake possa ser redelegado. Embora o operador de um validador tombstoned possa reiniciar a operação com uma nova chave, ele precisará reconstruir sua reputação e suas delegações do zero.

A Cosmos também garante a disponibilidade por meio de slashing automático em casos de indisponibilidade prolongada. Se um validador assinar menos de 5% dos últimos 10.000 blocos, ele será considerado inativo e receberá uma penalidade de slashing de 0,01% do stake. Embora pequena em comparação, essa aplicação é rígida e inegociável, garantindo que os validadores mantenham a disponibilidade e uma participação confiável no consenso.

Curiosamente, alguns validadores optam por aceitar essa pequena penalidade como custo do encerramento voluntário das operações, considerando a perda insignificante.

Embora as redes Cosmos SDK compartilhem parâmetros padrão de slashing, cada chain pode modificar ou ampliar essas regras para refletir suas próprias premissas de segurança e modelos de risco. Essa flexibilidade permite que cada rede calibre seu sistema de slashing de acordo com o tamanho do conjunto de validadores, suas metas de descentralização ou sua tolerância esperada a falhas. A atividade de slashing em 57 mainnets baseadas no Cosmos SDK oferece uma visão mais ampla da aplicação no ecossistema:

• 12.143 ocorrências de slashing relacionadas à indisponibilidade
• 111 ocorrências de slashing por assinatura dupla
• 326 outras infrações
• 12.580 incidentes de slashing no total

Esses números demonstram que, embora a assinatura dupla seja rara e severamente penalizada, o slashing por indisponibilidade é mais frequente e visto principalmente como um custo operacional rotineiro. 

Conclusão

O slashing continua sendo um dos temas mais debatidos e emocionalmente carregados da indústria blockchain. Sempre que surgem novas formas de conduta indevida de validadores ou desalinhamento de incentivos, os pedidos por slashing aparecem rapidamente. É fácil entender o motivo: à primeira vista, o slashing parece ser um poderoso mecanismo de dissuasão, oferecendo uma forma direta e on-chain de punir agentes maliciosos e preservar a integridade da rede.

No entanto, como este artigo demonstrou, o slashing programático está longe de ser uma solução universal para condutas indevidas. Sua eficácia depende de as infrações serem inequívocas e comprováveis, condições que nem sempre são fáceis de atender em situações complexas do mundo real. Aplicar slashing quando as evidências não são claras ou estão sujeitas a interpretação pode punir agentes honestos, abalar a confiança e causar mais danos do que as violações que o mecanismo busca evitar.

Pode-se dizer que o maior valor das formas automatizadas de slashing para uma rede é seu impacto psicológico sobre as partes interessadas. Até mesmo a mera possibilidade de perda econômica por qualquer tipo de violação, por mais rara que seja, pode ser suficiente para levar stakers avessos ao risco a distribuir suas delegações entre vários validadores, além de motivar operadores a investir em uma infraestrutura diversificada e independente.

Recursos adicionais

• Slashing: panaceia ou caixa de Pandora? - Tim Roughgarden, Accelerate Conference
• Os limites econômicos do consenso sem permissão - Eric Budish, Andrew Lewis-Pye, Tim Roughgarden 
• Disponibilidade responsabilizável - Andrew Lewis-Pye, Joachim Neu, Tim Roughgarden, Luca Zanolini