Este incidente é uma vitória para o capital, não para os utilizadores, e é um retrocesso para o desenvolvimento da indústria.
Bitcoin à esquerda, Sui à direita, cada movimento na indústria descentralizada traz uma crença mais forte no Bitcoin.
O mundo não precisa apenas de uma melhor infraestrutura financeira global, mas sempre haverá um grupo de pessoas que precisa de um espaço livre.
Era uma vez, as cadeias de consórcio eram mais populares do que as cadeias públicas porque atendiam às necessidades regulatórias da época. Hoje, o declínio das cadeias de consórcio significa, na verdade, que apenas cumprir esse requisito não reflete as verdadeiras necessidades dos usuários. Com a perda de usuários regulados, qual é a necessidade de ferramentas regulatórias?
Em 22 de maio de 2025, a Cetus, a maior exchange descentralizada (DEX) no ecossistema da cadeia pública Sui, sofreu um ataque hacker, resultando em uma queda instantânea de liquidez, no colapso dos preços de múltiplos pares de negociação e em perdas superiores a 220 milhões de dólares.
À data da publicação, a linha do tempo é a seguinte:
Relativamente aos princípios dos eventos, a indústria já publicou várias declarações. Aqui, apenas fornecemos uma visão geral dos princípios fundamentais:
Do ponto de vista do processo de ataque:
O atacante primeiro tomou emprestado aproximadamente 10,024,321.28 haSUI usando um empréstimo relâmpago, causando instantaneamente a queda do preço na piscina de negociação.
99,90%. Esta enorme ordem de venda fez com que o preço do pool alvo caísse de aproximadamente 1,8956×10^19 para 1,8425×10^19, quase esgotando.
Subsequentemente, o atacante criou uma posição de liquidez na Cetus dentro de uma faixa muito estreita (Limite inferior do Tick 300000, limite superior 300200, com uma largura de faixa de apenas 1.00496621%). Uma faixa tão estreita amplifica o impacto de erros de cálculo subsequentes na quantidade de tokens necessária.
O princípio central do ataque:
Há uma vulnerabilidade de estouro de inteiro na função get_delta_a utilizada pela Cetus para calcular o número necessário de tokens. Um atacante declara intencionalmente adicionar uma enorme liquidez (aproximadamente 10^37 unidades), mas na verdade contribui apenas com 1 token para o contrato.
Devido à condição de deteção de overflow incorreta do checked_shlw, o contrato sofreu truncamento de bits altos durante os cálculos de deslocamento à esquerda, fazendo com que o sistema subestimasse seriamente a quantidade necessária de haSUI, obtendo assim uma enorme quantidade de liquidez a um custo extremamente baixo.
Tecnicamente, a vulnerabilidade mencionada decorre do Cetus utilizar máscaras e condições de julgamento incorretas no contrato inteligente Move, permitindo que qualquer valor inferior a 0xffffffffffffffff << 192 contorne a deteção; além disso, os dados de ordem superior são truncados após um deslocamento à esquerda de 64 bits, fazendo com que o sistema acredite que ganhou liquidez significativa com apenas uma pequena quantidade de tokens coletados.
Após o incidente ocorrer, surgiram duas operações oficiais: "Congelar" vs "Recuperar", que são duas fases:
A própria cadeia Sui possui um mecanismo especial de Lista de Negação que permitiu o congelamento dos fundos deste hacker. Além disso, o padrão de token da Sui também possui um modelo de "token regulamentado", que inclui uma função de congelamento embutida.
Este congelamento de emergência utiliza esta característica: os nós validadores rapidamente adicionaram os endereços relacionados aos fundos roubados nos seus arquivos de configuração locais. Em teoria, cada operador de nó pode modificar o TransactionDenyConfig para atualizar a lista negra, mas para garantir a consistência da rede, a Sui Foundation, como o publicador original da configuração, coordenou centralmente.
A fundação primeiro lançou oficialmente uma atualização de configuração contendo o endereço do hacker, e os validadores sincronizaram de acordo com a configuração padrão, "selando" temporariamente os fundos do hacker na cadeia. Na verdade, existem fatores altamente centralizados por trás disso.
Para resgatar vítimas de fundos congelados, a equipe Sui rapidamente lançou um patch de mecanismo de lista branca.
Isto é para a operação de transferência de fundos de volta no futuro. Você pode pré-construir transações legítimas e registrá-las na lista branca. Mesmo que o endereço do fundo ainda esteja na lista negra, ele ainda pode ser executado à força.
Esta nova funcionalidade transaction_allow_list_skip_all_checks permite que transações específicas sejam pré-adicionadas à "lista de isenção", permitindo que essas transações pulem todas as verificações de segurança, incluindo assinaturas, permissões, listas negras, etc.
É importante notar que o patch da lista branca não apreende diretamente os ativos dos hackers; ele apenas concede a certos transações a capacidade de contornar congelamentos, enquanto a transferência real de ativos ainda requer uma assinatura legal ou módulos de permissão do sistema adicionais para ser concluída.
Na verdade, as soluções de congelamento predominantes na indústria ocorrem frequentemente ao nível do contrato do token e são controladas por multi-assinaturas do emissor.
Tomando o USDT emitido pela Tether como exemplo, seu contrato tem uma função de lista negra embutida, permitindo que a empresa emissora congele endereços não conformes, impedindo-os de transferir USDT. Este esquema requer uma assinatura múltipla para iniciar o pedido de congelamento na cadeia, e é executado apenas após a assinatura múltipla alcançar um consenso, portanto há um atraso na execução.
O mecanismo de congelamento da Tether é eficaz, mas as estatísticas mostram que o processo de multi-assinatura frequentemente tem "janelas de oportunidade", deixando espaço para que os criminosos se aproveitem.
Em contraste, o congelamento do Sui ocorre a nível do protocolo subjacente, operado coletivamente por nós validador, com uma velocidade muito mais rápida do que a das chamadas de contrato regulares.
Neste modelo, executar rapidamente significa que a gestão desses nós validadores é altamente unificada.
Ainda mais surpreendentemente, a Sui não apenas congelou os ativos do hacker, mas também planeia implementar uma atualização em cadeia para "devolver" os fundos roubados.
No dia 27 de maio, a Cetus propôs um plano de votação da comunidade para atualizar o protocolo e enviar os fundos congelados para uma carteira de custódia multi-assinatura. A Fundação Sui imediatamente iniciou uma votação de governança on-chain.
No dia 29 de maio, os resultados da votação foram anunciados, com aproximadamente 90,9% dos validadores ponderados a apoiar a proposta. Os oficiais da Sui anunciaram que, uma vez que a proposta seja aprovada, "todos os fundos congelados nas duas contas dos Hackers serão recuperados para uma carteira de múltiplas assinaturas sem necessidade das assinaturas dos Hackers."
Não é necessária a assinatura de um hacker, que característica única, a indústria de blockchain nunca teve um método de reparo assim.
A partir do PR oficial do GitHub da Sui, é claro que o protocolo introduziu um mecanismo de aliasing de endereços. A atualização inclui: a pré-especificação de regras de alias no ProtocolConfig, permitindo que certas transações permitidas considerem assinaturas válidas como enviadas de contas Hacker.
Especificamente, a lista de hashes de transações de resgate a serem executadas está vinculada ao endereço-alvo (ou seja, o endereço do Hacker). Qualquer executor que assine e publique estes resumos de transação fixos é considerado como tendo iniciado a transação como um proprietário válido do endereço do Hacker. Para estas transações específicas, o sistema de nós validadores irá ignorar a verificação da Lista de Negação.
Do ponto de vista do código, o Sui adicionou a seguinte verificação na lógica de validação de transações: quando uma transação é interceptada pela lista negra, o sistema itera sobre os seus signatários para verificar se protocol_config.is_tx_allowed_via_aliasing(sender, signer, tx_digest) é verdadeiro.
Desde que haja um signatário que cumpra a regra do alias, a transação marcada como permitida a passar ignorará os erros de intercepção anteriores e continuará a ser empacotada e executada normalmente.
O incidente Cetus, da minha perspectiva pessoal, pode passar rapidamente, mas este modelo não será esquecido, pois subverte a base da indústria e quebra o consenso tradicional de imutabilidade na blockchain sob o mesmo livro-razão.
No design de blockchain, os contratos são a lei, e o código é o árbitro.
No entanto, neste incidente, o código falhou, a governança interveio e o poder sobrepôs-se, formando um padrão de "comportamento de votação adjudicando resultados de código."
A razão é que a apropriação direta de transações pelo Sui contrasta fortemente com a forma como as blockchains tradicionais lidam com questões de hackers.
Historicamente:
Este é o mesmo padrão de hard fork, retrocedendo o livro-razão para antes do problema, após o qual os usuários ainda podem decidir qual sistema de livro-razão continuar a usar.
Ao contrário do hard fork do DAO, a Sui não escolheu dividir a cadeia, mas sim direcionou precisamente este evento através de atualizações de protocolo e aliases de configuração. Ao fazer isso, a Sui mantém a continuidade da cadeia e mantém a maioria das regras de consenso inalteradas, ao mesmo tempo que indica que o protocolo subjacente pode ser utilizado para implementar "operações de resgate" direcionadas.
O problema é que historicamente, os "rollback baseados em fork" são uma questão de escolha do usuário; as "correções baseadas em protocolo" da Sui são decisões tomadas em nome da cadeia.
A longo prazo, isso significa que a ideia de "Não suas chaves, não suas moedas" está sendo minada na cadeia Sui: mesmo que os usuários tenham as chaves privadas completas, a rede ainda pode impedir a movimentação de ativos e redirecionar ativos através de mudanças de protocolo coletivas.
Se isso se tornar um precedente para a blockchain responder a grandes incidentes de segurança no futuro, ou mesmo ser considerado uma prática que pode ser seguida novamente.
"Quando uma cadeia pode quebrar as regras da justiça, estabelece um precedente para quebrar qualquer regra."
Uma vez que há uma "apreensão de dinheiro para fins de bem público" bem-sucedida, da próxima vez pode ser uma operação na "zona cinzenta moral".
O que acontecerá então?
O hacker realmente roubou o dinheiro do usuário, então a votação em grupo pode tirar o dinheiro dele?
A votação é baseada em quem tem mais dinheiro (pos) ou quem tem mais pessoas? Se o que tem mais dinheiro ganha, então o produtor supremo na escrita de Liu Cixin chegará em breve. Se o que tem mais pessoas ganha, então a multidão caótica também fará ouvir suas vozes.
Nos sistemas tradicionais, é muito normal que os ganhos ilegais não sejam protegidos, e o congelamento e a transferência são operações rotineiras dos bancos tradicionais.
Mas, a partir de uma perspectiva teórica técnica, isso não pode ser alcançado, não é a raiz do desenvolvimento da indústria blockchain?
O bastão da conformidade industrial está em constante fermentação. Hoje pode congelar e modificar saldos de contas para hackers, e amanhã pode fazer modificações arbitrárias devido a fatores geopolíticos e fatores de conflito. Se a cadeia se tornar uma ferramenta regional.
O valor dessa indústria também foi significativamente comprimido, na melhor das hipóteses, é apenas mais um conjunto de um sistema financeiro menos útil.
Esta é também a razão pela qual o autor é firme na indústria: "A blockchain é valiosa não porque não pode ser congelada, mas porque não muda por si, mesmo que você a odeie."
Era uma vez que as cadeias de consórcio eram mais populares do que as cadeias públicas porque atendiam às necessidades regulatórias daquela época. Hoje em dia, o declínio dos consórcios significa que simplesmente aderir a essas necessidades não reflete as verdadeiras necessidades dos usuários. Os usuários perdidos para a regulação levantam a questão de quais ferramentas regulatórias são necessárias.
Do ponto de vista do desenvolvimento da indústria
"Centralização eficiente"—é uma etapa necessária no desenvolvimento da blockchain? Se o objetivo final da descentralização é proteger os interesses dos usuários, podemos tolerar a centralização como um meio transitório?
O termo "democracia" no contexto da governança em cadeia é, na verdade, ponderado por tokens. Portanto, se um hacker detiver uma grande quantidade de SUI (ou um dia uma DAO for hackeada e o hacker controlar os direitos de voto), eles também podem "votar legalmente para se exonerar"?
No final, o valor da blockchain não reside em saber se pode ser congelada, mas na escolha de não o fazer, mesmo quando o grupo tem a capacidade de congelar.
O futuro de uma cadeia é determinado não pela sua arquitetura técnica, mas pelo conjunto de crenças que escolhe defender.
Este incidente é uma vitória para o capital, não para os utilizadores, e é um retrocesso para o desenvolvimento da indústria.
Bitcoin à esquerda, Sui à direita, cada movimento na indústria descentralizada traz uma crença mais forte no Bitcoin.
O mundo não precisa apenas de uma melhor infraestrutura financeira global, mas sempre haverá um grupo de pessoas que precisa de um espaço livre.
Era uma vez, as cadeias de consórcio eram mais populares do que as cadeias públicas porque atendiam às necessidades regulatórias da época. Hoje, o declínio das cadeias de consórcio significa, na verdade, que apenas cumprir esse requisito não reflete as verdadeiras necessidades dos usuários. Com a perda de usuários regulados, qual é a necessidade de ferramentas regulatórias?
Em 22 de maio de 2025, a Cetus, a maior exchange descentralizada (DEX) no ecossistema da cadeia pública Sui, sofreu um ataque hacker, resultando em uma queda instantânea de liquidez, no colapso dos preços de múltiplos pares de negociação e em perdas superiores a 220 milhões de dólares.
À data da publicação, a linha do tempo é a seguinte:
Relativamente aos princípios dos eventos, a indústria já publicou várias declarações. Aqui, apenas fornecemos uma visão geral dos princípios fundamentais:
Do ponto de vista do processo de ataque:
O atacante primeiro tomou emprestado aproximadamente 10,024,321.28 haSUI usando um empréstimo relâmpago, causando instantaneamente a queda do preço na piscina de negociação.
99,90%. Esta enorme ordem de venda fez com que o preço do pool alvo caísse de aproximadamente 1,8956×10^19 para 1,8425×10^19, quase esgotando.
Subsequentemente, o atacante criou uma posição de liquidez na Cetus dentro de uma faixa muito estreita (Limite inferior do Tick 300000, limite superior 300200, com uma largura de faixa de apenas 1.00496621%). Uma faixa tão estreita amplifica o impacto de erros de cálculo subsequentes na quantidade de tokens necessária.
O princípio central do ataque:
Há uma vulnerabilidade de estouro de inteiro na função get_delta_a utilizada pela Cetus para calcular o número necessário de tokens. Um atacante declara intencionalmente adicionar uma enorme liquidez (aproximadamente 10^37 unidades), mas na verdade contribui apenas com 1 token para o contrato.
Devido à condição de deteção de overflow incorreta do checked_shlw, o contrato sofreu truncamento de bits altos durante os cálculos de deslocamento à esquerda, fazendo com que o sistema subestimasse seriamente a quantidade necessária de haSUI, obtendo assim uma enorme quantidade de liquidez a um custo extremamente baixo.
Tecnicamente, a vulnerabilidade mencionada decorre do Cetus utilizar máscaras e condições de julgamento incorretas no contrato inteligente Move, permitindo que qualquer valor inferior a 0xffffffffffffffff << 192 contorne a deteção; além disso, os dados de ordem superior são truncados após um deslocamento à esquerda de 64 bits, fazendo com que o sistema acredite que ganhou liquidez significativa com apenas uma pequena quantidade de tokens coletados.
Após o incidente ocorrer, surgiram duas operações oficiais: "Congelar" vs "Recuperar", que são duas fases:
A própria cadeia Sui possui um mecanismo especial de Lista de Negação que permitiu o congelamento dos fundos deste hacker. Além disso, o padrão de token da Sui também possui um modelo de "token regulamentado", que inclui uma função de congelamento embutida.
Este congelamento de emergência utiliza esta característica: os nós validadores rapidamente adicionaram os endereços relacionados aos fundos roubados nos seus arquivos de configuração locais. Em teoria, cada operador de nó pode modificar o TransactionDenyConfig para atualizar a lista negra, mas para garantir a consistência da rede, a Sui Foundation, como o publicador original da configuração, coordenou centralmente.
A fundação primeiro lançou oficialmente uma atualização de configuração contendo o endereço do hacker, e os validadores sincronizaram de acordo com a configuração padrão, "selando" temporariamente os fundos do hacker na cadeia. Na verdade, existem fatores altamente centralizados por trás disso.
Para resgatar vítimas de fundos congelados, a equipe Sui rapidamente lançou um patch de mecanismo de lista branca.
Isto é para a operação de transferência de fundos de volta no futuro. Você pode pré-construir transações legítimas e registrá-las na lista branca. Mesmo que o endereço do fundo ainda esteja na lista negra, ele ainda pode ser executado à força.
Esta nova funcionalidade transaction_allow_list_skip_all_checks permite que transações específicas sejam pré-adicionadas à "lista de isenção", permitindo que essas transações pulem todas as verificações de segurança, incluindo assinaturas, permissões, listas negras, etc.
É importante notar que o patch da lista branca não apreende diretamente os ativos dos hackers; ele apenas concede a certos transações a capacidade de contornar congelamentos, enquanto a transferência real de ativos ainda requer uma assinatura legal ou módulos de permissão do sistema adicionais para ser concluída.
Na verdade, as soluções de congelamento predominantes na indústria ocorrem frequentemente ao nível do contrato do token e são controladas por multi-assinaturas do emissor.
Tomando o USDT emitido pela Tether como exemplo, seu contrato tem uma função de lista negra embutida, permitindo que a empresa emissora congele endereços não conformes, impedindo-os de transferir USDT. Este esquema requer uma assinatura múltipla para iniciar o pedido de congelamento na cadeia, e é executado apenas após a assinatura múltipla alcançar um consenso, portanto há um atraso na execução.
O mecanismo de congelamento da Tether é eficaz, mas as estatísticas mostram que o processo de multi-assinatura frequentemente tem "janelas de oportunidade", deixando espaço para que os criminosos se aproveitem.
Em contraste, o congelamento do Sui ocorre a nível do protocolo subjacente, operado coletivamente por nós validador, com uma velocidade muito mais rápida do que a das chamadas de contrato regulares.
Neste modelo, executar rapidamente significa que a gestão desses nós validadores é altamente unificada.
Ainda mais surpreendentemente, a Sui não apenas congelou os ativos do hacker, mas também planeia implementar uma atualização em cadeia para "devolver" os fundos roubados.
No dia 27 de maio, a Cetus propôs um plano de votação da comunidade para atualizar o protocolo e enviar os fundos congelados para uma carteira de custódia multi-assinatura. A Fundação Sui imediatamente iniciou uma votação de governança on-chain.
No dia 29 de maio, os resultados da votação foram anunciados, com aproximadamente 90,9% dos validadores ponderados a apoiar a proposta. Os oficiais da Sui anunciaram que, uma vez que a proposta seja aprovada, "todos os fundos congelados nas duas contas dos Hackers serão recuperados para uma carteira de múltiplas assinaturas sem necessidade das assinaturas dos Hackers."
Não é necessária a assinatura de um hacker, que característica única, a indústria de blockchain nunca teve um método de reparo assim.
A partir do PR oficial do GitHub da Sui, é claro que o protocolo introduziu um mecanismo de aliasing de endereços. A atualização inclui: a pré-especificação de regras de alias no ProtocolConfig, permitindo que certas transações permitidas considerem assinaturas válidas como enviadas de contas Hacker.
Especificamente, a lista de hashes de transações de resgate a serem executadas está vinculada ao endereço-alvo (ou seja, o endereço do Hacker). Qualquer executor que assine e publique estes resumos de transação fixos é considerado como tendo iniciado a transação como um proprietário válido do endereço do Hacker. Para estas transações específicas, o sistema de nós validadores irá ignorar a verificação da Lista de Negação.
Do ponto de vista do código, o Sui adicionou a seguinte verificação na lógica de validação de transações: quando uma transação é interceptada pela lista negra, o sistema itera sobre os seus signatários para verificar se protocol_config.is_tx_allowed_via_aliasing(sender, signer, tx_digest) é verdadeiro.
Desde que haja um signatário que cumpra a regra do alias, a transação marcada como permitida a passar ignorará os erros de intercepção anteriores e continuará a ser empacotada e executada normalmente.
O incidente Cetus, da minha perspectiva pessoal, pode passar rapidamente, mas este modelo não será esquecido, pois subverte a base da indústria e quebra o consenso tradicional de imutabilidade na blockchain sob o mesmo livro-razão.
No design de blockchain, os contratos são a lei, e o código é o árbitro.
No entanto, neste incidente, o código falhou, a governança interveio e o poder sobrepôs-se, formando um padrão de "comportamento de votação adjudicando resultados de código."
A razão é que a apropriação direta de transações pelo Sui contrasta fortemente com a forma como as blockchains tradicionais lidam com questões de hackers.
Historicamente:
Este é o mesmo padrão de hard fork, retrocedendo o livro-razão para antes do problema, após o qual os usuários ainda podem decidir qual sistema de livro-razão continuar a usar.
Ao contrário do hard fork do DAO, a Sui não escolheu dividir a cadeia, mas sim direcionou precisamente este evento através de atualizações de protocolo e aliases de configuração. Ao fazer isso, a Sui mantém a continuidade da cadeia e mantém a maioria das regras de consenso inalteradas, ao mesmo tempo que indica que o protocolo subjacente pode ser utilizado para implementar "operações de resgate" direcionadas.
O problema é que historicamente, os "rollback baseados em fork" são uma questão de escolha do usuário; as "correções baseadas em protocolo" da Sui são decisões tomadas em nome da cadeia.
A longo prazo, isso significa que a ideia de "Não suas chaves, não suas moedas" está sendo minada na cadeia Sui: mesmo que os usuários tenham as chaves privadas completas, a rede ainda pode impedir a movimentação de ativos e redirecionar ativos através de mudanças de protocolo coletivas.
Se isso se tornar um precedente para a blockchain responder a grandes incidentes de segurança no futuro, ou mesmo ser considerado uma prática que pode ser seguida novamente.
"Quando uma cadeia pode quebrar as regras da justiça, estabelece um precedente para quebrar qualquer regra."
Uma vez que há uma "apreensão de dinheiro para fins de bem público" bem-sucedida, da próxima vez pode ser uma operação na "zona cinzenta moral".
O que acontecerá então?
O hacker realmente roubou o dinheiro do usuário, então a votação em grupo pode tirar o dinheiro dele?
A votação é baseada em quem tem mais dinheiro (pos) ou quem tem mais pessoas? Se o que tem mais dinheiro ganha, então o produtor supremo na escrita de Liu Cixin chegará em breve. Se o que tem mais pessoas ganha, então a multidão caótica também fará ouvir suas vozes.
Nos sistemas tradicionais, é muito normal que os ganhos ilegais não sejam protegidos, e o congelamento e a transferência são operações rotineiras dos bancos tradicionais.
Mas, a partir de uma perspectiva teórica técnica, isso não pode ser alcançado, não é a raiz do desenvolvimento da indústria blockchain?
O bastão da conformidade industrial está em constante fermentação. Hoje pode congelar e modificar saldos de contas para hackers, e amanhã pode fazer modificações arbitrárias devido a fatores geopolíticos e fatores de conflito. Se a cadeia se tornar uma ferramenta regional.
O valor dessa indústria também foi significativamente comprimido, na melhor das hipóteses, é apenas mais um conjunto de um sistema financeiro menos útil.
Esta é também a razão pela qual o autor é firme na indústria: "A blockchain é valiosa não porque não pode ser congelada, mas porque não muda por si, mesmo que você a odeie."
Era uma vez que as cadeias de consórcio eram mais populares do que as cadeias públicas porque atendiam às necessidades regulatórias daquela época. Hoje em dia, o declínio dos consórcios significa que simplesmente aderir a essas necessidades não reflete as verdadeiras necessidades dos usuários. Os usuários perdidos para a regulação levantam a questão de quais ferramentas regulatórias são necessárias.
Do ponto de vista do desenvolvimento da indústria
"Centralização eficiente"—é uma etapa necessária no desenvolvimento da blockchain? Se o objetivo final da descentralização é proteger os interesses dos usuários, podemos tolerar a centralização como um meio transitório?
O termo "democracia" no contexto da governança em cadeia é, na verdade, ponderado por tokens. Portanto, se um hacker detiver uma grande quantidade de SUI (ou um dia uma DAO for hackeada e o hacker controlar os direitos de voto), eles também podem "votar legalmente para se exonerar"?
No final, o valor da blockchain não reside em saber se pode ser congelada, mas na escolha de não o fazer, mesmo quando o grupo tem a capacidade de congelar.
O futuro de uma cadeia é determinado não pela sua arquitetura técnica, mas pelo conjunto de crenças que escolhe defender.