Fé inabalável após a crise de segurança: por que SUI ainda possui potencial de crescimento a longo prazo?
1. Uma reação em cadeia provocada por um ataque
No dia 22 de maio de 2025, o principal protocolo AMM Cetus, implantado na rede SUI, sofreu um ataque hacker. Os atacantes exploraram uma falha lógica relacionada ao "problema de estouro de inteiros" para realizar um controle preciso, resultando em perdas de mais de 200 milhões de dólares em ativos. Este incidente não só é um dos maiores acidentes de segurança no campo DeFi até agora este ano, como também se tornou o ataque hacker mais destrutivo desde o lançamento da mainnet SUI.
De acordo com os dados da DefiLlama, o TVL total da SUI caiu mais de 330 milhões de dólares no dia do ataque, e o montante bloqueado do protocolo Cetus evaporou instantaneamente 84%, caindo para 38 milhões de dólares. Como resultado, vários tokens populares na SUI desvalorizaram entre 76% e 97% em apenas uma hora, gerando ampla preocupação no mercado sobre a segurança e a estabilidade ecológica da SUI.
Mas, após essa onda de choque, o ecossistema SUI demonstrou uma grande resiliência e capacidade de recuperação. Embora o evento Cetus tenha causado uma volatilidade de confiança a curto prazo, os fundos on-chain e a atividade dos usuários não enfrentaram um declínio contínuo, mas antes impulsionaram uma atenção significativa do ecossistema para a segurança, construção de infraestrutura e qualidade dos projetos.
A Klein Labs irá analisar as causas deste ataque, o mecanismo de consenso dos nós do SUI, a segurança da linguagem MOVE e o desenvolvimento do ecossistema do SUI, organizando o atual padrão ecológico desta blockchain que ainda se encontra em fase inicial de desenvolvimento e discutindo seu potencial de desenvolvimento futuro.
2. Análise das causas do ataque ao evento Cetus
2.1 Processo de implementação do ataque
De acordo com a análise técnica da equipe Slow Mist sobre o evento de ataque ao Cetus, os hackers conseguiram explorar uma vulnerabilidade crítica de estouro aritmético no protocolo, utilizando empréstimos relâmpago, manipulação de preços precisa e falhas de contrato para roubar mais de 200 milhões de dólares em ativos digitais em um curto espaço de tempo. O caminho do ataque pode ser dividido em três fases principais:
①Iniciar um empréstimo relâmpago, manipular preços
Os hackers primeiro usaram a maior slippage para trocar 10 bilhões de haSUI em um empréstimo relâmpago, emprestando uma grande quantidade de fundos para manipulação de preços.
O empréstimo relâmpago permite que os usuários peçam emprestado e devolvam fundos na mesma transação, pagando apenas uma taxa, apresentando características de alta alavancagem, baixo risco e baixo custo. Os hackers utilizaram esse mecanismo para reduzir rapidamente o preço do mercado e controlá-lo com precisão dentro de um intervalo muito estreito.
Em seguida, o atacante se prepara para criar uma posição de liquidez extremamente estreita, definindo o intervalo de preços com precisão entre a cotação mais baixa de 300.000 e a cotação mais alta de 300.200, com uma largura de preço de apenas 1,00496621%.
Através da forma acima, os hackers utilizaram uma quantidade suficiente de tokens e uma enorme liquidez para manipular com sucesso o preço do haSUI. Em seguida, eles também manipularam vários tokens sem valor real.
②Adicionar liquidez
O atacante cria posições de liquidez estreitas, declara que adicionou liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acaba por receber apenas 1 token.
Essencialmente devido a duas razões:
A configuração da máscara é muito ampla: equivale a um limite máximo de adição de liquidez extremamente alto, resultando em uma verificação de entrada do usuário que é virtualmente inexistente no contrato. Hackers definem parâmetros anormais, construindo entradas que estão sempre abaixo desse limite, assim contornando a detecção de estouro.
Dados de transbordamento foram truncados: ao executar a operação de deslocamento n << 64 em um valor n, ocorreu truncamento de dados devido ao deslocamento exceder a largura de bits efetiva do tipo de dados uint256 (256 bits). A parte superior do transbordamento foi automaticamente descartada, resultando em um resultado de cálculo muito abaixo do esperado, levando o sistema a subestimar a quantidade de haSUI necessária para a troca. O resultado final do cálculo foi aproximadamente inferior a 1, mas como é arredondado para cima, o resultado final é igual a 1, ou seja, o hacker só precisa adicionar 1 token para obter uma enorme liquidez.
③ Retirar liquidez
Realizar o pagamento do empréstimo relâmpago, mantendo lucros substanciais. Por fim, retirar ativos de tokens no valor total de centenas de milhões de dólares de vários pools de liquidez.
A situação de perda de fundos é grave, o ataque resultou no roubo dos seguintes ativos:
1290 mil SUI (cerca de 5400 milhões de dólares)
6000 milhões USDC
490 milhões de dólares Haedal Staked SUI
1950万美元TOILET
Outros tokens como HIPPO e LOFI caíram 75--80%, a liquidez esgotou.
2.2 A causa e as características da vulnerabilidade desta vez
A falha do Cetus tem três características:
Custo de reparo extremamente baixo: por um lado, a causa raiz do evento Cetus foi uma falha na biblioteca matemática Cetus, e não um erro no mecanismo de preços do protocolo ou um erro na arquitetura subjacente. Por outro lado, a vulnerabilidade estava restrita apenas ao Cetus, não estando relacionada ao código do SUI. A raiz da vulnerabilidade estava em uma verificação de condição de borda, e apenas duas linhas de código precisam ser alteradas para eliminar completamente o risco; após a correção, pode ser imediatamente implantada na mainnet, garantindo que a lógica dos contratos subsequentes esteja completa e eliminando essa vulnerabilidade.
Alta ocultação: o contrato está em operação há dois anos de forma estável e sem falhas, o Cetus Protocol passou por várias auditorias, mas não foram encontrados vazamentos, sendo a principal razão o fato de a biblioteca Integer_Mate, utilizada para cálculos matemáticos, não ter sido incluída no escopo da auditoria.
Hackers use extreme values to precisely construct trading ranges, creating extremely rare scenarios with very high liquidity that trigger abnormal logic, indicating that such issues are difficult to detect through standard testing. These issues often lie in the blind spots of people's vision, which is why they remain hidden for a long time before being discovered.
Não é um problema exclusivo do Move:
Move é superior a várias linguagens de contratos inteligentes em segurança de recursos e verificação de tipos, incorporando detecção nativa para problemas de estouro de inteiros em cenários comuns. O estouro desta vez ocorreu porque, ao adicionar liquidez, foi usado um valor incorreto para a verificação do limite superior ao calcular a quantidade necessária de tokens, e a operação de deslocamento foi utilizada em vez da multiplicação convencional. Se fossem feitas operações convencionais de adição, subtração, multiplicação e divisão, o Move verificaria automaticamente a situação de estouro, evitando esse problema de truncamento de bits altos.
Vulnerabilidades semelhantes também ocorreram em outras linguagens (como Solidity, Rust), e eram ainda mais suscetíveis a serem exploradas devido à falta de proteção contra estouro de inteiros; antes da atualização da versão do Solidity, a verificação de estouro era bastante fraca. Historicamente, ocorreram estouros de adição, estouros de subtração, estouros de multiplicação, etc., e a causa direta foi que o resultado da operação ultrapassou o limite. Por exemplo, as vulnerabilidades nos contratos inteligentes BEC e SMT da linguagem Solidity foram exploradas através de parâmetros cuidadosamente construídos, contornando as instruções de verificação no contrato e realizando transferências excessivas para implementar ataques.
3. Mecanismo de consenso do SUI
3.1 Introdução ao mecanismo de consenso SUI
Resumo:
SUI adota um quadro de Prova de Participação Delegada (Delegated Proof of Stake, abreviado DPoS)). Embora o mecanismo DPoS possa aumentar a capacidade de transações, ele não consegue oferecer um alto nível de descentralização como o PoW (Prova de Trabalho). Portanto, o nível de descentralização do SUI é relativamente baixo, e a barreira de entrada para a governança é relativamente alta, dificultando que usuários comuns impactem diretamente a governança da rede.
Número médio de validadores: 106
Período médio da Epoch: 24 horas
Mecanismo de processo:
Delegação de direitos: os usuários comuns não precisam executar nós por conta própria, basta que façam o staking de SUI e deleguem a um validador candidato para participar da garantia de segurança da rede e da distribuição de recompensas. Este mecanismo pode reduzir a barreira de entrada para os usuários comuns, permitindo que eles participem do consenso da rede através da "contratação" de validadores de confiança. Esta é também uma grande vantagem do DPoS em relação ao PoS tradicional.
Representa a rodada de blocos: um pequeno número de validadores selecionados cria blocos em uma ordem fixa ou aleatória, aumentando a velocidade de confirmação e melhorando o TPS.
Eleição dinâmica: Após o término de cada ciclo de votação, realiza-se uma rotação dinâmica, reelecionando o conjunto de Validators com base no peso dos votos, garantindo a vitalidade dos nós, a consistência dos interesses e a descentralização.
Vantagens do DPoS:
Alta eficiência: Devido ao número controlável de nós de criação de blocos, a rede consegue completar a confirmação em milissegundos, atendendo à demanda de alto TPS.
Baixo custo: Menos nós participando do consenso resultam em uma redução significativa da largura de banda da rede e dos recursos computacionais necessários para a sincronização de informações e agregação de assinaturas. Assim, os custos de hardware e operação diminuem, a demanda por poder computacional é reduzida, resultando em custos mais baixos. Isso leva a taxas de usuário mais baixas.
Alta segurança: Os mecanismos de staking e delegação aumentam simultaneamente o custo e o risco de ataques; juntamente com o mecanismo de confisco on-chain, inibe efetivamente comportamentos maliciosos.
Ao mesmo tempo, no mecanismo de consenso do SUI, foi adotado um algoritmo baseado em BFT (tolerância a falhas bizantinas), que exige que mais de dois terços dos validadores concordem com os votos para confirmar a transação. Este mecanismo garante que, mesmo que alguns nós ajam de forma maliciosa, a rede possa manter uma operação segura e eficiente. Para qualquer atualização ou decisão significativa, também é necessário que mais de dois terços dos votos concordem para que a implementação ocorra.
Em essência, o DPoS é uma solução de compromisso para o triângulo impossível, equilibrando descentralização e eficiência. O DPoS, no "triângulo impossível" da segurança-descentralização-escala, escolhe reduzir o número de nós ativos de blocos para obter um desempenho mais alto, sacrificando em certa medida a completa descentralização em comparação com o PoS puro ou PoW, mas melhorando significativamente a capacidade de processamento da rede e a velocidade das transações.
3.2 O desempenho do SUI neste ataque
3.2.1 Funcionamento do mecanismo de congelamento
Neste evento, a SUI rapidamente congelou os endereços relacionados ao atacante.
Do ponto de vista do código, isso impede que as transações de transferência sejam empacotadas na blockchain. Os nós de validação são componentes centrais da blockchain SUI, responsáveis por validar transações e executar as regras do protocolo. Ao ignorar coletivamente as transações relacionadas ao atacante, esses validadores estão, em essência, implementando um mecanismo semelhante ao 'congelamento de contas' no nível de consenso, como acontece nas finanças tradicionais.
O SUI tem embutido um mecanismo de lista de rejeição (deny list), que é uma funcionalidade de blacklist que pode bloquear qualquer transação envolvendo endereços listados. Como essa funcionalidade já está presente no cliente, quando um ataque ocorre
SUI pode congelar imediatamente o endereço dos hackers. Se essa funcionalidade não existir, mesmo que SUI tenha apenas 113 validadores, será difícil para a Cetus coordenar todos os validadores para responder um por um em um curto espaço de tempo.
3.2.2 Quem tem o poder de alterar a lista negra?
TransactionDenyConfig é o arquivo de configuração YAML/TOML carregado localmente por cada validador. Qualquer pessoa que execute um nó pode editar este arquivo, recarregar a quente ou reiniciar o nó e atualizar a lista. À primeira vista, parece que cada validador está livre para expressar os seus próprios valores.
Na verdade, para garantir a consistência e a eficácia da política de segurança, a atualização dessa configuração crítica é geralmente coordenada. Como esta é uma "atualização urgente promovida pela equipe SUI", basicamente é a fundação SUI (ou desenvolvedores autorizados por ela) que define e atualiza esta lista de rejeição.
A SUI publicou uma lista negra, teoricamente os validadores podem escolher se a utilizam ou não------mas na prática a maioria das pessoas acaba por adotá-la automaticamente. Assim, embora esta funcionalidade proteja os fundos dos utilizadores, tem de facto um certo grau de centralização.
3.2.3 A essência da funcionalidade de lista negra
A funcionalidade de lista negra na verdade não é uma lógica de nível de protocolo, mas sim uma camada adicional de segurança destinada a lidar com situações inesperadas e garantir a segurança dos fundos dos usuários.
É essencialmente um mecanismo de garantia de segurança. Semelhante a uma "corrente de segurança" presa na porta, que é ativada apenas para aqueles que desejam invadir a casa, ou seja, para aqueles que pretendem fazer mal aos protocolos. Para os usuários:
Para os grandes investidores, que são os principais provedores de liquidez, o protocolo é o que mais deseja garantir a segurança dos fundos, pois na verdade os dados on-chain do tvl são todos contribuídos pelos principais grandes investidores. Para que o protocolo se desenvolva a longo prazo, é imprescindível garantir a segurança em primeiro lugar.
Para os investidores individuais, contribuintes para a atividade do ecossistema, apoiadores sólidos da construção conjunta de tecnologia e comunidade. A equipe do projeto também espera poder atrair investidores individuais para a construção conjunta, assim.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
12 gostos
Recompensa
12
4
Partilhar
Comentar
0/400
GweiWatcher
· 08-01 19:47
Então ainda temos que comprar no ponto mais baixo? Que pena.
Ver originalResponder0
DefiPlaybook
· 08-01 19:44
De acordo com a análise de dados na cadeia, a vulnerabilidade do Cetus expôs os riscos inerentes aos contratos inteligentes, a queda de 83,7% no TVL destaca a fragilidade da Liquidez.
Ver originalResponder0
GigaBrainAnon
· 08-01 19:37
Não há como consertar o céu.
Ver originalResponder0
0xSherlock
· 08-01 19:30
Só sabe especular e ter grandes subidas e grandes quedas.
A resiliência do ecossistema SUI destaca-se, mantendo potencial de crescimento a longo prazo após o incidente de segurança.
Fé inabalável após a crise de segurança: por que SUI ainda possui potencial de crescimento a longo prazo?
1. Uma reação em cadeia provocada por um ataque
No dia 22 de maio de 2025, o principal protocolo AMM Cetus, implantado na rede SUI, sofreu um ataque hacker. Os atacantes exploraram uma falha lógica relacionada ao "problema de estouro de inteiros" para realizar um controle preciso, resultando em perdas de mais de 200 milhões de dólares em ativos. Este incidente não só é um dos maiores acidentes de segurança no campo DeFi até agora este ano, como também se tornou o ataque hacker mais destrutivo desde o lançamento da mainnet SUI.
De acordo com os dados da DefiLlama, o TVL total da SUI caiu mais de 330 milhões de dólares no dia do ataque, e o montante bloqueado do protocolo Cetus evaporou instantaneamente 84%, caindo para 38 milhões de dólares. Como resultado, vários tokens populares na SUI desvalorizaram entre 76% e 97% em apenas uma hora, gerando ampla preocupação no mercado sobre a segurança e a estabilidade ecológica da SUI.
Mas, após essa onda de choque, o ecossistema SUI demonstrou uma grande resiliência e capacidade de recuperação. Embora o evento Cetus tenha causado uma volatilidade de confiança a curto prazo, os fundos on-chain e a atividade dos usuários não enfrentaram um declínio contínuo, mas antes impulsionaram uma atenção significativa do ecossistema para a segurança, construção de infraestrutura e qualidade dos projetos.
A Klein Labs irá analisar as causas deste ataque, o mecanismo de consenso dos nós do SUI, a segurança da linguagem MOVE e o desenvolvimento do ecossistema do SUI, organizando o atual padrão ecológico desta blockchain que ainda se encontra em fase inicial de desenvolvimento e discutindo seu potencial de desenvolvimento futuro.
2. Análise das causas do ataque ao evento Cetus
2.1 Processo de implementação do ataque
De acordo com a análise técnica da equipe Slow Mist sobre o evento de ataque ao Cetus, os hackers conseguiram explorar uma vulnerabilidade crítica de estouro aritmético no protocolo, utilizando empréstimos relâmpago, manipulação de preços precisa e falhas de contrato para roubar mais de 200 milhões de dólares em ativos digitais em um curto espaço de tempo. O caminho do ataque pode ser dividido em três fases principais:
①Iniciar um empréstimo relâmpago, manipular preços
Os hackers primeiro usaram a maior slippage para trocar 10 bilhões de haSUI em um empréstimo relâmpago, emprestando uma grande quantidade de fundos para manipulação de preços.
O empréstimo relâmpago permite que os usuários peçam emprestado e devolvam fundos na mesma transação, pagando apenas uma taxa, apresentando características de alta alavancagem, baixo risco e baixo custo. Os hackers utilizaram esse mecanismo para reduzir rapidamente o preço do mercado e controlá-lo com precisão dentro de um intervalo muito estreito.
Em seguida, o atacante se prepara para criar uma posição de liquidez extremamente estreita, definindo o intervalo de preços com precisão entre a cotação mais baixa de 300.000 e a cotação mais alta de 300.200, com uma largura de preço de apenas 1,00496621%.
Através da forma acima, os hackers utilizaram uma quantidade suficiente de tokens e uma enorme liquidez para manipular com sucesso o preço do haSUI. Em seguida, eles também manipularam vários tokens sem valor real.
②Adicionar liquidez
O atacante cria posições de liquidez estreitas, declara que adicionou liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acaba por receber apenas 1 token.
Essencialmente devido a duas razões:
A configuração da máscara é muito ampla: equivale a um limite máximo de adição de liquidez extremamente alto, resultando em uma verificação de entrada do usuário que é virtualmente inexistente no contrato. Hackers definem parâmetros anormais, construindo entradas que estão sempre abaixo desse limite, assim contornando a detecção de estouro.
Dados de transbordamento foram truncados: ao executar a operação de deslocamento n << 64 em um valor n, ocorreu truncamento de dados devido ao deslocamento exceder a largura de bits efetiva do tipo de dados uint256 (256 bits). A parte superior do transbordamento foi automaticamente descartada, resultando em um resultado de cálculo muito abaixo do esperado, levando o sistema a subestimar a quantidade de haSUI necessária para a troca. O resultado final do cálculo foi aproximadamente inferior a 1, mas como é arredondado para cima, o resultado final é igual a 1, ou seja, o hacker só precisa adicionar 1 token para obter uma enorme liquidez.
③ Retirar liquidez
Realizar o pagamento do empréstimo relâmpago, mantendo lucros substanciais. Por fim, retirar ativos de tokens no valor total de centenas de milhões de dólares de vários pools de liquidez.
A situação de perda de fundos é grave, o ataque resultou no roubo dos seguintes ativos:
1290 mil SUI (cerca de 5400 milhões de dólares)
6000 milhões USDC
490 milhões de dólares Haedal Staked SUI
1950万美元TOILET
Outros tokens como HIPPO e LOFI caíram 75--80%, a liquidez esgotou.
2.2 A causa e as características da vulnerabilidade desta vez
A falha do Cetus tem três características:
Custo de reparo extremamente baixo: por um lado, a causa raiz do evento Cetus foi uma falha na biblioteca matemática Cetus, e não um erro no mecanismo de preços do protocolo ou um erro na arquitetura subjacente. Por outro lado, a vulnerabilidade estava restrita apenas ao Cetus, não estando relacionada ao código do SUI. A raiz da vulnerabilidade estava em uma verificação de condição de borda, e apenas duas linhas de código precisam ser alteradas para eliminar completamente o risco; após a correção, pode ser imediatamente implantada na mainnet, garantindo que a lógica dos contratos subsequentes esteja completa e eliminando essa vulnerabilidade.
Alta ocultação: o contrato está em operação há dois anos de forma estável e sem falhas, o Cetus Protocol passou por várias auditorias, mas não foram encontrados vazamentos, sendo a principal razão o fato de a biblioteca Integer_Mate, utilizada para cálculos matemáticos, não ter sido incluída no escopo da auditoria.
Hackers use extreme values to precisely construct trading ranges, creating extremely rare scenarios with very high liquidity that trigger abnormal logic, indicating that such issues are difficult to detect through standard testing. These issues often lie in the blind spots of people's vision, which is why they remain hidden for a long time before being discovered.
Move é superior a várias linguagens de contratos inteligentes em segurança de recursos e verificação de tipos, incorporando detecção nativa para problemas de estouro de inteiros em cenários comuns. O estouro desta vez ocorreu porque, ao adicionar liquidez, foi usado um valor incorreto para a verificação do limite superior ao calcular a quantidade necessária de tokens, e a operação de deslocamento foi utilizada em vez da multiplicação convencional. Se fossem feitas operações convencionais de adição, subtração, multiplicação e divisão, o Move verificaria automaticamente a situação de estouro, evitando esse problema de truncamento de bits altos.
Vulnerabilidades semelhantes também ocorreram em outras linguagens (como Solidity, Rust), e eram ainda mais suscetíveis a serem exploradas devido à falta de proteção contra estouro de inteiros; antes da atualização da versão do Solidity, a verificação de estouro era bastante fraca. Historicamente, ocorreram estouros de adição, estouros de subtração, estouros de multiplicação, etc., e a causa direta foi que o resultado da operação ultrapassou o limite. Por exemplo, as vulnerabilidades nos contratos inteligentes BEC e SMT da linguagem Solidity foram exploradas através de parâmetros cuidadosamente construídos, contornando as instruções de verificação no contrato e realizando transferências excessivas para implementar ataques.
3. Mecanismo de consenso do SUI
3.1 Introdução ao mecanismo de consenso SUI
Resumo:
SUI adota um quadro de Prova de Participação Delegada (Delegated Proof of Stake, abreviado DPoS)). Embora o mecanismo DPoS possa aumentar a capacidade de transações, ele não consegue oferecer um alto nível de descentralização como o PoW (Prova de Trabalho). Portanto, o nível de descentralização do SUI é relativamente baixo, e a barreira de entrada para a governança é relativamente alta, dificultando que usuários comuns impactem diretamente a governança da rede.
Número médio de validadores: 106
Período médio da Epoch: 24 horas
Mecanismo de processo:
Delegação de direitos: os usuários comuns não precisam executar nós por conta própria, basta que façam o staking de SUI e deleguem a um validador candidato para participar da garantia de segurança da rede e da distribuição de recompensas. Este mecanismo pode reduzir a barreira de entrada para os usuários comuns, permitindo que eles participem do consenso da rede através da "contratação" de validadores de confiança. Esta é também uma grande vantagem do DPoS em relação ao PoS tradicional.
Representa a rodada de blocos: um pequeno número de validadores selecionados cria blocos em uma ordem fixa ou aleatória, aumentando a velocidade de confirmação e melhorando o TPS.
Eleição dinâmica: Após o término de cada ciclo de votação, realiza-se uma rotação dinâmica, reelecionando o conjunto de Validators com base no peso dos votos, garantindo a vitalidade dos nós, a consistência dos interesses e a descentralização.
Vantagens do DPoS:
Alta eficiência: Devido ao número controlável de nós de criação de blocos, a rede consegue completar a confirmação em milissegundos, atendendo à demanda de alto TPS.
Baixo custo: Menos nós participando do consenso resultam em uma redução significativa da largura de banda da rede e dos recursos computacionais necessários para a sincronização de informações e agregação de assinaturas. Assim, os custos de hardware e operação diminuem, a demanda por poder computacional é reduzida, resultando em custos mais baixos. Isso leva a taxas de usuário mais baixas.
Alta segurança: Os mecanismos de staking e delegação aumentam simultaneamente o custo e o risco de ataques; juntamente com o mecanismo de confisco on-chain, inibe efetivamente comportamentos maliciosos.
Ao mesmo tempo, no mecanismo de consenso do SUI, foi adotado um algoritmo baseado em BFT (tolerância a falhas bizantinas), que exige que mais de dois terços dos validadores concordem com os votos para confirmar a transação. Este mecanismo garante que, mesmo que alguns nós ajam de forma maliciosa, a rede possa manter uma operação segura e eficiente. Para qualquer atualização ou decisão significativa, também é necessário que mais de dois terços dos votos concordem para que a implementação ocorra.
Em essência, o DPoS é uma solução de compromisso para o triângulo impossível, equilibrando descentralização e eficiência. O DPoS, no "triângulo impossível" da segurança-descentralização-escala, escolhe reduzir o número de nós ativos de blocos para obter um desempenho mais alto, sacrificando em certa medida a completa descentralização em comparação com o PoS puro ou PoW, mas melhorando significativamente a capacidade de processamento da rede e a velocidade das transações.
3.2 O desempenho do SUI neste ataque
3.2.1 Funcionamento do mecanismo de congelamento
Neste evento, a SUI rapidamente congelou os endereços relacionados ao atacante.
Do ponto de vista do código, isso impede que as transações de transferência sejam empacotadas na blockchain. Os nós de validação são componentes centrais da blockchain SUI, responsáveis por validar transações e executar as regras do protocolo. Ao ignorar coletivamente as transações relacionadas ao atacante, esses validadores estão, em essência, implementando um mecanismo semelhante ao 'congelamento de contas' no nível de consenso, como acontece nas finanças tradicionais.
O SUI tem embutido um mecanismo de lista de rejeição (deny list), que é uma funcionalidade de blacklist que pode bloquear qualquer transação envolvendo endereços listados. Como essa funcionalidade já está presente no cliente, quando um ataque ocorre
SUI pode congelar imediatamente o endereço dos hackers. Se essa funcionalidade não existir, mesmo que SUI tenha apenas 113 validadores, será difícil para a Cetus coordenar todos os validadores para responder um por um em um curto espaço de tempo.
3.2.2 Quem tem o poder de alterar a lista negra?
TransactionDenyConfig é o arquivo de configuração YAML/TOML carregado localmente por cada validador. Qualquer pessoa que execute um nó pode editar este arquivo, recarregar a quente ou reiniciar o nó e atualizar a lista. À primeira vista, parece que cada validador está livre para expressar os seus próprios valores.
Na verdade, para garantir a consistência e a eficácia da política de segurança, a atualização dessa configuração crítica é geralmente coordenada. Como esta é uma "atualização urgente promovida pela equipe SUI", basicamente é a fundação SUI (ou desenvolvedores autorizados por ela) que define e atualiza esta lista de rejeição.
A SUI publicou uma lista negra, teoricamente os validadores podem escolher se a utilizam ou não------mas na prática a maioria das pessoas acaba por adotá-la automaticamente. Assim, embora esta funcionalidade proteja os fundos dos utilizadores, tem de facto um certo grau de centralização.
3.2.3 A essência da funcionalidade de lista negra
A funcionalidade de lista negra na verdade não é uma lógica de nível de protocolo, mas sim uma camada adicional de segurança destinada a lidar com situações inesperadas e garantir a segurança dos fundos dos usuários.
É essencialmente um mecanismo de garantia de segurança. Semelhante a uma "corrente de segurança" presa na porta, que é ativada apenas para aqueles que desejam invadir a casa, ou seja, para aqueles que pretendem fazer mal aos protocolos. Para os usuários:
Para os grandes investidores, que são os principais provedores de liquidez, o protocolo é o que mais deseja garantir a segurança dos fundos, pois na verdade os dados on-chain do tvl são todos contribuídos pelos principais grandes investidores. Para que o protocolo se desenvolva a longo prazo, é imprescindível garantir a segurança em primeiro lugar.
Para os investidores individuais, contribuintes para a atividade do ecossistema, apoiadores sólidos da construção conjunta de tecnologia e comunidade. A equipe do projeto também espera poder atrair investidores individuais para a construção conjunta, assim.