Аудит виявив проблеми: Ethereum відклала форк Hoodi для Glamsterdam

Розробники Ethereum призупинили форк тестової мережі Hoodi для Glamsterdam, поки вони опрацьовують висновки про те, як поводяться застосунки, коли транзакції не вистачає газу. Оновлення змінює спосіб, у який мережа стягує плату за деякі операції, що торкаються її стану або розширюють його, і аудитори виявили, що навіть контракти, написані до оновлення, можуть поводитися інакше за запропонованими правилами.

Розробники Ethereum мали форкнути Hoodi 26 жовтня. Вони відклали цей тест, і 6 листопада розробник Ethereum Foundation Маріус ван дер Вейден повідомив, що він залишається на паузі, поки розробники опрацьовували проблеми, виявлені під час перегляду газу.

Проблема зосереджена на деталі, з якою більшість людей стикаються лише тоді, коли транзакція зазнає невдачі. Контракти можуть викликати інші контракти й вирішувати, що робити, якщо ці виклики повертаються невдалими. Код, який ухвалює це рішення, може виглядати точно так само після оновлення, але йти іншим шляхом, оскільки мережа тепер по-іншому стягує плату за частини операції.

Ось чому оновлення, спрямоване на те, як Ethereum обліковує стан, стало питанням і для розробників застосунків, і для команд, які пишуть клієнти Ethereum. Обидві сторони мають знати, які старі припущення переживуть зміну.

Що Glamsterdam змінює щодо газу

EIP-8037 змінює те, як протокол обліковує операції, що створюють стан. Стан Ethereum включає записи, такі як сховище контракту. Зміна може зберігатися між транзакціями, тому її вартість має наслідки для вузлів, які підтримують ланцюг після завершення початкової транзакції. Пропозиція відокремлює облік деякого створення стану від звичайного газу виконання, з резервуаром, який можна використовувати для відповідних операцій.

EIP-8038 переоцінює операції, що звертаються до стану. Дві пропозиції впливають на різні частини шляху виконання. Контракт може зчитати значення, зробити зовнішній виклик і записати результат. Перегляд лише запропонованої ціни останнього запису пропускає вплив попередніх читань і викликів на бюджет, доступний, коли виконання до нього доходить.

Тому знайомий застосунок може давати інший результат, навіть коли користувач надає ті самі вхідні дані транзакції. Важливе питання полягає в тому, які відмінності відображають передбачену переоцінку, а які викривають припущення, на яке покладається клієнт або контракт.

Як невдалий виклик може змінити кінцевий результат

Розгляньмо контракт, який викликає другий контракт для виконання одного кроку в більшій операції. Якщо другий контракт зазнає невдачі, викликач може зупинити все або обробити збій і продовжити. Пакетний обробник може зафіксувати невдалий елемент і рухатися далі. Інший застосунок може очікувати, що вся операція буде відкочена, якщо невдалий виклик вичерпає достатньо газу.

Аналіз ChainSecurity описує, як новий облік може вплинути на цю відмінність. Ethereum вже обмежує, скільки газу викликач може передати далі за правилом EIP-150. Приблизно одна шістдесят четверта може залишитися у викликача у відповідному випадку. Питання в тому, скільки насправді має викликач у своєму розпорядженні після повернення виконання, і скільки коштує завершити інструкції на цьому шляху.

Припустімо, застосунок розглядає невдачу виклику як звичайний бізнес-результат. Якщо він має достатньо газу, щоб завершити обробник збою, він може записати результат або продовжити решту транзакції. Якщо він вичерпає газ під час цього, зовнішня транзакція буде відкочена. Ці результати залишають різні записи, хоча внутрішній виклик зазнав невдачі в обох випадках.

Аудитор також розглянув перевірки на основі gasleft(). Контракт може використовувати цю інструкцію, щоб порівняти свій залишковий бюджет виконання з жорстко заданим мінімумом. Поріг, відкалібрований за однією схемою, може стати поганим предиктором за іншої, особливо коли контракт стикається з операціями стану або пересилає газ на іншу адресу. Контракт не має автоматичного способу переглянути число, яке його розробник вбудував під час розгортання.

Що потрібно встановити аудиторам

Листопадове оновлення Фонду описує вісім припущень, що перебувають на розгляді. Є принаймні два різні питання для тестування. Клієнти, які впроваджують нові правила, повинні досягати однакового результату для даної транзакції. Оглядачі застосунків також повинні визначити випадки, коли цей спільний результат відрізняється від того, що очікують існуючі контракти.

Тест для першого питання може виконати ту саму транзакцію на кількох клієнтах і порівняти результати стану та газу. Тест для другого має слідувати власній логіці застосунку. Важливо, чи розглядає контракт невдалий зворотний виклик як сигнал продовжувати, чи записує він зміну стану перед викликом і чи може він відрізнити бізнес-відмову від виклику, який ніколи не мав достатньо газу.

Ці шляхи можуть бути легко пропущені в звичайному тесті розгортання. Типовий бюджет транзакції може провести виклик і його обробник через обидві схеми. Навмисно тісний бюджет може виявити різницю. Тому граничні тести повинні включати невдалі виклики та випадки, близькі до кількості газу, необхідної для входу або завершення обробника збою.

Що може показати Hoodi

Glamsterdam вже досяг тестової мережі Ethereum Sepolia, де розробники тестували ліміт у 200 мільйонів газу. Hoodi надав би розробникам ще одне спільне розгортання, у якому можна випробувати переглянуте оновлення.

Публічний форк тестової мережі дає командам клієнтів і операторам застосунків спільне середовище для запуску цих перевірок. Оператори можуть оновлювати клієнти за спільним графіком, порівнювати свої результати та тестувати інструменти відповідно до правил форку. Команди застосунків можуть перевірити, чи симуляція транзакцій і оцінка газу враховують ті самі зміни, які вони бачать під час виконання.

Успішний форк Hoodi дав би розробникам докази щодо версій і транзакцій, які вони тестували. Довгострокове питання полягає в тому, що роблять репрезентативні застосунки на межах своїх бюджетів газу. Нову дату форку буде легше оцінити разом із записом про те, які випадки було відтворено, що змінилося у відповідь і як команди це тестували.

Робота над газом відбувається паралельно з іншими виправленнями. Розробники Ethereum окремо переглянули специфікацію депозиту валідатора, поки тривав огляд газу Hoodi. Ці виправлення потребують власних тестів, оскільки вони впливають на іншу частину форку.

Наразі останнє оновлення розробників щодо газових ризиків дає причину для затримки і зазначає, що робота над Hegota триває. Воно залишає час наступного тесту Glamsterdam для подальшого рішення.

Як ліміти газу та витрати на стан поєднуються

Вищий ліміт газу блоку дає Ethereum більше простору для роботи в межах його системи обліку. Ціна, призначена окремій операції, визначає, яку частину цього простору займає операція. Тому зміна ліміту та зміна цін можуть впливати на різні частини однієї й тієї самої транзакції.

Деяка робота завершується разом із транзакцією. Створення стану відрізняється, оскільки дані можуть зберігатися, залишаючи операторам вузлів щось для зберігання та подальшої обробки. Новий слот зберігання, обліковий запис або контракт можуть додати до цього тягаря, навіть якщо застосунок, який їх створив, згодом отримує мало трафіку.

EIP-8037 змінює спосіб обліку вартості певного створення стану. EIP-8038 переоцінює доступ до стану, що може включати операції з записами, які вже існують. Транзакція, яка зчитує значення, викликає інший контракт і створює запис у сховищі, може зіткнутися з обома змінами протягом одного запуску.

Лише вищий ліміт блоку не вказує, чи коштуватиме ця послідовність більше чи менше. Він описує простір, доступний блоку в цілому. Шлях транзакції та ціна кожної операції визначають, чи вона зможе вкластися в газ, наданий відправником.

Ця відмінність була актуальною вже тоді, коли Sepolia почала тестувати Glamsterdam із лімітом газу 200 мільйонів. Тест показав, що розробники запускали в цій мережі. Затримка на Hoodi стосується того, чи готові правила для наступної тестової мережі, зокрема поведінки застосунків, які покладаються на попередні припущення щодо газу.

Вісім припущень, що перебувають на розгляді

Репозиторій аудитора Фонду Ethereum групує свої приклади за змінами цін операцій і змінами способу відстеження газу. Числа в репозиторії походять із закріпленої версії запропонованої специфікації й можуть змінитися, якщо пропозиції будуть переглянуті.

Перша група проблем стосується фіксованих лімітів і вартості завершення роботи після виклику. Розробники могли встановити ліміт газу для операції, яка тепер коштує більше. Резерв, призначений для оплати фінального запису, може більше не бути достатнім. В іншому випадку невелика частка, залишена викликачем, може бути достатньою для завершення шляху невдачі, який застосунок раніше очікував відкотити.

Зміни в обліку вносять інші можливості. Якщо окремий резервуар усе ще може фінансувати прийнятне створення стану, викликач може записати запис після невдалого виклику, навіть коли його звичайний бюджет виконання обмежений. Тоді кінцевий результат для викликача може залежати від того, які операції використовують цей окремий бюджет.

Очищення слота, створеного раніше в тій самій транзакції, може негайно повернути частину газу стану в переглянутій специфікації. Виклик, що відкочується, також може повертати газ стану. Тому код, написаний у припущенні, що весь газ, витрачений до відкату, зникає, може неправильно витлумачити те, що сталося.

Пара вимірювань gasleft() так само може дати неповне уявлення про вартість роботи. Контракт, який використовує різницю, щоб виставити комусь рахунок або розрахувати відшкодування, покладається на припущення про те, як газ змінюється між двома вимірюваннями. Стягнення, взяті з окремого пулу, і газ стану, повернутий під час виконання, можуть змінити це співвідношення.

Восьмий випадок стосується EIP-7702, який дозволяє обліковому запису авторизувати делегування коду контракту. Транзакція може бути включена, навіть якщо авторизація всередині неї не набула чинності через нестачу газу. Гаманець або сервіс, який використовує лише факт включення транзакції, щоб зробити висновок, що делегування спрацювало, може вважати незавершену дію завершеною.

У репозиторії зазначено, що багато висновків, отриманих його авторами, стосувалися фіксованих сум або резервів. Він просить розробників і аудиторів перевірити свої застосунки на прикладах і повідомляти про проблеми. Перелік визначає шаблони, які потребують перегляду. Він не означає, що кожен застосунок, який використовує один із цих шаблонів, зазнає збитків.

Як невдалий виклик все ще може залишити успішну транзакцію

Транзакція Ethereum може містити кілька викликів. Контракт може попросити інший контракт виконати крок, а потім вирішити, як реагувати на результат. Невдалий внутрішній виклик і невдала транзакція — це різні результати.

Пакетний обробник дає корисний приклад. Якщо один елемент зазнає невдачі, обробник може зафіксувати цю невдачу й перейти до наступного елемента. Якщо в нього закінчиться газ, перш ніж він зможе зафіксувати результат, зовнішня транзакція може відкотитися й скасувати попередні зміни. Той самий внутрішній збій, отже, залишає різний кінцевий стан залежно від того, що викликач може зробити після цього.

Інший застосунок може розглядати невдалий виклик як причину змінити, хто може подати запит або чи дозволено повторювати спробу. Якщо викликач може завершити шлях, який застосунок очікував відкотити, отриманий стан може зберегтися. Наслідок для безпеки залежить від того, що насправді фіксує завершений шлях.

Суб'єкт може мати можливість вибирати, скільки газу надає транзакція. Якщо ця особа може залишити достатньо газу для того, щоб зовнішній контракт увійшов у шлях, але замало для завершення внутрішнього виклику, збій можна спричинити бюджетом транзакції. Контракт, який діє на основі збою, повинен відрізняти цей випадок від виклику, який досяг викликаного й законно зазнав невдачі.

Ліміт пересилання EIP-150 є однією з частин цього. Викликач, який пересилає стільки газу, скільки дозволено, зберігає приблизно одну шістдесят четверту згідно з відповідним правилом. Збережена сума все ще повинна оплачувати інструкції, що йдуть далі. Чи завершаться ці інструкції, залежить від розкладу та обліку, застосованого до них.

Контракт може бути вразливим до вузького діапазону бюджетів. Дайте внутрішньому виклику достатньо газу — і він працює нормально. Дайте всій транзакції замало — і зовнішній шлях відкотиться. Проблемний інтервал — це коли внутрішній виклик зазнає невдачі, але у викликача все ще достатньо газу, щоб виконати дію, яку розробник не передбачав для цього збою.

Чому зміна фіксованого числа газу може не вирішити проблему

Жорстко закодований поріг може дати контракту простий спосіб перевірити, що в нього достатньо газу перед викликом. Розробник міг перевірити поріг на звичайних транзакціях і залишити запас для роботи, що йде далі. Число стає залежністю від розкладу, за якого його було обрано.

Операція також може коштувати різні суми залежно від того, чи застосунок оновлює наявний запис, чи створює новий. Переказ комусь, хто вже має баланс, може натрапити на інший шлях зберігання, ніж переказ, який створює перший баланс. Тест, який охоплює лише повторних одержувачів, може пропустити дорожчий шлях.

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

Зміна стипендії може мати власні наслідки. Вона може дозволити завершити шлях, який раніше зазнавав невдачі, а також може дати викликаному достатньо газу для виконання роботи, яку він не міг виконати за старої квоти. Розробнику потрібно знати, що квота мала запобігти, перш ніж коригувати її.

Деякі контракти можна змінити через процес управління або адміністрування. Інші є незмінними або залежать від компонентів, які не можна змінити на місці. Навіть коли контракт можна переглянути, сервіси, які оцінюють, спонсорують або передають його транзакції, також можуть потребувати оновлення власних припущень.

Що має показати переконливе відтворення

Тест може починатися з тієї самої транзакції, стану та ліміту газу за старими й запропонованими правилами. Порівняння має визначити, який виклик повертає збій, що викликач робить далі й чи фіксує транзакція якісь зміни, які раніше не зберігалися.

Тестування бюджетів трохи вище й трохи нижче порогу допомагає показати, чи ефект займає вузький діапазон. Воно також може визначити, де виконання розходиться. Рання перевірка балансу, сума, переслана викликаному, і запис в обробнику збою — це різні точки, у яких може проявитися зміна.

Потім рецензент має запитати, хто може досягти цього шляху. Зміна, відтворена в тестовому контракті, встановлює різницю у виконанні. Реальний застосунок може вимагати авторизації, перевіряти окрему умову або робити постраждалу операцію повторюваною. Ці деталі визначають, чи може хтось спричинити небажаний результат.

Існує також окремий тест для клієнтських команд. Усі клієнти виконання повинні досягати однакового результату для транзакції за однакової конфігурації форку. Розбіжність між клієнтами — це інша проблема, ніж ситуація, коли всі клієнти послідовно видають результат, якого застосунок не передбачав.

Набір тестів потребує як успішних шляхів, так і збоїв. Примусовий відкат кожного невдалого виклику може запобігти одній небажаній зміні стану, але також позбавити законної можливості завершити решту пакета. Запланована поведінка застосунку визначає, що виправлення повинно зберегти.

Хороше відтворення повинно робити кінцевий стан легким для перевірки. Якщо запис про збій залишається після одного запуску і зникає після іншого, тест може показати точну різницю, а не покладатися на загальний звіт про використання газу. Це полегшує оцінку як ризику, так і запропонованої зміни.

Що додають публічні тестові мережі після локального відтворення

Розробник може перевірити граничний випадок на локальному форку або в контрольованому клієнтському середовищі. Публічна тестова мережа потім дозволяє кільком операторам запустити те саме оновлення і порівняти його поведінку в спільних умовах. Вона також дає командам гаманців та інфраструктури місце для тестування власного програмного забезпечення проти активних правил.

Sepolia та Hoodi відіграють різні ролі в цьому процесі. Активація Sepolia показала, що розробники можуть запустити запланований код у цій мережі та дослідити його роботу в межах налаштованого ліміту газу. Hoodi дає їм подальше розгортання після врахування висновків, які стали важливими під час перегляду.

Застосунки, трафік та історичний стан у тестовій мережі відрізняються від головної мережі. Плавний форк може дати свідчення про узгодженість клієнтів і рутинні транзакції, не перевіряючи кожен шаблон контракту, на який покладаються користувачі. Цільове відтворення надає свідчення про граничний випадок, який може бути відсутнім у звичайному трафіку тестової мережі.

Інструкції з оновлення є ще однією частиною тесту. Оператору потрібен випуск, який реалізує заплановану конфігурацію, і точна точка активації. Застосунку потрібно знати, коли його симуляції повинні почати використовувати переглянуті правила. Нова дата корисна поряд із цими деталями.

Жовтневе відтермінування та листопадовий звіт про статус описують одну й ту саму затримку в різний час. Перше скасувало заплановану дату для Hoodi. Другий пояснив, що проблеми все ще потрібно вирішити. Наступне повідомлення про розгортання може показати, які зміни готові для тестування операторами.

Як гаманці можуть повідомляти про успіх, коли дія зазнає невдачі

Гаманці зазвичай оцінюють газ перед тим, як попросити користувача підписати. Оцінка залежить від стану та правил, які вузол застосовує у своїй симуляції. Сервіс, що використовує старішу конфігурацію форку, може дати оцінку, яка більше не підходить для транзакції, яку виконує поточний ланцюг.

Транзакція, що відкочується, все одно може коштувати відправнику газу. Зовнішня транзакція, яка завершується після перехоплення внутрішнього збою, може бути складнішою для інтерпретації. Ланцюг може записати загальну транзакцію як успішну, тоді як дія всередині неї не відбулася. Гаманець може потребувати подій або стану застосунку, щоб пояснити користувачеві різницю.

Релеєри та спонсори транзакцій стикаються з пов'язаною проблемою. Вони можуть обирати бюджет або оплачувати витрати за транзакцію, яку хтось інший запитує. Якщо бюджет більше не покриває запланований шлях, спонсор може оплатити виконання, яке не виконує запитану дію.

Індексатори можуть побачити ефект після виконання. Шлях збою, який тепер завершується, може створювати логи або зміни стану, яких downstream-система раніше не бачила. Індексатор все одно слідує фактичному стану ланцюга. Застосунок, який покладається на індексатор, може потребувати зміни того, як він інтерпретує отриманий запис.

Наскрізний тест може порівняти оцінку гаманця, поданий бюджет релеєра, результат виконання клієнта та пояснення інтерфейсу. Кожен крок може бути успішним сам по собі, тоді як користувач все ще отримує оманливий звіт про те, які дії набули чинності. Ця відмінність найважливіша там, де застосунок вважає результат остаточним.

Що могло б вирішити затримку Hoodi

Фонд просить команди застосунків визначити припущення, які вони використовують, і надати випадки, які розробники можуть відтворити. Деякі проблеми можуть бути вирішені через зміни в запропонованих правилах газу. Інші можуть вимагати від застосунку або постачальника інфраструктури переглянути те, як він обробляє нову поведінку.

Якщо специфікації зміняться, відповідним тестом є те, чи випадок, який раніше розходився, тепер досягає запланованого результату. Якщо розробники збережуть зміну поведінки, командам застосунків потрібно достатньо деталей, щоб визначити, чи їхнє програмне забезпечення покладається на попередній результат. Обидва результати залежать від опису ураженого виклику та того, що зберігається після нього.

Переглянута специфікація також має дійти до клієнтських збірок, які запускають оператори. Збірка, що підтримувала попередню конфігурацію Glamsterdam, може не містити подальших змін. Номери випусків у новому повідомленні Hoodi вказували б, які версії можна тестувати разом.

Листопадове оновлення Фонду зазначає, що робота над Hegota триває паралельно. Це означає, що призупинення попереднього форку не враховує кожного рішення щодо розробки наступного. Для Glamsterdam наступною важливою віхою є переглянутий графік Hoodi з конфігурацією, яку розробники готові запускати публічно.

Успішний форк дав би командам спільний запис для вивчення перед рішенням щодо mainnet. Випадки, що спричинили затримку, залишаються найяснішими тестами того, чи готові переглянуті правила. Ці тести мають показати, що відбувається, коли виклик зазнає невдачі близько до своєї межі газу, а зовнішня транзакція все ще має роботу, яку потрібно виконати.

Що запропоновані показники газу показують про різні шляхи

Репозиторій Фонду наводить конкретний приклад різниці між створенням стану та його оновленням. Згідно з його закріпленою специфікацією Glamsterdam, холодний запис, що створює новий слот, розподіляється між витратами на виконання та значно більшою платою за стан. Запис до наявного слота також переоцінюється, але за іншим розрахунком.

Різниця може торкнутися двох користувачів, які роблять, здавалося б, однаковий запит до застосунку. Один користувач міг раніше користуватися сервісом, тож контракт оновлює наявний запис. Іншому може знадобитися новий запис. Дозвіл на газ, що підходить для першого користувача, може не спрацювати для другого.

Репозиторій також зазначає, що окремий резервуар доступний лише понад вказану межу газу транзакції в конфігурації, яку він тестував. У менших транзакціях витрати на стан натомість беруться зі звичайного бюджету. Цей поріг робить важливим тестування кількох бюджетів, а не припущення, що резервуар поводиться однаково для кожного виклику.

Код, який зчитує залишок газу, таким чином може в деяких випадках спостерігати лише частину ресурсів транзакції. Дані, які він зчитує, все ще мають значення для бюджету, який відкриває інструкція. Що змінюється, так це висновок, який застосунок може зробити про загальні ресурси, що були використані або залишаються доступними.

Приклади з газом прив'язані до запропонованої конфігурації. Вони не дають єдиного множника, який можна застосувати до наявних оцінок гаманця. Перший запис у сховище, виклик із фіксованою стипендією та невдала делегація кожен потребують окремої перевірки, оскільки вони стикаються з різними частинами правил.

Ось чому переглянута дата Hoodi була б кориснішою разом із переглядом специфікації та переліком випадків, охоплених випуском. Ці деталі дозволили б командам повторно запустити тести, що відповідають їхнім застосункам, перш ніж робити висновки із загальної стабільності тестової мережі.

На що звернути увагу

• Розклад Hoodi: Переглянута дата форку має визначити версії клієнтів і конфігурацію форку, яку оператори мають запускати.
• Узгодженість клієнтів: Міжклієнтські тести можуть показати, чи клієнти виконання досягають однакового стану та результатів газу навколо нових меж.
• Поведінка контрактів: Відтворення мають показати, коли невдалий зовнішній виклик залишає викликачу достатньо газу для завершення та що записує зовнішня транзакція.
• Перегляд пропозицій: Зміни до EIP-8037 або EIP-8038 допоможуть показати, які результати перевірки вимагали зміни протоколу.
• Інструменти застосунків: Результати симуляції та оцінки газу можуть показати, чи гаманці та постачальники інфраструктури правильно відображають правила форку.

Поширені запитання