Fé 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 desencadeada por um ataque
No dia 22 de maio de 2023, o protocolo AMM de destaque, Cetus, implantado na rede SUI, sofreu um ataque de hackers. Os atacantes exploraram uma vulnerabilidade lógica relacionada ao "problema de estouro de inteiro" para realizar um controle preciso, resultando em perdas superiores a 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) despencaram de 76% a 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 forte resiliência e capacidade de recuperação. Embora o evento Cetus tenha trazido flutuações de confiança a curto prazo, os fundos on-chain e a atividade dos usuários não sofreram um declínio contínuo, mas, ao contrário, impulsionaram um aumento significativo na atenção de todo o ecossistema à segurança, construção de infraestrutura e qualidade dos projetos.
Este artigo irá abordar as causas deste incidente de 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 pública que ainda se encontra em fase inicial de desenvolvimento, e explorando seu potencial de desenvolvimento futuro.
2. Análise das causas do ataque Cetus
2.1 Processo de execução do ataque
De acordo com a análise técnica da equipe Slow Mist 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, roubando mais de 200 milhões de dólares em ativos digitais em um curto período 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 uma troca rápida com um deslizamento máximo de 10 bilhões de haSUI com um empréstimo relâmpago, emprestando uma grande quantidade de fundos para manipular os 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 reduzir rapidamente o preço do mercado e controlá-lo com precisão dentro de um intervalo extremamente estreito.
Em seguida, o atacante se preparou para criar uma posição de liquidez extremamente estreita, definindo o intervalo de preços com precisão entre a menor cotação de 300.000 e o preço mais alto 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 com 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
Os atacantes criam posições de liquidez estreitas, afirmando adicionar liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acabam recebendo apenas 1 token.
Isso se deve essencialmente a dois motivos:
A configuração da máscara é muito ampla: equivale a um limite de adição de liquidez extremamente grande, levando a uma verificação das entradas do usuário no contrato a ser ineficaz. Hackers definem 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 sobre o valor n, ocorreu truncamento de dados devido ao deslocamento exceder a largura de bits válida do tipo de dados uint256 (256 bits). A parte de transbordo alto foi automaticamente descartada, resultando em um resultado de cálculo muito abaixo do esperado, o que fez com que o sistema subestimasse 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, o resultado final foi igual a 1, ou seja, o hacker só precisou adicionar 1 token para conseguir uma enorme liquidez.
③ Retirar liquidez
Fazer o reembolso do empréstimo relâmpago, mantendo lucros massivos. No final, retirar ativos de token com um 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 dólares americanos)
6000万美元USDC
490万美元Haedal Staked SUI
1950万美元TOILET
Outros tokens como HIPPO e LOFI caíram 75--80%, a liquidez esgotou.
2.2 A causa e características da vulnerabilidade
A falha do Cetus tem três características:
Custo de reparo extremamente baixo: por um lado, a causa raiz do incidente 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 infraestrutura subjacente. Por outro lado, a vulnerabilidade estava restrita apenas ao Cetus e não tinha relação com o código do SUI. A origem da vulnerabilidade estava em uma verificação de condição de limite, sendo necessário apenas modificar duas linhas de código para eliminar completamente o risco; uma vez concluído o reparo, pode ser imediatamente implantado na mainnet, garantindo que a lógica dos contratos subsequentes esteja completa e eliminando essa vulnerabilidade.
Alta ocultação: O contrato está em funcionamento estável há dois anos sem falhas, o Cetus Protocol foi auditado várias vezes, mas as vulnerabilidades não foram encontradas, 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 precisamente intervalos de negociação, criando cenários extremamente raros com alta liquidez, que apenas desencadeiam lógicas anormais, indicando que tais problemas são difíceis de serem descobertos por testes comuns. Esses problemas geralmente estão em uma zona cega na visão das pessoas, portanto, ficam ocultos por muito tempo até serem descobertos.
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ções nativas para problemas de estouro inteiro em cenários comuns. Este estouro ocorreu porque, ao adicionar liquidez, foi utilizado um valor errado para a verificação do limite superior ao calcular a quantidade de tokens necessária, 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 e divisão, o Move verificaria automaticamente a situação de estouro e não haveria esse problema de truncamento de bits altos.
Vulnerabilidades semelhantes também ocorreram em outras linguagens (como Solidity e Rust), sendo até 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 estouros era bastante fraca. Historicamente, ocorreram estouros de adição, estouros de subtração, estouros de multiplicação, todos com a causa direta sendo que o resultado da operação excedeu o limite. Por exemplo, as vulnerabilidades nos contratos inteligentes BEC e SMT da linguagem Solidity foram exploradas por meio de parâmetros cuidadosamente elaborados, contornando as instruções de verificação nos contratos e realizando transferências excessivas para atacar.
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 taxa de transações, ele não consegue oferecer 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, tornando difícil para os usuários comuns influenciar diretamente a governança da rede.
Número médio de validadores: 106
Período médio de Epoch: 24 horas
Mecanismo de fluxo:
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. Esse mecanismo pode reduzir a barreira de participação para usuários comuns, permitindo que eles participem do consenso da rede "contratando" validadores de confiança. Esta também é uma grande vantagem do DPoS em relação ao PoS tradicional.
Representação de rodadas de criação de blocos: um número reduzido 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 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.
Vantagens do DPoS:
Alta eficiência: Devido ao número controlável de nós de blocos, a rede pode completar a confirmação em milissegundos, atendendo à demanda de alta TPS.
Baixo custo: menos nós participando do consenso, a largura de banda da rede e os recursos computacionais necessários para a sincronização de informações e agregação de assinaturas são significativamente reduzidos. Isso resulta na diminuição dos custos de hardware e operações, exigindo menos poder computacional e, portanto, custos mais baixos. No final, alcançou taxas de transação mais baixas para os usuários.
Alta segurança: os mecanismos de staking e delegação aumentam simultaneamente os custos e riscos de ataque; em conjunto com o mecanismo de confisco em cadeia, 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 a votação para confirmar uma transação. Este mecanismo garante que, mesmo que alguns nós atuem de forma maliciosa, a rede pode manter uma operação segura e eficiente. Para qualquer atualização ou decisão importante, também é necessário que mais de dois terços dos votos concordem para que seja implementado.
Em essência, o DPoS é uma solução de compromisso para o triângulo impossível, equilibrando descentralização e eficiência. O DPoS opta por reduzir o número de nós de bloco ativos em troca de maior desempenho dentro do "triângulo impossível" de segurança-descentralização-escalabilidade, sacrificando um certo grau de descentralização completa em comparação com o PoS ou PoW puros, mas melhorando significativamente a capacidade de transação e a velocidade das transações.
3.2 O desempenho do SUI nesta 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, isso 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 regras de protocolo. Ao ignorar coletivamente as transações relacionadas ao atacante, esses validadores equivalem a implementar um mecanismo semelhante ao de 'congelamento de conta' no nível de consenso, como no sistema financeiro tradicional.
O SUI possui um mecanismo de lista de rejeição (deny list) embutido, que é uma funcionalidade de blacklist que pode impedir 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 função não estiver disponível, 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 é um 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 a consistência e eficácia da política de segurança, a atualização de configurações críticas geralmente é coordenada, uma vez que se trata de uma "atualização de emergência promovida pela equipe SUI". Portanto, basicamente, é a fundação SUI (ou os desenvolvedores autorizados por ela) que estabelece 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 assume que a utilizará automaticamente. Assim, embora esta funcionalidade proteja os fundos dos usuários, na sua essência, tem de fato um certo grau de centralização.
3.2.3 A essência da função de lista negra
A funcionalidade de lista negra na verdade não é uma lógica de camada de protocolo, mas sim uma camada adicional de segurança destinada a 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, que é ativada apenas contra aqueles que desejam invadir a casa, ou seja, contra aqueles que querem fazer mal ao protocolo. Para os usuários:
Para os grandes investidores, os principais provedores de liquidez, o protocolo é aquele que mais deseja garantir a segurança dos fundos, pois, na realidade, os dados on-chain do 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, fortes apoiadores da construção conjunta de tecnologia e comunidade. O projeto também espera que seja possível
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.
8 gostos
Recompensa
8
4
Partilhar
Comentar
0/400
GetRichLeek
· 15h atrás
Estão a ser espancados Rekt, mas ainda assim não consigo resistir a comprar na baixa sui
Ver originalResponder0
ShadowStaker
· 07-26 06:40
a resiliência da rede está a ser testada fr... mas estes exploits de estouro de inteiro estão a envelhecer smh. onde está a validação adequada?
A resiliência do ecossistema SUI se manifesta, mostrando potencial de crescimento a longo prazo mesmo após a crise de segurança.
Fé 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 desencadeada por um ataque
No dia 22 de maio de 2023, o protocolo AMM de destaque, Cetus, implantado na rede SUI, sofreu um ataque de hackers. Os atacantes exploraram uma vulnerabilidade lógica relacionada ao "problema de estouro de inteiro" para realizar um controle preciso, resultando em perdas superiores a 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) despencaram de 76% a 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 forte resiliência e capacidade de recuperação. Embora o evento Cetus tenha trazido flutuações de confiança a curto prazo, os fundos on-chain e a atividade dos usuários não sofreram um declínio contínuo, mas, ao contrário, impulsionaram um aumento significativo na atenção de todo o ecossistema à segurança, construção de infraestrutura e qualidade dos projetos.
Este artigo irá abordar as causas deste incidente de 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 pública que ainda se encontra em fase inicial de desenvolvimento, e explorando seu potencial de desenvolvimento futuro.
2. Análise das causas do ataque Cetus
2.1 Processo de execução do ataque
De acordo com a análise técnica da equipe Slow Mist 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, roubando mais de 200 milhões de dólares em ativos digitais em um curto período 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 uma troca rápida com um deslizamento máximo de 10 bilhões de haSUI com um empréstimo relâmpago, emprestando uma grande quantidade de fundos para manipular os 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 reduzir rapidamente o preço do mercado e controlá-lo com precisão dentro de um intervalo extremamente estreito.
Em seguida, o atacante se preparou para criar uma posição de liquidez extremamente estreita, definindo o intervalo de preços com precisão entre a menor cotação de 300.000 e o preço mais alto 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 com 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
Os atacantes criam posições de liquidez estreitas, afirmando adicionar liquidez, mas devido a uma vulnerabilidade na função checked_shlw, acabam recebendo apenas 1 token.
Isso se deve essencialmente a dois motivos:
A configuração da máscara é muito ampla: equivale a um limite de adição de liquidez extremamente grande, levando a uma verificação das entradas do usuário no contrato a ser ineficaz. Hackers definem 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 sobre o valor n, ocorreu truncamento de dados devido ao deslocamento exceder a largura de bits válida do tipo de dados uint256 (256 bits). A parte de transbordo alto foi automaticamente descartada, resultando em um resultado de cálculo muito abaixo do esperado, o que fez com que o sistema subestimasse 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, o resultado final foi igual a 1, ou seja, o hacker só precisou adicionar 1 token para conseguir uma enorme liquidez.
③ Retirar liquidez
Fazer o reembolso do empréstimo relâmpago, mantendo lucros massivos. No final, retirar ativos de token com um 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 dólares americanos)
6000万美元USDC
490万美元Haedal Staked SUI
1950万美元TOILET
Outros tokens como HIPPO e LOFI caíram 75--80%, a liquidez esgotou.
2.2 A causa e características da vulnerabilidade
A falha do Cetus tem três características:
Custo de reparo extremamente baixo: por um lado, a causa raiz do incidente 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 infraestrutura subjacente. Por outro lado, a vulnerabilidade estava restrita apenas ao Cetus e não tinha relação com o código do SUI. A origem da vulnerabilidade estava em uma verificação de condição de limite, sendo necessário apenas modificar duas linhas de código para eliminar completamente o risco; uma vez concluído o reparo, pode ser imediatamente implantado na mainnet, garantindo que a lógica dos contratos subsequentes esteja completa e eliminando essa vulnerabilidade.
Alta ocultação: O contrato está em funcionamento estável há dois anos sem falhas, o Cetus Protocol foi auditado várias vezes, mas as vulnerabilidades não foram encontradas, 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 precisamente intervalos de negociação, criando cenários extremamente raros com alta liquidez, que apenas desencadeiam lógicas anormais, indicando que tais problemas são difíceis de serem descobertos por testes comuns. Esses problemas geralmente estão em uma zona cega na visão das pessoas, portanto, ficam ocultos por muito tempo até serem descobertos.
Move é superior a várias linguagens de contratos inteligentes em segurança de recursos e verificação de tipos, incorporando detecções nativas para problemas de estouro inteiro em cenários comuns. Este estouro ocorreu porque, ao adicionar liquidez, foi utilizado um valor errado para a verificação do limite superior ao calcular a quantidade de tokens necessária, 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 e divisão, o Move verificaria automaticamente a situação de estouro e não haveria esse problema de truncamento de bits altos.
Vulnerabilidades semelhantes também ocorreram em outras linguagens (como Solidity e Rust), sendo até 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 estouros era bastante fraca. Historicamente, ocorreram estouros de adição, estouros de subtração, estouros de multiplicação, todos com a causa direta sendo que o resultado da operação excedeu o limite. Por exemplo, as vulnerabilidades nos contratos inteligentes BEC e SMT da linguagem Solidity foram exploradas por meio de parâmetros cuidadosamente elaborados, contornando as instruções de verificação nos contratos e realizando transferências excessivas para atacar.
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 taxa de transações, ele não consegue oferecer 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, tornando difícil para os usuários comuns influenciar diretamente a governança da rede.
Número médio de validadores: 106
Período médio de Epoch: 24 horas
Mecanismo de fluxo:
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. Esse mecanismo pode reduzir a barreira de participação para usuários comuns, permitindo que eles participem do consenso da rede "contratando" validadores de confiança. Esta também é uma grande vantagem do DPoS em relação ao PoS tradicional.
Representação de rodadas de criação de blocos: um número reduzido 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 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.
Vantagens do DPoS:
Alta eficiência: Devido ao número controlável de nós de blocos, a rede pode completar a confirmação em milissegundos, atendendo à demanda de alta TPS.
Baixo custo: menos nós participando do consenso, a largura de banda da rede e os recursos computacionais necessários para a sincronização de informações e agregação de assinaturas são significativamente reduzidos. Isso resulta na diminuição dos custos de hardware e operações, exigindo menos poder computacional e, portanto, custos mais baixos. No final, alcançou taxas de transação mais baixas para os usuários.
Alta segurança: os mecanismos de staking e delegação aumentam simultaneamente os custos e riscos de ataque; em conjunto com o mecanismo de confisco em cadeia, 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 a votação para confirmar uma transação. Este mecanismo garante que, mesmo que alguns nós atuem de forma maliciosa, a rede pode manter uma operação segura e eficiente. Para qualquer atualização ou decisão importante, também é necessário que mais de dois terços dos votos concordem para que seja implementado.
Em essência, o DPoS é uma solução de compromisso para o triângulo impossível, equilibrando descentralização e eficiência. O DPoS opta por reduzir o número de nós de bloco ativos em troca de maior desempenho dentro do "triângulo impossível" de segurança-descentralização-escalabilidade, sacrificando um certo grau de descentralização completa em comparação com o PoS ou PoW puros, mas melhorando significativamente a capacidade de transação e a velocidade das transações.
3.2 O desempenho do SUI nesta 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, isso 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 regras de protocolo. Ao ignorar coletivamente as transações relacionadas ao atacante, esses validadores equivalem a implementar um mecanismo semelhante ao de 'congelamento de conta' no nível de consenso, como no sistema financeiro tradicional.
O SUI possui um mecanismo de lista de rejeição (deny list) embutido, que é uma funcionalidade de blacklist que pode impedir 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 função não estiver disponível, 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 é um 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 a consistência e eficácia da política de segurança, a atualização de configurações críticas geralmente é coordenada, uma vez que se trata de uma "atualização de emergência promovida pela equipe SUI". Portanto, basicamente, é a fundação SUI (ou os desenvolvedores autorizados por ela) que estabelece 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 assume que a utilizará automaticamente. Assim, embora esta funcionalidade proteja os fundos dos usuários, na sua essência, tem de fato um certo grau de centralização.
3.2.3 A essência da função de lista negra
A funcionalidade de lista negra na verdade não é uma lógica de camada de protocolo, mas sim uma camada adicional de segurança destinada a 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, que é ativada apenas contra aqueles que desejam invadir a casa, ou seja, contra aqueles que querem fazer mal ao protocolo. Para os usuários:
Para os grandes investidores, os principais provedores de liquidez, o protocolo é aquele que mais deseja garantir a segurança dos fundos, pois, na realidade, os dados on-chain do 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, fortes apoiadores da construção conjunta de tecnologia e comunidade. O projeto também espera que seja possível