30 листопада 2023 року розробники Ethereum зібралися в Zoom на зустріч All Core Developers Consensus (ACDC) #122. Конференц-дзвінок ACDC – це серія зустрічей, що проводяться раз на два тижні, модератором яких є дослідник Ethereum Foundation Денні Райан, на яких розробники обговорюють і координують зміни в рівні консенсусу (CL) Ethereum. Цього тижня розробники зосередилися на останніх розробках у тестуванні Канкуна/Денеба, зокрема:
· Запуск Devnet #12: Триває тестування клієнтського програмного забезпечення Teku, Lodestar та Lighthouse на Devnet #12, а також усього клієнтського програмного забезпечення виконавчого рівня (EL). Команда Prysm очікує, що їхнє програмне забезпечення буде готове до тестування протягом двох-трьох тижнів на останньому Devnet.
· Проблема виходу з валідатора на Devnet #11: На Devnet #11 розробники виявили проблему, пов'язану з виходом валідатора, яка в даний час вирішується клієнтською командою Nimbus. Devnet #11 продовжуватиме нормально функціонувати, доки проблема не буде вирішена.
· Уточнення специфікації мережі: Розробники обговорили уточнення специфікації для запитів «BlockByRoot» і «BlobSidecarsByRoot», уточнивши, чи повинні вузли рівня консенсусу (CL) відповідати на ці запити в певному порядку.
На додаток до оновлення Cancun/Deneb, розробники обговорили деякі питання процесу, підняті Тімом Бейко, керівником відділу підтримки протоколів Ethereum Foundation, для покращення координації оновлення Ethereum.
Devnet #12
У середу, 30 листопада 2023 року, оновлення Cancun/Deneb було офіційно запущено на Devnet #12. Маріо Вега (Mario Vega) з команди тестування Ethereum 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 та тестових мережах. Щоб переконатися, що цей інструмент працює, Джаянті попросив розробників поділитися подробицями відомих помилок, які викликали реорганізацію ланцюга на Ethereum. Джаянті пояснив, що він використовуватиме ці помилки для тестування інструменту та забезпечення того, щоб він міг надійно визначити, коли відбувається реорганізація та коли вона вирішується.
Уточнення специфікацій мережі
Розробники коротко обговорили відкритий запит на пул, запропонований дослідником Ethereum Foundation Джастіном Траглія щодо порядку відповідей, які клієнти CL повинні повертати при отриманні запиту «BlockbyRoot» або «BlobSidecarsByRoot». Райан запитує, як різні команди клієнтів CL вже впроваджують цю функцію. Ніхто з розробників на дзвінку не відповів на це питання. Райан запропонував відновити дискусію на каналі Ethereum Research & Development Discord, щоб залучити більш широке коло розробників-клієнтів. Райан визнає, що в специфікаціях двох запитів є неясності, які «можуть бути причиною проблем і дивних крайніх випадків» і «заслуговують на те, щоб бути проясненими та розібраними», стверджує Райан.
Райан також зазначив, що випустить нову версію специфікації CL у найближчі кілька днів. Остання версія значно додає специфікації щодо того, коли клієнт CL може надавати блоки та блоки через RPC-запит "byRoot". Для отримання додаткової інформації про те, як отримати відсутні блоки та блоки за допомогою RPC-запитів "byRoot", будь ласка, зверніться до попереднього журналу викликів. Райан підкреслює, що нові доповнення до специфікації CL, включені в останню версію, не матимуть жодних несумісних змін у коді, які впливають на код валідаторів, які вже працюють на Devnet #11 або #12.
Процес планування модернізації
Далі розробники обговорили різні елементи процесу, запропоновані Beiko. Бейко сказав, що повідомлення в блозі, яке попереджає користувачів тестової мережі Goerli про майбутнє припинення протягом 3 місяців після активації оновлення Cancun/Deneb на Goerli, або через 1 місяць після активації оновлення в основній мережі Ethereum, залежно від того, що настане пізніше, буде опубліковано в блозі Ethereum Foundation 30 листопада. Після завершення конкурсу вищезазначена публікація в блозі була опублікована, і її можна прочитати тут.
Beiko пропонує створити спеціальну папку для оновлення в репозиторії Ethereum «pm», щоб організувати різні файли, пов'язані з конкретним оновленням, в одну папку для подальшого використання. Розробники під час дзвінка погодилися з пропозицією Beiko.
Другий пункт процесу, запропонований Beiko, стосується створення документа «Meta EIP» для відстеження повного обсягу оновлень мережі, які були завершені на Ethereum. «Немає хорошого місця, щоб відстежувати повний обсяг оновлення мережі, перш ніж розгорнути та оголосити про це в дописі в блозі», — написав Бейко в дописі про свою пропозицію Meta EIP. «Для Dencun у нас є EL EIP у важкодоступному файлі Markdown 7, а CL EIP є частиною специфікації Beacon Chain Specification 3. Це не дуже добре, оскільки обидва трохи важко знайти, вони використовують різні «формати», і це призводить до дублювання. Оскільки ERC та EIP тепер розділені, я рекомендую (повертаючись) до використання Meta EIP для відстеження EIP, включених в оновлення мережі. Розробники виступили за створення цих документів. Бейко сказав, що цього тижня він підготує документ для перегляду оновлення Канкуна/Денеба.
Нарешті, Beiko порушила питання про корисність позначення запропонованих змін коду, Ethereum Improvement Proposals (EIPs), як «Розгляньте можливість включення» (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. Під час цього дзвінка не було чіткого рішення на тему статусу EIP та маркування CFI.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Підсумки останньої зустрічі розробників ядра Ethereum: Devnet #12启动, процес планування апгрейду
30 листопада 2023 року розробники Ethereum зібралися в Zoom на зустріч All Core Developers Consensus (ACDC) #122. Конференц-дзвінок ACDC – це серія зустрічей, що проводяться раз на два тижні, модератором яких є дослідник Ethereum Foundation Денні Райан, на яких розробники обговорюють і координують зміни в рівні консенсусу (CL) Ethereum. Цього тижня розробники зосередилися на останніх розробках у тестуванні Канкуна/Денеба, зокрема:
· Запуск Devnet #12: Триває тестування клієнтського програмного забезпечення Teku, Lodestar та Lighthouse на Devnet #12, а також усього клієнтського програмного забезпечення виконавчого рівня (EL). Команда Prysm очікує, що їхнє програмне забезпечення буде готове до тестування протягом двох-трьох тижнів на останньому Devnet.
· Проблема виходу з валідатора на Devnet #11: На Devnet #11 розробники виявили проблему, пов'язану з виходом валідатора, яка в даний час вирішується клієнтською командою Nimbus. Devnet #11 продовжуватиме нормально функціонувати, доки проблема не буде вирішена.
· Уточнення специфікації мережі: Розробники обговорили уточнення специфікації для запитів «BlockByRoot» і «BlobSidecarsByRoot», уточнивши, чи повинні вузли рівня консенсусу (CL) відповідати на ці запити в певному порядку.
На додаток до оновлення Cancun/Deneb, розробники обговорили деякі питання процесу, підняті Тімом Бейко, керівником відділу підтримки протоколів Ethereum Foundation, для покращення координації оновлення Ethereum.
Devnet #12
У середу, 30 листопада 2023 року, оновлення Cancun/Deneb було офіційно запущено на Devnet #12. Маріо Вега (Mario Vega) з команди тестування Ethereum 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 та тестових мережах. Щоб переконатися, що цей інструмент працює, Джаянті попросив розробників поділитися подробицями відомих помилок, які викликали реорганізацію ланцюга на Ethereum. Джаянті пояснив, що він використовуватиме ці помилки для тестування інструменту та забезпечення того, щоб він міг надійно визначити, коли відбувається реорганізація та коли вона вирішується.
Уточнення специфікацій мережі
Розробники коротко обговорили відкритий запит на пул, запропонований дослідником Ethereum Foundation Джастіном Траглія щодо порядку відповідей, які клієнти CL повинні повертати при отриманні запиту «BlockbyRoot» або «BlobSidecarsByRoot». Райан запитує, як різні команди клієнтів CL вже впроваджують цю функцію. Ніхто з розробників на дзвінку не відповів на це питання. Райан запропонував відновити дискусію на каналі Ethereum Research & Development Discord, щоб залучити більш широке коло розробників-клієнтів. Райан визнає, що в специфікаціях двох запитів є неясності, які «можуть бути причиною проблем і дивних крайніх випадків» і «заслуговують на те, щоб бути проясненими та розібраними», стверджує Райан.
Райан також зазначив, що випустить нову версію специфікації CL у найближчі кілька днів. Остання версія значно додає специфікації щодо того, коли клієнт CL може надавати блоки та блоки через RPC-запит "byRoot". Для отримання додаткової інформації про те, як отримати відсутні блоки та блоки за допомогою RPC-запитів "byRoot", будь ласка, зверніться до попереднього журналу викликів. Райан підкреслює, що нові доповнення до специфікації CL, включені в останню версію, не матимуть жодних несумісних змін у коді, які впливають на код валідаторів, які вже працюють на Devnet #11 або #12.
Процес планування модернізації
Далі розробники обговорили різні елементи процесу, запропоновані Beiko. Бейко сказав, що повідомлення в блозі, яке попереджає користувачів тестової мережі Goerli про майбутнє припинення протягом 3 місяців після активації оновлення Cancun/Deneb на Goerli, або через 1 місяць після активації оновлення в основній мережі Ethereum, залежно від того, що настане пізніше, буде опубліковано в блозі Ethereum Foundation 30 листопада. Після завершення конкурсу вищезазначена публікація в блозі була опублікована, і її можна прочитати тут.
Beiko пропонує створити спеціальну папку для оновлення в репозиторії Ethereum «pm», щоб організувати різні файли, пов'язані з конкретним оновленням, в одну папку для подальшого використання. Розробники під час дзвінка погодилися з пропозицією Beiko.
Другий пункт процесу, запропонований Beiko, стосується створення документа «Meta EIP» для відстеження повного обсягу оновлень мережі, які були завершені на Ethereum. «Немає хорошого місця, щоб відстежувати повний обсяг оновлення мережі, перш ніж розгорнути та оголосити про це в дописі в блозі», — написав Бейко в дописі про свою пропозицію Meta EIP. «Для Dencun у нас є EL EIP у важкодоступному файлі Markdown 7, а CL EIP є частиною специфікації Beacon Chain Specification 3. Це не дуже добре, оскільки обидва трохи важко знайти, вони використовують різні «формати», і це призводить до дублювання. Оскільки ERC та EIP тепер розділені, я рекомендую (повертаючись) до використання Meta EIP для відстеження EIP, включених в оновлення мережі. Розробники виступили за створення цих документів. Бейко сказав, що цього тижня він підготує документ для перегляду оновлення Канкуна/Денеба.
Нарешті, Beiko порушила питання про корисність позначення запропонованих змін коду, Ethereum Improvement Proposals (EIPs), як «Розгляньте можливість включення» (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. Під час цього дзвінка не було чіткого рішення на тему статусу EIP та маркування CFI.