Підсумки останньої зустрічі основних розробників ETH Місце проведення: запущено Devnet 12 та модернізовано процес планування оновлень

Оригінальна назва: Консенсус усіх основних розробників Ethereum #123

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

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

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

Семінар ETH Усі основні конкурси консенсусу розробників (ACDC) проводяться раз на два тижні для обговорення та координації змін у Рівні консенсусу (CL) ETH Workshop. Це 123-й телефонний дзвінок ACDC, який був зосереджений на оцінці оновлень тестів Cancun/Deneb та Devnet #12, а також на вирішенні проблем виходу з валідатора, які виникли в Devnet #11. Крім того, розробники провели поглиблену дискусію щодо уточнення специфікацій мережі, процесу планування оновлення та статусу EIP.

Під час обговорення Cancun/Deneb розробники зробили акцент на стабільності та обговорили, чи варто запускати тіньовий форк Goerli. Однак, оскільки клієнт Prysm не був готовий до тестування, було вирішено дочекатися його готовності. Обговорення інструментів тестування та реструктуризації ланцюга підкреслили необхідність більш повного охоплення тестами та надали рекомендації щодо використання наборів тестів Hive та Kurtosis. У питанні статусу EIP та CFI міток Beiko висловила занепокоєння щодо того, чи слід зберігати ці теги, і розробники ще не досягли чіткого консенсусу з цього питання.

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

30 листопада 2023 року ETH розробники зібралися в Zoom на сесію All Core Developers Consensus (ACDC) #122. Конференц-дзвінок ACDC – це серія зустрічей, що проводяться раз на два тижні під керівництвом Денні Райана, дослідника ETH Workshop Foundation, де розробники обговорюють та координують зміни до ETH Рівня консенсусу семінарів (CL). Цього тижня розробники зосередилися на останніх розробках у тестуванні Канкуна/Денеба, зокрема:

· Запуск Devnet #12: Триває тестування клієнтського програмного забезпечення Teku, Lodestar та Lighthouse, а також усього клієнтського програмного забезпечення виконавчого рівня (EL) на Devnet #12. Команда Prysm очікує, що їхнє програмне забезпечення буде готове до тестування протягом двох-трьох тижнів на останньому Devnet.

· Проблема виходу з валідатора на Devnet #11: На Devnet #11 розробники виявили проблему, пов’язану з виходом валідатора, яка в даний час вирішується клієнтською командою Nimbus. Devnet #11 продовжуватиме нормально функціонувати, доки проблема не буде вирішена.

· Уточнення специфікації мережі: Розробники обговорили уточнення специфікації для запитів «BlockByRoot» і «BlobSidecarsByRoot», уточнивши, чи повинні вузли рівня консенсусу (CL) відповідати на ці запити в певному порядку.

На додаток до оновлення Cancun/Deneb, розробники обговорили деякі питання процесу, підняті Тімом Бейко, керівником відділу підтримки протоколів Фонду ETH, для покращення координації оновлення ETH Workshop.

Devnet #12

У середу, 30 листопада 2023 року, оновлення Cancun/Deneb було офіційно запущено на Devnet #12. Маріо Вега (Mario Vega) з команди тестування ETH Foundation сказав, що «на сьогоднішній день не було виявлено жодних серйозних проблем» у трьох клієнтах CL, які зараз працюють у тестовій мережі. Барнабас Буса, DevOps-інженер у Фонді, зазначив, що загалом існує 225 валідаторів, розподілених на трьох вузлах між Lighthouse, Teku та Lodestar. У зв’язку зі стабільністю Devnet #12, Парітош Джаянті, DevOps-інженер у Фонді, запитав розробників, чи варто їм почати планувати тіньовий форк Goerli для подальшого тестування Cancun/Deneb. Однак, враховуючи, що Prysm, найпопулярніший клієнт CL на даний момент, ще не приєднався до Devnet #12, розробники вирішили призупинити плани щодо тіньового форку Goerli до тих пір, поки клієнтське програмне забезпечення Prysm не буде готове до тестування. Бейко пропонує рухатися на тіньовій розвилці Goerli десь до кінця року. У зв’язку зі стабільністю Devnet #12, плани призупиняються до тих пір, поки клієнтське програмне забезпечення Prysm не буде готове до тестування.

Devnet #11

Розробник Nimbus, відомий під псевдонімом “Дастін”, ділиться подробицями проблеми Devnet #11, над якою працює його команда. Ці проблеми були вперше виявлені, коли розробники вийшли з однієї третини валідаторів Devnet #11 для використання в Devnet #12. Раян запитує Дастіна, чи може він виявити ці проблеми за допомогою додаткового тестування. Дастін відповів, що, на його думку, природа цих помилок була викликана деталями реалізації, що виходять за рамки специфікації консенсусу. Однак він також визнає, що існує «явна напруга» між написанням клієнтського програмного забезпечення строго за специфікацією CL, щоб перевірити переваги покриття, і проникненням у сірі зони специфікації з метою досягнення кращої продуктивності вузлів.

«Я кажу, що більше тестування – це завжди добре, але більш систематично з’ясовувати, як включити більше функцій на стороні клієнта в запуск тестів, можливо, більше автоматизації, будь то використання Hive, Kurtosis або чогось ще. Якщо ці проблеми можуть бути вирішені або речі можуть бути розбиті досить добре, щоб мати можливість включити більше цих завдань, я думаю, що це, безумовно, було б корисно», — додав Дастін, додавши, що ще одна проблема, яку розробники CL повинні розглянути для вирішення, полягає в тому, щоб з’ясувати рівень деталізації, на якому специфікація CL повинна диктувати та стандартизувати поведінку вузлів. «Іншою проблемою тут є ступінь стандартизації, яка насправді є не просто питанням програмної інженерії, наскільки стандартизованою має бути поведінка?» — запитав Дастін. Всі клієнти CL тестуються для перевірки базової поведінки, але поведінка, що виходить за рамки цих тестів, неоднозначна. "Це навмисно розпливчасті речі? Що дійсно має бути чітко визначено специфікацією, а що має бути навмисно незрозумілим?» — запитав Дастін.

Принаймні, розробники погодилися додати більше тестів до майбутніх Devnet та тестнетів для великої кількості виходів валідаторів у Канкуні/Денебі. Райан також визнає, що є простір для більш суворого та всебічного охоплення тестуванням, коли справа доходить до клієнтів CL та впровадження специфікації CL. Вега запропонувала Дастіну створити пост на HackMD, в якому детально описав свої занепокоєння та обговорити цю тему під час наступного тестового дзвінка в Канкуні/Денебі. Джаянті додав, що, виходячи з деяких проблем, нещодавно виявлених у Cancun/Deneb Devnets, розробникам існує чітка потреба в інструментах, які можуть систематично виконувати певну кількість поведінки, пов’язаної з інтеграцією в ланцюжку, наприклад, стейкінг ETH зняття коштів, зняття коштів валідаторами тощо. Для цього Джаянті рекомендує використовувати суміш наборів тестів Hive і Kurtosis для створення такого інструменту.

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

Уточнення специфікації мережі

Розробники коротко обговорили відкритий запит на пул, запропонований Джастіном Траглія, дослідником з ETH Foundation, щодо порядку відповідей, які клієнти CL повинні повертати при отриманні запиту “BlockbyRoot” або “BlobSidecarsByRoot”. Райан запитує, як різні команди клієнтів CL вже впроваджують цю функцію. Ніхто з розробників на дзвінку не відповів на це питання. Райан запропонував відновити дискусію на каналі Discord ETH Research & Development, щоб залучити ширше коло розробників-клієнтів. Райан визнає, що в специфікаціях двох запитів є неясності, які «можуть бути причиною проблем і дивних крайніх випадків» і «заслуговують на те, щоб бути проясненими та розібраними», стверджує Райан.

Райан також зазначив, що випустить нову версію специфікації CL у найближчі кілька днів. Остання версія значно додає специфікацію того, коли клієнт CL може надавати блоки та блоки через RPC-запит “byRoot”. Для отримання додаткової інформації про те, як отримати відсутні фрагменти та фрагменти за допомогою RPC-запитів “byRoot”, будь ласка, зверніться до попереднього журналу викликів. Райан підкреслює, що нові доповнення до специфікації CL, включені в останню версію, не матимуть жодних несумісних змін у коді, які вплинуть на код валідаторів, які вже працюють на Devnet #11 або #12.

Процес планування оновлення

Далі розробники обговорили різні елементи процесу, запропоновані Beiko. За словами Бейко, повідомлення в блозі, що попереджає користувачів тестової мережі Goerli про майбутнє припинення підтримки протягом 3 місяців після активації оновлення Cancun/Deneb на Goerli, або протягом 1 місяця після активації оновлення в основній мережі ETH, залежно від того, що настане пізніше, буде опубліковано в блозі ETH Foundation 30 листопада. Після завершення конкурсу вищезазначена публікація в блозі була опублікована, і її можна прочитати тут.

Beiko рекомендує створити спеціальну папку для оновлення в репозиторії ETH “pm”, щоб організувати різні файли, пов’язані з певним оновленням, в одну папку для подальшого використання. Розробники під час дзвінка погодилися з пропозицією Beiko.

Другим пунктом процесу, запропонованим Beiko, було створення документа «Meta EIP» для відстеження повного обсягу оновлень мережі, які були завершені на ETH. «Немає хорошого місця, щоб відстежувати повний обсяг оновлення мережі, перш ніж розгорнути та оголосити про це в дописі в блозі», — написав Бейко в дописі про свою пропозицію Meta EIP. «Для Dencun у нас є EL EIP у важкодоступному файлі Markdown 7, а CL EIP є частиною специфікації Beacon Chain Specification 3. Це не дуже добре, оскільки обидва трохи важко знайти, кожен з них використовує різний «формат», що призводить до дублювання. Оскільки ERC та EIP тепер розділені, я б рекомендував (повертаючись) до використання Meta EIP для відстеження EIP, включених до оновлення мережі. Розробники виступили за створення цих документів. Бейко сказав, що цього тижня він підготує документ для розгляду модернізації Канкун/Денеб.

Нарешті, Бейко порушив питання про корисність позначення запропонованих змін до коду, ETH пропозицій щодо покращення (EIP) як таких, що «вважаються включеними» (CFI). За словами Бейко, CFI – це стан, який розробники історично використовували як «м’які сигнали», що вказує на те, що автори EIP повинні продовжувати наполегливо працювати над пропозиціями, які можуть бути включені в майбутні хардфорки. Він використовується лише для змін та оновлень коду, орієнтованих на EL. 「[CFI] вище, ніж випадкові ідеї від випадкових людей, але до того, як вони будуть прийняті у вилку", - сказала Бейко.

У минулому мітки CFI мало вказували, які EIP на EL будуть реалізовані в оновленні або коли. Він застосовується до широкого спектру EIP з різним ступенем готовності коду та підтримкою з боку команд клієнтів. У випадку з пропозицією EVM Object Format (EOF) розробники використовують цей тег, щоб позначити свою прихильність до впровадження EOF у наступному майбутньому оновленні, Cancun/Deneb. Однак, EOF, а також кілька інших пропозицій, які також були позначені як CFI, були відхилені з Канкуна/Денеба, і неясно статус цих EIP, позначених як CFI у наступному оновленні Prague/Electra.

Бейко сказала, що якщо цей стан не допомагає, розробники повинні видалити його, але якщо вони мають намір його зберегти, розробники CL також повинні використовувати той самий ярлик для змін коду, які вони розглядають для впровадження в оновленнях CL. Незрозуміло, якою мірою процес розгляду CL EIP відображає процес перегляду EL EIP і чи повинні вони розвиватися таким же чином у майбутньому. Як правило, запропоновані зміни коду специфікації CL обговорюються під час конференц-дзвінка ACDC, тоді як запропоновані EIP до специфікації EL обговорюються під час конференц-дзвінка ACDE.

Данно Феррін (Danno Ferrin) з Swirlds Labs також виступив з ідеєю створення поля-заповнювача для всіх EIP, пов’язаних з CL або EL, яке визначає їх статус під час процесу рецензування, включаючи статус CFI. Чіткого рішення на тему статусу ЕІП та CFI ярликів щодо цього дзвінка не було.