31 серпня розробники Ethereum зібралися на Zoom для конференції Core Developers ution (ACDE). Зустріч ACDE, організована Тімом Бейко з Ethereum Foundation, — це серія зустрічей, які проходять раз на два тижні, на яких команда клієнтів Ethereum обговорює та координує зміни в рівні виконання Ethereum (EL). Цього тижня розробники обговорили хід розробки та тестування:
Оновлення Cancun/Deneb (Dencun).
Перетворення Verkle Trie
Оновлення серіалізації SSZ
1. Оновлення в Канкуні
Devnet #8 стартував два тижні тому, 16 серпня. Барнабас Буса, інженер DevOps з Ethereum Foundation, сказав, що орієнтована на розробників тестова мережа оновлення Cancun працює добре. Буса зазначив, що, здається, виникли деякі проблеми з вузлами, на яких працює клієнтське програмне забезпечення Nethermind (EL). Розробник клієнта Nethermind Лукаш Розмей пояснив, що суть проблеми полягає в неправильній конфігурації в реалізації пулу транзакцій blob. (Примітка перекладача: Devnet 8 — це перша спеціальна тестова мережа, яка містить усі завершені EIP для оновлення Cancun/Deneb)
Що стосується EIP 4788, розробники коротко підтвердили нову стратегію розгортання для змін коду. Контракти, які розкривають дані ланцюга маяків на EL, будуть розгорнуті як звичайні смарт-контракти, які вимагають, щоб хтось фінансував адресу контракту до активації оновлення. Devnet #9, наступна тестова мережа для оновлення Cancun, запровадить цей робочий процес і забезпечить ознайомлення з ним розробників.
Замість того, щоб відкладати дату випуску Devnet #9, розробники погодилися продовжити тестування на Devnet #8, доки всі проблеми з клієнтською реалізацією не будуть вирішені. «Я краще буду впевнений у Devnet №9, ніж скажу, що ми сподіваємося, що ці речі спрацюють... Я краще вирішу проблеми, про які ми знаємо. Інакше, якщо у нас будуть важкі проблеми в Devnet #9, ми обов’язково це зробимо мати Devnet #10 знову, я не кажу, що ми не повинні мати Devnet #10. Ми повинні мати значну кількість devnet. Я думаю, тепер ми можемо спробувати зробити Devnet #9 дійсно надійним." Ether Денні Райан, співробітник Square Foundation і голова конференції ACDC.
Інші учасники дзвінка, включно з Тімом Бейко, Маріусом Ван Дер Віденом і Джастіном Флорентіном, виступили за те, щоб приділяти більше часу тестуванню на Devnet #8 і перевірити зміни в EIP 4788 на Devnet #9 пізніше. Бейко запропонував розробникам знову зібратися для Devnet #9 під час наступної конференції ACDE. Що стосується стратегії розгортання testnet, Бейко рекомендує наступну послідовність:
Devnet #9: ще одна Devnet, специфікація Dencun якої заморожена. Виконайте стрес-тест мережі та припустіть, що розробники нею задоволені, а потім перейдіть до публічної тестової мережі. В іншому випадку запустіть Devnet #10.
Holesky: створіть форк нещодавно запущеної тестової мережі Holeksy та розгорніть у ній оновлення Dencun.
Goerli: Потім розгорніть Dencun на Goerli. Оскільки це передостанній запуск тестової мережі перед основною мережею, специфікації оновлення на даний момент мають бути остаточними та надати користувачам і програмам достатньо часу для тестування свого програмного забезпечення до активації оновлення основної мережі. Dencun, ймовірно, буде останнім форком на Goerli перед тим, як Goerli буде застарілим і замінений на Holesky. (Примітка перекладача: слово Dencun є складним словом, що складається з Cancun (Cancun) і Deneb. Cancun — це назва оновлення рівня виконання Ethereum, а Deneb — це ім’я оновлення рівня протоколу. Таким чином, оновлення Cancun пов’язане з Денеб. Оновлення спільно називаються оновленнями Dencun.)
Сеполія: нарешті розгорніть Dencun на Сеполії, щоб досягти хороших результатів.
Ніхто не заперечував проти пропозиції Beiko випустити testnet після Devnet #9. Бейко зазначив, що вищезазначена хронологія буде представлена ширшій спільноті ethereum у дописі в блозі після офіційного запуску тестової мережі Holesky 15 вересня. Крім того, Бейко сказав, що також розробляється тестова мережа під назвою Ephemery. Ehemery — це тестова мережа Ethereum для операторів верифікаційних вузлів, які повернуться до стану генезису через тиждень або два. Щоб дізнатися більше про мережу Ephemery, прочитайте сторінку проекту на GitHub тут.
Перш ніж перейти до обговорення Verkle Tries, Буса підкреслив відкритий запит на отримання (PR) на GitHub для тестової мережі Holesky. На прохання команди Erigon (EL), PR пропонує видалити конкретний час активації для оновлення Dencun на Holesky. Пізніше розробники встановлять значення для активації Dencun на Holesky замість перезапису існуючого значення. Busa також підняв питання щодо тестування цільового/максимального значення 3/6 краплі замість обмеження 2/4. Стосовно цієї теми Бейко запропонував знову підняти це питання під час телефонної розмови ACDC наступного тижня, причому Райан згадав, що нещодавні експерименти з великими розмірами блоків принесуть нове розуміння.
2. Перетворення Verkle Trie
Далі розробники обговорили пропозицію Віталіка Бутеріна поєднати дорожні карти Verkle Trie і State Expiry, щоб зменшити складність впровадження Verkle Trie і прискорити використання переваг State Expiry на Ethereum. Як довідкова інформація, Verkle Trie або Verkle Tree — це структура даних, яка дозволяє користувачам легко перевіряти великі обсяги даних, спираючись на єдиний криптографічний доказ. Вони нічим не відрізняються від Merkle Patricia Trie (MPT), яка є структурою даних, яка використовується для зберігання стану Ethereum. Однак ефективність перевірки дерев Verkle порівняно вища, ніж MPT, тому розробники працювали над переходом MPT на Verkle.
Термін дії стану — це окрема програма, призначена для вирішення проблеми необмеженого зростання стану. Метою закінчення терміну дії стану є зменшення розміру стану з понад 100 ГБ до менше 50 ГБ шляхом видалення частин стану Ethereum, до яких користувач не відкривав протягом певного періоду часу (наприклад, 365 днів). Ендрю Ашихмін з команди облікових записів Erigon (EL) віддав перевагу об’єднанню двох оновлень, припускаючи, що перетворення Verkle Trie значно спроститься в поєднанні з State Expiry. Ґійом Балет із команди клієнтів Geth (EL), який очолював проект Verkle Trie, стурбований тим, що сполучення призведе до затримки Verkle Trie, оскільки закінчується термін дії стану, оскільки тема дослідження була «залишена» протягом останніх двох років.
Бутерін розповів більше про мотивацію своєї пропозиції, сказавши: «З [Verkle] Процес переходу, основна проблема полягає в перетворенні 50+ ГБ Merkle Patricia Trie на... Verkle Trie у живій мережі просто досить складний. Це справді те, над чим дослідницька група боролася більше року. Я пам’ятаю, минулого року на Devconnect це було, по суті, предметом дослідницької події, і в основному стільки ж науково-дослідницької роботи, скільки вся решта дорожньої карти Verkle разом узяті, просто процес того, як здійснити той останній перехід. У певному сенсі його складність не поступається складності злиття. "
Бутерін продовжив, як State Expiry значно зменшив складність переходу на Verkle. Однак він також зазначив, що закінчення терміну дії стану має складні передумови, такі як необхідність додавати більше адресних просторів для підтримки нових «періодів адрес» щороку. Тож хоча складність реалізації Verkle зменшиться, розробникам все ще потрібно Розв’язати головоломку Додатково, якщо Verkle Tries буде реалізовано до State Expiry, State Expiry матиме меншу терміновість, тому розробникам слід розглянути можливість використання Verkle для переходу або почекати кілька років, поки State Expiry буде введено після Verkle. незрозуміло щодо додаткової цінності, яка буде результатом об’єднання цих двох оновлень разом, і погодився продовжити асинхронне обговорення цієї теми на Discord і Verkle Trie Implementors’ Call.
3. Серіалізація SSZ
Потім Ітан Кісслінг, розробник клієнта Nimbus (CL), представив свій останній прогрес у оновленні структур даних Ethereum до формату серіалізації SSZ. Щоб дізнатися більше про цю проблему, прочитайте стенограму попередньої розмови з розробниками Ethereum тут. Кісслінг висвітлив новий підхід до оновлення серіалізації даних Ethereum за допомогою формату на основі SSZ «PartialContainer». У коментарях під програмою телефонної конференції цього тижня Кісслінг написав: «Цей [формат] по суті поєднує в собі всі переваги [попереднього формату] і також може повторно використовуватися для інших цілей, таким чином поступово припиняючи невикористаний наразі SSZ Union і необов’язковий тип SSZ. " (Примітка перекладача: Проста серіалізація (SSZ) — це метод серіалізації, який використовується в ланцюжку маяків. Цей метод замінює рівень реалізації, який використовується скрізь на консенсусному рівні, крім протоколу виявлення однорангових. Рекурсивна серіалізація за префіксом довжини. Проста конструкція серіалізації є детермінованою та також можна ефективно мерклезувати.)
Після оновлення Бейко швидко похвалив нещодавно створену довідкову реалізацію EL у Python (називається EELS). У нещодавній публікації в блозі Ethereum Foundation редактор EIP і дослідник Ethereum Foundation Сем Вілсон написав: "EELS — це еталонна реалізація Python основних компонентів клієнта виконання Ethereum, зосереджена на читабельності та чіткості. EELS розроблено, щоб бути духовним наступником Yellow Paper, більш зручний для програмування та синхронізований із форками після злиття, EELS може заповнювати та виконувати тести зі збереженням стану, дотримуватись основної мережі та є чудовим місцем для прототипування нових EIP».
Деякі розробники вже використовують EELS для повторного впровадження своїх EIP, а фонд Ethereum має грант для всіх, хто зацікавлений в оновленні жовтої книги, щоб включити відсутні попередньо об’єднані оновлення мережі, як-от Лондон і Париж, щоб доповнити EELS.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Підсумок 116-ї виконавчої зустрічі розробників Ethereum Core: оновлення в Канкуні, перетворення Verkle Trie і серіалізація SSZ
Автор: Крістін Кім / Джерело:
Переклад: Huohuo/народний блокчейн
31 серпня розробники Ethereum зібралися на Zoom для конференції Core Developers ution (ACDE). Зустріч ACDE, організована Тімом Бейко з Ethereum Foundation, — це серія зустрічей, які проходять раз на два тижні, на яких команда клієнтів Ethereum обговорює та координує зміни в рівні виконання Ethereum (EL). Цього тижня розробники обговорили хід розробки та тестування:
Оновлення Cancun/Deneb (Dencun).
Перетворення Verkle Trie
Оновлення серіалізації SSZ
1. Оновлення в Канкуні
Devnet #8 стартував два тижні тому, 16 серпня. Барнабас Буса, інженер DevOps з Ethereum Foundation, сказав, що орієнтована на розробників тестова мережа оновлення Cancun працює добре. Буса зазначив, що, здається, виникли деякі проблеми з вузлами, на яких працює клієнтське програмне забезпечення Nethermind (EL). Розробник клієнта Nethermind Лукаш Розмей пояснив, що суть проблеми полягає в неправильній конфігурації в реалізації пулу транзакцій blob. (Примітка перекладача: Devnet 8 — це перша спеціальна тестова мережа, яка містить усі завершені EIP для оновлення Cancun/Deneb)
Що стосується EIP 4788, розробники коротко підтвердили нову стратегію розгортання для змін коду. Контракти, які розкривають дані ланцюга маяків на EL, будуть розгорнуті як звичайні смарт-контракти, які вимагають, щоб хтось фінансував адресу контракту до активації оновлення. Devnet #9, наступна тестова мережа для оновлення Cancun, запровадить цей робочий процес і забезпечить ознайомлення з ним розробників.
Замість того, щоб відкладати дату випуску Devnet #9, розробники погодилися продовжити тестування на Devnet #8, доки всі проблеми з клієнтською реалізацією не будуть вирішені. «Я краще буду впевнений у Devnet №9, ніж скажу, що ми сподіваємося, що ці речі спрацюють... Я краще вирішу проблеми, про які ми знаємо. Інакше, якщо у нас будуть важкі проблеми в Devnet #9, ми обов’язково це зробимо мати Devnet #10 знову, я не кажу, що ми не повинні мати Devnet #10. Ми повинні мати значну кількість devnet. Я думаю, тепер ми можемо спробувати зробити Devnet #9 дійсно надійним." Ether Денні Райан, співробітник Square Foundation і голова конференції ACDC.
Інші учасники дзвінка, включно з Тімом Бейко, Маріусом Ван Дер Віденом і Джастіном Флорентіном, виступили за те, щоб приділяти більше часу тестуванню на Devnet #8 і перевірити зміни в EIP 4788 на Devnet #9 пізніше. Бейко запропонував розробникам знову зібратися для Devnet #9 під час наступної конференції ACDE. Що стосується стратегії розгортання testnet, Бейко рекомендує наступну послідовність:
Devnet #9: ще одна Devnet, специфікація Dencun якої заморожена. Виконайте стрес-тест мережі та припустіть, що розробники нею задоволені, а потім перейдіть до публічної тестової мережі. В іншому випадку запустіть Devnet #10.
Holesky: створіть форк нещодавно запущеної тестової мережі Holeksy та розгорніть у ній оновлення Dencun.
Goerli: Потім розгорніть Dencun на Goerli. Оскільки це передостанній запуск тестової мережі перед основною мережею, специфікації оновлення на даний момент мають бути остаточними та надати користувачам і програмам достатньо часу для тестування свого програмного забезпечення до активації оновлення основної мережі. Dencun, ймовірно, буде останнім форком на Goerli перед тим, як Goerli буде застарілим і замінений на Holesky. (Примітка перекладача: слово Dencun є складним словом, що складається з Cancun (Cancun) і Deneb. Cancun — це назва оновлення рівня виконання Ethereum, а Deneb — це ім’я оновлення рівня протоколу. Таким чином, оновлення Cancun пов’язане з Денеб. Оновлення спільно називаються оновленнями Dencun.)
Сеполія: нарешті розгорніть Dencun на Сеполії, щоб досягти хороших результатів.
Ніхто не заперечував проти пропозиції Beiko випустити testnet після Devnet #9. Бейко зазначив, що вищезазначена хронологія буде представлена ширшій спільноті ethereum у дописі в блозі після офіційного запуску тестової мережі Holesky 15 вересня. Крім того, Бейко сказав, що також розробляється тестова мережа під назвою Ephemery. Ehemery — це тестова мережа Ethereum для операторів верифікаційних вузлів, які повернуться до стану генезису через тиждень або два. Щоб дізнатися більше про мережу Ephemery, прочитайте сторінку проекту на GitHub тут.
Перш ніж перейти до обговорення Verkle Tries, Буса підкреслив відкритий запит на отримання (PR) на GitHub для тестової мережі Holesky. На прохання команди Erigon (EL), PR пропонує видалити конкретний час активації для оновлення Dencun на Holesky. Пізніше розробники встановлять значення для активації Dencun на Holesky замість перезапису існуючого значення. Busa також підняв питання щодо тестування цільового/максимального значення 3/6 краплі замість обмеження 2/4. Стосовно цієї теми Бейко запропонував знову підняти це питання під час телефонної розмови ACDC наступного тижня, причому Райан згадав, що нещодавні експерименти з великими розмірами блоків принесуть нове розуміння.
2. Перетворення Verkle Trie
Далі розробники обговорили пропозицію Віталіка Бутеріна поєднати дорожні карти Verkle Trie і State Expiry, щоб зменшити складність впровадження Verkle Trie і прискорити використання переваг State Expiry на Ethereum. Як довідкова інформація, Verkle Trie або Verkle Tree — це структура даних, яка дозволяє користувачам легко перевіряти великі обсяги даних, спираючись на єдиний криптографічний доказ. Вони нічим не відрізняються від Merkle Patricia Trie (MPT), яка є структурою даних, яка використовується для зберігання стану Ethereum. Однак ефективність перевірки дерев Verkle порівняно вища, ніж MPT, тому розробники працювали над переходом MPT на Verkle.
Термін дії стану — це окрема програма, призначена для вирішення проблеми необмеженого зростання стану. Метою закінчення терміну дії стану є зменшення розміру стану з понад 100 ГБ до менше 50 ГБ шляхом видалення частин стану Ethereum, до яких користувач не відкривав протягом певного періоду часу (наприклад, 365 днів). Ендрю Ашихмін з команди облікових записів Erigon (EL) віддав перевагу об’єднанню двох оновлень, припускаючи, що перетворення Verkle Trie значно спроститься в поєднанні з State Expiry. Ґійом Балет із команди клієнтів Geth (EL), який очолював проект Verkle Trie, стурбований тим, що сполучення призведе до затримки Verkle Trie, оскільки закінчується термін дії стану, оскільки тема дослідження була «залишена» протягом останніх двох років.
Бутерін розповів більше про мотивацію своєї пропозиції, сказавши: «З [Verkle] Процес переходу, основна проблема полягає в перетворенні 50+ ГБ Merkle Patricia Trie на... Verkle Trie у живій мережі просто досить складний. Це справді те, над чим дослідницька група боролася більше року. Я пам’ятаю, минулого року на Devconnect це було, по суті, предметом дослідницької події, і в основному стільки ж науково-дослідницької роботи, скільки вся решта дорожньої карти Verkle разом узяті, просто процес того, як здійснити той останній перехід. У певному сенсі його складність не поступається складності злиття. "
Бутерін продовжив, як State Expiry значно зменшив складність переходу на Verkle. Однак він також зазначив, що закінчення терміну дії стану має складні передумови, такі як необхідність додавати більше адресних просторів для підтримки нових «періодів адрес» щороку. Тож хоча складність реалізації Verkle зменшиться, розробникам все ще потрібно Розв’язати головоломку Додатково, якщо Verkle Tries буде реалізовано до State Expiry, State Expiry матиме меншу терміновість, тому розробникам слід розглянути можливість використання Verkle для переходу або почекати кілька років, поки State Expiry буде введено після Verkle. незрозуміло щодо додаткової цінності, яка буде результатом об’єднання цих двох оновлень разом, і погодився продовжити асинхронне обговорення цієї теми на Discord і Verkle Trie Implementors’ Call.
3. Серіалізація SSZ
Потім Ітан Кісслінг, розробник клієнта Nimbus (CL), представив свій останній прогрес у оновленні структур даних Ethereum до формату серіалізації SSZ. Щоб дізнатися більше про цю проблему, прочитайте стенограму попередньої розмови з розробниками Ethereum тут. Кісслінг висвітлив новий підхід до оновлення серіалізації даних Ethereum за допомогою формату на основі SSZ «PartialContainer». У коментарях під програмою телефонної конференції цього тижня Кісслінг написав: «Цей [формат] по суті поєднує в собі всі переваги [попереднього формату] і також може повторно використовуватися для інших цілей, таким чином поступово припиняючи невикористаний наразі SSZ Union і необов’язковий тип SSZ. " (Примітка перекладача: Проста серіалізація (SSZ) — це метод серіалізації, який використовується в ланцюжку маяків. Цей метод замінює рівень реалізації, який використовується скрізь на консенсусному рівні, крім протоколу виявлення однорангових. Рекурсивна серіалізація за префіксом довжини. Проста конструкція серіалізації є детермінованою та також можна ефективно мерклезувати.)
Після оновлення Бейко швидко похвалив нещодавно створену довідкову реалізацію EL у Python (називається EELS). У нещодавній публікації в блозі Ethereum Foundation редактор EIP і дослідник Ethereum Foundation Сем Вілсон написав: "EELS — це еталонна реалізація Python основних компонентів клієнта виконання Ethereum, зосереджена на читабельності та чіткості. EELS розроблено, щоб бути духовним наступником Yellow Paper, більш зручний для програмування та синхронізований із форками після злиття, EELS може заповнювати та виконувати тести зі збереженням стану, дотримуватись основної мережі та є чудовим місцем для прототипування нових EIP».
Деякі розробники вже використовують EELS для повторного впровадження своїх EIP, а фонд Ethereum має грант для всіх, хто зацікавлений в оновленні жовтої книги, щоб включити відсутні попередньо об’єднані оновлення мережі, як-от Лондон і Париж, щоб доповнити EELS.