Este incidente é uma vitória para o capital, não para os usuários, e é um retrocesso para o desenvolvimento da indústria.
Bitcoin à esquerda, Sui à direita, cada tremor 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 chains de consórcio eram mais populares do que as chains públicas porque atendiam às necessidades regulatórias daquela época. Hoje, o declínio das chains de consórcio na verdade significa que apenas cumprir esse requisito não reflete as verdadeiras necessidades dos usuários. Com a perda de usuários regulamentados, 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, o colapso dos preços de múltiplos pares de negociação e perdas superiores a $220 milhões.
No momento da publicação, a linha do tempo é a seguinte:
Em relação aos princípios dos eventos, a indústria já publicou várias declarações. Aqui, fornecemos apenas uma visão geral dos princípios centrais:
Do ponto de vista do processo de ataque:
O atacante primeiro pegou emprestado aproximadamente 10.024.321,28 haSUI usando um empréstimo relâmpago, causando instantaneamente a queda do preço na pool 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%). Essa faixa estreita amplifica o impacto de erros de cálculo subsequentes na quantidade de token necessária.
O princípio básico do ataque:
Há uma vulnerabilidade de estouro de inteiro na função get_delta_a usada pela Cetus para calcular o número necessário de tokens. Um atacante afirma intencionalmente adicionar uma enorme liquidez (aproximadamente 10^37 unidades), mas na verdade contribui apenas com 1 token para o contrato.
Devido à condição incorreta de detecção de overflow do checked_shlw, o contrato experimentou 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 quantidade massiva de liquidez a um custo extremamente baixo.
Tecnicamente, a vulnerabilidade mencionada decorre do Cetus usar máscaras e condições de julgamento incorretas no contrato inteligente Move, permitindo que qualquer valor menor que 0xffffffffffffffff << 192 evite a detecção; além disso, os dados de ordem superior são truncados após um deslocamento à esquerda de 64 bits, fazendo o sistema acreditar que ganhou liquidez significativa com apenas uma pequena quantidade de tokens coletados.
Após o incidente ocorrido, duas operações oficiais surgiram: "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 regulado", 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 em 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 blockchain. 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.
Isso é 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 os congelamentos, enquanto a transferência real de ativos ainda requer uma assinatura legal ou módulos adicionais de permissão do sistema para ser concluída.
Na verdade, as soluções de congelamento mais comuns na indústria geralmente ocorrem no nível do contrato do token e são controladas por múltiplas assinaturas do emissor.
Tomando o USDT emitido pela Tether como exemplo, seu contrato possui 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 ele só é executado após a assinatura múltipla alcançar um consenso, assim, há um atraso na execução.
O mecanismo de congelamento da Tether é eficaz, mas estatísticas mostram que o processo de multi-assinatura frequentemente tem "janelas de oportunidade", deixando espaço para que criminosos se aproveitem.
Em contraste, o congelamento do Sui ocorre no nível do protocolo subjacente, operado coletivamente pelos nós validadores, 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 planeja implementar uma atualização on-chain para "transferir de volta" os fundos roubados.
Em 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 apoiando a proposta. Funcionários 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 multi-assinatura sem a necessidade de assinaturas dos Hackers."
Não é necessária assinatura de hacker, que recurso único, a indústria de blockchain nunca teve um método de reparo como esse.
A partir do PR oficial do GitHub da Sui, está claro que o protocolo introduziu um mecanismo de aliasing de endereço. A atualização inclui: pré-especificação de regras de alias na 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 assinar e publicar esses resumos de transação fixos é considerado como tendo iniciado a transação como um proprietário válido do endereço do Hacker. Para essas transações específicas, o sistema de nós validadores ignorará a verificação da Lista de Negação.
Do ponto de vista do código, 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 seus signatários para verificar se protocol_config.is_tx_allowed_via_aliasing(sender, signer, tx_digest) é verdadeiro.
Enquanto houver um signatário que atenda à regra de alias, a transação marcada como permitida ignorará os erros de interceptaçã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 no blockchain sob o mesmo livro-razão.
No design de blockchain, contratos são a lei, e código é o árbitro.
No entanto, neste incidente, o código falhou, a governança interveio e o poder sobrepôs, formando um padrão de "comportamento de votação adjudicando resultados do código."
A razão é que a apropriação direta de transações pelo Sui contrasta fortemente com a forma como as blockchains mainstream lidam com questões de hackers.
Historicamente:
Este é o mesmo padrão de hard fork, revertendo 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 usando.
Ao contrário do hard fork do DAO, a Sui não escolheu dividir a cadeia, mas sim direcionou precisamente esse evento por meio 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 em que indica que o protocolo subjacente pode ser usado para implementar "operações de resgate" direcionadas.
O problema é que historicamente, "rollback baseado em fork" é 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 o movimento de ativos e redirecionar ativos por meio de mudanças coletivas no protocolo.
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 haja uma "captura de dinheiro de bem público" bem-sucedida, da próxima vez pode ser uma operação na "área cinza 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 vencer, então o produtor supremo na escrita de Liu Cixin logo chegará. Se o que tem mais pessoas vencer, então a multidão caótica também fará suas vozes serem ouvidas.
Em sistemas tradicionais, é muito normal que ganhos ilegais não sejam protegidos, e congelar e transferir são operações rotineiras dos bancos tradicionais.
Mas, do ponto de vista teórico técnico, isso não pode ser alcançado, não é a raiz do desenvolvimento da indústria de blockchain?
O bastão da conformidade industrial está fermentando continuamente. Hoje ele pode congelar e modificar saldos de contas para hackers, e amanhã pode fazer modificações arbitrárias por 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: "Blockchain é valioso não porque não pode ser congelado, mas porque não muda para você mesmo que você o odeie."
Era uma vez, 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 na verdade 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 do 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 on-chain é, na verdade, ponderado por tokens. Portanto, se um hacker possui uma grande quantidade de SUI (ou se um dia um DAO é hackeado e o hacker controla os direitos de voto), eles também podem "votar legalmente para se exonerar"?
Em última análise, o valor do blockchain não está em saber se ele pode ser congelado, mas na escolha de não fazê-lo, 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 usuários, e é um retrocesso para o desenvolvimento da indústria.
Bitcoin à esquerda, Sui à direita, cada tremor 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 chains de consórcio eram mais populares do que as chains públicas porque atendiam às necessidades regulatórias daquela época. Hoje, o declínio das chains de consórcio na verdade significa que apenas cumprir esse requisito não reflete as verdadeiras necessidades dos usuários. Com a perda de usuários regulamentados, 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, o colapso dos preços de múltiplos pares de negociação e perdas superiores a $220 milhões.
No momento da publicação, a linha do tempo é a seguinte:
Em relação aos princípios dos eventos, a indústria já publicou várias declarações. Aqui, fornecemos apenas uma visão geral dos princípios centrais:
Do ponto de vista do processo de ataque:
O atacante primeiro pegou emprestado aproximadamente 10.024.321,28 haSUI usando um empréstimo relâmpago, causando instantaneamente a queda do preço na pool 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%). Essa faixa estreita amplifica o impacto de erros de cálculo subsequentes na quantidade de token necessária.
O princípio básico do ataque:
Há uma vulnerabilidade de estouro de inteiro na função get_delta_a usada pela Cetus para calcular o número necessário de tokens. Um atacante afirma intencionalmente adicionar uma enorme liquidez (aproximadamente 10^37 unidades), mas na verdade contribui apenas com 1 token para o contrato.
Devido à condição incorreta de detecção de overflow do checked_shlw, o contrato experimentou 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 quantidade massiva de liquidez a um custo extremamente baixo.
Tecnicamente, a vulnerabilidade mencionada decorre do Cetus usar máscaras e condições de julgamento incorretas no contrato inteligente Move, permitindo que qualquer valor menor que 0xffffffffffffffff << 192 evite a detecção; além disso, os dados de ordem superior são truncados após um deslocamento à esquerda de 64 bits, fazendo o sistema acreditar que ganhou liquidez significativa com apenas uma pequena quantidade de tokens coletados.
Após o incidente ocorrido, duas operações oficiais surgiram: "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 regulado", 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 em 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 blockchain. 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.
Isso é 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 os congelamentos, enquanto a transferência real de ativos ainda requer uma assinatura legal ou módulos adicionais de permissão do sistema para ser concluída.
Na verdade, as soluções de congelamento mais comuns na indústria geralmente ocorrem no nível do contrato do token e são controladas por múltiplas assinaturas do emissor.
Tomando o USDT emitido pela Tether como exemplo, seu contrato possui 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 ele só é executado após a assinatura múltipla alcançar um consenso, assim, há um atraso na execução.
O mecanismo de congelamento da Tether é eficaz, mas estatísticas mostram que o processo de multi-assinatura frequentemente tem "janelas de oportunidade", deixando espaço para que criminosos se aproveitem.
Em contraste, o congelamento do Sui ocorre no nível do protocolo subjacente, operado coletivamente pelos nós validadores, 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 planeja implementar uma atualização on-chain para "transferir de volta" os fundos roubados.
Em 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 apoiando a proposta. Funcionários 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 multi-assinatura sem a necessidade de assinaturas dos Hackers."
Não é necessária assinatura de hacker, que recurso único, a indústria de blockchain nunca teve um método de reparo como esse.
A partir do PR oficial do GitHub da Sui, está claro que o protocolo introduziu um mecanismo de aliasing de endereço. A atualização inclui: pré-especificação de regras de alias na 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 assinar e publicar esses resumos de transação fixos é considerado como tendo iniciado a transação como um proprietário válido do endereço do Hacker. Para essas transações específicas, o sistema de nós validadores ignorará a verificação da Lista de Negação.
Do ponto de vista do código, 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 seus signatários para verificar se protocol_config.is_tx_allowed_via_aliasing(sender, signer, tx_digest) é verdadeiro.
Enquanto houver um signatário que atenda à regra de alias, a transação marcada como permitida ignorará os erros de interceptaçã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 no blockchain sob o mesmo livro-razão.
No design de blockchain, contratos são a lei, e código é o árbitro.
No entanto, neste incidente, o código falhou, a governança interveio e o poder sobrepôs, formando um padrão de "comportamento de votação adjudicando resultados do código."
A razão é que a apropriação direta de transações pelo Sui contrasta fortemente com a forma como as blockchains mainstream lidam com questões de hackers.
Historicamente:
Este é o mesmo padrão de hard fork, revertendo 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 usando.
Ao contrário do hard fork do DAO, a Sui não escolheu dividir a cadeia, mas sim direcionou precisamente esse evento por meio 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 em que indica que o protocolo subjacente pode ser usado para implementar "operações de resgate" direcionadas.
O problema é que historicamente, "rollback baseado em fork" é 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 o movimento de ativos e redirecionar ativos por meio de mudanças coletivas no protocolo.
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 haja uma "captura de dinheiro de bem público" bem-sucedida, da próxima vez pode ser uma operação na "área cinza 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 vencer, então o produtor supremo na escrita de Liu Cixin logo chegará. Se o que tem mais pessoas vencer, então a multidão caótica também fará suas vozes serem ouvidas.
Em sistemas tradicionais, é muito normal que ganhos ilegais não sejam protegidos, e congelar e transferir são operações rotineiras dos bancos tradicionais.
Mas, do ponto de vista teórico técnico, isso não pode ser alcançado, não é a raiz do desenvolvimento da indústria de blockchain?
O bastão da conformidade industrial está fermentando continuamente. Hoje ele pode congelar e modificar saldos de contas para hackers, e amanhã pode fazer modificações arbitrárias por 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: "Blockchain é valioso não porque não pode ser congelado, mas porque não muda para você mesmo que você o odeie."
Era uma vez, 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 na verdade 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 do 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 on-chain é, na verdade, ponderado por tokens. Portanto, se um hacker possui uma grande quantidade de SUI (ou se um dia um DAO é hackeado e o hacker controla os direitos de voto), eles também podem "votar legalmente para se exonerar"?
Em última análise, o valor do blockchain não está em saber se ele pode ser congelado, mas na escolha de não fazê-lo, 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.