Останній звіт про засідання основних розробників Ethereum: активація PeerDAS, підвищення обмеження на газ для blob

Написав: Крістін Кім

Компіляція: Luccy, BlockBeats

Редакція: Засідання всіх основних розробників Ethereum (ACDC) відбуваються щотижня для обговорення та координації змін у рівні консенсусу Ethereum (CL). Це 135-те засідання ACDC було присвячене підготовці тестових мереж Pectra Devnet 1, PeerDAS Devnet 1 та пропозицій щодо вдосконалення Ethereum (EIPs) з простим серіалізацією (SSZ).

Розробники зайнялися глибоким обговоренням питань, таких як підтримка пакетів програмного забезпечення, EIP, включаючи процеси та назви нового етапу оновлення консенсусного рівня Ethereum. Крім того, на зустрічі також обговорювалися питання щодо прогресу реалізації в рамках специфікації Electra, впливу змін мережі PeerDAS на обробку та перевірку даних вузлами Ethereum, а також складних інженерних проблем, пов’язаних з розширенням обмежень blob gas.

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

13 червня 2024 року розробники Ethereum зібралися на Zoom, щоб взяти участь у засіданні All Core Developers Consensus (ACDC)Call #135. Телефонні засідання ACDC проводяться щодвотижня і проводяться під керівництвом дослідника Фонду Ethereum Алекса Стокса, розробники обговорюють та координують зміни в консенсусному шарі Ethereum (CL, також відомому як сигнальна мережа). Цього тижня розробники обговорили підготовку до Pectra Devnet 1, PeerDAS Devnet 1 та третьої спеціалізованої тестової мережі для простого серіалізування (SSZ) пропозицій щодо вдосконалення Ethereum (EIPs).

Оголошення

Розробники розпочали зустріч з двох оголошень. Інженер з розробки та операцій Ефіріум Фонду Parithosh Jayanthi заявив, що команда ethPandaOps, яка складається з інженерів, які працюють в розробці та операціях ЕФ DevOps, візьме на себе обслуговування та розробку модуля ethereum-пакету Kurtosis. У минулому цей пакет використовувався розробниками для запуску тестової мережі Ефіріуму та пов’язаних інструментів, таких як панель приладів Grafana для моніторингу та тестування різних реалізацій клієнта. У процесі перенесення цього пакету від команди технології Kurtosis до команди ethPandaOps можливо буде вплив на користувачів, оскільки деякі посилання будуть перенаправлені на сховище GitHub, яким керує команда ethPandaOps, а не на команду Kurtosis. Jayanthi рекомендує користувачам оновити свої програмні посилання та слідкувати за випуском нових версій від команди ethPandaOps.

Друге оголошення було опубліковано Тімом Бейко, керівником підтримки протоколу Ethereum Foundation. Бейко зазначає, що він працює над впровадженням нових процесів для поетапного включення EIP у поновлення Ethereum. Він створив проект EIP, в якому визначено такі мітки, як «Proposed for Inclusion» (Пропоновано для включення), «Considered for Inclusion» (Розглядається для включення) та «Scheduled for Inclusion» (Заплановано для включення). Він сподівається, що розробники проглянуть цей документ і нададуть зворотний зв’язок. Він планує завершити цей документ до наступної зустрічі ACD.

Електра

Наступна основна версія Electra v1.5.0-alpha.3 з кодовою назвою вже майже завершена. Розробники погодилися на злиття запиту на вилучення (PR) #3768 з GitHub-репозиторію консенсусних стандартів у наступну версію. Зазначений запит на вилучення був створений розробником Nimbus Етаном Кіслінгом, який вказав, що поле “committee_bits” повинно бути додане в кінець “Attestation”, а не у середину даних, щоб уникнути проблем серіалізації даних. Крім PR #3768, Стокс питав, чи є ще які-небудь невирішені питання, які потрібно вирішити до випуску наступної основної версії Electra. Джаянті у чаті Zoom зазначив, що існують деякі невирішені питання інтеграції перевірки, спровокованої рівнем виконання (EL). Стокс записав питання щодо стану інтеграції перевірки, спровокованої рівнем виконання (EL), які виникли після наради.

Щодо останніх досягнень у впровадженні нового стандарту Electra, більшість команд клієнтів на рівні консенсусу (CL) на зустрічі заявили, що вони зможуть підготувати нову версію для тестування протягом одного-двох тижнів після остаточного затвердження v1.5.0-alpha.3. Розробники погодилися обговорити графік наступної мережі розробки Pectra Devnet 1 через кілька тижнів.

PeerDAS

Далі розглядалися прогреси впровадження PeerDAS розробниками. PeerDAS є покращенням мережі Ethereum, яке збільшить здатність вузлів обробляти та перевіряти велику кількість довільних даних, які користувачі надсилають через блоб-транзакцію. Стокс згадав рішення, прийняте на попередній зустрічі ACDC, що розробники будуть паралельно розробляти PeerDAS разом з іншими Pectra EIPs, активуючи PeerDAS окремим активаційним циклом на розробчій мережі.

Розробники Lodestar, Gajinder Singh, повідомив, що на основі оновлення Deneb розробники активують PeerDAS на розробницькій мережі, відокремленій від інших Pectra EIP. Розробники Teku, Enrico Del Fante, заявив, що розробники легше будуть будувати PeerDAS на стабільних кодових стандартах, визначених під час попереднього оновлення Ethereum Deneb, ніж на постійно змінюваних кодових стандартах Pectra. Jayanthi погодився, що реалізація PeerDAS разом з іншими реалізаціями Pectra EIP наразі може призвести до складних проблем під час тестування, особливо при спробі виявлення джерела помилок. Він запропонував розірвати ці два процеси, а потім об’єднати їх після того, як реалізація обох буде більш стабільною. Stokes погодився з цим і сказав, що розробники можуть повернутися до обговорення об’єднання PeerDAS і інших реалізацій Pectra EIP через близько місяця.

Щодо запуску теми PeerDAS Devnet 1, команді клієнтів немає чіткої оцінки щодо готовності запуску тестової мережі. Особиста оцінка на зустрічі була приблизно від 2 тижнів до 1 місяця. Стокс запропонував після декількох тижнів, коли у команди клієнтів буде більше часу на впровадження PeerDAS, знову обговорити графік часу для розробки мережі.

Далі Бейко зазначив, що хоча PeerDAS є поліпшенням мережі, а не зміною основного протоколу Ethereum, він все ще хотів включити зміни коду до мета-EIP оновлення Pectra. Документ мета-EIP містить публічний список усіх змін основного протоколу Ethereum, які містяться в оновленні. Бейко зазначив, що PeerDAS є «найбільшою функцією» Pectra, і хоча для його активації не потрібна жорстка відгалуження, його все ж слід включити до документа, щоб показати, що розробники серйозно готуються до його своєчасного включення при активації на основній мережі Pectra. Ніяких заперечень щодо цього.

Підвищення обмеження газу blob

PeerDAS змінює спосіб обробки та передачі даних вузлами через мережевий шар Ethereum. Щоб користувачі, особливо Layer-2 роллапи, могли скористатися цими змінами, розробникам потрібно збільшити поточне обмеження на шість блобів на кожний блок до вищого порогу, що дозволить більший пропускний здатності для блобів (довільних даних). Зміна обмеження блобів потребує зміни основного протоколу Ethereum, що, як розмовляли розробники на зустрічі цього тижня, може вимагати більш складної інженерної роботи, ніж просте налаштування значення константи в технічному стеку протоколу.

Стоукс пропонує роз’єднати залежності між рівнем виконання (EL) та рівнем консенсусу (CL) при зміні меж газ BLOB. В даний час будь-які зміни в лімітах газ BLOB-об’єктів вимагають внесення змін до протоколів EL і CL. Стоукс пропонує способи зламати ці залежності та дозволити розробникам безпечно видалити жорстко закодовані обмеження газ BLOB з EL і залишити це повністю на розсуд CL. Данкрад Файст, дослідник з Фонду Ethereum (EF), зазначає, що на додаток до проблем залежності між EL і CL, також важливим є хвильовий ефект зміни обмежень газ BLOB на газ обчислення Блок. «Найкращий спосіб зробити це – змінити те, як ви це робите», – каже Файст. Може бути помилкою, якщо ціна на газ обчислення відбувається в EL. Це має бути в CL, але зараз це важче змінити. …… Це непросто».

Розробники погодилися провести подальші дослідження щодо найкращого шляху зміни обмежень газу blob та обчислення газу в блоках. Розробники також погодилися продовжити обговорення щодо збільшення обмежень газу blob при активації PeerDAS в Pectra. Розробники виявили розбіжності щодо того, чи слід поєднувати ці зміни в одному форку чи реалізувати їх у різних фазах.

Jayanthi заявила, що поєднання цих змін - це “ризикове” рішення, оскільки розробники не будуть знати конкретну функціональність PeerDAS на головній мережі до її активації. Інженер з автоматизації розробки в EF Barnabas Busa додав, що обсяг жорсткого форку Pectra вже досить великий і не потребує додаткових змін коду. Busa сказав: “Ключовою є те, що у нас вже є багато EIP, і я вважаю, що постійне додавання нового контенту не дозволить нам завершити процес. Тож нам потрібно провести лінію, що буде нашим кінцевим пунктом. На мою думку, неможливо випустити PeerDAS та збільшити кількість блоків протягом наступного півтораріччя тестування.”

Розробник з псевдонімом Francesco запропонував видалити PeerDAS, щоб зменшити ризик Pectra, якщо зміни мережі не супроводжуватимуть збільшення кількості blob. Francesco запитує: «Яка вигода від PeerDAS у Pectra, якщо кількість blob не збільшується?»

Щоб додатково пояснити складність тестування PeerDAS, Джаянті вказує на те, що тестування включення блобів до EIP 4844 Ethereum не повністю симулює реальну поведінку та вплив блобів на основній мережі Ethereum. Джаянті говорить: “Проблема полягає в тому, що тестові мережі дуже складні. Ми дійсно провели багато відмінних тестів, пов’язаних з 4844, але поведінка блобів на головній мережі відрізняється від їх поведінки в тестуванні. Ми дійсно бачили проблеми з менш сильними вузлами. Ми дійсно бачили виклики у часі та інші подібні ситуації, тому навіть якщо ми можемо ідеально симулювати PeerDAS та збільшення кількості блобів, що працюють на розробницькій мережі, це не має ніякого практичного значення для головної мережі, і це є головною причиною, чому ми повинні рухатися поступово, а не одним великим кроком.”

Дослідник ЕФ Ансгар Дітріхс заявив, що зв’язувати збільшення кількості блобів із PeerDAS - це неправильно, оскільки саме PeerDAS уже вимагає від розробників вибрати значення кількості блобів. Хоча розробники можуть обрати ту саму цифру, що й на основній мережі Ethereum, проте рішення про те, яку цифру повинен використовувати PeerDAS, має бути прийняте. Єдиний резон обрати ту саму цифру полягає у тому, що розробники ускладнюють PeerDAS, щоб у разі помилки воно могло повернутися до механізму розповсюдження блобів, що передбачено в поточній специфікації Deneb. Дітріхс додав, що стурбованість щодо складності тестування ще більше підкреслює його думку, що Pectra повинна запускатися через дві жорсткі форки, а не одну, але це не означає, що він вважає, що PeerDAS повинен бути відокремлений від зміни кількості блобів.

Оновлення SSZ

Кіслінґ поділився оновленнями з прогресом трьох EIP, пов’язаних із SSZ. Він вказав, що робота над впровадженням цих EIP вже почалася на декількох клієнтах, включаючи Teku, Grandine та Lighthouse. Він сказав, що розробники можуть почати обговорення графіку мережі для розробки цих EIP SSZ та можливо включити їх до оновлення Pectra на наступній зустрічі ACDC.

Назви F-Star

У Ethereum Magicians є допис, де обговорюється назва наступного рівня консенсусу (CL) після Electra. Розробники вже визначили назву оновлення виконавчого рівня (EL) після Prague: Osaka. Кандидати на назву оновлення CL: Fulu, Felis, Formosa і Funi. Ці назви відповідають головному звичаю назви головних зірок, що починаються з «F», і підходять для шостого загального оновлення Beacon Chain. Stokes проходить розмову з розробниками щодо цієї теми на форумі Magicians.