31 августа разработчики Ethereum собрались в Zoom на телеконференцию Core Developers (ACDE). Конференц-связь ACDE, модерируемая Тимом Бейко из Ethereum Foundation, представляет собой серию конференц-звонков, проводимую раз в две недели, в ходе которой клиентская команда Ethereum обсуждает и координирует изменения на уровне исполнения Ethereum (EL). На этой неделе разработчики обсудили ход разработки и тестирования:
Обновление Канкун/Денеб (Денкун)
Преобразование Веркла Трие
Обновление сериализации SSZ
1. Обновление Канкуна
Devnet #8 запущен две недели назад, 16 августа. Барнабас Буса, инженер DevOps в Ethereum Foundation, сказал, что ориентированная на разработчиков тестовая сеть обновления Cancun, похоже, работает хорошо. Буса упомянул, что, похоже, есть некоторые проблемы с узлами, на которых работает клиентское программное обеспечение Nethermind (EL). Лукаш Розмей, разработчик клиента Nethermind, объяснил, что природа проблемы связана с неправильной конфигурацией реализации пула транзакций Blob. **(Примечание переводчика: Devnet 8 — первая выделенная тестовая сеть, которая содержит все завершенные EIP обновления Канкун/Денеб)
Что касается EIP 4788**, разработчики кратко подтвердили новую стратегию развертывания изменений кода**. Контракты, которые предоставляют данные цепочки маяков на EL, будут развернуты как обычные смарт-контракты, которые требуют, чтобы кто-то профинансировал адрес контракта до активации обновления. Devnet #9, следующая тестовая сеть для обновления Cancun, примет этот рабочий процесс и обеспечит знакомство с ним разработчиков.
Вместо того чтобы откладывать дату выпуска Devnet #9, разработчики согласились продолжить тестирование Devnet #8 до тех пор, пока не будут решены все проблемы с реализацией клиента. «Я лучше буду уверен в Devnet #9, чем буду говорить, что мы надеемся, что эти вещи будут работать. ... Я лучше буду решать проблемы, о которых мы знаем. В противном случае, если у нас возникнут серьезные проблемы в Devnet #9, мы обязательно их решим. снова иметь Devnet #10, я не говорю, что у нас не должно быть Devnet #10. У нас должно быть значительное количество Devnet. Я думаю, теперь мы можем попытаться сделать Devnet #9 действительно надежным", - сказал Этер Дэнни Райан, коллега. в Фонде Фанга и председатель телеконференции ACDC.
*Другие участники телеконференции, в том числе Тим Бейко, Мариус Ван Дер Вейден и Джастин Флорентайн, высказались за то, чтобы потратить больше времени на тестирование в Devnet #8, а затем протестировать изменения в EIP 4788 в Devnet #9 *. Бейко предложила разработчикам время вновь созвать Devnet #9 во время следующей телеконференции ACDE. Что касается стратегий развертывания тестовой сети, Beiko рекомендует следующую последовательность:
Devnet #9: Еще один Devnet, спецификация Dencun которого заморожена. Проведите стресс-тестирование сети и предположите, что разработчики ею довольны, а затем перейдите к общедоступной тестовой сети. В противном случае запустите Devnet #10.
Holesky: форк недавно запущенной тестовой сети Holeksy и развертывание на ней обновления Dencun.
Герли: Затем разверните Денкун на Герли. Поскольку предпоследняя тестовая сеть будет запущена перед основной сетью, спецификация обновления на данный момент должна быть окончательной и предоставить пользователям и приложениям достаточно времени для тестирования своего программного обеспечения до активации обновления основной сети. Dencun, вероятно, станет последним форком Goerli, прежде чем он будет признан устаревшим и заменен Holesky. (Примечание переводчика: слово Dencun — это составное слово, состоящее из слов Cancun (Канкун) и Денеб. Канкун — это название обновления уровня исполнения Ethereum, а Денеб — имя обновления уровня протокола. Поэтому обновление Канкуна вместе с обновлением Deneb они вместе называются обновлением Dencun.)
Сеполия: Наконец, разверните Денкун на Сеполии, чтобы добиться хороших результатов.
Никто не возражал против предложения Бейко выпустить тестовую сеть после Devnet #9. Бейко упомянул, что приведенный выше график будет представлен широкому сообществу Ethereum в сообщении в блоге после официального запуска тестовой сети Holesky 15 сентября. Кроме того, Бейко сообщил, что в стадии разработки находится тестовая сеть под названием Ephemery. Ehemery — это тестовая сеть Ethereum для операторов узлов проверки, которая возвращается в исходное состояние через неделю или две. Для получения дополнительной информации о сети Ephemery прочитайте страницу проекта на GitHub здесь.
Прежде чем перейти к обсуждению Verkle Tries, Буса рассказал об открытом запросе на извлечение (PR) на GitHub для тестовой сети Holesky. По просьбе команды Erigon (EL) ПР предлагает убрать конкретное время активации апгрейда Dencun на Holesky. Позже разработчик установит значение активации Dencun в Holesky, а не перезапишет существующее значение. Буса также спросил о тестировании целевого/максимального размера 3/6 BLOB-объектов вместо ограничения 2/4. **По этой теме Бейко предложил снова поднять этот вопрос на телеконференции ACDC на следующей неделе, при этом Райан упомянул, что недавние эксперименты с большими размерами блоков принесут новые идеи. **
2. Преобразование Веркла Трие
Затем разработчики обсудили предложение Виталика Бутерина объединить дорожные карты Verkle Trie и State Expiry, чтобы уменьшить сложность реализации Verkle Trie и ускорить преимущества State Expiry на Ethereum. В качестве фона: **Verkle Trie или Verkle Tree — это структура данных, которая позволяет пользователям легко проверять большие объемы данных, опираясь на одно криптографическое доказательство. **Они ничем не отличаются от Merkle Patricia Trie (MPT), структуры данных, используемой для хранения состояния Эфириума. Однако эффективность доказательства у деревьев Веркла относительно выше, чем у MPT, поэтому разработчики работают над переходом MPT на Verkle.
**Истечение срока действия штата — это отдельная инициатива, призванная решить проблему неограниченного роста штата. **Целью истечения срока действия состояния является уменьшение размера состояния с более чем 100 ГБ до менее 50 ГБ путем удаления частей состояния Ethereum, к которым пользователь не имел доступа в течение определенного периода времени (например, 365 дней). Эндрю Ашихмин из команды по работе с клиентами 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 Tryes будет реализован до истечения срока действия состояния, срок действия состояния будет менее срочным, поэтому разработчикам следует рассмотреть возможность использования Verkle для осуществления перехода или подождать несколько лет, прежде чем будет введен Verkle then State Expiry. Разработчикам не было ясно, какую дополнительную выгоду получит объединение двух обновлений, и они согласились продолжить асинхронное обсуждение этой темы на 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 Foundation предлагает грант всем, кто заинтересован в обновлении «Желтой книги», включив в нее недостающие предварительно объединенные обновления сети, такие как Лондон и Париж, в дополнение к EELS.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Краткое изложение последней встречи руководителей основных разработчиков Ethereum
Автор: Кристин Ким, галактика; Перевод: Huohuo/Vernacular Blockchain
31 августа разработчики Ethereum собрались в Zoom на телеконференцию Core Developers (ACDE). Конференц-связь ACDE, модерируемая Тимом Бейко из Ethereum Foundation, представляет собой серию конференц-звонков, проводимую раз в две недели, в ходе которой клиентская команда Ethereum обсуждает и координирует изменения на уровне исполнения Ethereum (EL). На этой неделе разработчики обсудили ход разработки и тестирования:
Обновление Канкун/Денеб (Денкун)
Преобразование Веркла Трие
Обновление сериализации SSZ
1. Обновление Канкуна
Devnet #8 запущен две недели назад, 16 августа. Барнабас Буса, инженер DevOps в Ethereum Foundation, сказал, что ориентированная на разработчиков тестовая сеть обновления Cancun, похоже, работает хорошо. Буса упомянул, что, похоже, есть некоторые проблемы с узлами, на которых работает клиентское программное обеспечение Nethermind (EL). Лукаш Розмей, разработчик клиента Nethermind, объяснил, что природа проблемы связана с неправильной конфигурацией реализации пула транзакций Blob. **(Примечание переводчика: Devnet 8 — первая выделенная тестовая сеть, которая содержит все завершенные EIP обновления Канкун/Денеб)
Что касается EIP 4788**, разработчики кратко подтвердили новую стратегию развертывания изменений кода**. Контракты, которые предоставляют данные цепочки маяков на EL, будут развернуты как обычные смарт-контракты, которые требуют, чтобы кто-то профинансировал адрес контракта до активации обновления. Devnet #9, следующая тестовая сеть для обновления Cancun, примет этот рабочий процесс и обеспечит знакомство с ним разработчиков.
Вместо того чтобы откладывать дату выпуска Devnet #9, разработчики согласились продолжить тестирование Devnet #8 до тех пор, пока не будут решены все проблемы с реализацией клиента. «Я лучше буду уверен в Devnet #9, чем буду говорить, что мы надеемся, что эти вещи будут работать. ... Я лучше буду решать проблемы, о которых мы знаем. В противном случае, если у нас возникнут серьезные проблемы в Devnet #9, мы обязательно их решим. снова иметь Devnet #10, я не говорю, что у нас не должно быть Devnet #10. У нас должно быть значительное количество Devnet. Я думаю, теперь мы можем попытаться сделать Devnet #9 действительно надежным", - сказал Этер Дэнни Райан, коллега. в Фонде Фанга и председатель телеконференции ACDC.
*Другие участники телеконференции, в том числе Тим Бейко, Мариус Ван Дер Вейден и Джастин Флорентайн, высказались за то, чтобы потратить больше времени на тестирование в Devnet #8, а затем протестировать изменения в EIP 4788 в Devnet #9 *. Бейко предложила разработчикам время вновь созвать Devnet #9 во время следующей телеконференции ACDE. Что касается стратегий развертывания тестовой сети, Beiko рекомендует следующую последовательность:
Devnet #9: Еще один Devnet, спецификация Dencun которого заморожена. Проведите стресс-тестирование сети и предположите, что разработчики ею довольны, а затем перейдите к общедоступной тестовой сети. В противном случае запустите Devnet #10.
Holesky: форк недавно запущенной тестовой сети Holeksy и развертывание на ней обновления Dencun.
Герли: Затем разверните Денкун на Герли. Поскольку предпоследняя тестовая сеть будет запущена перед основной сетью, спецификация обновления на данный момент должна быть окончательной и предоставить пользователям и приложениям достаточно времени для тестирования своего программного обеспечения до активации обновления основной сети. Dencun, вероятно, станет последним форком Goerli, прежде чем он будет признан устаревшим и заменен Holesky. (Примечание переводчика: слово Dencun — это составное слово, состоящее из слов Cancun (Канкун) и Денеб. Канкун — это название обновления уровня исполнения Ethereum, а Денеб — имя обновления уровня протокола. Поэтому обновление Канкуна вместе с обновлением Deneb они вместе называются обновлением Dencun.)
Сеполия: Наконец, разверните Денкун на Сеполии, чтобы добиться хороших результатов.
Никто не возражал против предложения Бейко выпустить тестовую сеть после Devnet #9. Бейко упомянул, что приведенный выше график будет представлен широкому сообществу Ethereum в сообщении в блоге после официального запуска тестовой сети Holesky 15 сентября. Кроме того, Бейко сообщил, что в стадии разработки находится тестовая сеть под названием Ephemery. Ehemery — это тестовая сеть Ethereum для операторов узлов проверки, которая возвращается в исходное состояние через неделю или две. Для получения дополнительной информации о сети Ephemery прочитайте страницу проекта на GitHub здесь.
Прежде чем перейти к обсуждению Verkle Tries, Буса рассказал об открытом запросе на извлечение (PR) на GitHub для тестовой сети Holesky. По просьбе команды Erigon (EL) ПР предлагает убрать конкретное время активации апгрейда Dencun на Holesky. Позже разработчик установит значение активации Dencun в Holesky, а не перезапишет существующее значение. Буса также спросил о тестировании целевого/максимального размера 3/6 BLOB-объектов вместо ограничения 2/4. **По этой теме Бейко предложил снова поднять этот вопрос на телеконференции ACDC на следующей неделе, при этом Райан упомянул, что недавние эксперименты с большими размерами блоков принесут новые идеи. **
2. Преобразование Веркла Трие
Затем разработчики обсудили предложение Виталика Бутерина объединить дорожные карты Verkle Trie и State Expiry, чтобы уменьшить сложность реализации Verkle Trie и ускорить преимущества State Expiry на Ethereum. В качестве фона: **Verkle Trie или Verkle Tree — это структура данных, которая позволяет пользователям легко проверять большие объемы данных, опираясь на одно криптографическое доказательство. **Они ничем не отличаются от Merkle Patricia Trie (MPT), структуры данных, используемой для хранения состояния Эфириума. Однако эффективность доказательства у деревьев Веркла относительно выше, чем у MPT, поэтому разработчики работают над переходом MPT на Verkle.
**Истечение срока действия штата — это отдельная инициатива, призванная решить проблему неограниченного роста штата. **Целью истечения срока действия состояния является уменьшение размера состояния с более чем 100 ГБ до менее 50 ГБ путем удаления частей состояния Ethereum, к которым пользователь не имел доступа в течение определенного периода времени (например, 365 дней). Эндрю Ашихмин из команды по работе с клиентами 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 Tryes будет реализован до истечения срока действия состояния, срок действия состояния будет менее срочным, поэтому разработчикам следует рассмотреть возможность использования Verkle для осуществления перехода или подождать несколько лет, прежде чем будет введен Verkle then State Expiry. Разработчикам не было ясно, какую дополнительную выгоду получит объединение двух обновлений, и они согласились продолжить асинхронное обсуждение этой темы на 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 Foundation предлагает грант всем, кто заинтересован в обновлении «Желтой книги», включив в нее недостающие предварительно объединенные обновления сети, такие как Лондон и Париж, в дополнение к EELS.