Fé firme após a crise de segurança: por que o SUI ainda tem potencial para subir a longo prazo?
1. Uma reação em cadeia provocada por um ataque
No dia 22 de maio de 2023, 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 inteiros", realizando 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 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 valor bloqueado do protocolo Cetus evaporou instantaneamente 84%, caindo para 38 milhões de dólares. Como resultado, vários tokens populares na SUI (incluindo Lofi, Sudeng, Squirtle, entre outros) caíram entre 76% e 97% em apenas uma hora, gerando ampla preocupação no mercado sobre a segurança da SUI e a estabilidade do seu ecossistema.
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 sofreram um declínio contínuo, mas sim impulsionaram uma atenção significativa para a segurança, construção de infraestrutura e qualidade dos projetos em todo o ecossistema.
Vamos abordar as causas deste ataque, o mecanismo de consenso dos nós da SUI, a segurança da linguagem MOVE e o desenvolvimento do ecossistema da SUI, analisando 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 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 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 grosso modo 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 de haSUI com o maior deslizamento possível, emprestando uma grande quantidade de fundos para manipulação de preços.
O empréstimo relâmpago permite que os usuários peguem emprestado e devolvam fundos na mesma transação, pagando apenas uma taxa, apresentando características de alta alavancagem, baixo risco e baixo custo. Hackers exploraram esse mecanismo para reduzir rapidamente os preços de mercado e controlá-los com precisão em um intervalo extremamente estreito.
Em seguida, os atacantes se prepararam para criar uma posição de liquidez extremamente estreita, definindo o intervalo de preços com precisão entre a menor oferta de 300.000 e o preço máximo de 300.200, com uma largura de preço de apenas 1,00496621%.
Através da maneira 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, afirmando adicionar liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acaba por receber apenas 1 token.
Na essência, isso se deve a duas razões:
Configuração de máscara muito 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. Hackers configuraram parâmetros anormais, construindo entradas que estão sempre abaixo desse limite, contornando assim a detecção de estouro.
A transbordo de dados foi truncado: ao executar a operação de deslocamento n << 64 no 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 transbordo foi automaticamente descartada, resultando em um resultado de cálculo muito abaixo do esperado, fazendo com que o sistema subestimasse a quantidade de haSUI necessária para a troca. O resultado final do cálculo é 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 trocar por uma enorme liquidez.
③ Retirar liquidez
Realizar o reembolso de um empréstimo relâmpago, mantendo lucros substanciais. No final, retirar um total de ativos de token no valor 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 mil 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%, a liquidez secou.
2.2 Causas e características da vulnerabilidade desta vez
A falha do Cetus tem três características:
O custo de reparação é extremamente baixo: por um lado, a causa raiz do incidente Cetus é 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 está limitada apenas ao Cetus e não tem relação com o código do SUI. A origem da vulnerabilidade está em uma verificação de condição de limite, e basta modificar duas linhas de código para eliminar completamente o risco; após a reparação, pode ser imediatamente implantado na mainnet, garantindo a lógica dos contratos subsequentes completa e eliminando essa vulnerabilidade.
Alta ocultação: O contrato funcionou de forma estável e sem falhas durante dois anos, o Cetus Protocol passou por várias auditorias, mas as vulnerabilidades não foram encontradas, principalmente porque a biblioteca Integer_Mate usada para cálculos matemáticos não foi incluída no âmbito da auditoria.
Os hackers utilizam valores extremos para construir com precisão intervalos de negociação, criando cenários extremamente raros de submissão de liquidez muito alta, que acionam uma lógica anômala, indicando que esse tipo de problema é difícil de ser descoberto por testes comuns. Esses problemas costumam estar em áreas de sombra na visão das pessoas, e por isso permanecem ocultos por muito tempo até serem descobertos.
Não é um problema exclusivo do Move:
Move é superior a várias linguagens de contratos inteligentes em termos de segurança de recursos e verificação de tipos, possuindo uma detecção nativa para problemas de estouro de inteiros em cenários comuns. Este estouro ocorreu porque, ao adicionar liquidez, foi usado um valor incorreto para verificar o limite superior ao calcular a quantidade necessária de tokens, e a operação de deslocamento foi usada em vez da operação de multiplicação convencional. Se fossem realizadas operações de adição, subtração, multiplicação ou divisão convencionais, 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 até mesmo foram mais fáceis de 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 muito fraca. Historicamente, houve estouros de adição, estouros de subtração, estouros de multiplicação, etc., sendo que 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, permitindo transferências excessivas para realizar ataques.
3. Mecanismo de consenso 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 consiga aumentar o volume de transações, não consegue proporcionar um nível de descentralização tão elevado quanto o PoW (Prova de Trabalho). Portanto, o nível de descentralização do SUI é relativamente baixo, com um limiar de governança relativamente alto, 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
Mecanismo de processo:
Delegação de direitos: 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 usuários comuns, permitindo que eles participem do consenso da rede através da "contratação" de validadores de confiança. Esta é uma das grandes vantagens do DPoS em relação ao PoS tradicional.
Representa o ciclo de produção de blocos: 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 com base no peso dos votos, reelecionando o conjunto de Validadores, garantindo a vitalidade dos nós, a consistência dos interesses e a descentralização.
As vantagens do DPoS:
Alta eficiência: Devido ao número controlável de nós de bloco, a rede pode completar a confirmação em milissegundos, satisfazendo a necessidade de alto TPS.
Baixo custo: Menos nós participam do consenso, reduzindo significativamente a largura de banda da rede e os 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, os requisitos de poder computacional diminuem e os custos ficam 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 simultaneamente os custos e riscos de ataques; em conjunto com o mecanismo de confisco em cadeia, efetivamente inibe 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 uma transação. Este mecanismo garante que, mesmo que alguns nós ajam de forma maliciosa, a rede pode permanecer segura e operar de forma eficiente. Qualquer atualização ou decisão importante também requer mais de dois terços dos votos para ser implementada.
Em essência, o DPoS é uma solução de compromisso para o triângulo impossível, realizando um equilíbrio entre descentralização e eficiência. O DPoS, no triângulo "impossível" de segurança-descentralização-escabilidade, opta por reduzir o número de nós de blocos ativos em troca de um desempenho superior, renunciando a um certo grau de completa descentralização em comparação com o PoS puro ou PoW, mas aumentando significativamente a taxa de transações e a velocidade da rede.
3.2 O desempenho do SUI neste ataque
3.2.1 Mecanismo de congelamento em operação
Neste evento, o SUI rapidamente congelou os endereços relacionados ao atacante.
Do ponto de vista do código, impede que as transações de transferência sejam empacotadas na cadeia. 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 implementaram, em um nível de consenso, um mecanismo semelhante ao 'congelamento de contas' na finança tradicional.
O SUI possui um mecanismo de lista de rejeição (deny list) embutido, que é uma funcionalidade de lista negra que pode bloquear quaisquer transações envolvendo endereços listados. Como essa funcionalidade já existe no cliente, quando um ataque ocorre,
SUI pode congelar imediatamente o endereço dos hackers. Sem essa funcionalidade, mesmo que SUI tenha apenas 113 validadores, será difícil para a Cetus coordenar todos os validadores um a 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, fazer hot reload 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 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 urgente impulsionada pela equipe SUI", é basicamente a fundação SUI (ou os 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 irá automaticamente adotá-la. Assim, embora esta funcionalidade proteja os fundos dos utilizadores, na sua essência 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 da camada 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 à porta, que é ativada apenas para aqueles que desejam invadir a casa, ou seja, para aqueles que querem fazer mal ao protocolo. Para os usuários:
Para os grandes investidores, os principais provedores de liquidez, o protocolo deseja garantir a segurança dos fundos, pois na verdade os dados em cadeia tvl são todos contribuídos pelos principais investidores. Para que o protocolo se desenvolva a longo prazo, a segurança será sempre priorizada.
Para os investidores individuais, contribuintes para a atividade do ecossistema, fortes apoiadores da construção conjunta de tecnologia e comunidade. Projeto
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
10 Curtidas
Recompensa
10
6
Compartilhar
Comentário
0/400
GhostInTheChain
· 07-07 02:54
Hacker também é muito duro, no mundo crypto ainda é preciso jogar com cautela.
Ver originalResponder0
MevHunter
· 07-07 02:54
Ainda é divertido comprar na baixa durante o Bear Market.
Ver originalResponder0
FlashLoanKing
· 07-07 02:36
Crítico é crítico, comprar na baixa é uma festa!
Ver originalResponder0
GweiTooHigh
· 07-07 02:35
Quem é responsável por essa falha?
Ver originalResponder0
MEVHunter
· 07-07 02:29
A vulnerabilidade de estouro p2=p1 ainda pode ser explorada. Código lixo a torto e a direito. Os arbitradores estão em êxtase.
Ver originalResponder0
MaticHoleFiller
· 07-07 02:25
fazer as pessoas de parvas Puxar o tapete Onde está a próxima vítima
Resiliência após a crise de segurança do ecossistema SUI: Perspectivas de crescimento a longo prazo além do evento Cetus
Fé firme após a crise de segurança: por que o SUI ainda tem potencial para subir a longo prazo?
1. Uma reação em cadeia provocada por um ataque
No dia 22 de maio de 2023, 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 inteiros", realizando 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 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 valor bloqueado do protocolo Cetus evaporou instantaneamente 84%, caindo para 38 milhões de dólares. Como resultado, vários tokens populares na SUI (incluindo Lofi, Sudeng, Squirtle, entre outros) caíram entre 76% e 97% em apenas uma hora, gerando ampla preocupação no mercado sobre a segurança da SUI e a estabilidade do seu ecossistema.
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 sofreram um declínio contínuo, mas sim impulsionaram uma atenção significativa para a segurança, construção de infraestrutura e qualidade dos projetos em todo o ecossistema.
Vamos abordar as causas deste ataque, o mecanismo de consenso dos nós da SUI, a segurança da linguagem MOVE e o desenvolvimento do ecossistema da SUI, analisando 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 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 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 grosso modo 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 de haSUI com o maior deslizamento possível, emprestando uma grande quantidade de fundos para manipulação de preços.
O empréstimo relâmpago permite que os usuários peguem emprestado e devolvam fundos na mesma transação, pagando apenas uma taxa, apresentando características de alta alavancagem, baixo risco e baixo custo. Hackers exploraram esse mecanismo para reduzir rapidamente os preços de mercado e controlá-los com precisão em um intervalo extremamente estreito.
Em seguida, os atacantes se prepararam para criar uma posição de liquidez extremamente estreita, definindo o intervalo de preços com precisão entre a menor oferta de 300.000 e o preço máximo de 300.200, com uma largura de preço de apenas 1,00496621%.
Através da maneira 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, afirmando adicionar liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acaba por receber apenas 1 token.
Na essência, isso se deve a duas razões:
Configuração de máscara muito 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. Hackers configuraram parâmetros anormais, construindo entradas que estão sempre abaixo desse limite, contornando assim a detecção de estouro.
A transbordo de dados foi truncado: ao executar a operação de deslocamento n << 64 no 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 transbordo foi automaticamente descartada, resultando em um resultado de cálculo muito abaixo do esperado, fazendo com que o sistema subestimasse a quantidade de haSUI necessária para a troca. O resultado final do cálculo é 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 trocar por uma enorme liquidez.
③ Retirar liquidez
Realizar o reembolso de um empréstimo relâmpago, mantendo lucros substanciais. No final, retirar um total de ativos de token no valor 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 mil 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%, a liquidez secou.
2.2 Causas e características da vulnerabilidade desta vez
A falha do Cetus tem três características:
O custo de reparação é extremamente baixo: por um lado, a causa raiz do incidente Cetus é 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 está limitada apenas ao Cetus e não tem relação com o código do SUI. A origem da vulnerabilidade está em uma verificação de condição de limite, e basta modificar duas linhas de código para eliminar completamente o risco; após a reparação, pode ser imediatamente implantado na mainnet, garantindo a lógica dos contratos subsequentes completa e eliminando essa vulnerabilidade.
Alta ocultação: O contrato funcionou de forma estável e sem falhas durante dois anos, o Cetus Protocol passou por várias auditorias, mas as vulnerabilidades não foram encontradas, principalmente porque a biblioteca Integer_Mate usada para cálculos matemáticos não foi incluída no âmbito da auditoria.
Os hackers utilizam valores extremos para construir com precisão intervalos de negociação, criando cenários extremamente raros de submissão de liquidez muito alta, que acionam uma lógica anômala, indicando que esse tipo de problema é difícil de ser descoberto por testes comuns. Esses problemas costumam estar em áreas de sombra na visão das pessoas, e por isso permanecem ocultos por muito tempo até serem descobertos.
Move é superior a várias linguagens de contratos inteligentes em termos de segurança de recursos e verificação de tipos, possuindo uma detecção nativa para problemas de estouro de inteiros em cenários comuns. Este estouro ocorreu porque, ao adicionar liquidez, foi usado um valor incorreto para verificar o limite superior ao calcular a quantidade necessária de tokens, e a operação de deslocamento foi usada em vez da operação de multiplicação convencional. Se fossem realizadas operações de adição, subtração, multiplicação ou divisão convencionais, 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 até mesmo foram mais fáceis de 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 muito fraca. Historicamente, houve estouros de adição, estouros de subtração, estouros de multiplicação, etc., sendo que 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, permitindo transferências excessivas para realizar ataques.
3. Mecanismo de consenso 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 consiga aumentar o volume de transações, não consegue proporcionar um nível de descentralização tão elevado quanto o PoW (Prova de Trabalho). Portanto, o nível de descentralização do SUI é relativamente baixo, com um limiar de governança relativamente alto, 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
Mecanismo de processo:
Delegação de direitos: 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 usuários comuns, permitindo que eles participem do consenso da rede através da "contratação" de validadores de confiança. Esta é uma das grandes vantagens do DPoS em relação ao PoS tradicional.
Representa o ciclo de produção de blocos: 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 com base no peso dos votos, reelecionando o conjunto de Validadores, garantindo a vitalidade dos nós, a consistência dos interesses e a descentralização.
As vantagens do DPoS:
Alta eficiência: Devido ao número controlável de nós de bloco, a rede pode completar a confirmação em milissegundos, satisfazendo a necessidade de alto TPS.
Baixo custo: Menos nós participam do consenso, reduzindo significativamente a largura de banda da rede e os 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, os requisitos de poder computacional diminuem e os custos ficam 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 simultaneamente os custos e riscos de ataques; em conjunto com o mecanismo de confisco em cadeia, efetivamente inibe 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 uma transação. Este mecanismo garante que, mesmo que alguns nós ajam de forma maliciosa, a rede pode permanecer segura e operar de forma eficiente. Qualquer atualização ou decisão importante também requer mais de dois terços dos votos para ser implementada.
Em essência, o DPoS é uma solução de compromisso para o triângulo impossível, realizando um equilíbrio entre descentralização e eficiência. O DPoS, no triângulo "impossível" de segurança-descentralização-escabilidade, opta por reduzir o número de nós de blocos ativos em troca de um desempenho superior, renunciando a um certo grau de completa descentralização em comparação com o PoS puro ou PoW, mas aumentando significativamente a taxa de transações e a velocidade da rede.
3.2 O desempenho do SUI neste ataque
3.2.1 Mecanismo de congelamento em operação
Neste evento, o SUI rapidamente congelou os endereços relacionados ao atacante.
Do ponto de vista do código, impede que as transações de transferência sejam empacotadas na cadeia. 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 implementaram, em um nível de consenso, um mecanismo semelhante ao 'congelamento de contas' na finança tradicional.
O SUI possui um mecanismo de lista de rejeição (deny list) embutido, que é uma funcionalidade de lista negra que pode bloquear quaisquer transações envolvendo endereços listados. Como essa funcionalidade já existe no cliente, quando um ataque ocorre,
SUI pode congelar imediatamente o endereço dos hackers. Sem essa funcionalidade, mesmo que SUI tenha apenas 113 validadores, será difícil para a Cetus coordenar todos os validadores um a 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, fazer hot reload 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 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 urgente impulsionada pela equipe SUI", é basicamente a fundação SUI (ou os 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 irá automaticamente adotá-la. Assim, embora esta funcionalidade proteja os fundos dos utilizadores, na sua essência 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 da camada 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 à porta, que é ativada apenas para aqueles que desejam invadir a casa, ou seja, para aqueles que querem fazer mal ao protocolo. Para os usuários:
Para os grandes investidores, os principais provedores de liquidez, o protocolo deseja garantir a segurança dos fundos, pois na verdade os dados em cadeia tvl são todos contribuídos pelos principais investidores. Para que o protocolo se desenvolva a longo prazo, a segurança será sempre priorizada.
Para os investidores individuais, contribuintes para a atividade do ecossistema, fortes apoiadores da construção conjunta de tecnologia e comunidade. Projeto