В своём последнем отчёте об охоте за багами я обнаружил то, что выглядело как критическая ошибка округления в продукте с доходностью на основе траншей: при каждом выводе терялось 100,000,000,000 wei. Усечение накапливалось на двух уровнях преобразования. Черновик с уровнем серьёзности «Высокий» был готов к отправке. Но по моему правилу проверки нужно сначала воспроизвести проблему на форке основной сети, прежде чем верить каким-либо цифрам. И вот что выяснилось:
Мок-пул предполагал 18 десятичных знаков и делитель 1e30.
У настоящего токена 6 десятичных знаков, а делитель — 1e18.
Из-за этого несовпадения масштаба в 1e12 мок возвращал ноль при каждом выводе, поэтому потеря равнялась запрошенной сумме. Это была не ошибка протокола — сломался мой тестовый стенд. В основной сети реальная потеря составляла около 2–3 wei за вывод, что укладывалось в предусмотренный разработчиком бюджет округления в 100 wei. Так и задумано. Выводы:
Находка, подтверждённая только на моке, — это гипотеза, а не баг.
У uint256 нет единиц измерения: ошибка масштаба в 12 порядков компилируется без проблем и проходит все анализаторы.
Если заявленная вами «потеря» равна всей сумме, проблема в масштабе, а не в контракте.
Прежде чем определять уровень серьёзности, прочитайте комментарии разработчика о допустимой погрешности и epsilon. Результат: 0 отправленных отчётов, 4 кандидата отсеяны при проверке, один честно потраченный день и репутация не пострадала. Прежде чем отправлять очередной отчёт о «неограниченной потере из-за округления», прогоните одну единицу через реальный контракт в форке. Если ваша потеря укладывается в epsilon разработчика, у вас не находка — у вас проблема с моками.
#Web3Security #BugBounty #SmartContracts #solidity #CyberSecurity
(Безопасно для NDA: общий лог, без названий протоколов, адресов, репозиториев или действующих PoC.)
Читайте полный технический разбор в моём блоге (ссылка в первом комментарии) 👇