Смарт-контрактные мэксисы, Ваш компилятор Solidity мог тихо удалить запись, которая вам была нужна, и вы никогда не увидите этого в исходном коде. Solidity 0.8.38 вышла в прошлый четверг. Она исправляет ошибку в оптимизаторе Yul, присутствовавшую во всех версиях с 0.8.19 по 0.8.37. Оптимизатор ведёт учёт того, что находится в памяти и хранилище. Он использует эти данные, чтобы заменить загрузку значением, которое уже известно, и пропустить запись, которая сохраняет то, что уже есть. Чтобы определить, могут ли два адреса перекрываться, он описывает каждый из них как базовую переменную плюс смещение. Одинаковая база, разное смещение — значит, это разные слоты. Эти описания кэшировались. Затем кто-то переassign-ит базовую переменную. Оптимизатор не всегда это замечает. Теперь он сравнивает адрес, построенный по старому значению, с адресом, построенным по новому значению, как будто они имеют общую базу. Он решает, что они разные, но во время выполнения они указывают на одно и то же место. Результат — устаревшая запись. Поздняя загрузка может вернуть старое значение. Запись, которая вам была нужна, может быть удалена. Keccak256 над этим местом может хешировать устаревшие данные. Подвержены только коды, скомпилированные с включённым оптимизатором. С via-IR — любой код может столкнуться с этой ошибкой, даже без встроенной сборки. Со стандартной устаревшей цепочкой — только некоторые встроенные сборки и вспомогательные функции, генерируемые компилятором. Сборки без оптимизации безопасны. Команда оценивает её как низкую степень серьёзности, и они сделали то, чего я хотел бы видеть от каждой команды компиляторов: они повторно скомпилировали каждый подтверждённый контракт из базы данных Sourcify с исправлением и без него — байт-код у всех остался идентичным. Так что это редко. Редко — не значит никогда, особенно если ваш код свежий и ещё не развернут. Ошибка была обнаружена через баг-бонти Ethereum Foundation, и второй отчёт показал, что обычный Solidity без сборки тоже может её вызвать.