Crença firme após a crise de segurança: por que o 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 de hackers. Os atacantes exploraram uma falha lógica relacionada a um "problema de estouro de inteiro" para realizar uma manipulação precisa, resultando em perdas de mais de 200 milhões de dólares em ativos. Este incidente não é apenas um dos maiores acidentes de segurança no espaço DeFi até agora este ano, mas também se tornou o ataque hacker mais destrutivo desde o lançamento da mainnet da SUI.
De acordo com os dados, o TVL total da SUI caiu mais de 330 milhões de dólares no dia do ataque, e o valor total bloqueado do protocolo Cetus evaporou instantaneamente 84%, caindo para 38 milhões de dólares. Como resultado, vários tokens populares na SUI despencaram 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 esta onda de choque, o ecossistema SUI demonstrou uma grande resiliência e capacidade de recuperação. Apesar do evento Cetus ter trazido flutuações de confiança a curto prazo, os fundos na cadeia e a atividade dos usuários não enfrentaram um declínio contínuo, mas sim impulsionaram uma atenção significativamente maior em relação à segurança, à construção de infraestrutura e à qualidade dos projetos em todo o ecossistema.
Este artigo irá abordar as causas deste ataque, o mecanismo de consenso de nós do SUI, a segurança da linguagem MOVE e o desenvolvimento ecológico do SUI, delineando o atual padrão ecológico desta blockchain que ainda está em estágio inicial de desenvolvimento e explorando seu potencial de desenvolvimento futuro.
2. Análise das causas do ataque Cetus
2.1 Processo de implementação do ataque
De acordo com a análise técnica da equipe de segurança sobre o incidente 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 precisa de preços e falhas em contratos 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 aproximadamente nas seguintes três fases:
①Iniciar um empréstimo relâmpago, manipular preços
Os hackers primeiro utilizaram um empréstimo relâmpago de 10 bilhões haSUI com o maior deslizamento, emprestando uma grande quantidade de fundos para manipulação de preços.
O empréstimo relâmpago permite que os usuários emprestem e devolvam fundos na mesma transação, pagando apenas uma taxa, com características de alta alavancagem, baixo risco e baixo custo. Os hackers aproveitaram esse mecanismo para baixar rapidamente os preços do mercado, controlando-os com precisão dentro de um intervalo muito estreito.
Em seguida, o atacante prepara-se para criar uma posição de liquidez extremamente estreita, definindo a faixa de preços com precisão entre a menor oferta de 300.000 e o maior preço 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 adicionar 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 é demasiado ampla: equivale a um limite de adição de liquidez extremamente grande, resultando em uma verificação de entrada do usuário no contrato que é praticamente irrelevante. Os hackers contornam a detecção de overflow configurando parâmetros anômalos, fazendo com que a entrada esteja sempre abaixo desse limite.
A sobrecarga de dados foi truncada: ao executar a operação de deslocamento n << 64 sobre o valor n, ocorreu truncamento de dados devido ao deslocamento exceder a largura de bits efetiva do tipo de dado uint256 (256 bits). A parte de overflow de bits altos foi automaticamente descartada, resultando em um resultado de cálculo muito inferior ao esperado, levando o sistema a subestimar a quantidade de haSUI necessária para a troca. O resultado final do cálculo foi cerca de 1, mas como foi arredondado para cima, acabou sendo igual a 1, ou seja, o hacker só precisava adicionar 1 token para trocar por uma enorme liquidez.
③ Retirar liquidez
Fazer o reembolso de um empréstimo relâmpago, mantendo lucros significativos. No final, retirar ativos de tokens com um valor total de centenas de milhões de dólares de múltiplos pools de liquidez.
A situação de perda de fundos é grave, o ataque resultou no roubo dos seguintes ativos:
1290 milhões de SUI (cerca de 5400 milhões de dólares)
6000万美元USDC
490万美元 Haedal Staked SUI
1950万美元TOILET
Outros tokens como HIPPO e LOFI caíram 75--80%, com liquidez esgotada
2.2 Causas e características da vulnerabilidade desta vez
A vulnerabilidade do Cetus tem três características:
O custo de reparação é 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 na arquitetura subjacente. Por outro lado, a falha está limitada apenas ao Cetus e não tem relação com o código do SUI. A raiz da falha está em uma verificação de condição de limite, sendo necessário modificar apenas duas linhas de código para eliminar completamente o risco; após a conclusão da reparação, pode ser imediatamente implementada na rede principal, garantindo que a lógica dos contratos subsequentes seja completa e prevenindo essa falha.
Alta ocultação: o contrato está em funcionamento há dois anos sem falhas, tendo sido auditado várias vezes, mas as vulnerabilidades não foram descobertas, principalmente porque a biblioteca Integer_Mate utilizada para cálculos matemáticos não foi incluída no escopo da auditoria.
Os hackers utilizam valores extremos para construir com precisão intervalos de negociação, criando cenários raríssimos de submissão de liquidez extremamente alta, o que aciona uma lógica anormal, indicando que esse tipo de problema é difícil de ser descoberto através de testes comuns. Esses problemas costumam estar em áreas cegas da percepção das pessoas, por isso permanecem ocultos por muito tempo até serem descobertos,
Não é um problema exclusivo do Move:
Move é superior a várias linguagens de contrato inteligente em termos de segurança de recursos e verificação de tipos, incorporando a detecção nativa de problemas de estouro de inteiros em cenários comuns. O estouro ocorreu porque, ao adicionar liquidez, o número necessário de tokens foi inicialmente verificado com um valor incorreto como limite, e a operação de deslocamento foi usada em vez da operação de multiplicação convencional. Se fossem usadas operações convencionais de adição, subtração, multiplicação ou divisão, o Move automaticamente verificaria a situação de estouro, evitando esse tipo de truncamento de bits altos.
Vulnerabilidades semelhantes também ocorreram em outras linguagens (como Solidity e Rust), e eram até mais fáceis de explorar devido à falta de proteção contra overflow de inteiros; antes da atualização da versão do Solidity, a verificação de overflow era muito fraca. Historicamente, ocorreram overflows de adição, subtração e multiplicação, cuja 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 elaborados, contornando as instruções de verificação no contrato, permitindo transferências excessivas para realizar ataques.
3. Mecanismo de consenso SUI
3.1 Introdução ao mecanismo de consenso SUI
Resumo:
SUI adota a estrutura de Prova de Participação Delegada (DeleGated Proof of Stake, abreviada como DPoS). Embora o mecanismo DPoS possa aumentar a taxa de transações, ele não consegue fornecer um nível de descentralização tão alto quanto o PoW (Prova de Trabalho). Assim, 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 influenciem diretamente a governança da rede.
Número médio de validadores: 106
Período médio de Epoch: 24 horas
Processo de mecanismo:
Delegação de direitos: usuários comuns não precisam operar nós por conta própria, basta que deleguem e empenhem SUI a validadores candidatos para participar da garantia de segurança da rede e da distribuição de recompensas. Este mecanismo pode reduzir a barreira de entrada para 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 o ciclo de bloco: um pequeno número de validadores selecionados produzem 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 contagem de votos, realiza-se uma rotação dinâmica, reeleccionando o conjunto de Validators com base no peso dos votos, garantindo a vitalidade dos nós, a consistência de interesses e a descentralização.
Vantagens do DPoS:
Alta eficiência: devido ao número controlável de nós de bloco, a rede pode concluir a confirmação em milissegundos, atendendo à alta demanda de TPS.
Baixo custo: Menos nós participando do consenso resultam em uma redução significativa da largura de banda de rede e dos recursos computacionais necessários para sincronização de informações e agregação de assinaturas. Assim, os custos de hardware e de operação diminuem, as exigências de poder computacional diminuem e os custos são mais baixos. Isso resulta em taxas de transação mais baixas para os usuários.
Alta segurança: o mecanismo de staking e delegação amplifica os custos e riscos de ataques; em conjunto com o mecanismo de confisco on-chain, inibe eficazmente comportamentos maliciosos.
Ao mesmo tempo, no mecanismo de consenso do SUI, foi adotado um algoritmo baseado em BFT (tolerância a falhas bizantinas), que requer que mais de dois terços dos votos dos validadores concordem para confirmar transações. Este mecanismo garante que, mesmo que um pequeno número de nós aja de forma maliciosa, a rede pode manter uma operação segura e eficiente. Para realizar qualquer atualização ou decisão significativa, também é necessário que mais de dois terços dos votos sejam alcançados 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" de segurança-descentralização-escalabilidade, opta por reduzir o número de nós ativos de bloqueio para obter um desempenho mais elevado, renunciando a um certo grau de descentralização completa em comparação com o PoS puro ou o 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 Mecanismo de congelamento em funcionamento
Neste evento, a SUI congelou rapidamente os endereços relacionados ao atacante.
Do ponto de vista do código, isso impede que 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 regras do protocolo. Ao ignorar coletivamente transações relacionadas a atacantes, esses validadores implementam, em nível de consenso, um mecanismo semelhante ao 'congelamento de contas' encontrado nas finanças tradicionais.
O SUI possui um mecanismo de lista de rejeição (deny list) embutido, que é uma funcionalidade de lista negra que pode bloquear qualquer transação envolvendo endereços listados. Como essa funcionalidade já existe no cliente, quando um ataque ocorre
SUI pode congelar imediatamente o endereço do hacker. Se esta funcionalidade não existir, mesmo que SUI tenha apenas 113 validadores, será difícil coordenar todos os validadores para responder um a um em pouco 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, recarregá-lo em quente ou reiniciar o nó, e atualizar a lista. À primeira vista, parece que cada validador está livre para expressar seus próprios valores.
Na verdade, para garantir a consistência e eficácia das políticas de segurança, a atualização dessa configuração crítica é geralmente coordenada. Como se trata de uma "atualização de emergência impulsionada pela equipe", basicamente é a fundação (ou os desenvolvedores autorizados por ela) que define e atualiza esta lista de rejeição.
Publicar uma lista negra, teoricamente os validadores podem escolher se a adotam ou não------mas na prática a maioria das pessoas automaticamente a adota por padrão. Portanto, embora esta funcionalidade proteja os fundos dos usuários, na sua essência, realmente possui 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 do nível do protocolo, mas sim uma camada adicional de segurança para lidar com situações imprevistas 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 à porta, é ativado apenas para aqueles que desejam invadir a casa, ou seja, para aqueles que querem prejudicar o protocolo. Para o usuário:
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 tvl são todos contribuídos pelos principais investidores; para que o protocolo se desenvolva a longo prazo, certamente priorizará a segurança.
Para os investidores individuais, contribuintes da atividade ecológica, apoiadores fortes da construção conjunta de tecnologia e comunidade. O projeto também espera atrair investidores individuais para co-construir, assim poderá gradualmente aperfeiçoar a ecologia e aumentar a taxa de retenção. E para o campo DeFi, a prioridade mais importante
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
A resiliência do ecossistema SUI: análise do incidente de ataque Cetus e discussão sobre o potencial de desenvolvimento futuro
Crença firme após a crise de segurança: por que o 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 de hackers. Os atacantes exploraram uma falha lógica relacionada a um "problema de estouro de inteiro" para realizar uma manipulação precisa, resultando em perdas de mais de 200 milhões de dólares em ativos. Este incidente não é apenas um dos maiores acidentes de segurança no espaço DeFi até agora este ano, mas também se tornou o ataque hacker mais destrutivo desde o lançamento da mainnet da SUI.
De acordo com os dados, o TVL total da SUI caiu mais de 330 milhões de dólares no dia do ataque, e o valor total bloqueado do protocolo Cetus evaporou instantaneamente 84%, caindo para 38 milhões de dólares. Como resultado, vários tokens populares na SUI despencaram 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 esta onda de choque, o ecossistema SUI demonstrou uma grande resiliência e capacidade de recuperação. Apesar do evento Cetus ter trazido flutuações de confiança a curto prazo, os fundos na cadeia e a atividade dos usuários não enfrentaram um declínio contínuo, mas sim impulsionaram uma atenção significativamente maior em relação à segurança, à construção de infraestrutura e à qualidade dos projetos em todo o ecossistema.
Este artigo irá abordar as causas deste ataque, o mecanismo de consenso de nós do SUI, a segurança da linguagem MOVE e o desenvolvimento ecológico do SUI, delineando o atual padrão ecológico desta blockchain que ainda está em estágio inicial de desenvolvimento e explorando seu potencial de desenvolvimento futuro.
2. Análise das causas do ataque Cetus
2.1 Processo de implementação do ataque
De acordo com a análise técnica da equipe de segurança sobre o incidente 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 precisa de preços e falhas em contratos 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 aproximadamente nas seguintes três fases:
①Iniciar um empréstimo relâmpago, manipular preços
Os hackers primeiro utilizaram um empréstimo relâmpago de 10 bilhões haSUI com o maior deslizamento, emprestando uma grande quantidade de fundos para manipulação de preços.
O empréstimo relâmpago permite que os usuários emprestem e devolvam fundos na mesma transação, pagando apenas uma taxa, com características de alta alavancagem, baixo risco e baixo custo. Os hackers aproveitaram esse mecanismo para baixar rapidamente os preços do mercado, controlando-os com precisão dentro de um intervalo muito estreito.
Em seguida, o atacante prepara-se para criar uma posição de liquidez extremamente estreita, definindo a faixa de preços com precisão entre a menor oferta de 300.000 e o maior preço 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 adicionar 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 é demasiado ampla: equivale a um limite de adição de liquidez extremamente grande, resultando em uma verificação de entrada do usuário no contrato que é praticamente irrelevante. Os hackers contornam a detecção de overflow configurando parâmetros anômalos, fazendo com que a entrada esteja sempre abaixo desse limite.
A sobrecarga de dados foi truncada: ao executar a operação de deslocamento n << 64 sobre o valor n, ocorreu truncamento de dados devido ao deslocamento exceder a largura de bits efetiva do tipo de dado uint256 (256 bits). A parte de overflow de bits altos foi automaticamente descartada, resultando em um resultado de cálculo muito inferior ao esperado, levando o sistema a subestimar a quantidade de haSUI necessária para a troca. O resultado final do cálculo foi cerca de 1, mas como foi arredondado para cima, acabou sendo igual a 1, ou seja, o hacker só precisava adicionar 1 token para trocar por uma enorme liquidez.
③ Retirar liquidez
Fazer o reembolso de um empréstimo relâmpago, mantendo lucros significativos. No final, retirar ativos de tokens com um valor total de centenas de milhões de dólares de múltiplos pools de liquidez.
A situação de perda de fundos é grave, o ataque resultou no roubo dos seguintes ativos:
1290 milhões de SUI (cerca de 5400 milhões de dólares)
6000万美元USDC
490万美元 Haedal Staked SUI
1950万美元TOILET
Outros tokens como HIPPO e LOFI caíram 75--80%, com liquidez esgotada
2.2 Causas e características da vulnerabilidade desta vez
A vulnerabilidade do Cetus tem três características:
O custo de reparação é 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 na arquitetura subjacente. Por outro lado, a falha está limitada apenas ao Cetus e não tem relação com o código do SUI. A raiz da falha está em uma verificação de condição de limite, sendo necessário modificar apenas duas linhas de código para eliminar completamente o risco; após a conclusão da reparação, pode ser imediatamente implementada na rede principal, garantindo que a lógica dos contratos subsequentes seja completa e prevenindo essa falha.
Alta ocultação: o contrato está em funcionamento há dois anos sem falhas, tendo sido auditado várias vezes, mas as vulnerabilidades não foram descobertas, principalmente porque a biblioteca Integer_Mate utilizada para cálculos matemáticos não foi incluída no escopo da auditoria.
Os hackers utilizam valores extremos para construir com precisão intervalos de negociação, criando cenários raríssimos de submissão de liquidez extremamente alta, o que aciona uma lógica anormal, indicando que esse tipo de problema é difícil de ser descoberto através de testes comuns. Esses problemas costumam estar em áreas cegas da percepção das pessoas, por isso permanecem ocultos por muito tempo até serem descobertos,
Move é superior a várias linguagens de contrato inteligente em termos de segurança de recursos e verificação de tipos, incorporando a detecção nativa de problemas de estouro de inteiros em cenários comuns. O estouro ocorreu porque, ao adicionar liquidez, o número necessário de tokens foi inicialmente verificado com um valor incorreto como limite, e a operação de deslocamento foi usada em vez da operação de multiplicação convencional. Se fossem usadas operações convencionais de adição, subtração, multiplicação ou divisão, o Move automaticamente verificaria a situação de estouro, evitando esse tipo de truncamento de bits altos.
Vulnerabilidades semelhantes também ocorreram em outras linguagens (como Solidity e Rust), e eram até mais fáceis de explorar devido à falta de proteção contra overflow de inteiros; antes da atualização da versão do Solidity, a verificação de overflow era muito fraca. Historicamente, ocorreram overflows de adição, subtração e multiplicação, cuja 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 elaborados, contornando as instruções de verificação no contrato, permitindo transferências excessivas para realizar ataques.
3. Mecanismo de consenso SUI
3.1 Introdução ao mecanismo de consenso SUI
Resumo:
SUI adota a estrutura de Prova de Participação Delegada (DeleGated Proof of Stake, abreviada como DPoS). Embora o mecanismo DPoS possa aumentar a taxa de transações, ele não consegue fornecer um nível de descentralização tão alto quanto o PoW (Prova de Trabalho). Assim, 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 influenciem diretamente a governança da rede.
Número médio de validadores: 106
Período médio de Epoch: 24 horas
Processo de mecanismo:
Delegação de direitos: usuários comuns não precisam operar nós por conta própria, basta que deleguem e empenhem SUI a validadores candidatos para participar da garantia de segurança da rede e da distribuição de recompensas. Este mecanismo pode reduzir a barreira de entrada para 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 o ciclo de bloco: um pequeno número de validadores selecionados produzem 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 contagem de votos, realiza-se uma rotação dinâmica, reeleccionando o conjunto de Validators com base no peso dos votos, garantindo a vitalidade dos nós, a consistência de interesses e a descentralização.
Vantagens do DPoS:
Alta eficiência: devido ao número controlável de nós de bloco, a rede pode concluir a confirmação em milissegundos, atendendo à alta demanda de TPS.
Baixo custo: Menos nós participando do consenso resultam em uma redução significativa da largura de banda de rede e dos recursos computacionais necessários para sincronização de informações e agregação de assinaturas. Assim, os custos de hardware e de operação diminuem, as exigências de poder computacional diminuem e os custos são mais baixos. Isso resulta em taxas de transação mais baixas para os usuários.
Alta segurança: o mecanismo de staking e delegação amplifica os custos e riscos de ataques; em conjunto com o mecanismo de confisco on-chain, inibe eficazmente comportamentos maliciosos.
Ao mesmo tempo, no mecanismo de consenso do SUI, foi adotado um algoritmo baseado em BFT (tolerância a falhas bizantinas), que requer que mais de dois terços dos votos dos validadores concordem para confirmar transações. Este mecanismo garante que, mesmo que um pequeno número de nós aja de forma maliciosa, a rede pode manter uma operação segura e eficiente. Para realizar qualquer atualização ou decisão significativa, também é necessário que mais de dois terços dos votos sejam alcançados 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" de segurança-descentralização-escalabilidade, opta por reduzir o número de nós ativos de bloqueio para obter um desempenho mais elevado, renunciando a um certo grau de descentralização completa em comparação com o PoS puro ou o 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 Mecanismo de congelamento em funcionamento
Neste evento, a SUI congelou rapidamente os endereços relacionados ao atacante.
Do ponto de vista do código, isso impede que 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 regras do protocolo. Ao ignorar coletivamente transações relacionadas a atacantes, esses validadores implementam, em nível de consenso, um mecanismo semelhante ao 'congelamento de contas' encontrado nas finanças tradicionais.
O SUI possui um mecanismo de lista de rejeição (deny list) embutido, que é uma funcionalidade de lista negra que pode bloquear qualquer transação envolvendo endereços listados. Como essa funcionalidade já existe no cliente, quando um ataque ocorre
SUI pode congelar imediatamente o endereço do hacker. Se esta funcionalidade não existir, mesmo que SUI tenha apenas 113 validadores, será difícil coordenar todos os validadores para responder um a um em pouco 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, recarregá-lo em quente ou reiniciar o nó, e atualizar a lista. À primeira vista, parece que cada validador está livre para expressar seus próprios valores.
Na verdade, para garantir a consistência e eficácia das políticas de segurança, a atualização dessa configuração crítica é geralmente coordenada. Como se trata de uma "atualização de emergência impulsionada pela equipe", basicamente é a fundação (ou os desenvolvedores autorizados por ela) que define e atualiza esta lista de rejeição.
Publicar uma lista negra, teoricamente os validadores podem escolher se a adotam ou não------mas na prática a maioria das pessoas automaticamente a adota por padrão. Portanto, embora esta funcionalidade proteja os fundos dos usuários, na sua essência, realmente possui 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 do nível do protocolo, mas sim uma camada adicional de segurança para lidar com situações imprevistas 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 à porta, é ativado apenas para aqueles que desejam invadir a casa, ou seja, para aqueles que querem prejudicar o protocolo. Para o usuário:
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 tvl são todos contribuídos pelos principais investidores; para que o protocolo se desenvolva a longo prazo, certamente priorizará a segurança.
Para os investidores individuais, contribuintes da atividade ecológica, apoiadores fortes da construção conjunta de tecnologia e comunidade. O projeto também espera atrair investidores individuais para co-construir, assim poderá gradualmente aperfeiçoar a ecologia e aumentar a taxa de retenção. E para o campo DeFi, a prioridade mais importante