Na noite de 22 de setembro, um usuário enviou uma transferência de ATOM.
Depois de uma noite, a transação ainda permanecia "aguardando confirmação".
A chave privada não foi perdida, e a carteira não mostrou anomalias de assinatura. Ao verificar novamente no dia seguinte, vários RPCs públicos mostravam que o Cosmos Hub havia parado na altura de bloco 33.086.740.
Sem novos blocos sendo produzidos, naturalmente não havia onde empacotar essa transação.
Somente cerca de um dia depois, após o Cosmos Hub retomar a produção de blocos, essa transferência de ATOM, que estivera em estado de espera o tempo todo, finalmente foi concluída com sucesso.
Para usuários comuns, esta pode ser a lição mais intuitiva para entender o consenso de blockchain.
Estamos acostumados a dizer que "nenhuma instituição central pode desligar uma cadeia pública", mas a realidade é claramente muito mais complexa. Uma blockchain suficientemente descentralizada de fato geralmente não tem aquele "botão de desligar" em uma sala de servidores, mas ainda pode parar.
Esta pausa do Cosmos Hub acabou expondo completamente esse conjunto de mecanismos, geralmente ocultos na camada subjacente, aos usuários comuns.
1. Por que o Cosmos de repente "parou de produzir blocos"?
Primeiro, é necessário esclarecer uma questão que é fácil de confundir: o que foi diretamente atacado desta vez não foi o Cosmos Hub.
O incidente ocorreu primeiro na Neutron.
Em 22 de setembro, uma proposta de governança da Neutron chamada "AIATO: AI Agent Takeover" foi aprovada. O atacante explorou uma brecha nas permissões de governança em nível de cadeia e usou instruções privilegiadas nativamente fornecidas pelo framework wasmd para alterar os administradores de contratos de aplicações como Astroport e Drop para endereços controlados pelo atacante.
Isso não é o que normalmente entendemos como uma "vulnerabilidade de código" ou "falha de protocolo".
Pode ser simplesmente entendido como: as próprias aplicações têm suas "fechaduras de porta", mas a governança em nível de cadeia da Neutron também possui uma "chave mestra" de privilégio superior, e quando o atacante controla o resultado da governança, é equivalente a obter essa chave, permitindo-lhe reatribuir administradores, migrar contratos e transferir ainda mais os ativos dentro deles.
O que realmente arrastou o Cosmos Hub foi a transferência de fundos entre cadeias que se seguiu.
A análise post-mortem do Cosmos Labs mostra que, antes de a Neutron parar de operar, o atacante já havia movido alguns ativos para várias redes, entre os quais cerca de 1,7 milhão de ATOM foram transferidos para o Cosmos Hub e começaram a ser trocados por meio de liquidez entre cadeias.
Em outras palavras, o próprio Cosmos Hub não foi diretamente atacado, e os fundos dos usuários comuns do Hub não foram diretamente roubados por causa da vulnerabilidade da Neutron.
Mas os ATOM obtidos a partir do ataque já haviam entrado no Hub, e, para impedir que os ATOM restantes continuassem a fluir para fora, alguns validadores do Cosmos Hub começaram a parar de executar seus nós.
Por volta das 19h18 de 22 de setembro (SGT), os validadores que haviam parado de operar já representavam mais de um terço do poder de voto total, então o Cosmos Hub não pôde mais continuar formando novos blocos e finalmente parou em 33.086.740.
Este passo é muito crítico.
Isso significa que o Cosmos Hub não tem um botão de "Pausa" que alguma empresa possa clicar diretamente, nem passou primeiro por uma votação de governança on-chain. O que realmente parou a rede foi que validadores suficientes deixaram de participar da formação de consenso.
Mas o que é mais notável é, na verdade, o processo de recuperação posterior.
Cerca de 4 horas após a parada da chain, os validadores receberam um plano de recuperação completo: executar uma modificação de estado única na altura em que a chain parou, transferindo os ATOM restantes no endereço do atacante para um endereço multisig gerenciado conjuntamente pelos validadores da comunidade.
A Cosmos Labs então produziu o patch Gaia v28.3.0 com base no plano já acordado pelos validadores, testou-o e distribuiu-o aos validadores.
Essa versão do Gaia executaria uma alteração de estado única na altura de recuperação especificada, transferindo 1.227.121 ATOM do endereço do atacante para um endereço multisig 4-de-6 composto por seis partes: Nansen, Keplr, Enigma, Silknodes, Kiln e Polkachu.
Na madrugada de 23 de setembro, os validadores confirmados como tendo instalado a v28.3.0 já ultrapassavam 67% do poder de voto total, então às 12:00 UTC daquele dia, a Cosmos Hub coordenou uma reinicialização. Cerca de 6 minutos depois, essa modificação de estado única foi executada na altura de bloco 33.086.741, e a rede retomou a produção normal de blocos.
Em última análise, ao longo de todo o processo, desde a parada da produção de blocos da Cosmos até a retomada da operação, os validadores primeiro fizeram a rede perder a Liveness, e então mais de dois terços do poder de voto aceitaram um novo conjunto de regras de transição de estado, tornando, por fim, esse conjunto de regras o estado canônico após a recuperação.
Neste ponto, surge uma pergunta aparentemente simples: já que é uma chain pública descentralizada, por que mais de um terço do poder de validação pode pará-la, enquanto restaurar a rede exige que validadores suficientes aceitem e executem conjuntamente o mesmo software?
A resposta está, na verdade, escondida na palavra "consenso".
2. O chamado consenso nunca foi "nunca para"
Uma das coisas mais facilmente mal compreendidas sobre blockchain é equiparar "descentralização" com "nunca cai".
Na verdade, o que o mecanismo de consenso realmente resolve é como, sem um guardião central do livro-razão, muitos nós podem chegar a um acordo sobre a ordem das transações e o estado do livro-razão.
No entanto, diferentes chains públicas não implementam isso da mesma forma.
Por exemplo, o mecanismo mais clássico do Bitcoin é o PoW, prova de trabalho — os mineradores competem para produzir blocos usando poder computacional. Quando dois ramos válidos aparecem na rede por um curto período, os nós escolhem um deles para continuar construindo com base no trabalho acumulado.
Portanto, o Bitcoin não tem um momento claro em que "após 67% de votos, este bloco é para sempre Finalizado". Ele está mais próximo de uma espécie de finalidade probabilística: quanto mais blocos subsequentes houver, maior será o custo de poder computacional necessário para reorganizar e remover transações anteriores.
É também por isso que as pessoas costumavam dizer que é melhor esperar 6 confirmações de bloco para uma transação Bitcoin. Afinal, mesmo com maior poder computacional, não se pode simplesmente ignorar as regras de consenso que os nós estão executando.
É claro que isso não significa que o estado do Bitcoin seja "absolutamente impossível de modificar" sob quaisquer circunstâncias. Teoricamente, se todo o ecossistema aceitar um novo cliente e novas regras de consenso, por meio de um Hard Fork, também é possível fazer com que alterações de estado que eram inválidas sob as regras antigas se tornem válidas.
Mas aqui está o problema: quem tem a capacidade de fazer com que mineradores, Full Nodes, plataformas de negociação, carteiras e usuários suficientes aceitem conjuntamente esse novo conjunto de regras?
Quase ninguém.
A equipe de desenvolvimento não pode decidir sozinha as regras de consenso para toda a rede Bitcoin, e também é difícil para mineradores e plataformas de negociação, porque o limiar de consenso que precisa ser ultrapassado é muito alto. Quando a Binance foi hackeada em 7.000 BTC, algumas pessoas sugeriram que CZ contatasse grandes mineradores para operar, mas no final nada aconteceu.
O Ethereum fornece outro exemplo muito clássico.
Após mudar para PoS, o Ethereum agora usa o consenso Gasper, composto por Casper FFG e LMD-GHOST juntos. Simplificando, uma parte do mecanismo é responsável por determinar "qual chain deve ser seguida atualmente", enquanto a outra parte é responsável por dar aos blocos verdadeira Finalidade.
Somente quando validadores que representam pelo menos dois terços do ETH em staking concordam com o checkpoint correspondente é que um bloco pode avançar mais em direção à finalização; por outro lado, se mais de um terço do stake não participar de votação correta por um longo período, a rede pode temporariamente ser incapaz de formar Finalidade. No entanto, o Ethereum também projetou um inactivity leak, que reduz gradualmente o peso efetivo dos validadores offline quando a finalização não pode ser alcançada por um longo tempo, dando à rede a chance de eventualmente restaurar a Finalidade.
Para realmente mudar esse resultado, é igualmente necessário alterar as regras do protocolo e os clientes.
Assim como no incidente do The DAO em 2016, a comunidade Ethereum acabou realizando um Hard Fork, executando no bloco 1.920.000 uma modificação especial de estado que a Fundação Ethereum na época chamou diretamente de mudança irregular de estado, transferindo os ETH relevantes para um contrato de recuperação.
No entanto, alguns mineradores e membros da comunidade que se recusaram a atualizar e continuaram a manter o estado original acabaram formando o Ethereum Classic (ETC), levando ao conhecido fork entre ETH e ETC, mostrando que nem todos aceitaram esse conjunto de regras.
O Cosmos Hub é diferente novamente. Ele usa o CometBFT, que está mais próximo do consenso BFT típico.
Pode ser entendido como um consenso BFT mais típico, significando que, para um bloco ser realmente confirmado, ele precisa obter um Commit de mais de dois terços do poder de voto.
Sua vantagem é que a Finalidade é muito clara. Uma vez que um bloco foi confirmado após votação por poder de verificação suficiente, não há necessidade de continuar esperando por mais e mais blocos como no PoW, trocando probabilidade por uma sensação de segurança.
Mas seu outro lado também é muito direto: se um terço ou mais do poder de voto não fornecer mais os votos necessários para formar um Commit, então, não importa o quanto os validadores restantes se esforcem, eles não conseguirão reunir mais de dois terços.
Neste ponto, a escolha mais segura para a rede é exatamente a "pausa na produção de blocos" vista desta vez, então, da perspectiva de sistemas distribuídos, essa breve parada do Cosmos Hub na verdade não é misteriosa.
Em uma palavra, depois que um grupo de validadores detendo poder de voto suficiente para de participar, o protocolo de consenso, de acordo com suas próprias regras, prefere perder disponibilidade a continuar confirmando novos blocos sem consenso suficiente.
Por trás disso, na verdade, correspondem dois conceitos em sistemas distribuídos que são frequentemente confundidos por usuários comuns:
- Segurança: nós diferentes não devem confirmar simultaneamente dois estados finais conflitantes;
- Vivacidade: se a rede ainda pode continuar funcionando e processar novas transações;
Para sistemas BFT, quando há nós insuficientes participando do consenso, pausar às vezes é precisamente o preço pago para manter a Segurança. Para ser franco, este livro-razão descentralizado prefere parar ali primeiro a deixar as pessoas restantes cada uma manter seus próprios registros.
Olhando para trás deste ângulo, percebe-se que muitos incidentes aparentemente completamente diferentes na história das blockchains públicas na verdade giram em torno da mesma coisa:
Quando nós distribuídos não conseguem mais formar um consenso sobre o "estado correto", o que a rede deve fazer?
III. Do Bitcoin ao Solana, onde está a verdadeira fronteira de risco das blockchains públicas?
Esta não é a primeira vez que o Cosmos coloca essa questão na mesa.
Já em 2013, o Bitcoin passou por um incidente de fork de cadeia muito clássico.
Na época, o Bitcoin 0.8 trocou seu banco de dados subjacente do Berkeley DB para o LevelDB. Posteriormente, apareceu um bloco contendo um grande número de entradas de transação. Nós da nova versão conseguiam processá-lo normalmente, mas alguns nós da versão antiga, devido ao limite de contagem de locks do Berkeley DB, julgaram esse bloco como inválido.
Assim surgiu uma cena muito embaraçosa: todos estavam executando o Bitcoin, mas os clientes antigos e novos começaram a dar respostas diferentes para "se este bloco é legal ou não".
A rede, portanto, se dividiu em duas cadeias, e o lado da nova versão 0.8 chegou a ter cerca de 60% da taxa de hash, e não podia contar com a competição normal de taxa de hash para convergir rapidamente por conta própria.
No final, grandes pools de mineração coordenaram-se para voltar à versão antiga, recuperaram mais taxa de hash do lado das regras antigas, e só então a rede convergiu novamente. O Bitcoin depois revisou especificamente este incidente com o BIP 50.
Em 2016, o incidente do The DAO no Ethereum empurrou o problema um passo adiante.
Como mencionado acima em relação ao incidente do The DAO, a comunidade Ethereum acabou realizando um Hard Fork, executando no bloco 1.920.000 uma modificação especial de estado explicitamente chamada pela Ethereum Foundation de alteração irregular de estado, transferindo os ETH relevantes para um contrato de recuperação.
Mas nem todos concordaram com esse tratamento. Alguns mineradores e membros da comunidade que se recusaram a aceitar a modificação de estado continuaram a manter as regras originais, o que levou ao Ethereum Classic (ETC), que existe até hoje.
Esse DAO Fork também foi um evento clássico, equivalente a dizer a todos que quando ocorrem eventos extremos, além do consenso de código, também existe o consenso social. Se não for possível formar opiniões suficientemente consistentes, uma chain realmente pode se dividir em duas.
A Solana em 2021 demonstrou outro caminho de falha completamente diferente.
Em setembro daquele ano, uma grande quantidade de transações de bots inundou a rede, fazendo com que os nós validadores ficassem sem memória e muitos nós travassem. Eventualmente, toda a rede não conseguiu formar consenso sobre o estado atual e parou de confirmar novos blocos por cerca de 17 horas, após o que os validadores coordenaram-se conjuntamente para restaurar a rede.
Juntando esses incidentes, percebe-se que eles não são a mesma coisa:
- O problema do Bitcoin em 2013 era que clientes diferentes começaram a aplicar regras de validade diferentes;
- O problema da Solana em 2021 era que uma grande quantidade de nós validadores não conseguia mais participar normalmente do consenso, e a rede perdeu Liveness;
- O que o Ethereum DAO enfrentou estava mais próximo da questão de saber se uma comunidade deveria modificar ativamente o estado por meio de novas regras de protocolo;
- E desta vez o Cosmos Hub tem mais uma camada de particularidade: a rede primeiro perdeu Liveness ativamente por meio da coordenação dos validadores para impedir que os ativos atacados continuassem a se mover; depois, uma proporção suficientemente alta de poder de voto aceitou conjuntamente o novo software e o estado de recuperação, permitindo que a rede voltasse a formar consenso;
Portanto, em vez de simplesmente reduzir esses eventos a "então blockchains realmente podem parar" ou "a descentralização é toda falsa", é melhor admitir um fato mais real:
O mecanismo de consenso nunca foi uma máquina que não pode quebrar. O que ele realmente fornece é, na verdade, um conjunto de regras descentralizadas, como quem decide a chain correta quando surgem divergências; quantos participantes são necessários para que um estado obtenha finalidade; se a rede escolhe continuar funcionando ou parar quando ocorrem falhas; e, em circunstâncias extremas, que tipo de ação coletiva pode mudar as regras de funcionamento daqui para frente.
Isso também deixa este incidente do Cosmos com uma questão mais digna de reflexão para usuários comuns do que "se a chain deve ser parada".
Considerações Finais
Costumamos dizer: not your keys, not your coins.
Essa afirmação, é claro, ainda é verdadeira, só que ela enfatiza o controle dos ativos — desde que a chave privada esteja em suas próprias mãos, carteiras, plataformas de negociação ou outras terceiras partes não podem assinar uma transferência em seu nome.
A premissa é que a blockchain em que você está deve ser capaz de processar essa assinatura a qualquer momento.
No dia em que o Cosmos Hub parou de produzir blocos, os usuários ainda mantinham suas próprias chaves privadas, e os ativos não desapareceram no ar por causa disso, apenas que, mesmo que você assinasse corretamente uma transação, não havia um novo bloco para aceitá-la.
O processo de recuperação ilustra ainda mais que, se participantes de consenso suficientes aceitarem um novo conjunto de regras de estado, o estado on-chain de contas específicas também pode mudar sem ser assinado pela chave privada do endereço original.
Isso não invalida "Not your keys, not your coins", mas nos lembra que a soberania da chave privada e o poder de consenso subjacente nunca foram a mesma coisa.
E para carteiras, o mesmo é verdade.
As carteiras podem garantir que as chaves privadas e os direitos de assinatura estejam nas mãos dos próprios usuários, podem identificar anomalias no nível da cadeia o mais rápido possível, exibir com precisão o status das transações, estabelecer redundância de RPC e nós, e reconfirmar o resultado final das transações após a rede se recuperar.
Mas as carteiras não podem restaurar o consenso de uma cadeia pública, nem podem garantir que a rede subjacente nunca será interrompida, muito menos garantir que as regras e o estado na cadeia nunca sofrerão mudanças no nível de consenso.
Portanto, o que um sistema descentralizado maduro realmente precisa buscar talvez nunca tenha sido "nada pode jamais ser alterado"; pelo contrário, deve esclarecer essas fronteiras imperfeitas o máximo possível: Quem pode pausar o consenso? Quanto peso é necessário? Em que circunstâncias a intervenção de emergência é permitida?
Porque a verdadeira descentralização não pode fazer com que o sistema nunca encontre acidentes; o ponto-chave é que, mesmo que um acidente realmente aconteça, ainda possamos saber quem, com base em quais regras e com quanto consenso, decidiu como este livro-razão deve ser registrado a seguir.
