Підсумки останньої зустрічі розробників ETH Workshop Core: Активуйте оновлення Cancun у тестовій мережі на початку січня 2024 року

Оригінальна назва: Ethereum All Core Developers ution Call #176 Запис

Оригінал статті Крістін Кім

Оригінальна компіляція: Luccy, BlockBeats

Примітка редактора:

Семінар ETH Усі основні конкурси консенсусу розробників (ACDE) проводяться кожні два тижні для обговорення та координації змін у ETH Рівні виконання семінарів (EL). Це 176-й телефонний дзвінок ACDE, і він охоплюватиме обговорення оновлення Cancun/Deneb, хід тестування Devnet #12 та план оновлення Prague/Electra.

Розробники обговорили, як тестування оновлення Cancun/Deneb на Devnet #12, включаючи прогрес і деякі проблеми, виявлені різними командами клієнтів, а також технічні проблеми з поширенням BLOB, MEV (максимальне значення, що видобувається) і багато іншого. Для майбутнього оновлення Prague/Electra розробники запропонували низку можливих технічних змін.

Крістін Кім, VP відділу досліджень Galaxy Digital, детально розповіла про основні моменти зустрічі, які BlockBeasts склали наступним чином:

7 грудня 2023 року ETH розробники зібралися на Zoom for All Core Developers ution (ACDE) call #176. Конференц-дзвінок ACDC – це серія зустрічей, що проводяться раз на два тижні під керівництвом Тіма Бейко, керівника відділу підтримки протоколів у ETH Foundation, де розробники обговорюють та координують зміни в виконавчому рівні (EL) ETH Place. Цього тижня розробники обговорювали тестування оновлення Cancun/Deneb на Devnet #12. Вони домовилися узгодити дату активації оновлення в тестовій мережі Goerli ETH початку січня після закінчення свята. Крім того, на початку січня планують розпочати обговорення того, які зміни коду мають бути включені до наступного оновлення ETH воркшопу Prague/Electra.

Оновлення Devnet #12

Тестування оновлення Cancun/Deneb на Devnet #12 проходить добре. Парітош Джаянті, DevOps-інженер у Фонді, розповів, що деякі помилки були виявлені у двох клієнтів, Reth і Lighthouse, і що дві клієнтські команди працюють над екстреним виправленням. Щоб ретельніше протестувати робочі процеси MEV, команди DevOps більше зосереджуються на включенні програмного забезпечення MEV-Boost на більшій кількості валідаторів на Devnet #12. За словами Джаянті, його команда знайшла принаймні одну помилку в реалізації ретрансляції MEV Flashbots. Денні Райан, дослідник ETH Foundation, підкреслив, що для того, щоб гарантувати, що валідатори можуть перейти на локальну збірку блоку в разі відмови реле, необхідне додаткове тестування для перевірки наявності альтернативних механізмів.

Теренс Цао (Terence Tsao), розробник клієнта Prysm, сказав, що його команда працює над оновленим дизайном для поширення ACDC #122中讨论的 BLOB. Цао підтвердив, що клієнт Prysm буде готовий приєднатися до Devnet #12 для тестування наступного тижня, можливо, наступного тижня. Джастін Флорентін, розробник клієнта Besu, заявив, що Besu готовий перейти з Devnet #12. Представники клієнтських команд Nethermind, Erigon, Lodestar і Teku також заявили, що готові продовжити тестування оновлення на публічній ETH тестовій мережі.

Виходячи з готовності клієнта, Beiko рекомендує узгодити дату хардфорка, як тільки розробники закінчать відпустку. Припускаючи, що в найближчі кілька тижнів після приєднання клієнта Prysm на Devnet #12 не буде виявлено серйозних помилок, Бейко заявляє, що активація Cancun/Deneb на Goerli, швидше за все, відбудеться приблизно в середині січня. Бен Едінгтон з команди Teku запитав розробників, чи впевнені вони в тому, що змінять кількість ляпок на блоці з двох до трьох. Райан пропонує додаткове тестування збільшених мішеней для ляпень під час масивного тіньового форку та активації Канкуна/Денеба на Ґерлі. Бейко підтвердила, що активація оновлення на Goerli стане «останнім значним випробуванням» трьох цілей ляпень на блок. За умови, що проблем не буде виявлено, розробники продовжуватимуть використовувати збільшену кількість BLOB-об’єктів для активації основної мережі.

В цілому, Бейко заявила, що розробники продовжать тестувати оновлення на Devnet #12 з цього моменту і до кінця свят. Команда DevOps планує запустити принаймні один тіньовий форк Goerli до кінця грудня в рамках підготовки до справжнього хардфорку Goerli в січні. Якщо розробники зберуться на Новий рік, то обговорять дату активації хардфорка Goerli.

Прапорці перевизначення конструктора

Далі Цао запитав команду клієнта про їхній прогрес у впровадженні прапорця перевизначення Builder. Прапорець перевизначення Builder — це нове логічне поле в оновленні Cancun, яке клієнт виконавчого рівня може використовувати, щоб вказати клієнту рівня консенсусу, що коли Builder виявляє цензурну активність, валідатор повинен повернутися до локальної генерації блоків, а не використовувати сторонній конструктор. Як підкреслює Цао, деталі впровадження щодо того, як виявити перевірку діяльності Builder, є суб’єктивними і навмисно залишені команді клієнта для проектування. Для отримання додаткової інформації про прапорці перевизначення Builder, будь ласка, зверніться до протоколів ACDC#112 та ACDE#165.

Розробник клієнтської команди Geth, який виступає під псевдонімом “Lightclient”, заявив, що його команда реалізувала прапор, але не буде об’єднувати його в офіційному релізі “найближчим часом”. Представники команд Besu та Nethermind заявили, що цей необов’язковий прапор ще не впроваджений у їхніх клієнтів. Цао підкреслив, що прапор може бути корисним інструментом, і найкраще впровадити його якомога раніше, щоб відбити бажання та відбиття бажання у стейкінг-пулів або операторів великих вузлів валідаторів брати участь у певних «іграх на час». Цао пояснив, що валідатори можуть заробити більше MEV (Maximum Extractable Value), затримуючи поширення блоку, і що після введення blobs після оновлення Cancun відбудеться затримка в поширенні блоку. Під час цих затримок валідатори можуть включити в блок більш вигідні транзакції MEV, що є неоптимальним для своєчасного поширення BLOB.

Підтверджуючи, що транзакціям BLOB доведеться конкурувати зі звичайними транзакціями, розробник під псевдонімом Prysm, який виступає під псевдонімом Potuz, додав: «Blobs повинні конкурувати не тільки з комісіями, але й із самою затримкою та всіма MEV, отриманими від затримки блоків. Розробляючи механізм комісії за ляпки, я думав, що це ринок, який не був заблокований або врахований. Цао сказав, що знову підніме це питання в Ethereum Research Discord для подальшого обговорення. Крім того, Райан виділив останню публікацію дослідників Ethereum Foundation Каспара Шварца-Шиллінга та Майка Нойдера про «ігри на час» на веб-сайті Ethresearch.

Хід виконання проекту

Далі Бейко поділилася трьома оновленнями, пов’язаними з процесом планування оновлення ETH Workshop. По-перше, як і в #123上讨论的那样 ACDC, Beiko створила документ Meta EIP для оновлення Cancun/Deneb, в якому перераховані всі ETH Пропозиції щодо вдосконалення (EIP), які були включені в Cancun/Deneb. Він був створений на GitHub з номером EIP 7569. Крім того, Beiko створила EIP 7568 як документ Meta EIP для всіх попередніх оновлень, і розробники не створили спеціального документа для відстеження списку EIP, включених до оновлення. EIP 7568 пов’язано зі специфікацією коду оновлення.

По-друге, Бейко оголосив, що створив нову гілку обговорення на веб-сайті Ethereum Magicians, щоб визначити наступне оновлення мережі, Prague/Electra. Він попросив розробників критично подумати про те, чи варто об’єднувати оновлення Execution Layer (EL) і Consensus Layer (CL) разом, як це зробили попередні два хардфорки. Активація певних змін коду, таких як EIP 7002, вимагатиме змін як для EL, так і для CL, тому оновлення Prague та Electra потрібно буде координувати. Однак для інших змін коду, таких як дерево Веркла, є спосіб переробити реалізацію, і потрібно лише оновити CL.

Райан зазначив, що розробники рівня консенсусу (CL), які працюють паралельно з деревом Веркла, також вносять зміни в код для підтримки вибірки доступності даних. Beiko радить розробникам не вдаватися в подробиці про всі EIP, які вони хочуть бачити в оновленні Prague/Electra, а краще переглянути всі зміни коду кандидатів під час свят і бути готовими серйозно обговорити їх у січні. Потуз погоджується, додаючи, що EIP, розроблений для вирішення зростаючої проблеми розміру набору валідаторів ETH був би важливою зміною коду в Празі/Електрі. Виходячи зі складності змін коду, Beiko рекомендує, щоб для певних EIP, таких як Verkle або вибірка доступності даних, розробники організовували спеціальні зустрічі після свят, щоб детально обговорити ці більші зміни протоколу.