Автор: Крістін Кім, Galaxy Упорядник: Wu Baht, Golden Finance
12 вересня 2024 року розробники протоколу Ethereum зустрілися віртуально через Zoom для 196-ї конференції All-Core Developer Execution (ACDE). Цього тижня дзвінок провів Тім Бейко, керівник відділу підтримки протоколів Ethereum Foundation (EF). Конференц-дзвінок ACDE — це серія конференцій, які проводяться раз на два тижні, де розробники обговорюють і координують зміни рівня виконання Ethereum (EL).
На ACDE#196розробники поділилися останніми оновленнями щодо випуску Pectra Devnet 3 і обговорили різні зміни коду Pectra, які будуть реалізовані в майбутній мережі розробки. Вони серйозно обговорюють розділення оновлення на дві частини, щоб вони могли опублікувати зміни коду на Devnet 3 швидше, можливо, до лютого наступного року. Розробники погодилися прийняти остаточне рішення щодо цього під час наступного дзвінка ACD. І нарешті, операційний інженер розробника EF, який називається «pk910», поділився оновленнями щодо своєї роботи з очищення загальнодоступного репозиторію тестової мережі Ethereum GitHub і його реструктуризації, щоб полегшити використання.
Pectra Devnet 3
Інженер EF DevOps Парітош Джаянті пояснює випуск Pectra Devnet 3. Мережа розробки запускається в середу, 11 вересня. Він містить виправлення для об’єднання валідатора в EIP 7251 і оновлені специфікації для EIP 7702. Виходячи з поточного тестування на Devnet 3, EIP 7251 і EIP 7702, здається, працюють належним чином. Джаянті зазначив, що деякі проблеми були виявлені в клієнтах Nethermind і EthereumJS і що дві команди клієнтів наполегливо працюють над їх вирішенням. Джаянті додав, що оскільки EIP 7702 працює на Devnet 3, було б гарною ідеєю дозволити розробникам гаманців протестувати реалізацію та надати відгук про їхнє використання. Усю інформацію про Pectra Devnet 3, включаючи крани для запиту testnet ETH, можна знайти на цьому веб-сайті.
Оновлення специфікації Pectra
Розробник Geth Фелікс Ланге запропонував змінити кодування запитів тригерів EL у Pectra. Як фон, Pectra дозволить смарт-контрактам на EL ініціювати вилучення валідаторів і злиття на CL. Під час останнього виклику ACD Ланге поділився рекомендацією зменшити обсяг роботи, необхідний клієнтам EL для аналізу цих запитів. Після телефонної розмови минулого тижня Ланге формалізував свої рекомендації та роботу, яку має виконати команда клієнтів EL, щоб оновити кодування наступних чотирьох EIP:
EIP 7685, Generic Execution Layer Request;
EIP 7002, EL може ініціювати зняття;
EIP 6110, депозит валідатора поставок у мережі;
EIP 7251, збільшити максимальний ефективний баланс.
Розробники в цілому погоджуються з пропозицією Ланге. Однак розробник Nimbus, який називається «Дастін», вважає, що ця пропозиція є «безглуздо гнучкою» та не сумісною з майбутніми змінами у форматі серіалізації EL. Він також підкреслив, що необхідні додаткові специфікації, щоб чітко регламентувати порядок запитів від клієнтів EL і поведінку клієнтів CL, коли EL надсилає недійсні запити до CL. Ланге погодився додати більше тексту в API двигуна, щоб визначити порядок запитів. Він також погоджується з Дастіном, що слід більш детально розглянути поведінку клієнта CL, коли клієнт CL виявляє недійсний запит від клієнта EL.
Дослідник Ethereum Foundation Пітер Міллер зазначив, що, виходячи з логічної поведінки клієнтів CL згідно з поточною специфікацією, клієнти CL повинні відхиляти блоки з EL, які не впорядковані належним чином. Крім того, якщо є недійсні запити в списку, який EL надає CL, CL має просто обробити всі дійсні запити в списку та проігнорувати недійсні запити. Дастін погоджується з Міллером і рекомендує розробникам вказати таку поведінку у відповідній документації. Бейко сказав, що розробники повинні попрацювати над вирішенням проблем у пропозиції Ланге та завершити це до наступного виклику ACD.
Згодом розробник Erigon Ендрю Ашихмін запропонував оновити EIP 7702, налаштувавши коди облікових записів EOA. Він зазначив, що перевірки дійсності, зазначені в EIP, не узгоджуються з тими, що вказані в старому EIP. Розробник Geth Метт Гарнетт (він же «Lightclient») каже, що у нього є альтернатива для вирішення проблем узгодженості та спрощення перевірок EIP 7702. Розробники здебільшого виступають за доопрацювання пропозиції Lightclient і додавання її до Pectra Devnet 4.
Наступне обговорення, пов’язане з Pectra, стосується ціни попередньої компіляції BLS згідно з EIP 2537. Розробник Geth Джаред Васінгер сказав, що, виходячи з його порівняльного аналізу, попередня компіляція BLS має коштувати вдвічі дорожче, ніж зараз заявлено. Наразі вартість базується на багатопоточному виконанні, що не є стандартом, за яким оцінюються інші попередньо скомпільовані виконання. Таким чином, на основі свого аналізу з використанням однопотокового виконання, Васінгер рекомендував змінити таблицю знижок для операцій у EIP 2537. Команда Nethermind повідомляє, що вони розробляють інструмент, щоб інші команди клієнтів могли легко проводити власний порівняльний аналіз EIP. Бейко запропонував команді провести власні тести попередньої компіляції BLS і виробити ідеї щодо переоцінки цих операцій протягом наступних двох тижнів.
Доповнення Pectra EIP
Потім розробники почали обговорювати додавання нових EIP для оновлень Pectra. На початку обговорення Бейко попередив: «У нас уже є велика кількість EIP у Pectra. Це вже найбільший форк на сьогоднішній день з точки зору обсягу EIP». сказав: «Зрозуміло, що EIP 7742 (розділення кількості блоків між EL і CL) є найменш суперечливим у списку EIP, які все ще розглядаються для включення в оновлення.
Дослідник EF Алекс Стокс знову висунув ідею розділити Pectra на два менших хардфорка. «Я думаю, що всі погоджуються, що це дуже великий форк. Тому природно розділити його на дві частини. Як правило, менші форки менш ризиковані. Зокрема, Pectra тепер має багато міжшарових EIP, які дійсно збільшує навантаження на тестування, безпеку та перевірку», — сказав Стокс. Джаянті, який також підняв цю ідею під час попереднього дзвінка, сказав, що все ще підтримує цю ідею. «Я вважаю, що головна причина полягає в тому, що зараз у нас багато EIP, і ми схильні торкатися багатьох шарів стека, і чим більше ми додаємо, комусь одній людині важко мати загальне уявлення про всі зміни. , навіть за нинішнього навантаження", - сказав Джаянті.
Щодо того, як поточний EIP Pectra можна розділити на дві гілки, Стоукс запропонував використовувати всі EIP, які зараз працюють у мережі розробки, щоб випустити першу частину Pectra, а потім використовувати PeerDAS, EOF та кілька інших додаткових EIP, щоб випустити другу частину Пектра . Розробники впевнені, що завдяки цьому вони зможуть випустити першу частину Pectra до лютого наступного року. «Я думаю, що цей форк був би невдалим, якби ми все ще випускали лише першу половину в червні», — сказав дослідник EF Ансгар Дітріхс у чаті Zoom.
Beiko підтримує ідею розгалуження, але застерігає від видалення будь-яких EIP з мережі розробників, оскільки це може створити більше роботи для команд клієнтів і подовжити, а не скоротити, терміни підготовки цих змін коду для активації основної мережі. Данно Феррін, незалежний розробник протоколу Ethereum, запропонував завершити EIP на Devnet 3 якомога швидше, щоб активувати основну мережу, а потім працювати паралельно, починаючи з Devnet 4 або 5, щоб перенести PeerDAS і EOF на Pectra EIP. Насправді в оновленні після Pectra Devnet 4 або 5 стане Devnet 0, і розробники не знають, як його назвати.
У попередньому дзвінку розробники погодилися назвати оновлення на честь Pectra Fusaka, але вони також погодилися зарезервувати оновлення для переходу Verkle. На цій ноті Феррін порадив розробникам не робити попередніх замовлення на оновлення, доки вони не будуть впевнені, що зміни коду готові для активації основної мережі. Це викликало гнів розробника Geth Гійома Балета, який очолював роботу з переходу Verkle і наполягав, що перехід Verkle був готовий «давно». Щоб зменшити напруженість, Бейко сказав, що мета поділу Pectra на дві частини полягала в тому, щоб спробувати оприлюднити зміни коду Pectra у швидший термін, що допоможе розчистити шлях для наступного переходу Verkle.
Однак існує ризик того, що друга частина оновлення Pectra може стати більшою, оскільки додається більше EIP, і, отже, для випуску знадобиться більше часу, ніж для одночасного випуску поточного списку Pectra EIP. Розробник Nethermind Бен Адамс запитав, як працюватиме процес тестування Pectra, якщо оновлення розділити на дві частини. Враховуючи, що це рішення повністю змінить масштаби наступного негайного оновлення Ethereum, Бейко рекомендував розробникам витратити тиждень на розгляд цієї ідеї. Він попросив розробників підготуватися до прийняття остаточного рішення з цього питання під час консенсус-дзвінка для всіх основних розробників наступного четверга.
Вирівнювання структури конфігурації мережі
І останнє, але не менш важливе, інженер EF DevOps «pk910» поділився оновленою інформацією про свою роботу з очищення загальнодоступного репозиторію тестової мережі Ethereum GitHub і його реструктуризації для полегшення використання. Він попросив команду облікових записів перевірити конфігурацію вузла основної та тестової мережі Ethereum і додати будь-яку відсутню інформацію до відповідних сховищ.
