contratos inteligentes中的ataque de negação de serviço

ataque de negação de serviço ( DoS ) pode levar a contratos inteligentes a ficarem indisponíveis por um período de tempo ou até permanentemente. As principais razões incluem:

1. A lógica do contrato tem falhas. Por exemplo, a implementação de algumas funções públicas não considera a complexidade computacional, o que pode ultrapassar o limite de Gas e levar à falha da transação.

2. No cenário de chamada entre contratos, a execução do contrato depende do estado do contrato externo. A execução do contrato externo pode ser não confiável e pode bloquear a execução deste contrato, como quando os fundos ficam bloqueados e não podem ser depositados ou retirados.

3. Fatores humanos, como a perda da chave privada pelo proprietário do contrato, que impedem a atualização do estado crítico do sistema.

Abaixo, analisaremos a vulnerabilidade de ataque de negação de serviço (DoS) com exemplos específicos.

1. Percorrendo estruturas de dados grandes que podem ser modificadas externamente

Segue um contrato simples para "distribuição de lucros" a usuários registrados:

O estado do contrato inclui uma lista de usuários registrados e um mapeamento de saldos de conta. Os usuários podem se registrar e inicializar através de register_account().

O administrador distribui dividendos aos usuários através do distribute_token(), percorrendo o array registered e transferindo um número específico de tokens para cada usuário.

O problema é que o tamanho de registered é ilimitado e pode ser manipulado maliciosamente, levando a um consumo de Gas excessivo durante a iteração que ultrapassa o limite.

Solução recomendada:

• Limitar o tamanho da estrutura de dados, garantindo que mesmo ao atingir o valor máximo não ultrapasse o limite de Gas
• Adotar o modo de retirada, primeiro registar, o usuário pode retirar a recompensa através de withdraw.

2. A dependência de estado entre contratos causa bloqueio

Considere um cenário de contrato de "licitação":

• Registar o actual licitador mais alto e o montante
• Os usuários podem registrar contas para participar da licitação
• Quando a oferta for superior ao preço mais alto atual, devolver o preço mais alto anterior e atualizar o estado

O problema é que o reembolso depende do estado do contrato externo. Se a conta do maior licitante anterior tiver sido cancelada, o reembolso falhará, levando à impossibilidade de atualizar o maior lance, bloqueando todo o processo de licitação.

Solução: Considerar que chamadas externas podem falhar, implementando um tratamento de erros razoável. Como armazenar temporariamente fundos que não podem ser devolvidos, permitindo posteriormente que o usuário os retire separadamente.

3. Chave privada do administrador perdida

Parte das funções-chave (, como pausar/reiniciar transações ), só podem ser chamadas pelo administrador. A perda da chave privada do administrador resultará na incapacidade de usar essas funções, e o contrato pode não funcionar corretamente a longo prazo.

Solução: Adotar um mecanismo de múltiplas assinaturas em vez de um único administrador, para implementar a governança descentralizada e evitar falhas de ponto único.