A descentralização nunca significa que a rede esteja sempre online. A operação da cadeia depende de um número suficiente de participantes chegar a um consenso.
Na noite de 22 de setembro, um usuário enviou uma transferência ATOM.
Uma noite se passou e a transação ainda estava “aguardando confirmação”.
A chave privada não foi perdida e não houve exceção de assinatura na carteira. Verificando novamente no dia seguinte, vários RPCs públicos mostraram que o Cosmos Hub parou na altura do bloco 33.086.740.
Se nenhum novo bloco for gerado, naturalmente não haverá lugar para empacotar esta transação.
Só quando o Cosmos Hub retomou a produção de blocos, cerca de um dia depois, é que a transferência ATOM que estava esperando foi finalmente bem-sucedida.
Para usuários comuns, esta pode ser a lição mais intuitiva para entender o consenso do blockchain.
Costumamos dizer que “nenhuma organização central pode encerrar uma cadeia pública”, mas a realidade é obviamente muito mais complicada. Um blockchain suficientemente descentralizado geralmente não possui o “botão de desligamento” na sala do servidor, mas ainda assim pode parar.
A suspensão do Cosmos Hub desta vez expôs completamente esse mecanismo que normalmente fica oculto na parte inferior para usuários comuns.
- Por que o Cosmos de repente “parou de produzir blocos”?
Em primeiro lugar, precisamos esclarecer uma questão facilmente confusa. Não foi o Cosmos Hub que foi atacado diretamente desta vez.
O incidente ocorreu pela primeira vez em Neutron.
Em 22 de setembro, uma proposta de governança da Neutron chamada “AIATO: AI Agent Takeover” foi aprovada. O invasor aproveitou as brechas nas permissões de governança em nível de cadeia e usou as instruções privilegiadas fornecidas nativamente pela estrutura wasmd para alterar os administradores de contrato de aplicativos como Astroport e Drop para endereços controlados pelo invasor.
Este não é o tipo de “vulnerabilidade de código” ou “falha de protocolo” que normalmente entendemos.
Pode-se simplesmente entender que o próprio aplicativo possui sua própria “fechadura de porta”, mas a governança em nível de cadeia do Neutron também possui uma “chave mestra” com autoridade superior. Quando o invasor controla os resultados da governança, equivale a obter essa chave, podendo redesignar o administrador, migrar o contrato e transferir ainda mais os ativos.
O que realmente envolveu o Cosmos Hub foi a subsequente transferência de fundos entre cadeias.
A análise do Cosmos Labs mostra que antes do Neutron parar de funcionar, o invasor transferiu alguns ativos para várias redes. Cerca de 1,7 milhão de ATOMs foram transferidos para o Cosmos Hub e começaram a ser trocados por meio de liquidez cruzada.
Em outras palavras, o Cosmos Hub em si não foi atacado diretamente e os fundos comuns dos usuários do Hub não foram roubados diretamente devido à vulnerabilidade do Neutron.
Porém, o ATOM obtido no ataque já entrou no Hub. Para evitar que o ATOM restante flua, alguns validadores do Cosmos Hub começaram a interromper a operação do nó.
Por volta das 19h18 do dia 22 de setembro (SGT), os validadores parados representavam mais de um terço do poder de voto total, e o Cosmos Hub foi, portanto, incapaz de continuar a formar novos blocos, parando eventualmente em 33.086.740.
Esta etapa é muito crítica.
Isso significa que não existe um botão “Pausar” no qual uma empresa possa clicar diretamente no Cosmos Hub, nem passa primeiro por uma votação de governança na cadeia. O que realmente impede a rede é quando um número suficiente de validadores deixa de participar na formação de um consenso.
Mas o que é mais digno de nota é, na verdade, o processo de recuperação subsequente.
Cerca de 4 horas após a suspensão da cadeia, o verificador recebeu um plano de recuperação completo: realizar uma modificação única de status para o auge da suspensão da cadeia e transferir o ATOM restante no endereço do invasor para um endereço com múltiplas assinaturas gerenciado conjuntamente por validadores da comunidade.
O Cosmos Labs então produziu o patch Gaia v28.3.0 com base na solução que os verificadores alcançaram, testou-o e distribuiu-o aos verificadores.
Esta versão do Gaia realizará uma mudança de estado única na altura de recuperação especificada, transferindo 1.227.121 ATOM no endereço do invasor para um endereço de assinatura múltipla 4 de 6 composto por Nansen, Keplr, Enigma, Silknodes, Kiln e Polkachu.
Na madrugada de 23 de setembro, o número de validadores confirmados com instalação da v28.3.0 ultrapassou 67% do poder de voto total. Portanto, às 12h UTC daquele dia, o Cosmos Hub coordenou um reinício. Cerca de 6 minutos depois, essa modificação única de status foi executada na altura do bloco 33.086.741 e a rede retornou à produção normal de blocos.
Em última análise, durante todo o processo, desde quando o Cosmos parou de produzir blocos até quando retomou a operação, foram os validadores que primeiro fizeram com que a rede perdesse a vitalidade e, em seguida, mais de dois terços do poder de voto aceitaram um novo conjunto de regras de transição de estado, tornando esse conjunto de regras o estado canônico restaurado.
Neste ponto, surge uma questão aparentemente simples: uma vez que se trata de uma cadeia pública descentralizada, porque é que mais de um terço dos direitos de verificação podem interrompê-la e, para restaurar a rede, são necessários validadores suficientes para aceitar e executar o mesmo conjunto de software?
A resposta, na verdade, está na palavra “consenso”.
- O chamado consenso não “nunca para”.
Uma das coisas mais incompreendidas sobre o blockchain é que “descentralização” é equiparada a “nunca tempo de inatividade”.
Na verdade, o problema que o mecanismo de consenso realmente resolve é quantos nós podem chegar a um acordo sobre a sequência da transação e o status do razão na ausência de um contador central.
No entanto, diferentes cadeias públicas implementam isto de maneiras diferentes.
O exemplo mais clássico de Bitcoin é o PoW, que é uma prova de trabalho – os mineradores competem para produzir blocos com base no poder computacional. Quando duas filiais jurídicas aparecem na rede em um curto espaço de tempo, o nó escolhe uma delas para continuar construindo de acordo com a carga de trabalho acumulada.
Portanto, o Bitcoin não tem um momento claro de “este bloco será finalizado para sempre após 67% de votação”. Está mais próximo de uma finalidade probabilística. Quanto mais blocos subsequentes houver, maior será o custo do poder de computação necessário para reorganizar as transações anteriores.
É por isso que todo mundo dizia que é melhor para uma transação Bitcoin esperar 6 blocos para confirmação. Afinal, não importa quão alto seja o poder computacional, ele não pode simplesmente ignorar as regras de consenso executadas pelos nós.
É claro que isso não significa que o estado do Bitcoin seja “absolutamente inalterável” sob nenhuma circunstância. Teoricamente, se todo o ecossistema aceitar um novo conjunto de clientes e novas regras de consenso, através do Hard Fork, as alterações de status que eram inválidas nas regras anteriores também poderão ser tornadas válidas.
Mas aqui está a questão: quem tem a capacidade de fazer com que mineradores, Full Nodes, plataformas de negociação, carteiras e usuários suficientes aceitem esse novo conjunto de regras?
Dificilmente.
A equipe de desenvolvimento não pode decidir as regras de consenso para toda a rede Bitcoin. Também é difícil para mineradores e plataformas de negociação porque o limite de consenso que precisa ser ultrapassado é muito alto. Quando 7.000 BTC foram roubados da Binance, algumas pessoas sugeriram que CZ contatasse grandes mineradores para operar, mas nada aconteceu no final.
Ethereum fornece outro exemplo clássico.
Depois de mudar para PoS, Ethereum agora usa o consenso Gasper composto por Casper FFG e LMD-GHOST. Para simplificar, uma parte do mecanismo é responsável por determinar “qual cadeia deve ser seguida atualmente”, enquanto a outra parte é responsável por fazer com que o bloco alcance a finalidade no verdadeiro sentido.
Quando os validadores representando pelo menos dois terços do ETH apostado chegarem a um acordo sobre o ponto de verificação correspondente, o bloco poderá avançar em direção à finalização; inversamente, se mais de um terço das apostas não participarem na votação correcta durante um longo período de tempo, a rede pode ficar temporariamente impossibilitada de formar a finalidade. No entanto, Ethereum também projetou um vazamento de inatividade para reduzir gradualmente o peso efetivo dos validadores offline quando a finalização não puder ser finalizada por um longo tempo, dando à rede a chance de finalmente restaurar a finalidade.
Para realmente alterar esse resultado, você também precisa alterar as regras do protocolo e o cliente.
Assim como o incidente DAO em 2016, a comunidade Ethereum finalmente implementou uma modificação especial de estado chamada mudança irregular de estado pela Fundação Ethereum no bloco 1.920.000 através do Hard Fork e transferiu o ETH relevante para o contrato de recuperação.
No entanto, alguns mineiros e comunidades que se recusaram a atualizar e continuaram a manter o estado original acabaram por formar o Ethereum Classic (ETC), levando à conhecida bifurcação de ETH e ETC, indicando que nem todos aceitam este conjunto de regras.
O Cosmos Hub é diferente novamente. Ele usa o CometBFT, que está mais próximo de um consenso típico do BFT.
Pode ser entendido como um consenso mais típico do BFT, ou seja, para que um bloco seja verdadeiramente submetido é necessário 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 é submetido através de votação com direitos de verificação suficientes, não há necessidade de continuar esperando por mais e mais blocos como PoW, trocando probabilidade por uma sensação de segurança.
Mas o outro lado também é muito simples, ou seja, se um terço ou mais do poder de voto já não fornecer os votos necessários para formar um Commit, os restantes validadores não conseguirão obter mais de dois terços, por mais que trabalhem arduamente.
A escolha mais segura para a rede neste momento é “pausar a produção de blocos” desta vez, portanto, do ponto de vista de um sistema distribuído, esta breve suspensão do Cosmos Hub não é realmente misteriosa.
Em suma, depois de um grupo de validadores com poder de voto suficiente deixar de participar, o protocolo de consenso, de acordo com as suas próprias regras, prefere perder disponibilidade do que continuar a confirmar 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 podem confirmar dois estados finais conflitantes ao mesmo tempo;
Vivência: a rede pode continuar avançando e processando novas transações?
Para o sistema BFT, quando não há nós suficientes participando do consenso, a suspensão às vezes é o preço pago pela manutenção da Segurança. Para ser franco, este livro-razão descentralizado prefere parar por aí do que deixar que as restantes pessoas mantenham as suas próprias contas.
Olhando para trás a partir desta perspectiva, você descobrirá que muitos acidentes aparentemente completamente diferentes na história das cadeias públicas giram em torno da mesma coisa:
O que a rede faz quando os nós distribuídos não conseguem mais chegar a um acordo sobre o “estado correto”?
- Do Bitcoin ao Solana, onde está o limite real de risco das cadeias públicas?
Esta não é a primeira vez que o Cosmos traz esta questão à mesa.
Já em 2013, o Bitcoin sofreu um clássico acidente de garfo de corrente.
Naquela época, o Bitcoin 0.8 mudou o banco de dados subjacente de Berkeley DB para LevelDB e, em seguida, apareceu um bloco contendo um grande número de entradas de transação. A nova versão do nó poderia processá-lo normalmente, mas alguns nós da versão antiga consideraram o bloco inválido devido ao limite no número de bloqueios do Berkeley DB.
Então apareceu uma cena muito embaraçosa. Todo mundo usava Bitcoin, mas os clientes antigos e novos começaram a ter respostas diferentes sobre “se esse bloqueio é legal”.
Como resultado, a rede se dividiu em duas cadeias, e o lado da nova versão 0.8 já tinha cerca de 60% do poder de computação e não podia contar com a competição normal de poder de computação para convergir rapidamente por conta própria.
No final, grandes pools de mineração se coordenaram para voltar à versão antiga, recuperando mais poder computacional ao lado das regras antigas, e a rede convergiu novamente. Posteriormente, o Bitcoin revisou especificamente o acidente com o BIP 50.
Em 2016, o incidente DAO no Ethereum levou o problema um passo adiante.
Conforme mencionado acima no incidente DAO, a comunidade Ethereum finalmente implementou uma modificação especial de estado explicitamente chamada de mudança de estado irregular pela Fundação Ethereum através do Hard Fork no bloco 1.920.000, transferindo o ETH relevante para o contrato de recuperação.
Mas nem todos concordaram com esta decisão. Alguns mineradores e comunidades que se recusaram a aceitar a modificação de status continuaram a manter as regras originais, e o antigo Ethereum Classic (ETC) surgiu mais tarde.
Este DAO Fork também é um evento clássico, o que equivale a dizer a todos que quando ocorrem eventos extremos, também existe consenso social além do consenso de código. Se não for possível formar uma opinião suficientemente consistente, uma cadeia pode realmente ser dividida em duas.
O Solana 2021 mostra um caminho de falha completamente diferente.
Em setembro daquele ano, um grande número de transações robóticas invadiu a rede, fazendo com que a memória do nó de verificação se esgotasse e um grande número de nós travasse. No final, toda a rede não conseguiu chegar a um consenso sobre o estado atual e parou de confirmar novos blocos por cerca de 17 horas. Em seguida, os validadores trabalharam juntos para restaurar a rede.
Juntando esses acidentes, você descobrirá que eles não são a mesma coisa:
O problema com o Bitcoin em 2013 é que diferentes clientes começaram a implementar diferentes regras de validade;
O problema de Solana em 2021 é que um grande número de nós de verificação não pode continuar a participar normalmente do consenso e a rede perde vitalidade;
O que o Ethereum DAO enfrenta está mais próximo da questão de saber se uma comunidade deve modificar ativamente o status por meio de novas regras de protocolo;
Desta vez, o Cosmos Hub tem outra camada de especialidade. A rede primeiro perde ativamente a vitalidade por meio da coordenação do validador para evitar que os ativos do ataque continuem a se mover; então, uma proporção suficientemente alta de direitos de verificação aceita conjuntamente novo software e restaura o estado, tornando a rede consistente novamente;
Portanto, em vez de simplesmente atribuir estes incidentes a “blockchains podem encerrar” e “a descentralização é falsa”, é melhor admitir um facto mais real:
O mecanismo de consenso nunca é uma máquina indestrutível. O que ela realmente fornece é um conjunto de regras descentralizadas, como quem decidirá a cadeia correta quando ocorrer um desacordo; quantos participantes podem chegar à final estadual; quando ocorre uma falha, a rede opta por continuar funcionando ou parar; e em casos extremos, que tipo de ação coletiva pode alterar as próximas regras de funcionamento.
Isso também faz com que o incidente do Cosmos deixe uma questão que é mais digna de consideração pelos usuários comuns do que “a cadeia deve ser interrompida?”
escreva no final
Costumamos dizer: nem suas chaves, nem suas moedas.
É claro que esta frase ainda é verdadeira, mas enfatiza o controle de ativos - desde que a chave privada esteja em suas próprias mãos, carteiras, plataformas de negociação ou outros terceiros normalmente não poderão assinar uma transferência para você.
A premissa é que o blockchain em que você está deve ser capaz de processar essa assinatura a qualquer momento.
No dia em que o Cosmos Hub parar de produzir blocos, os usuários ainda manterão suas chaves privadas e os ativos não desaparecerão do nada. Porém, mesmo que você assine uma transação corretamente, não há nenhum novo bloco para aceitá-la.
O processo de recuperação explica ainda que se um número suficiente de participantes do consenso aceitarem um novo conjunto de regras de status, o status na cadeia de uma conta específica também poderá mudar sem a assinatura da chave privada do endereço original.
Isto não invalida “Nem as suas chaves, nem as suas moedas”, mas lembra-nos que a autonomia da chave privada e os direitos de consenso subjacentes nunca são a mesma coisa.
O mesmo vale para carteiras.
A carteira pode garantir que a chave privada e os direitos de assinatura estejam nas mãos do usuário, identificar anomalias no nível da cadeia o mais rápido possível, exibir com precisão o status da transação, estabelecer RPC e redundância de nós e reconfirmar o resultado final da transação após a restauração da rede.
No entanto, a carteira não pode restaurar o consenso para uma cadeia pública, nem pode garantir que a rede subjacente nunca será interrompida, nem pode garantir que as regras e o estatuto da cadeia nunca mudarão ao nível do consenso.
Portanto, o que um sistema descentralizado maduro realmente precisa buscar talvez nunca seja “nada pode ser mudado”; pelo contrário, estas fronteiras imperfeitas devem ser tão claras quanto possível: quem pode suspender o consenso? Quanto peso é necessário? Em que circunstâncias é permitida a intervenção de emergência?
Devido à verdadeira descentralização, é impossível que o sistema nunca encontre acidentes. A chave é que, mesmo que ocorra um acidente, ainda podemos saber quem, de acordo com que regras e com que nível de consenso, determina como esta conta deve ser registada a seguir.