Glamsterdam відкладено: Ethereum перевіряє ризики для смарт-контрактів на Hoodi

Тест Hoodi 26 жовтня скасовано, включно із запланованим лімітом газу в 200 мільйонів. Розробники вивчають пропозицію щодо переоцінки вартості стосовно контрактів, які вже перебувають у mainnet.

Ethereum скасував тест, який мав відбутися наступного понеділка. Повідомлення Ethereum Foundation від 22 жовтня зазначає, що Glamsterdam не активується на Hoodi о 17:42:48 UTC 26 жовтня, і нова епоха не встановлена. Супутнє збільшення ліміту газу до 200 мільйонів також вилучено з розкладу тестової мережі. Це відтермінування майбутньої конфігурації, а не скасування блоків, уже записаних Hoodi.

Розробники ухвалили рішення дослідити, як EIP-8037, зміна ціни створення нового стану Ethereum, взаємодіє з контрактами в mainnet. Фонд не заявив, що оновлення зламало mainnet. Він також не призначив дату для виробничого форку. Безпосередній операційний ризик стосується Hoodi: клієнти або користувацькі конфігурації, які досі містять старий час активації, можуть не погоджуватися з переглянутим розкладом. Глибше питання полягає в тому, як змінити вартість роботи всередині транзакції, не порушивши застосунки, які вбудували старі числа в код.

Форк Hoodi 26 жовтня знято з календаря

Оголошення Hoodi від 16 жовтня визначало епоху 132 352 і слот 4 235 264. Воно поєднувало зміни рівня виконання Amsterdam зі змінами рівня консенсусу Gloas та лімітом газу в 200 мільйонів. Нове повідомлення повністю замінює ці інструкції. Оператори повинні прочитати останні примітки до випуску для обох типів клієнтів; попередній випуск, описаний як сумісний із Glamsterdam, може все ще містити тепер скасовану активацію Hoodi.

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

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

Glamsterdam активовано на Sepolia 6 жовтня, де розробники протестували ліміт газу в 200 мільйонів. Успішний тест не вирішує, як EIP-8037 вплине на контракти, що вже працюють у mainnet. Репетицію Hoodi відкладено, поки розробники досліджують ці взаємодії, і дату заміни не оголошено.

Цього року послідовність змінювалася не один раз. Вересневий звіт про план Sepolia описував проблеми devnet та проблему реалізації EIP-8037 ще до того, як публічний тест відбувся. Ті попередні проблеми не є доказом тієї самої причини, що й жовтневе розслідування контрактів 22 жовтня. Вони показують, чому дати були умовними, оскільки команди клієнтів переходять від приватних випробувань до публічних мереж. Окремі занепокоєння щодо поведінки білдерів у тестових мережах стосуються іншої частини Glamsterdam і не повинні змішуватися з переоцінкою. Останнє повідомлення наводить одну конкретну причину паузи Hoodi: подальше дослідження взаємодії EIP-8037 з контрактами mainnet.

Чому створення стану коштує дорожче в пропозиції

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

Ілюстративна таблиця пропозиції встановлює компонент створення стану для нового облікового запису на рівні 183 600 газу порівняно з поточними 25 000; для нового слота сховища — 97 920 порівняно з 20 000; а для розгортання обсягом 24 кілобайти — 37 784 880 порівняно з 4 947 200. Таблиця не є універсальним прогнозом комісії в ETH, яку сплатить користувач. Вона ізолює компонент за запропонованою константою, з іншими витратами на виконання зверху, а остаточна вартість у валюті залежить від ціни газу на той момент. Масштаб зміни пояснює, чому контракти з жорсткими лімітами заслуговують на уважніший розгляд.

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

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

Шаблони transfer і send у Solidity історично передають стипендію в 2 300 газу. Багато команд уже відмовилися від покладання на цю стипендію, але розгорнуті контракти можуть залишатися в використанні роками. Фонд визначає фіксовані стипендії як одну з категорій ризику; він не стверджує, що кожен виклик, який їх використовує, зазнає невдачі. Одержувач, який виконує мало роботи, може залишатися в межах ліміту, тоді як контракт, який звертається до щойно переоціненого стану, може його перевищити. Тестування фактичних контрагентів важливіше, ніж вважати саму лише наявність назви функції доказом поломки.

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

Які контракти можуть зіткнутися з проблемами?

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

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

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

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

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

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

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

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

Гаманці, RPC та фабрики стикаються з різною роботою

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

Детерміновані фабрики розгортання становлять ще один вузький випадок. EIP-8037 обговорює фабрики, спочатку розміщені за стандартними адресами з використанням попередньо підписаних транзакцій із жорстко заданими лімітами газу. У новій мережі, яка приймає новий графік до існування фабрики, старе попередньо підписане розгортання могло б вичерпати газ. Пропозиція прямо зазначає, що вже розгорнуті екземпляри в існуючих мережах mainnet і layer 2 не зачіпаються цим конкретним сценарієм генезису. Повідомлення про цю застереження має значення: було б оманливим припускати, що кожна фабрика, вже використана в Ethereum, ось-ось зникне.

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

Цифри в EIP-8037 заслуговують на ще одне уточнення. Його приклад перетворює запропонований газ в ETH, використовуючи припущену базову комісію 0,08 gwei. Якщо базова комісія зміниться, ETH, сплачений за той самий газ, також зміниться. Розробник, який порівнює таблицю з наявним рахунком, повинен додати витрати на виконання та фактичні умови транзакції, а не подавати семиразову зміну вартості стану як семиразове збільшення повної оплати користувача. Мета пропозиції — призначити витрати ресурсам; остаточна комісія особи залежить від суміші цих ресурсів у транзакції.

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

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

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

Цифра 200 мільйонів була налаштуванням тестової мережі

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

Видалення графіка обмеження газу Hoodi зберігає компоненти відкладеного форку разом. Оператори не тестуватимуть заплановану вищу пропускну здатність під Glamsterdam у цій мережі наступного понеділка. Розробники все ще можуть використовувати Sepolia та спеціально створені devnet для дослідження наслідків переоцінки. Відсутня репетиція на Hoodi впливає на послідовність, у якій команди клієнтів можуть набувати впевненості перед вибором часу для mainnet, але Фонд не опублікував переглянутий графік виробництва.

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

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

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

Чому розробники вирішили зачекати

Процес Ethereum дозволяє командам клієнтів коригувати план перед активацією публічного тестнету. Рішення від 22 жовтня на All Core Devs Execution call 248 слідує за попередніми попередженнями та зверненнями до постраждалих розробників. Публічне повідомлення визначає сферу, що досліджується, але не публікує остаточну кількість контрактів під ризиком, нову версію EIP-8037 або дату, коли дослідження завершиться. Називати затримку підтвердженим дефектом у всіх розгорнутих контрактах означало б вийти за межі релізу; називати її рутинним переміщенням у календарі означало б проігнорувати зазначену причину.

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

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

Варто чітко окреслити сферу дії повідомлення для операторів. Звичайний власник на mainnet не потребує зміни гаманця через відкликання графіка Hoodi. Оператор вузла Hoodi, який готувався до форку, справді потребує перегляду приміток до випуску. Інженер протоколу, який досліджує EIP, повинен визначити, чи є поведінка контракту, виявлена під час відтворень, прийнятною, виправною за допомогою інструментів, чи причиною змінити пропозицію. Команда застосунку повинна тестувати власні маршрути виконання. Це різні аудиторії з різними дедлайнами, і єдине сповіщення «оновлення відкладено» не дає кожній із них правильну інструкцію.

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

Що передує іншій даті

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

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

Що відстежувати

• Релізи клієнтів: Оновлення виконання та консенсусу, які явно видаляють стару активацію Hoodi 26 жовтня.
• Результати EIP-8037: Нові результати повторного відтворення, зміни до запропонованих правил газу та обробка контрактів із жорстко закодованими лімітами або логікою gasleft().
• Заміна епохи: Датований план Hoodi, який відновлює тестовану конфігурацію після розслідування.
• Виправлення застосунків: Звіти від постраждалих розробників, які пояснюють, чи достатньо вищих лімітів, чи розгорнутому коду потрібен інший шлях.
• Повідомлення про mainnet: Окремий виробничий графік від Фонду після послідовності тестнету та координації клієнтів.

Часті запитання