Desde agosto, o desenvolvimento do ecossistema SUI tem sido rápido. De acordo com DefiLlama, o TVL do SUI ultrapassou US$ 1 bilhão, um aumento de 200% nos últimos dois meses, e atualmente o volume de negociação do Cetus, um Dex construído no SUI, ultrapassa US$ 160 milhões por dia.

Em 9 de outubro, o USDC nativo da SUI entrou na mainnet, o que continuará a atrair mais fundos para o ecossistema da SUI. Como um membro importante do Ecossistema Move, a SUI está comprometida em fornecer serviços de transação rápidos e seguros para uma variedade de cenários de aplicação blockchain.

Neste artigo, a Beosin irá ajudá-lo a entender os desafios de segurança enfrentados pelos usuários e desenvolvedores do ecossistema SUI com anos de experiência em auditoria de segurança.

Segurança de Contrato

Sui usa o Move como sua linguagem de programação para contratos inteligentes. O Move foi projetado para ser uma linguagem de bytecode executável com algoritmos de segurança embutidos e verificador de bytecode, e usa chamadas estáticas ao chamar contratos.

Este design permite que o Move aborde vulnerabilidades comuns em contratos inteligentes, como ataques de reentrância, estouro de inteiros, gastos duplos e possíveis problemas de compilador, mas ainda é possível para os desenvolvedores introduzirem inadvertidamente vulnerabilidades no desenvolvimento do contrato. Em resposta, a Beosin introduziu o Move Lint em 2023, uma ferramenta de detecção estática que automatiza a detecção de possíveis riscos de segurança em contratos e localiza vulnerabilidades.

Além das ferramentas de detecção, as seguintes são questões de segurança às quais os desenvolvedores precisam prestar atenção adicional no desenvolvimento de contratos Move para melhorar a segurança:

1) Overflow de inteiro

Comparado com outras linguagens de contrato inteligente, o Move verifica automaticamente os problemas de overflow por padrão ao realizar operações matemáticas de números inteiros, o que pode prevenir um grande número de problemas de overflow, mas ainda há dois pontos a serem observados:

As operações de bits na linguagem Move não realizam automaticamente verificações de overflow porque as operações de bits são essencialmente operações em nível de bit em dados que se comportam de forma diferente das operações de inteiros.

Quando a verificação de overflow automática do Move entra em vigor, a execução da função lança uma exceção, o que, se mal projetado, pode fazer com que o negócio do projeto falhe em executar como esperado, resultando em ataques de DoS.

2) Controle de permissão e acesso

A passagem de objetos privilegiados e chamadas de função privilegiadas deve ser cuidadosamente autenticada, pois essas funções e objetos estão envolvidos na segurança do financiamento. Além disso, os tipos de objetos precisam ser verificados para determinar se são objetos privados ou compartilhados. Se um objeto for convertido incorretamente de um objeto privado para um objeto compartilhado, usuários não autorizados podem ser capazes de acessar o objeto, representando um potencial risco de segurança.

Os desenvolvedores podem usar o Move Prover para verificar se o programa está fazendo cumprir uma política explícita de controle de acesso. Por exemplo, em std.offer, podemos ver que a função é encerrada quando o destinatário não está na lista branca:

3) Problema de dependência da ordem da transação

Dependência da Ordem de Transação (TOD) refere-se ao fato de que o comportamento de um contrato pode ter resultados diferentes dependendo da ordem em que as transações são executadas, especialmente em um ambiente descentralizado onde o minerador ou verificador pode escolher como as transações são ordenadas. Isso pode trazer riscos como ataques de front-running.

Em Sui, ainda cabe ao produtor de blocos executar a ordem das transações, portanto, os contratos MOVE ainda podem ser afetados por esse problema se forem projetados para depender da ordem das transações para alterações de estado.

4) Problema de consumo de gás

Na cadeia Sui, o problema de gás dos contratos inteligentes do Move é principalmente refletido nos custos de cálculo e armazenamento necessários para a execução do contrato. Com o aumento da complexidade do contrato e das mudanças de estado, o consumo de gás também aumenta proporcionalmente. Os desenvolvedores precisam focar na otimização da lógica do contrato, reduzindo cálculos desnecessários e atualizações de status para reduzir os custos das transações para os usuários e, especialmente, evitar a situação de iterações incontroláveis no contrato, que podem ser devido a gás insuficiente e não ser capaz de realizar o negócio corretamente.

5) Precisão de cálculo

Atualmente, o tipo numérico suportado pelo Move é o inteiro sem sinal e não suporta ponto flutuante, portanto, a parte fracionária será truncada e arredondada para baixo durante as operações de divisão, o que resultará em resultados de cálculos imprecisos, o que pode afetar algumas políticas-chave, resultar em perda de receita e até mesmo se tornar uma vulnerabilidade de segurança.

Para este problema, a medida usual de mitigação é estender a precisão, mas deve-se notar que a precisão precisa ser restaurada quando o resultado final é obtido.

6) Gerenciamento de objetos

Nos contratos inteligentes Move na blockchain Sui, a gestão de objetos é um desafio chave, abrangendo múltiplos aspectos do ciclo de vida do objeto, propriedade, acesso concorrente, serialização e custos de armazenamento. Os desenvolvedores precisam gerenciar precisamente a criação, atualização e destruição de objetos para evitar o desperdício de recursos e a inconsistência de estado. Ao mesmo tempo, o design razoável da lógica do contrato para controlar a propriedade e os direitos de acesso de objetos, bem como lidar com múltiplos usuários acessando o mesmo objeto simultaneamente, são fatores importantes para garantir a operação segura e eficiente de contratos inteligentes.

7) Problemas de design e implementação de lógica de negócios

Por exemplo, com a implementação do empréstimo relâmpago no projeto Sui DeFi, os atacantes podem usar empréstimos relâmpago para realizar ataques de grandes fundos, como manipulação de preços.

Na função comum de troca de tokens AMM, os desenvolvedores podem usar o Move Prover para verificar se o número de tokens mudou corretamente:

Por exemplo, os protocolos de empréstimo devem sempre estar totalmente seguros após uma série de depósitos, empréstimos e saques. No caso de o livro de ordens do acordo de negociação de contratos perpétuos on-chain ser cancelado após a ordem ser feita, não deve haver mudanças no livro-razão, etc., que precisam ser verificados e confirmados pelo desenvolvedor.

Desafios no Ecossistema SUI

Atualmente, DeFi e Memecoins de SUI estão florescendo, e o volume de negociação e TVL têm atraído um crescimento explosivo. Posteriormente, há cada vez mais tipos de golpes e negociações de spam que os usuários precisam evitar.

Phishings

Este ano, apareceu um golpe de airdrop chamado Suisses no Sui Eco, que permitiu que muitos usuários tivessem seus ativos roubados. Quando um usuário se conecta a uma carteira no site Suisses e clica em Reivindicar, uma solicitação de transação para a transferência dos ativos do usuário aparece. Se o usuário assinar a transação, ele descobrirá que todos os ativos de sua carteira foram transferidos.

Devido às características do SUI: tudo é objeto, não apenas os tokens na carteira do usuário, NFT é objeto, mas também a participação do usuário em mineração DeFi, garantia de liquidez e outros certificados. Se ocorrer um ataque de phishing, todos os ativos de um usuário dentro do ecossistema SUI podem ser transferidos pelo hacker de uma só vez.

Fraudes de Token

Existem muitos tokens falsos e armadilhas no ecossistema Sui. Em particular, quando os usuários negociam memecoins no Ecossistema Sui, eles podem ser pegos acidentalmente.

Ao criar tokens na SUI, como mostrado abaixo, hackers podem definir os mesmos ícones e nomes que tokens populares ou principais, tornando-os indistinguíveis para usuários comuns. Portanto, os usuários precisam verificar se o formato de dados do token está correto ao comprar o token.

Além disso, os hackers também podem adicionar uma função DenyList ao contrato do token, para que os usuários que compram o token não possam vendê-lo, causando perdas aos usuários.

Desafio MEV

MEV significa valor máximo extraível. MEV originalmente referia-se a Valor Extraível pelo Minerador, onde os mineradores na rede BTC ganham recompensas além das taxas de bloco e de rede ao reordenar transações nos blocos. MEV não tem nada a ver com o tipo de rede blockchain. MEV existe em todas as blockchains, e Sui não é uma exceção.

Sui usa Narwhal como um pool de memória para atribuir transações inacabadas aos nós, e usa o algoritmo Bullshark como motor de consenso para classificar transações.

A regra de ordenação do SUI para transações é baseada em taxas de gás. Além disso, como o SUI adota um esquema de execução de transações combinando paralelo e sequencial, transações que compartilham o mesmo estado de pool de transações da AMM só podem ser executadas sequencialmente. Portanto, o ataque sanduíche / transação de frontrunning é viável. Um invasor pode lançar um ataque sanduíche através de uma taxa de gás mais alta, fazendo com que os usuários que participam de negociações DeFi sofram perdas.

Aviso legal:

1. Este artigo é reproduzido de [beosin]. Todos os direitos autorais pertencem ao autor original [beosin]. Se houver objeções a esta reimpressão, por favor, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe de aprendizado da gate. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.