Как Æ предотвращает любимую схему хакеров на уровне протокола
Пример тогоб как повышение лимитов Ethereum предотвращает хаккерские атаки, которые на сегодняшний день принесли владельцам токенов ERC20 ущерб свыше нескольких миллионов.
Иногда неожиданные события приводят к катастрофическим последствиям. При разработке "умных" контрактов к хаосу не всегда приводит запутанный код или слабая логика. Иногда требуется что-то настолько простое, как арифметические вычисления с начальной школы: сложение, вычитание и умножение.
Возьмем к примеру наименьшее и наибольшее число (беззнаковые целые числа), которое могут быть представлены в Ethereum Virtual Machine (EVM) - 0 и 2²⁵⁶ — 1.
Несмотря на то, что с арифметической точки зрения они кажутся максимально удаленными друг от друга, для разработчиков они слишком близки: Вычитая 1 из первого числа или прибавляя 1 ко второму, вы получаете следующие результаты: 0–1 == 2²⁵⁶ — 1 и 2²⁵⁶ — 1 + 1 == 0.
Таким образом происходит выход за границы допустимых целочисленных значений.
Из-за ограничений EVM это типичная проблема для Ethereum. Разработчики вынужденны дополнительно осуществлять проверки, чтобы недопустить эти баги. И им далеко не всегда это удается, как вы сможете убедиться ниже.
Почему это важно?
В 2018 и последующие годы так называемая "ошибка batchOverflow" во многих контрактах Ethereum позволила хакерам генерировать токены из воздуха, тем самым серьезно вредя биржам и держателям токенов.
Ошибка batchOverflow означает, что хакер отправляет нескольким получателям большее колличество токенов, чем он владеет на самом деле. Используя при этом функцию контрактов по передачи токенов, которая на первый взгляд кажется вполне нормальной.
Как это работает?
Чтобы гарантировать, что отправитель не передаст больше токенов, чем у него есть, количество получателей умножается на стоимость токенов, которые должны быть переданы каждому из них.
Перевод большего числа в значение приводит к выходу за границы допустимых целочисленных значений, возвращая маленькое число. Теперь, для проверки безопасности в строке 17, видно, что происходит передача ограниченного количества токенов. Суммы, которую отправитель транзакции действительно может себе позволить.
После этой проверки, значение добавляется к балансу каждого получателя.
Et voilà - прибыль!
Почему это невозможно в Aeternity?
The Fast Æternity Transaction Engine (FATE) VM тип безопасного программирования, который не позволяет беззнаковым числам обернуться ниже 0 (читай: вычитание 1 из вашего токен-баланса 0 не делает вас миллионером).
В FATE также нет фиксированных верхних границ для чисел, то есть 2²⁵⁶ - 1 - не самое большое число. Единственными ограничениями для арифметических значений являются транзакционные издержки и, в конечном счете, хранение.
В примере выше хакер может попытаться отправить 2²⁵⁶ - 1 или большее колличество токенов X числу людей за одну транзакцию. Однако контракт не будет обманут и транзакция может быть осуществлена в том случае, если отправитель фактически владеет необходимой суммой.
Меньше лазеек для хакеров, меньше забот для разработчиков.