Автор: Крістін Кім, галактика; Переклад: Huohuo/Blockchain in Vernacular
31 серпня розробники Ethereum зібралися на конференції Zoom for the Core Developers (ACDE). Модератором Тіма Бейко з Ethereum Foundation є конференц-дзвінок ACDE, який проходить раз на два тижні, де команда клієнта 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.
*Інші учасники дзвінка, зокрема Тім Бейко, Маріус Ван Дер Віден і Джастін Флорентін, виступили за те, щоб приділяти більше часу тестуванню змін у EIP 4788 на Devnet №8, а пізніше на Devnet №9 *. Бейко запропонував розробникам час для повторного скликання Devnet #9 під час наступної конференції ACDE. Що стосується стратегій розгортання testnet, Бейко рекомендує наступну послідовність:
Devnet #9: ще одна Devnet, специфікація Dencun якої була заморожена. Проведіть стрес-тест мережі та припустіть, що розробники нею задоволені, а потім перейдіть до публічної тестової мережі. В іншому випадку запустіть Devnet #10.
Holesky: створіть форк нещодавно запущеної тестової мережі Holeksy та розгорніть у ній оновлення Dencun.
Goerli: Потім розгорніть Dencun на Goerli. Оскільки запуск передостанньої тестової мережі перед основною мережею, специфікація оновлення на даний момент має бути остаточною та надавати користувачам і програмам достатньо часу для тестування свого програмного забезпечення до активації оновлення основної мережі. Dencun, ймовірно, буде останнім форком на Goerli, перш ніж його застаріють і замінять на Holesky. (Примітка перекладача: Слово Dencun є складним словом, що складається з Cancun (Cancun) і Deneb. Cancun — це назва оновлення рівня виконання Ethereum, а Deneb — це ім’я оновлення рівня протоколу. Тому оновлення Cancun Together з оновленням Deneb вони разом називаються оновленням 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.
**State Expiration — це окрема ініціатива, спрямована на вирішення проблеми необмеженого зростання стану. **Мета закінчення терміну дії стану — видалити частини стану Ethereum, до яких користувачі не отримували доступу протягом певного періоду часу (наприклад, 365 днів), таким чином зменшивши розмір стану з понад 100 ГБ до менше ніж 50 ГБ. Ендрю Ашихмін з групи облікових записів Erigon (EL) віддав перевагу об’єднанню двох оновлень, припускаючи, що перетворення Verkle Trie буде значно спрощено у поєднанні з State Expiry. Гійом Балет з клієнтської групи Geth (EL), який керував проектом Verkle Trie, стурбований тим, що з’єднання призведе до затримки Verkle Tries, оскільки закінчення терміну дії як теми дослідження було «залишено» протягом останніх двох років.
Бутерін розповів більше про мотивацію своєї пропозиції, сказавши: «З [Verkle] Процес переходу, основна проблема полягає в перетворенні 50+ ГБ Merkle Patricia Trie на... Verkle Trie у живій мережі просто досить складний. Це справді те, над чим дослідницька група боролася більше року. Я пам’ятаю, минулого року на Devconnect це було в основному предмет дослідницької діяльності, в основному стільки ж науково-дослідницької роботи, скільки й уся решта дорожньої карти Verkle, як відбувався останній перехід. У певному сенсі це конкурує зі злиттям за складністю. "
Далі Бутерін розповів, як State Expiry значно зменшує складність переходу на Verkle. Однак він також зазначив, що існують складні передумови для завершення терміну дії стану, наприклад необхідність додавати більше адресного простору для підтримки нових «періодів адрес» щороку. Отже, хоча складність впровадження Verkle буде зменшена, але розробникам все одно потрібно Крім того, якщо Verkle Tries реалізовано до State Expiry, State Expiry матиме меншу терміновість, тому розробникам варто розглянути можливість використання Verkle для здійснення переходу або зачекати кілька років, перш ніж Verkle Then State Expiry буде представлено. Розробникам було незрозуміло, яку додаткову цінність матиме об’єднання двох оновлень разом, і погодилися продовжити асинхронне обговорення цієї теми на Discord і Verkle Trie Implementors’ Call.
3. Серіалізація SSZ
Потім Ітан Кісслінг, розробник клієнта Nimbus (CL), представив свій останній прогрес у оновленні структур даних Ethereum до формату серіалізації SSZ. Щоб дізнатися більше про цю проблему, прочитайте стенограму попередньої розмови з розробниками Ethereum тут. Кіслінг висвітлив новий спосіб оновлення серіалізації даних Ethereum за допомогою формату на основі SSZ "PartialContainer". Кіслінг написав у коментарях під програмою телефонної конференції цього тижня: «Цей [формат] по суті поєднує в собі всі переваги [попереднього формату] і також може повторно використовуватися для інших цілей, усуваючи наразі невикористовувані типи SSZ Union і SSZ. ." (Примітка перекладача: проста серіалізація (SSZ) — це метод серіалізації, який використовується в ланцюжку маяків. Цей метод замінює всі аспекти консенсусного рівня, крім протоколу виявлення однорангових. Рекурсивна серіалізація за префіксом довжини, що використовується на рівні виконання. Проста проекти серіалізації є детермінованими, а також можуть бути ефективно Merkleized.)
Після оновлення Бейко швидко похвалив нещодавно створену довідкову реалізацію EL у Python (називається EELS). У нещодавній публікації в блозі Ethereum Foundation редактор EIP і дослідник Ethereum Foundation Сем Вілсон написав: «EELS — це еталонна реалізація Python основних компонентів клієнта виконання Ethereum, зосереджена на читабельності та чіткості. EELS прагне бути духовним наступником. до Жовтої книги, зручніший для програміста та синхронізований із форками після злиття, EELS може заповнювати та виконувати тести стану, стежити за основною мережею та є чудовим місцем для прототипування нових EIP».
Деякі розробники вже використовують EELS для повторного впровадження своїх EIP, а Ethereum Foundation пропонує грант усім, хто зацікавлений в оновленні Жовтої книги, щоб включити відсутні попередньо об’єднані оновлення мережі, як-от Лондон і Париж, щоб доповнити EELS.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Підсумок останньої зустрічі розробників Ethereum
Автор: Крістін Кім, галактика; Переклад: Huohuo/Blockchain in Vernacular
31 серпня розробники Ethereum зібралися на конференції Zoom for the Core Developers (ACDE). Модератором Тіма Бейко з Ethereum Foundation є конференц-дзвінок ACDE, який проходить раз на два тижні, де команда клієнта 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.
*Інші учасники дзвінка, зокрема Тім Бейко, Маріус Ван Дер Віден і Джастін Флорентін, виступили за те, щоб приділяти більше часу тестуванню змін у EIP 4788 на Devnet №8, а пізніше на Devnet №9 *. Бейко запропонував розробникам час для повторного скликання Devnet #9 під час наступної конференції ACDE. Що стосується стратегій розгортання testnet, Бейко рекомендує наступну послідовність:
Devnet #9: ще одна Devnet, специфікація Dencun якої була заморожена. Проведіть стрес-тест мережі та припустіть, що розробники нею задоволені, а потім перейдіть до публічної тестової мережі. В іншому випадку запустіть Devnet #10.
Holesky: створіть форк нещодавно запущеної тестової мережі Holeksy та розгорніть у ній оновлення Dencun.
Goerli: Потім розгорніть Dencun на Goerli. Оскільки запуск передостанньої тестової мережі перед основною мережею, специфікація оновлення на даний момент має бути остаточною та надавати користувачам і програмам достатньо часу для тестування свого програмного забезпечення до активації оновлення основної мережі. Dencun, ймовірно, буде останнім форком на Goerli, перш ніж його застаріють і замінять на Holesky. (Примітка перекладача: Слово Dencun є складним словом, що складається з Cancun (Cancun) і Deneb. Cancun — це назва оновлення рівня виконання Ethereum, а Deneb — це ім’я оновлення рівня протоколу. Тому оновлення Cancun Together з оновленням Deneb вони разом називаються оновленням 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.
**State Expiration — це окрема ініціатива, спрямована на вирішення проблеми необмеженого зростання стану. **Мета закінчення терміну дії стану — видалити частини стану Ethereum, до яких користувачі не отримували доступу протягом певного періоду часу (наприклад, 365 днів), таким чином зменшивши розмір стану з понад 100 ГБ до менше ніж 50 ГБ. Ендрю Ашихмін з групи облікових записів Erigon (EL) віддав перевагу об’єднанню двох оновлень, припускаючи, що перетворення Verkle Trie буде значно спрощено у поєднанні з State Expiry. Гійом Балет з клієнтської групи Geth (EL), який керував проектом Verkle Trie, стурбований тим, що з’єднання призведе до затримки Verkle Tries, оскільки закінчення терміну дії як теми дослідження було «залишено» протягом останніх двох років.
Бутерін розповів більше про мотивацію своєї пропозиції, сказавши: «З [Verkle] Процес переходу, основна проблема полягає в перетворенні 50+ ГБ Merkle Patricia Trie на... Verkle Trie у живій мережі просто досить складний. Це справді те, над чим дослідницька група боролася більше року. Я пам’ятаю, минулого року на Devconnect це було в основному предмет дослідницької діяльності, в основному стільки ж науково-дослідницької роботи, скільки й уся решта дорожньої карти Verkle, як відбувався останній перехід. У певному сенсі це конкурує зі злиттям за складністю. "
Далі Бутерін розповів, як State Expiry значно зменшує складність переходу на Verkle. Однак він також зазначив, що існують складні передумови для завершення терміну дії стану, наприклад необхідність додавати більше адресного простору для підтримки нових «періодів адрес» щороку. Отже, хоча складність впровадження Verkle буде зменшена, але розробникам все одно потрібно Крім того, якщо Verkle Tries реалізовано до State Expiry, State Expiry матиме меншу терміновість, тому розробникам варто розглянути можливість використання Verkle для здійснення переходу або зачекати кілька років, перш ніж Verkle Then State Expiry буде представлено. Розробникам було незрозуміло, яку додаткову цінність матиме об’єднання двох оновлень разом, і погодилися продовжити асинхронне обговорення цієї теми на Discord і Verkle Trie Implementors’ Call.
3. Серіалізація SSZ
Потім Ітан Кісслінг, розробник клієнта Nimbus (CL), представив свій останній прогрес у оновленні структур даних Ethereum до формату серіалізації SSZ. Щоб дізнатися більше про цю проблему, прочитайте стенограму попередньої розмови з розробниками Ethereum тут. Кіслінг висвітлив новий спосіб оновлення серіалізації даних Ethereum за допомогою формату на основі SSZ "PartialContainer". Кіслінг написав у коментарях під програмою телефонної конференції цього тижня: «Цей [формат] по суті поєднує в собі всі переваги [попереднього формату] і також може повторно використовуватися для інших цілей, усуваючи наразі невикористовувані типи SSZ Union і SSZ. ." (Примітка перекладача: проста серіалізація (SSZ) — це метод серіалізації, який використовується в ланцюжку маяків. Цей метод замінює всі аспекти консенсусного рівня, крім протоколу виявлення однорангових. Рекурсивна серіалізація за префіксом довжини, що використовується на рівні виконання. Проста проекти серіалізації є детермінованими, а також можуть бути ефективно Merkleized.)
Після оновлення Бейко швидко похвалив нещодавно створену довідкову реалізацію EL у Python (називається EELS). У нещодавній публікації в блозі Ethereum Foundation редактор EIP і дослідник Ethereum Foundation Сем Вілсон написав: «EELS — це еталонна реалізація Python основних компонентів клієнта виконання Ethereum, зосереджена на читабельності та чіткості. EELS прагне бути духовним наступником. до Жовтої книги, зручніший для програміста та синхронізований із форками після злиття, EELS може заповнювати та виконувати тести стану, стежити за основною мережею та є чудовим місцем для прототипування нових EIP».
Деякі розробники вже використовують EELS для повторного впровадження своїх EIP, а Ethereum Foundation пропонує грант усім, хто зацікавлений в оновленні Жовтої книги, щоб включити відсутні попередньо об’єднані оновлення мережі, як-от Лондон і Париж, щоб доповнити EELS.