Автор Крістін Кім

Упорядники: Luccy, BlockBeats

Примітка редактора: кожні два тижні для обговорення та координації змін у консенсусному рівні Ethereum (CL) проводиться консенсусна зустріч усіх основних розробників (ACDC). Це 134-та конференція ACDC. На цій конференції розробники обговорили деталі реалізації та технічні проблеми кількох ключових EIP, включаючи EIP 7549, EIP 7251, EIP 6110, EIP 7688 тощо.

Крім того, розробники також детально обговорили впровадження PeerDAS, технології вибірки доступності даних, яка, як очікується, значно покращить здатність мережі Ethereum підтримувати зведення та їхні вимоги до доступності даних. Під час зустрічі було внесено пропозицію розділити Pectra на два хардфорки для оновлення, а також обговорювалися питання часу активації та взаємозалежності різних EIP.

Крістін Кім, віце-президент із досліджень у Galaxy Digital, детально записала ключові моменти цієї зустрічі. BlockBeasts склав оригінальний текст таким чином:

30 травня 2024 року розробники Ethereum зібралися в Zoom на зустріч №134 All Core Developers Consensus (ACDC). Конкурс ACDC — це серіал, який проводиться раз на два тижні під керівництвом дослідника Ethereum Foundation Алекса Стоукса, де розробники обговорюють і координують зміни в консенсусному рівні Ethereum (CL, також відомому як Beacon Chain). Цього тижня розробники обговорюють досвід і відкриті проблеми з моменту запуску Pectra Devnet 0. Вони також обговорювали доцільність розширення обсягу оновлення Pectra, щоб включити зміни коду контейнера peerDAS і SSZ.

Devnet 0 Огляд

З огляду на запуск Pectra на Devnet 0, команда клієнта погодилася залишити поведінку перевірки, на яку впливає EIP 7549, незмінною під час активації хардфорка. На попередній зустрічі ACDC розробники розглянули різні варіанти, щоб гарантувати, що вплив EIP 7549 не призведе до великої кількості недійсних перевірок під час розгалуження. Щоб уникнути подальшого ускладнення оновлень, команда клієнта вирішила активувати EIP 7549 у ту саму епоху, що й інші Pectra EIP, не змінюючи поведінку перевірки до та після розгалуження.

Що стосується EIP 7251, розробники все ще не впевнені, чи слід дозволити злиття ставки ETH запускати з рівня виконання (EL). Це була б ідеальна функція для пулів ставок, таких як Lido, щоб об’єднання ставок не покладалося на операторів вузлів, а натомість могло здійснюватися за допомогою смарт-контрактів. Стоукс рекомендував перевірити прогрес клієнтів, які впроваджують злиття валідаторів, за кілька тижнів, перш ніж вирішити, чи мають вони бути операціями EL чи CL.

Потім розробники обговорили деякі запитання без відповіді щодо остаточного підтвердження депозитів валідатора відповідно до EIP 6110. Розробник Teku Михайло Калінін резюмував напрямки вирішення цих проблем у коментарі GitHub перед конференцією. Розробник Lighthouse "sean" підняв питання про версії запиту "GetPayloadBodies" в API двигуна. Стокс рекомендував розробникам опублікувати свої коментарі в запиті на отримання, створеному для проблеми на GitHub.

Зміни EIP 7549

Розробник Nimbus Ітан Кісслінг запропонував невеликі зміни в реалізації EIP 7549. «Це стосується стабільності узагальненого індексу. Коли ми додаємо нове поле в середині контейнера, наступним полям буде присвоєно новий індекс, що порушить доказ на основі EIP 4788 на рівні виконання (EL), і деякі оманливі. … Тому я рекомендую перенести нове поле в кінець, щоб уникнути обох проблем», – пояснив Кісслінг. Заперечень проти цієї зміни не було. Стоукс рекомендує розробникам ознайомитися з запитом Kissling на GitHub.

Ще одна зміна EIP 7549, запропонована на зустрічі, полягала б у створенні запитів та інших запитів, ініційованих EL, як доповнень до блоків EL. Стосовно цієї зміни Калінін сказав: «На мій погляд, це дуже гарне дизайнерське рішення, воно спрощує EL... і в основному є альтернативою узагальненим запитам у блоці рівня виконання». знову обговорити на наступній зустрічі CL, щоб розробники мали більше часу для перегляду пропозиції на GitHub.

Обговорення обсягу Pectra

Є деякі EIP, орієнтовані на консенсусний рівень (CL), які офіційно не включені або виключені з оновлення Pectra. На зустрічі цього тижня розробники обговорювали, чи додавати EIP 7688 і PeerDAS до Pectra. EIP 7688 використовує частину структури даних SSZ "StableContainer", щоб забезпечити пряму сумісність змін атестації EIP 7549. Як довідковий вступ, SSZ — це структура даних, яка використовується в CL, і розробники також хочуть використовувати її на рівні виконання (EL). Для отримання додаткової інформації про перехід SSZ перегляньте протокол попередньої зустрічі. PeerDAS — це реалізація вибірки доступності даних на Ethereum, яка, як очікується, значно покращить здатність мережі підтримувати зведення та її вимоги щодо доступності даних. На практиці очікується, що PeerDAS збільшить кількість транзакцій blob, які валідатори можуть приєднати до блоку, з 3 до 64 або більше на блок.

Барнабас Буса, інженер з операцій розробників у Ethereum Foundation, сказав, що розробники запустили ранню ітерацію PeerDAS у мережі розробки. «Я думаю, що багато клієнтів виявили багато проблем, і коли ми досягнемо значного прогресу, ми завжди зможемо перезапустити нову мережу розробки», — сказав Буса. Стокс запитав розробників, чи готові вони додати PeerDAS до Pectra без затримок оновлення.

Розробник на прізвисько "Nishant" відновив пропозицію відокремити активацію PeerDAS від активації інших EIP у Pectra. Хоча це можливо, інший розробник під псевдонімом "atd" підкреслив, що якщо розробники планують активувати ці оновлення одне за одним протягом короткого періоду часу, користувачам все одно потрібно буде оновити своє програмне забезпечення одночасно. atd сказав: «Я вважаю, що це трохи божевільно робити форк через два місяці після чергового оновлення. Якщо ми збираємося координувати всіх для оновлення клієнта, ми не хочемо, щоб кожен оновлював клієнта через два місяці. Це б , навіть одного циклу випуску недостатньо».

atd додав, що, на його думку, PeerDAS є найбільш «цікавою» зміною коду в EIP, включеному та обговорюваному в Pectra. Стокс сказав, що сподівається включити PeerDAS у Pectra, навіть якщо це спричинить затримки оновлення. Розробник клієнта Grandine Саулюс Грігайтіс запропонував видалити EIP 7549 і EIP 7688 із Pectra на користь PeerDAS. Це спонукало до обговорення деталей реалізації EIP 7688. Розробники не змогли домовитися про зміни коду, і пропозиція буде переглянута на наступному засіданні ACDC.

Що стосується PeerDAS, розробники продовжують обдумувати ідею поділу Pectra на два хардфорки. Інженер з опцій для розробників Ethereum Foundation Парітхош Джаянті попередив, що якщо розробники розділять Pectra на два оновлення, вони повинні бути обережними, щоб не додати більше EIP у майбутній частині 2 Pectra. Джаянті сказав: «Одна річ, яку я хочу зазначити, полягає в тому, що якщо ми розглядаємо можливість поділу на два форки, ми повинні бути дуже обережними, щоб не додати більше нових EIP у наступному форку. Я не знаю, чи зможемо ми це зробити До цього моменту. Якщо ми можемо взяти на себе зобов’язання зробити щось рік чи півтора тому, тому що ми завжди придумуємо нові ідеї, пріоритети змінюються тощо».

Продовжуючи обговорення двох ідей оновлення, розробник Lighthouse «шон» сказав, що він не передбачив багато взаємозалежностей між PeerDAS і поточним списком Pectra EIP. Тому їх можна робити окремо, а потім легко об’єднати, коли розробник стане впевненішим у їх реалізації. Atd погодився, стверджуючи, що не буде великого ризику в об’єднанні Pectra EIP, PeerDAS і EIP 7688 після їх окремої розробки та тестування.

Busa рекомендує продовжувати тестувати Pectra EIP і PeerDAS, але внести зміни в код, щоб PeerDAS активувався на одну епоху пізніше, ніж Pectra EIP, у мережах розробки та тестування. Він зазначив, що вже таким чином проводиться тестування Pectra EIP і PeerDAS на Devnet 0. «Насправді нічого не потрібно змінювати», — сказав Буса, додавши, що якщо PeerDAS не буде готовий, коли будуть інші Pectra EIP, розробники можуть видалити цю зміну коду з оновлення. Це викликає кілька запитань про те, як різні епохи активації PeerDAS впливають на роботу команд клієнтів. Зрештою, розробники погодилися продовжити розробку PeerDAS і Pectra EIP, але передумовою було те, що PeerDAS буде активовано в різні епохи в мережі розробки та тестовій мережі.

Як згадувалося раніше, розробники погодилися залишити обговорення того, чи буде EIP 7688 включений у Pectra, до наступного виклику ACDC.