Підсумки останньої зустрічі основних розробників ETH Place: До кінця року відбудеться тіньова вилка Goerli та тест оновлення Cancun/Deneb

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

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

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

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

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

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

14 грудня 2023 року ETH розробники зібралися в Zoom на сесію All Core Developers Consensus (ACDC) #124. Конференц-дзвінок ACDC – це серія зустрічей, що проводяться раз на два тижні під керівництвом Денні Райана, дослідника ETH Workshop Foundation, де розробники обговорюють та координують зміни до ETH Рівня консенсусу семінарів (CL). Цього тижня розробники зосередилися на прогресі тестування апгрейду Cancun/Deneb на тестовій мережі Devnet #12. З моменту зустрічі All-Core Developer Execution (ACDE), що відбулася минулого тижня, всі комбінації клієнтів Execution Layer (EL) і Consensus Layer (CL) були підключені до Devnet #12, включаючи клієнт Prysm. Програмне забезпечення MEV-Boost увімкнено, але комбінації клієнтів із Prysm не включені. Розробники заявили, що планують запустити тіньову гілку Goerli в найближчі один-два тижні, щоб протестувати оновлення Cancun/Deneb і включити всіх клієнтів. Крім того, розробники обговорили правила поширення інформації про Slashable, а також графік дзвінків на найближчі два тижні.

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

Барнабас Буса, DevOps Engineer в ETH Foundation, розповів, що всі комбінації клієнтів EL/CL, включаючи ті, які використовують Prysm як клієнт CL, були успішно інтегровані в Devnet #12. Клієнтський портфель за допомогою Prysm не тестувався на програмне забезпечення MEV-Boost. Однак на Devnet #12 робочий процес MEV тестує інші клієнти CL. Нещодавно клієнт Lighthouse зазнав оновлення патчу для усунення помилок, пов’язаних з MEV. Крім того, Парітош Джаянті, інший інженер DevOps у Фонді, сказав, що вони помітили проблему з вузлом Besu на Devnet #12 і що вони все ще працюють над визначенням першопричини. Наступним кроком розробники навмисно надсилатимуть шкідливі блоки через мережу, тестуватимуть генератори блоків і запускатимуть тести вуликів для нещодавно доданих клієнтів Prysm для стрес-тестування комбінацій клієнтів у Devnet. Джаянті заявив у публічному повідомленні Discord під час дзвінка, що розробники все ще планують запустити тіньову гілку в тестовій мережі Goerli до кінця року.

Оновлена різка інформація

Далі розробники коротко обговорили кілька питань, пов’язаних із поширенням та термінами появи повідомлення Slashable на ETH після оновлення Cancun/Deneb. Наприклад, коса риска інформація включає поширення дублікатів або недійсних блоків і blob-об’єктів. Dapplion, анонімний розробник клієнта Lodestar, зробив pull request (PR) через GitHub, який має на меті додати нові події до API Beacon Chain, щоб дозволити операторам вузлів швидше дізнаватися про події Slashable, що було б особливо корисно, якщо є велика кількість інформації Slashable. У своєму PR Dapplion згадує: «Для великих операторів загальна вартість різання значною мірою залежить від часу їх відгуку. Якщо в операційних помилках бере участь багато ключів, то може знадобитися деякий час, щоб ця різка інформація була включена в ланцюжок. PR Dapplion був об’єднаний зі специфікацією API Beacon Chain до дзвінка і впроваджується різними командами клієнтів CL, такими як Prysm і Lighthouse.

Dapplion також пропонує PR, пов’язаний з вимірюванням часу поширення блоку. Він зазначив, що вимірювання часу поширення блоку стане складнішим у зв’язку з оновленням Cancun/Deneb та впровадженням транзакцій BLOB. Dapplion детально розповідає про рішення, яке він пропонує у своєму PR. Як помітили розробники в гілці PR, вони, як правило, вирішують цю проблему, додаючи поле часової позначки до існуючих пов’язаних подій API Beacon Chain.

Третьою темою, яку обговорювали розробники, пов’язаною з поширенням інформації Slashable після оновлення Cancun/Deneb, були умови поширення ляпень. Розробник Lighthouse “sean” (або “realbigsean” на GitHub) зазначив, що існуючі правила поширення BLOB призвели до непередбачуваних наслідків. Під час дзвінка Шон сказав: «Якщо ви використовуєте Beacon API для широкомовної автентифікації, несподівано, що підхід пліток може призвести до дійсних і недійсних повідомлень. Причина цього полягає в тому, що технічно можна розмножити дві ляпки з різними індексами блобів пов’язаного з ними заголовка Slashable. Вам дозволено розмножувати їх, але не ті, які мають однаковий індекс BLOB. 」

Шон додав, що дивна поведінка, коли справа доходить до різкого поширення інформації про блоби, не має суттєвого впливу на здоров’я мережі, крім просто «дивного» результату для розуміння та аналізу операторами вузлів. Тому, хоча немає нагальної потреби в активації Cancun/Deneb, він пропонує розробникам розглянути можливість внесення змін до правил поводження з поширенням різаної інформації в майбутніх оновленнях. Денні Райан погоджується, кажучи, що розробники повинні знайти час, щоб «цілісно» подумати про те, як вирішити цю проблему. Райан пропонує повернутися до цієї теми в січні, щоб дати розробникам час розробити всеосяжний план оновлення правил поширення блобів і блоків Slashable.

Далі розробники обговорили незначні зміни в мережевому протоколі libp2p, щоб зменшити ефект посилення на вузлах, що надсилають великі повідомлення, такі як блоки з великою кількістю блобів. Шон виділив нове керуюче повідомлення «IDONTWANT», яким можна скористатися для сповіщення вузлів libp2p про призупинення надсилання великих повідомлень. Райан сказав, що він спробує зв’язатися з командою libp2p, щоб об’єднати цей PR, і якщо виникнуть подальші затримки, це питання буде переглянуто під час телефонної конференції ACDE наступного тижня.