Fé firme após a crise de segurança: por que SUI ainda tem potencial de crescimento a longo prazo?
1. Uma reação em cadeia provocada por um ataque
No dia 22 de maio de 2023, o protocolo AMM líder 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" para realizar uma manipulação precisa, 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 campo 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 temporariamente mais de 330 milhões de dólares no dia do ataque, com o valor bloqueado do protocolo Cetus evaporando 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 uma 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 na cadeia e a atividade dos usuários não sofreram um declínio contínuo, mas, ao contrário, impulsionaram uma atenção significativamente maior de todo o ecossistema para a segurança, a construção de infraestrutura e a qualidade dos projetos.
Vamos analisar as razões por trás 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 está em estágio inicial de desenvolvimento e discutindo seu potencial de desenvolvimento futuro.
2. Análise das causas do ataque ao evento Cetus
2.1 Implementaçã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 de preços precisa e falhas de contrato para roubar 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 usaram uma troca rápida com um deslizamento máximo de 100 bilhões de haSUI através de um empréstimo relâmpago, emprestando grandes quantias de dinheiro 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 de serviço, apresentando 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 muito estreito.
Em seguida, o atacante se prepara 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 preço mais alto de 300.200, com uma largura de preço de apenas 1,00496621%.
Dessa forma, os hackers conseguiram manipular o preço do haSUI utilizando uma quantidade suficiente de tokens e uma enorme liquidez. Em seguida, eles também manipularam vários tokens sem valor real.
②Adicionar liquidez
O atacante cria uma posição de liquidez estreita, 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:
Configuração de máscara muito ampla: equivale a um limite de adição de liquidez extremamente alto, resultando numa verificação de entrada do usuário na contratualidade que é praticamente inexistente. Hackers configuram parâmetros anormais, construindo entradas que estão sempre abaixo desse limite, conseguindo assim contornar a detecção de estouro.
Dados de overflow foram truncados: ao realizar a operação de deslocamento n << 64 em um valor n, ocorreu truncamento de dados devido ao deslocamento ultrapassar a largura de bits válida do tipo de dados uint256 (256 bits). A parte de overflow mais alta foi automaticamente descartada, levando a 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 aproximadamente inferior a 1, mas como foi arredondado para cima, o resultado final foi igual a 1, ou seja, o hacker só precisava adicionar 1 token para conseguir retirar uma grande liquidez.
③ Retirar liquidez
Realizar o reembolso do empréstimo relâmpago, mantendo lucros substanciais. No final, retirar um total de ativos de tokens 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 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 as características desta vulnerabilidade
A vulnerabilidade do Cetus tem três características:
Custo de reparo 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á restrita apenas ao Cetus e não está relacionada ao código SUI. A origem da vulnerabilidade está em uma verificação de condição de limite, e apenas duas linhas de código precisam ser modificadas para eliminar completamente o risco; após a conclusão da 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 funcionamento estável sem falhas há dois anos, o Cetus Protocol passou por várias auditorias, 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 com precisão intervalos de negociação, criando cenários extremamente raros que submetem uma liquidez muito alta, o que aciona uma lógica anômala, indicando que esse tipo de problema é difícil de ser detectado por 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 contratos inteligentes em termos de segurança de recursos e verificação de tipos, incorporando detecção nativa para problemas de estouro de inteiros em cenários comuns. Este estouro ocorreu porque, ao adicionar liquidez, foi utilizado um valor incorreto para a verificação do limite superior ao calcular a quantidade de tokens necessária, e a operação de deslocamento foi utilizada em vez da operação de multiplicação convencional. Se fossem utilizadas operações convencionais de adição, subtração, multiplicação ou divisão, o Move verificaria automaticamente a situação de estouro, evitando esse tipo de problema de truncamento de bits altos.
Vulnerabilidades semelhantes também ocorreram em outras linguagens (como Solidity e Rust), e eram até 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, ocorreram estouros em adição, subtração e multiplicação, 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 dentro do contrato, resultando em transferências excessivas para realizar ataques.
3. Mecanismo de consenso do 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 para DPoS)). Embora o mecanismo DPoS possa aumentar a capacidade de transação, ele não consegue oferecer um nível de descentralização tão alto quanto o PoW (Prova de Trabalho). Portanto, o nível de descentralização do SUI é relativamente baixo, com um limite de governança relativamente alto, tornando difícil para usuários comuns influenciarem 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 um nó por conta própria, basta que façam a aposta 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 diminuir a barreira de entrada 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 a rodada de blocos: um número limitado 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, reelecionando 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 controlado de nós de produção de blocos, a rede consegue completar a confirmação em milissegundos, satisfazendo a necessidade de alta TPS.
Baixo custo: Menos nós participando do consenso resultam em uma redução significativa na largura de banda da rede e nos recursos computacionais necessários para a sincronização de informações e agregação de assinaturas. Assim, os custos de hardware e de operação diminuem, e a exigência em relação ao poder de computação é 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 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 votos dos validadores cheguem a um consenso para confirmar a transação. Este mecanismo garante que, mesmo que um pequeno número de nós aja de forma maliciosa, a rede possa manter uma operação segura e 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, fazendo uma troca entre descentralização e eficiência. O DPoS, no triângulo "impossível" da segurança-descentralização-escabilidade, opta por reduzir o número de nós ativos de criação de blocos em troca de um desempenho mais elevado, abandonando um certo grau de total 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 nesta ataque
3.2.1 mecanismo de congelamento em operação
Neste evento, a SUI rapidamente congelou os endereços relacionados ao atacante.
Do ponto de vista do código, isso impede que 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 nível de consenso, um mecanismo semelhante ao de 'congelamento de conta' no setor financeiro tradicional.
O SUI possui um mecanismo de lista de rejeição (deny list) embutido, que é uma funcionalidade de lista negra 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. 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 reload a quente ou reiniciar o nó e atualizar a lista. À primeira vista, cada validador parece estar 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 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 adotam ou não------mas na prática a maioria das pessoas adotará automaticamente. Assim, embora esta funcionalidade proteja os fundos dos usuários, ela tem, de fato, 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; é mais como uma camada adicional de segurança para 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 "cadeia de segurança" presa à porta, que é ativada apenas para aqueles que desejam invadir a casa, ou seja, para aqueles que querem prejudicar o protocolo. Para os usuários, isso significa:
Para os grandes investidores, que são os principais provedores de liquidez, o protocolo deseja garantir a segurança dos fundos, pois na verdade os dados na cadeia tvl são todos contribuídos pelos principais investidores. Para que o protocolo se desenvolva a longo prazo, é imprescindível priorizar a segurança.
Para os investidores individuais, contribuintes da atividade ecológica, fortes apoiantes da construção conjunta de tecnologia e comunidade. O projeto também espera atrair investidores individuais para a construção conjunta,
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.
13 gostos
Recompensa
13
5
Partilhar
Comentar
0/400
MEVHunterNoLoss
· 15h atrás
Esta onda de hack não tenho medo de perda de corte
Ver originalResponder0
gas_fee_trauma
· 15h atrás
炒币亏完了就全在这
Responder0
faded_wojak.eth
· 15h atrás
Ainda tens coragem de falar em resiliência, foste diretamente despojado.
Ver originalResponder0
LiquidationKing
· 15h atrás
sui pode não estar necessariamente frio, mas o ferro deve ser tratado com cuidado
A resiliência do ecossistema SUI se destaca, mostrando um potencial de crescimento a longo prazo após o incidente de segurança.
Fé firme após a crise de segurança: por que SUI ainda tem potencial de crescimento a longo prazo?
1. Uma reação em cadeia provocada por um ataque
No dia 22 de maio de 2023, o protocolo AMM líder 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" para realizar uma manipulação precisa, 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 campo 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 temporariamente mais de 330 milhões de dólares no dia do ataque, com o valor bloqueado do protocolo Cetus evaporando 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 uma 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 na cadeia e a atividade dos usuários não sofreram um declínio contínuo, mas, ao contrário, impulsionaram uma atenção significativamente maior de todo o ecossistema para a segurança, a construção de infraestrutura e a qualidade dos projetos.
Vamos analisar as razões por trás 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 está em estágio inicial de desenvolvimento e discutindo seu potencial de desenvolvimento futuro.
2. Análise das causas do ataque ao evento Cetus
2.1 Implementaçã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 de preços precisa e falhas de contrato para roubar 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 usaram uma troca rápida com um deslizamento máximo de 100 bilhões de haSUI através de um empréstimo relâmpago, emprestando grandes quantias de dinheiro 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 de serviço, apresentando 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 muito estreito.
Em seguida, o atacante se prepara 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 preço mais alto de 300.200, com uma largura de preço de apenas 1,00496621%.
Dessa forma, os hackers conseguiram manipular o preço do haSUI utilizando uma quantidade suficiente de tokens e uma enorme liquidez. Em seguida, eles também manipularam vários tokens sem valor real.
②Adicionar liquidez
O atacante cria uma posição de liquidez estreita, 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:
Configuração de máscara muito ampla: equivale a um limite de adição de liquidez extremamente alto, resultando numa verificação de entrada do usuário na contratualidade que é praticamente inexistente. Hackers configuram parâmetros anormais, construindo entradas que estão sempre abaixo desse limite, conseguindo assim contornar a detecção de estouro.
Dados de overflow foram truncados: ao realizar a operação de deslocamento n << 64 em um valor n, ocorreu truncamento de dados devido ao deslocamento ultrapassar a largura de bits válida do tipo de dados uint256 (256 bits). A parte de overflow mais alta foi automaticamente descartada, levando a 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 aproximadamente inferior a 1, mas como foi arredondado para cima, o resultado final foi igual a 1, ou seja, o hacker só precisava adicionar 1 token para conseguir retirar uma grande liquidez.
③ Retirar liquidez
Realizar o reembolso do empréstimo relâmpago, mantendo lucros substanciais. No final, retirar um total de ativos de tokens 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 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 as características desta vulnerabilidade
A vulnerabilidade do Cetus tem três características:
Custo de reparo 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á restrita apenas ao Cetus e não está relacionada ao código SUI. A origem da vulnerabilidade está em uma verificação de condição de limite, e apenas duas linhas de código precisam ser modificadas para eliminar completamente o risco; após a conclusão da 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 funcionamento estável sem falhas há dois anos, o Cetus Protocol passou por várias auditorias, 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 com precisão intervalos de negociação, criando cenários extremamente raros que submetem uma liquidez muito alta, o que aciona uma lógica anômala, indicando que esse tipo de problema é difícil de ser detectado por 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 contratos inteligentes em termos de segurança de recursos e verificação de tipos, incorporando detecção nativa para problemas de estouro de inteiros em cenários comuns. Este estouro ocorreu porque, ao adicionar liquidez, foi utilizado um valor incorreto para a verificação do limite superior ao calcular a quantidade de tokens necessária, e a operação de deslocamento foi utilizada em vez da operação de multiplicação convencional. Se fossem utilizadas operações convencionais de adição, subtração, multiplicação ou divisão, o Move verificaria automaticamente a situação de estouro, evitando esse tipo de problema de truncamento de bits altos.
Vulnerabilidades semelhantes também ocorreram em outras linguagens (como Solidity e Rust), e eram até 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, ocorreram estouros em adição, subtração e multiplicação, 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 dentro do contrato, resultando em transferências excessivas para realizar ataques.
3. Mecanismo de consenso do 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 para DPoS)). Embora o mecanismo DPoS possa aumentar a capacidade de transação, ele não consegue oferecer um nível de descentralização tão alto quanto o PoW (Prova de Trabalho). Portanto, o nível de descentralização do SUI é relativamente baixo, com um limite de governança relativamente alto, tornando difícil para usuários comuns influenciarem 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 um nó por conta própria, basta que façam a aposta 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 diminuir a barreira de entrada 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 a rodada de blocos: um número limitado 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, reelecionando 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 controlado de nós de produção de blocos, a rede consegue completar a confirmação em milissegundos, satisfazendo a necessidade de alta TPS.
Baixo custo: Menos nós participando do consenso resultam em uma redução significativa na largura de banda da rede e nos recursos computacionais necessários para a sincronização de informações e agregação de assinaturas. Assim, os custos de hardware e de operação diminuem, e a exigência em relação ao poder de computação é 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 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 votos dos validadores cheguem a um consenso para confirmar a transação. Este mecanismo garante que, mesmo que um pequeno número de nós aja de forma maliciosa, a rede possa manter uma operação segura e 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, fazendo uma troca entre descentralização e eficiência. O DPoS, no triângulo "impossível" da segurança-descentralização-escabilidade, opta por reduzir o número de nós ativos de criação de blocos em troca de um desempenho mais elevado, abandonando um certo grau de total 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 nesta ataque
3.2.1 mecanismo de congelamento em operação
Neste evento, a SUI rapidamente congelou os endereços relacionados ao atacante.
Do ponto de vista do código, isso impede que 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 nível de consenso, um mecanismo semelhante ao de 'congelamento de conta' no setor financeiro tradicional.
O SUI possui um mecanismo de lista de rejeição (deny list) embutido, que é uma funcionalidade de lista negra 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. 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 reload a quente ou reiniciar o nó e atualizar a lista. À primeira vista, cada validador parece estar 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 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 adotam ou não------mas na prática a maioria das pessoas adotará automaticamente. Assim, embora esta funcionalidade proteja os fundos dos usuários, ela tem, de fato, 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; é mais como uma camada adicional de segurança para 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 "cadeia de segurança" presa à porta, que é ativada apenas para aqueles que desejam invadir a casa, ou seja, para aqueles que querem prejudicar o protocolo. Para os usuários, isso significa:
Para os grandes investidores, que são os principais provedores de liquidez, o protocolo deseja garantir a segurança dos fundos, pois na verdade os dados na cadeia tvl são todos contribuídos pelos principais investidores. Para que o protocolo se desenvolva a longo prazo, é imprescindível priorizar a segurança.
Para os investidores individuais, contribuintes da atividade ecológica, fortes apoiantes da construção conjunta de tecnologia e comunidade. O projeto também espera atrair investidores individuais para a construção conjunta,