Смартконтрактні макси, ваш компілятор Solidity може тихо видалити запис, який вам знадобиться, і ви ніколи не побачите цього у своєму коді. Solidity 0.8.38 вийшла минулого четверга. Вона виправляє баг у оптимізаторі Yul, який був у кожному релізі з 0.8.19 по 0.8.37. Оптимізатор зберігає інформацію про те, що знаходиться в пам’яті та сховищі. Він використовує цю інформацію, щоб замінити завантаження значенням, яке вже відоме, та пропустити запис, який записує те, що вже є. Щоб визначити, чи можуть два адреси перекриватися, він описує кожну з них як базову змінну плюс зсув. Однакова база, різний зсув — отже, це повинні бути різні слоти. Ці описи кешувалися. Потім хтось змінював базову змінну. Оптимізатор не завжди це помічає. Тепер він порівнює адресу, побудовану зі старого значення, з адресою, побудованою з нового значення, якби вони мали спільну базу. Він вирішує, що вони різні, але під час виконання вони вказують на одне й те саме місце. Результат — застарілий запис. Пізніше завантаження може повернути старе значення. Запис, який вам знадобився, може бути видалений. Keccak256 над цим місцем може хешувати застарілі дані. Піддаються ризику лише коди, скомпільовані з увімкненим оптимізатором. З via-IR — будь-який код може стати жертвою, навіть без вбудованого асемблера. Зі стандартним старим конвеєром — лише деякі вбудовані асемблерні фрагменти та допоміжні функції компілятора. Незоптимізований код безпечний. Команда оцінила це як низький рівень серйозності, і вони зробили те, чого я бажав би від кожної команди компілятора: вони повторно скомпілювали всі підтверджені смартконтракти з бази даних Sourcify з увімкненим та вимкненим виправленням — байт-код у всіх випадках був ідентичним. Отже, це рідкісне явище. Рідкісне — не означає «ніколи», особливо якщо ваш код новий і ще не розгорнуто. Цей баг був виявлений через баг-бант Ethereum Foundation, а другий звіт показав, що його можна спровокувати навіть чистим Solidity-кодом без асемблера.