Três blockchains paradas em quatro dias: quem tem o poder de pausar?

Autor: Liam 'Akiba' Wright, cryptoslate

Compilação: Saoirse, Foresight News

Em quatro dias, três redes blockchain pararam de produzir blocos sucessivamente. Cada paragem da rede recorreu a poderes de emergência completamente diferentes, e apenas a Cronos reescreveu parte do histórico oficial da cadeia.

A Cronos afirmou que, após o protocolo Tectonic ter sofrido um ataque de exploração, os nós validadores encerraram a rede através do mecanismo de consenso, restauraram a cadeia para o estado anterior ao ataque e reiniciaram a produção de blocos a partir da altura de bloco 90.896.189. Esta operação não só parou a produção de blocos, como também reescreveu diretamente o estado da cadeia. As transações e alterações de estado geradas após o ponto de restauro deixaram de pertencer à cadeia principal oficial após o reinício.

A Ontology e a ICON adotaram outro conjunto de medidas de emergência. A Ontology suspendeu a produção de blocos antes de confirmar a atividade maliciosa, e a sua atualização de 1 de setembro indicou que a atividade maliciosa não causou perdas de ativos dos utilizadores. A ICON primeiro suspendeu o contrato atacado e só depois encerrou toda a rede; a fundação afirmou que, durante a fase de migração, a rede estava sob o seu controlo, e nessa altura a maior parte do ICX roubado já tinha sido transferida para contas de custódia de exchanges.

A paragem da blockchain é apenas a primeira camada de controlo. A questão mais profunda é: quem tem autoridade para ordenar o encerramento da rede? Podem reescrever o estado da cadeia já confirmado? Quando os fundos fluem entre cadeias ou entram em instituições de custódia centralizadas, que perdas se tornam irrecuperáveis?

Comparação das abordagens de emergência das três blockchains públicas Cronos, Ontology e ICON

Cronos: da paragem à reescrita do estado da cadeia

A Cronos chamou o tratamento deste incidente de "ação de emergência por consenso dos validadores". O anúncio de reinício de 31 de agosto mostrou que, às 23:49:01 UTC de 30 de agosto, a rede retomou a produção de blocos a partir da altura de bloco 90.896.189, com o estado da cadeia revertido para antes do ataque de exploração do Tectonic.

A operação de paragem da Cronos implica uma escolha de alocação de interesses relativamente ao ponto de restauro. Após o checkpoint, os estados na cadeia relacionados com a exploração, juntamente com todas as transações não relacionadas nesse período, foram apagados da cadeia oficial. O anúncio de reinício não incluiu lista de transações, estatísticas dos nós validadores, limiar de peso de votação nem lista de nós participantes. A Cronos comprometeu-se a publicar um relatório de análise pós-evento, que precisa de explicar completamente o processo de tratamento e o alcance do impacto técnico.

Até a dimensão dos ativos efetivamente protegidos por esta intervenção ainda não está definida. A TRM Labs estima que, após a manipulação do preço do token TONIC, foram emprestados ativos no valor de cerca de 75 milhões de dólares; destes, cerca de 6 milhões de dólares foram para a Ethereum e cerca de 68,7 milhões de dólares foram revertidos dentro da cadeia Cronos. As estatísticas da Bitquery indicam um fluxo total de saída mais elevado, com cerca de 8,3 milhões de dólares em ativos transferidos para a Ethereum e um total de 10.961 blocos descartados.

Os dois métodos estatísticos medem objetos diferentes, e os dados finais de perdas oficiais do Tectonic ainda estão por divulgar. Mas um ponto já é muito claro: a reversão da Cronos só pode restaurar o estado que permaneceu dentro da sua própria cadeia, e os ativos na cadeia Ethereum estão completamente fora do seu controlo.

O plano de tratamento de ativos do Tectonic ainda deixa problemas de conta para os utilizadores. O protocolo afirmou que dará prioridade à abertura das funções de levantamento e reembolso de empréstimos, suspendendo simultaneamente depósitos e novos empréstimos. Este plano oferece aos utilizadores uma via de saída e de redução de alavancagem, mas ainda não foi confirmado se os fornecedores de capital poderão resgatar integralmente. O relatório pós-evento que o Tectonic ainda vai publicar precisa de esclarecer o princípio da vulnerabilidade, o fluxo total de saída de fundos, a dimensão dos créditos incobráveis, os ativos já recuperados e as restantes dívidas pendentes.

O progresso de recuperação das várias infraestruturas não está alinhado com o reinício do consenso da cadeia. A Cronos alertou que os vários protocolos, pontes entre cadeias, exploradores de blocos e serviços RPC precisarão de mais tempo para recuperar. A página de estado da Alchemy também registou separadamente esta paragem e a recuperação subsequente. A rede da cadeia pode declarar o reinício oficial, mas os serviços que dela dependem podem ainda não estar prontos.

Ontology: a paragem serve apenas para ganhar tempo de tratamento, sem reverter transações

A ação de resposta da Ontology ocorreu antes da confirmação da atividade maliciosa. A rede afirmou que a equipa de desenvolvimento principal detetou riscos de segurança potenciais durante a inspeção de rotina e suspendeu imediatamente a produção de blocos, entregando a revisão sistemática à equipa técnica e aos nós validadores.

A atualização de 1 de setembro afirmou que a revisão confirmou a existência de atividade maliciosa, que a mainnet continuará parada e que serão realizadas a correção da vulnerabilidade e a atualização da rede; o ataque não prejudicou os ativos dos utilizadores. O objetivo da Ontology é retomar o funcionamento normal dentro de 24 horas, desde que a deteção de segurança, a correção da vulnerabilidade, a atualização e os testes sejam todos concluídos com sucesso.

A paragem da Ontology preserva todo o estado da cadeia já confirmado, parando apenas a confirmação e o assentamento de novas transações. O anúncio não especificou um ponto de restauro nem publicou o conjunto de transações a anular.

A informação sobre autoridade divulgada publicamente não é completa. O anúncio menciona a participação da equipa de desenvolvimento principal, da equipa técnica e dos nós validadores da rede, mas não indica quem tem o poder de decisão final vinculativo, nem fornece um limiar numérico para o acionamento da emergência. A documentação VBFT da Ontology descreve o mecanismo de consenso regular, incluindo a geração de blocos de confirmação pelos nós e a atualização do conjunto de nós de consenso através de contratos de gestão, mas a documentação cobre apenas cenários de funcionamento normal; as regras de suspensão de emergência utilizadas em 31 de agosto não foram divulgadas publicamente.

Mesmo sem causar perdas de ativos, a paragem acarreta custos efetivos. A Ontology informou os utilizadores de que as transações na cadeia não poderão ser processadas e recomendou que não executem operações sensíveis ao tempo; posteriormente indicou que o reinício da rede depende da correção da vulnerabilidade, da atualização e dos testes. Os utilizadores não podem ajustar posições nem fazer transferências e liquidações na cadeia, e todos os serviços externos ligados a esta cadeia só podem aguardar pelo sinal da rede.

Os critérios para a retomada do funcionamento são orientados para a segurança, mas os detalhes concretos são limitados. A Ontology afirmou que, assim que a correção, a atualização, os testes e a verificação estiverem todos concluídos, tentará retomar o serviço dentro de 24 horas, mas não foi divulgado quem decide que as condições foram cumpridas nem qual é o limiar de acionamento.

Daí resulta uma incerteza ao nível da governança: o anúncio indica as partes envolvidas na revisão, mas a entidade com poder final de decisão sobre o reinício não foi claramente identificada. Para os utilizadores, o risco atual provém da interrupção do serviço, e não de perdas de ativos confirmadas ou de uma reversão da cadeia.

ICON: porque é que a paragem da blockchain já era tarde demais

O incidente da ICON mostra de forma completa todo o processo de alerta, tratamento e saída dos ativos do controle da cadeia.

De acordo com o relatório de análise pós-evento da fundação, o atacante reproduziu 1.492 vezes duas mensagens de levantamento com assinaturas historicamente válidas entre as 02:01:02 e as 02:21:12 UTC de 27 de agosto. Um defeito de precisão fez com que 1.490 dessas chamadas fossem bem-sucedidas, transferindo 119.866.000 ICX e 531.600 bnUSD da pool de ativos da fundação.

Às 02:08, o sistema de monitorização emitiu um alerta, mas a equipe técnica só iniciou a investigação mais tarde; o contrato afetado foi suspenso às 03:53. As principais exchanges começaram a suspender os depósitos e saques de ICX às 05:54, e a paragem de toda a rede entrou oficialmente em vigor às 06:18:54. A ICON concluiu o reinício por volta das 07:51 de 28 de agosto, após um intervalo de cerca de 25 horas, corrigindo simultaneamente a vulnerabilidade de base.

O relatório de análise considera que a causa raiz do problema foi o processo de resposta a incidentes, e não a falta de capacidade de detecção. O alerta foi acionado em 7 minutos, mas este tipo de alerta confunde-se frequentemente com anomalias RPC não relacionadas, e o sistema não notificou o pessoal de plantão. A investigação técnica só começou por volta das 03:40, e o contrato foi suspenso logo depois.

Quando a cadeia foi oficialmente parada, a maior parte do ICX afetado já tinha sido incorporada no sistema de custódia das exchanges. As medidas de controle do lado da cadeia ICON não podem impedir as exchanges de transferir ou converter os ativos que detêm. A fundação só pode contar com o congelamento de ativos pelas exchanges, notificações de conservação, advogados e autoridades policiais para o tratamento.

O limite da custódia determina diretamente a atribuição das perdas. A ICON afirmou que todos os ativos afetados pertencem à fundação e que os depósitos, saldos e posições dos utilizadores comuns não foram alterados. O relatório mostra que 531.600 bnUSD e 1.366.000 SODA foram totalmente recuperados; dos 113.634 USDC emprestados, 82.430 foram recuperados. A perda líquida confirmada é de cerca de 150,2 ETH, mais 31.204 USDC. A grande maioria do ICX envolvido foi apenas congelada ou monitorada nas exchanges, não tendo sido verdadeiramente recuperada.

A arquitetura de controle da ICON também difere dos outros dois casos. O relatório de análise indica que, durante a migração de tokens, a rede estava sob controle da fundação; o documento de orientação da migração menciona que o consenso funcionava em modo de manutenção, com apenas 7 nós principais. Portanto, esta paragem baseou-se numa arquitetura operacional especial claramente gerida pela fundação.

O poder de emergência é, na essência, também um poder ao nível do balanço patrimonial

Cada paragem de uma blockchain é, na essência, uma transferência de risco para lugares diferentes.

• A Cronos modificou o histórico oficial da cadeia: pode proteger os ativos que ainda estão sob o controle da cadeia, mas anula também a atividade normal na cadeia fora da exploração, e nada pode fazer quanto aos ativos na Ethereum.
• A Ontology converteu o risco em custo de tempo e perda de disponibilidade do serviço; durante a investigação, as transações não puderam ser liquidadas, sem perdas contábeis de ativos confirmadas.
• A ICON só concluiu o isolamento do contrato e da rede depois de os ativos já terem saído da esfera de custódia da cadeia; as perdas confirmadas são suportadas pela fundação, e a recuperação do ICX congelado depende das exchanges e das autoridades judiciais.

Um simples índice de descentralização esconderia estes desfechos completamente diferentes. Critérios de avaliação mais pragmáticos são: as regras de tratamento de emergência são públicas? Qual é o limite que aciona o tratamento? Apenas se param novos blocos ou se reescreve o estado da cadeia já confirmado? Quando a intervenção ocorre, quem controla os ativos que saíram da jurisdição da cadeia? Quem se compromete a suportar as perdas remanescentes?

A Cronos e o Tectonic ainda têm de publicar relatórios de revisão completos. A Ontology precisa de divulgar os detalhes do ataque e as regras de autorização de emergência, e de confirmar posteriormente se as condições para a atualização e o reinício foram cumpridas. O que realmente vale a pena comparar é o limite de risco que cada rede define — que históricos, tempos e fundos serão colocados em risco.

Ligação original