смарт-контракты中的атака типа «отказ в обслуживании»

атака типа «отказ в обслуживании» ( DoS ) может привести к тому, что смарт-контракты не будут функционировать должным образом в течение определенного времени или даже навсегда. Основные причины включают:

1. Логика контракта имеет недостатки. Например, некоторые реализации public функций не учитывают вычислительную сложность, что может привести к превышению ограничения Gas и, как следствие, к сбою транзакции.

2. В сценах межконтрактного вызова выполнение контракта зависит от состояния внешнего контракта. Ненадежное выполнение внешнего контракта может заблокировать работу данного контракта, например, средства могут быть заблокированы и не подлежат пополнению или выводу.

3. Человеческий фактор, например, потеря владельцем контракта закрытого ключа, приводит к тому, что ключевое состояние системы не может быть обновлено.

Ниже рассмотрим уязвимости атаки типа «отказ в обслуживании» на конкретных примерах.

1. Циклический обход больших данных, которые могут быть изменены извне

Вот простой контракт для "распределения дивидендов" зарегистрированным пользователям:

Состояние контракта включает список зарегистрированных пользователей и отображение баланса счетов. Пользователи могут зарегистрироваться и инициализировать через register_account().

Менеджер распределяет дивиденды пользователям через distribute_token(), обходя массив registered и переводя каждому пользователю указанное количество токенов.

Проблема заключается в том, что размер зарегистрированных данных не ограничен и может быть злоупотреблен, что приводит к чрезмерному потреблению газа при переборе, превышающему лимит.

Рекомендуемое решение:

• Ограничить размер структуры данных, чтобы гарантировать, что даже при достижении максимального значения не будет превышен лимит Gas
• Используйте режим вывода, сначала ведите учет, пользователи могут самостоятельно забрать вознаграждение через withdraw.

!

2. Зависимость состояния между смарт-контрактами приводит к блокировке

Рассмотрим сценарий контракта "торги":

• Записать текущего высшего ставщика и сумму
• Пользователи могут зарегистрировать учетную запись для участия в торгах
• При ставке выше текущей максимальной цены, вернуть предыдущую максимальную цену, обновить состояние

Проблема в том, что возврат средств зависит от состояния внешнего контракта. Если аккаунт предыдущего самого высокого ставщика был закрыт, возврат средств потерпит неудачу, что приведет к невозможности обновить самую высокую цену, и весь процесс аукциона будет заблокирован.

Решение: Учитывайте, что внешние вызовы могут завершиться неудачей, реализуйте разумную обработку ошибок. Например, временно храните средства, которые нельзя вернуть, и затем разрешите пользователю отдельно их выводить.

!

3. Потеря приватного ключа администратора

Некоторые ключевые функции (, такие как приостановка/перезапуск торговли ), могут вызываться только администратором. Утрата приватного ключа администратора приведет к невозможности использования этих функций, и смарт-контракты могут долгое время не функционировать должным образом.

Решение: Использование механизма мультиподписей вместо единого администратора для достижения децентрализованного управления и избежания единой точки отказа.