👾 Все о хардфорке Ethereum - FUSAKA 2025-2026 [гайд по EIP / песочницам / Pectra] обновляется - Страница 12

UPD: Следующее обновление сети Ethereum под названием Fusaka намечено на вторую половину 2025 года.
По словам одного из руководителей Ethereum Foundation, Томаша Станчака, хардфорк планируют провести в сентябре или октябре, однако точных сроков пока нет.

Про Fusaka простыми словами

Во второй половине 2025 года в сети Ethereum ожидается следующее крупное обновление — Fusaka, которое продолжит развитие платформы после успешно реализованного форка Pectra. По словам соисполнительного директора Ethereum Foundation Томаша Станчака, запуск Fusaka планируется на сентябрь или октябрь, однако точная дата хардфорка пока не определена.

Ключевые особенности Fusaka

Главным элементом обновления станет внедрение PeerDAS — технологии, призванной значительно улучшить масштабируемость Ethereum. PeerDAS (Peer-to-Peer Data Availability Sampling) позволит снизить нагрузку на ноды, повысить пропускную способность сети и подготовить инфраструктуру к увеличению объема данных. В частности, речь идёт об увеличении размеров бинарных массивов данных (BLOB) с текущих 6 МБ до 32 МБ.

Разработка PeerDAS вызвала оживленные дискуссии в сообществе. Ещё в 2024 году один из ведущих разработчиков Ethereum, Петер Силадьи, критиковал технологию, заявляя, что она может создать препятствия для домашних валидаторов и тем самым угрожать децентрализации сети. Тем не менее, команда разработчиков решила сделать PeerDAS центральным элементом Fusaka, отложив его внедрение в рамках Pectra.

Исключение Ethereum Object Format (EOF)

Одним из ожидавшихся компонентов Fusaka был Ethereum Object Format (EOF) — предложение по изменению формата байткода EVM с целью оптимизации выполнения смарт-контрактов и снижения стоимости операций. Однако Тим Бейко, ведущий координации core-разработчиков Ethereum, сообщил, что от внедрения EOF в Fusaka решено отказаться. Причина — техническая неопределённость и отсутствие консенсуса в сообществе.

Бейко также подчеркнул, что ситуация с EOF продемонстрировала слабые места в текущем процессе приоритизации предложений для хардфорков. Несмотря на поддержку EOF со стороны многих разработчиков, проект вызвал возражения у ряда участников сообщества, что привело к его исключению из текущей дорожной карты.

Стратегия и временные рамки

На сегодняшний день обновление Fusaka находится на стадии раннего планирования. Параллельно ведётся работа над формированием перечня улучшений (EIP), которые войдут в релиз. В частности, ожидается реализация предложений, направленных на снижение вычислительных узких мест, улучшение пропускной способности и подготовку к дальнейшему увеличению лимитов газа.

Хотя точный график развертывания Fusaka пока не зафиксирован, команда Ethereum придерживается активного и открытого подхода к координации — с регулярными встречами All Core Devs и техническими сессиями (ACDT), на которых формируется структура будущего обновления.

Во время встречи All Core Developers Consensus (ACDC) #162 был утверждён поэтапный график подготовки к запуску основной сети в ноябре.

Основные даты:

• 1 сентября 2025 — выпуск клиентов для Holesky и Sepolia
• 8 сентября 2025 — старт программы по поиску багов (bug bounty)
• 15 сентября 2025 — форк Holesky
• 22 сентября 2025 — форк Sepolia
• 1 октября 2025 — выпуск клиента для основной сети и форк Hoodi
• 8 октября 2025 — активация форка Hoodi
• 5 ноября 2025 — запланированный запуск Fusaka mainnet

Про Pectra

Обновление Ethereum под названием «Pectra» обещает стать одним из самых амбициозных и преобразующих обновлений в истории технологии блокчейн

Название обновления сочетает в себе слова «Прага», где проходила Конференция разработчиков Ethereum (Devcon 4), и «Электра», звезда, названная в соответствии с традицией Ethereum использовать астрономические имена.

Это обновление символизирует достижения как на уровне исполнения, так и на уровне консенсуса сети. Цель обновления заключается в повышении производительности сети и решении ключевых проблем удобства использования и безопасности.

Ключевые моменты Pectra​

• Более масштабируемая и эффективная платформа: Обновление Pectra основано на видении сообщества Ethereum о создании более масштабируемой и эффективной блокчейн-платформы. Оно будет состоять из двух частей: первая часть сосредоточится на EIP, которые были протестированы на Pectra Devnet, а вторая фаза будет включать более сложные предложения.
• Оптимизация решений для масштабирования: Изменения направлены на оптимизацию решений для масштабирования уровня 1 (L1) и уровня 2 (L2), а также на обеспечение более плавной интеграции децентрализованных приложений (dApps) и валидаторов

Спойлер: Что такое EIP простыми словами

В экосистеме Ethereum каждое новое улучшение или функциональное дополнение реализуется через предложение EIP (Ethereum Improvement Proposal).

EIP могут как представлять новые функции, так и улучшать существующие процессы.

Репозиторий для управления проектом был создан в октябре 2015 года, и с тех пор все обновления можно отслеживать через сайт EIPs. Основной целью всех EIP является улучшение сети Ethereum. Авторы предложений обязаны предоставить веские аргументы и технические стандарты, после чего требуется экспертная оценка и консенсус сообщества для их утверждения.

Модель EIP вдохновлена BIP (Bitcoin Improvement Proposals), применяемой в Bitcoin. Эта модель позволяет эффективно удовлетворять потребности в обновлениях и улучшениях, сохраняя децентрализованный характер управления сетью. Кроме того, она способствует удобству использования и развитию новых приложений.

Спойлер: Категории EIP в Ethereum

EIP можно разделить на три основные категории:

• Стандартный трек (Standard Track EIPs): Стандартные EIP оказывают влияние на большинство или все реализации Ethereum. Они включают изменения сетевого протокола, правил действительности блоков или транзакций, предлагаемые стандарты для приложений и любые изменения, которые затрагивают совместимость приложений, использующих Ethereum. Стандартные EIP можно разделить на несколько категорий:

Ядро: Улучшения, требующие консенсусного форка, такие как EIP-5 и EIP-101. Также включают изменения, связанные с "core dev", например, EIP-1559, направленное на улучшение структуры платы за газ и требующее хард форка.​

​

Сетевые технологии: Улучшения вокруг devp2p и Light Ethereum Subprotocol, а также предложения по улучшению сетевых протоколов whisper и swarm. Например, EIP-2124 направлено на снижение затрат при использовании данных о транзакциях.​

​

Интерфейс: Улучшения спецификаций и стандартов клиентских API/RPC, а также стандарты на уровне языка (имена методов и ABI контрактов), например, EIP-695, который определяет метод eth_chainId.​

​

ERC: Стандарты и соглашения на уровне приложений, включая стандарты контрактов (например, стандарты токенов), реестры имен, схемы URI, форматы библиотек/пакетов и форматы кошельков, такие как известные ERC-20 и ERC-721.​

• Метатрек (Meta Track EIPs): Эти предложения связаны с процессами управления и организационными аспектами, которые влияют на разработку и управление проектом Ethereum. Метатрек может включать изменения в процессах принятия решений, коммуникационные стандарты и другие важные процессы.
• Информационные (Informational EIPs): Информационные EIP предоставляют руководства или объяснения определенных процессов или стандартов, но не обязательно вносят изменения в код или протокол. Эти предложения служат для предоставления информации сообществу Ethereum.

Спойлер: Все о статусах EIP простыми словами

В экосистеме Ethereum любой человек может инициировать EIP.

Прежде чем воплотить идею в жизнь, автору сначала необходимо обсудить ее в сообществе Ethereum, чтобы избежать дублирования существующих предложений.

Процесс статусов EIP включает следующие этапы:

• Черновик (Draft): После обсуждения и одобрения идеи в сообществе, автор может создать черновик EIP. Разработчики и редакторы будут приглашены для экспертной оценки.
• Обзор (Review): Авторы должны убедить сообщество принять их EIP, после чего предложение проходит через процесс экспертной оценки.
• Последний звонок (Last Call): После экспертной оценки EIP вступает в "Last Call", который обычно длится 14 дней. В течение этого периода, если EIP требует изменений, он возвращается в статус "Обзор". Пройдя "Last Call", предложение помечается как "Окончательное (Final)".
• Окончательное (Final): Предложения, прошедшие "Last Call", становятся окончательными и получают статус "Final".
• Отозванное (Withdrawn): Для EIP в статусах "Черновик", "Обзор" или "Последний звонок" автор все еще может отозвать предложение, и тогда оно получает статус "Отозванное".
• Застой (Stagnant): Если EIP в статусах "Черновик", "Обзор" или "Последний звонок" неактивен в течение 6 месяцев без отзыва, он получает статус "Застойное".
• Живые (Living): Предложения, такие как EIP-1, которые должны постоянно обновляться и не достигают окончательного завершения, помечаются как "Живые".

Спойлер: Что такое блобы (+видео)

👾 Все о хардфорке Ethereum - FUSAKA 2025-2026 [гайд по EIP / песочницам / Pectra] обновляется

UPD: Следующее обновление сети Ethereum под названием Fusaka намечено на вторую половину 2025 года. По словам одного из руководителей Ethereum Foundation, Томаша Станчака, хардфорк планируют провести в сентябре или октябре, однако точных сроков пока нет. Про Fusaka простыми словами Во...

mmgp.com

Спойлер: Дерево Меркла Патриции

Дерево Меркла Патриции - это особая структура данных, которая объединяет преимущества деревьев Меркла и Патриции для эффективного хранения и проверки состояния блокчейна Ethereum - ПОДРОБНЕЕ В ОДНОМ ИЗ КОММЕНТАРИЕВ

Спойлер: Что такое тестнет Mekong простыми словами?

Mekong - это тестовая сеть Ethereum, созданная для испытаний ключевых обновлений, которые войдут в обновление Pectra. Среди них:

Улучшенный UX кошельков: Благодаря EIP-7702 разработчики смогут протестировать новые методы повышения удобства использования Ethereum-кошельков, обеспечивая более плавный пользовательский опыт.
Обновления ETH-стейкинга: Важные изменения в механизме стейкинга упростят процессы внесения и вывода средств.
Оптимизированные депозиты и выход из стейкинга: Новые предложения, такие как EIP-6110 и EIP-7002, улучшат процессы взаимодействия со стейкингом, сделав их проще и эффективнее.

Почему называется Mekong? Название тестовой сети связано с рекой Меконг, протекающей через Таиланд, Камбоджу, Вьетнам и другие страны Юго-Восточной Азии. Это не случайный выбор — в Бангкоке пройдет Devcon, и тестовая сеть Mekong стала своеобразной «прелюдией» к этому событию для сообщества Ethereum.

Как присоединиться к Mekong?

Разработчики кошельков могут протестировать обновления UX из EIP-7702, чтобы заранее адаптировать свои продукты под будущие изменения. Их отзывы помогут улучшить новые функции.

Опытные пользователи Ethereum могут развернуть узел в тестовой сети Mekong, следуя инструкциям по настройке уровня исполнения и консенсуса. Этот процесс аналогичен настройке узла в основной сети Ethereum.

Стейкеры могут протестировать обновленные механизмы депозита и вывода ETH. Это отличная возможность ознакомиться с изменениями и оставить обратную связь.

Влияет ли это на основную сеть?

Mekong не оказывает влияния на основную сеть Ethereum и другие тестовые сети, такие как Holesky и Sepolia. Это изолированная тестовая среда для проверки обновлений перед их внедрением.

Спойлер: EIP Proposal Builder - конструктор предложений EIP

EIP Proposal Builder - это новый инструмент на платформе EIPsInsight.com, который призван кардинально упростить процесс создания предложений по улучшению Ethereum (EIP). Независимо от опыта разработки, этот инструмент помогает составлять EIP быстрее, удобнее и интуитивнее.

В EIP Proposal Builder есть:

• Интуитивные поля: четко структурированные разделы, такие как «Название», «Описание» и «Автор», помогут вам быстро заполнить все необходимые данные.
• Полезные подсказки: инструмент предлагает рекомендации вроде «Объясните, почему текущий протокол неадекватен», что помогает точно сформулировать вашу идею.

Продолжение в комментариях

Спойлер: Что такое ERC-7779 простыми словами

ERC-7779 - это стандарт, который упрощает перенос кошельков Ethereum, обеспечивая плавный переход между ними.

Представьте, что вы меняете смартфон: для того, чтобы сохранить все приложения, данные и настройки, вам нужно воспользоваться функцией резервного копирования в облаке. Это позволяет без труда перенести всё на новое устройство, не начиная настройку с нуля.

ERC-7779 выполняет ту же роль для кошельков Ethereum. С развитием учетных записей Ethereum, которые теперь поддерживают дополнительные функции (например, спонсорство газа, пакетирование транзакций и автоматизация), возникает необходимость переноса этих возможностей при смене кошелька.

ERC-7779 стандартизирует этот процесс, обеспечивая сохранение функциональности и безопасности при миграции.

Продолжение и примеры для новичков в комментариях

Спойлер: Что такое тестовая среда Ephemery

Разработка Ethereum требует надежных тестовых сред перед развертыванием обновлений, приложений или изменений в протоколе основной сети. Традиционные тестовые сети, такие как Goerli, Sepolia и Holesky, выполняют эту функцию, но сталкиваются с проблемами перегруженности и ограниченной доступности.

Ephemery - это временная, регулярно сбрасываемая тестовая среда Ethereum, позволяющая разработчикам начинать тестирование с чистого листа каждый месяц. В отличие от традиционных тестовых сетей, она не сохраняет историческое состояние, обеспечивая свободную от устаревших данных и перегрузок среду.

Зачем нужна тестовая сеть Ephemery?

Ephemery устраняет ключевые ограничения долгосрочных тестовых сетей:

• Перегрузка: Со временем тестовые сети Ethereum накапливают данные, увеличивая нагрузку на хранилище и снижая производительность.
• Дефицит тестового ETH: Доступ к тестовому ETH в Goerli и Sepolia может быть затруднен из-за ограниченного распределения через краны.
• Проблемы с завершенностью сети: Долгосрочные тестовые сети страдают от заброшенных валидаторов, что влияет на их стабильность и безопасность.
• Неэффективность для краткосрочных тестов: Традиционные сети не подходят для одноразовых экспериментов, необходимых для быстрого развития.
• Ephemery решает эти проблемы, автоматически сбрасываясь каждый месяц, обеспечивая новый цикл тестирования без накопленного состояния.

Продолжение в комментариях в нескольких частях

Подтвержденные EIP​

Среди подтвержденных предложений по улучшению Ethereum (EIP) для обновления Pectra есть несколько ключевых, направленных на улучшение основной инфраструктуры, работы валидаторов и мер безопасности:

1. EIP-2537: Поддержка подписей BLS < пост MMGP
   • Введение предварительно скомпилированных контрактов для операций с кривыми BLS12–381, что позволяет проверять подпись BLS и снижать сложность проверки.
2. EIP-2935: Хранение хэшей исторических блоков < пост MMGP
   • Позволяет хранить последние 8 192 хэша блоков в системном контракте, что обеспечивает более гибкую и масштабируемую модель без сохранения состояния.
3. EIP-6110: Депозиты через валидаторов< пост MMGP
   • Переносит обработку депозитов валидаторов с уровня консенсуса на уровень исполнения, повышая безопасность процесса внесения депозита.
4. EIP-7002: Исполняемые выходы для валидаторов < пост MMGP
   • Позволяет держателям ваучеров на вывод средств самостоятельно инициировать выход из процесса стейкинга, что расширяет возможности пользователей и повышает безопасность.
5. EIP-7251: Увеличение лимита стейкинга < пост MMGP
   • Повышает верхний предел балансов валидаторов для стейкинга, снижая перегрузку сети и улучшая общую производительность.
6. EIP-7549: Оптимизированное голосование на основе консенсуса < пост MMGP
   • Удаляет индекс комитета из сообщения о подписи в механизме консенсуса Ethereum, что позволяет более эффективно агрегировать голоса и снижать нагрузку на сеть.
7. EIP-7685: Запросы общего уровня исполнения < пост MMGP
   • Представляет фреймворк для обработки различных запросов уровня исполнения, что упрощает реализацию новых функций без изменения структуры блоков.
8. EIP-7702: Выполнение кода для внешних учетных записей (EOA) < пост MMGP
   • Добавляет возможности выполнения кода в EOA, что позволяет делегировать задачи смарт-контрактам, такие как пакетные транзакции или контроль разрешений.
9. EIP-4444: Предложение по улучшению Ethereum, направленное на уменьшение объема хранилища, необходимого для запуска узла < пост MMGP
10. ОСТАЛЬНЫЕ EIP в комментариях

Спойлер: EIP, которые не были включены в Pectra

Их немного

Спойлер: Знаменитые EIP 2015-2019

Их всего четыре, самые горячие

Спойлер: Первый апгрейд Homestead 2016

14 мая 2016 года разработчики Ethereum объявили о выпуске обновления Homestead — первого стабильной версии протокола, которая пришла на смену предыдущей Frontier (также известна как альфа-версия Ethereum, в которой не гарантировалась безопасность). Новая версия ПО имплементирована в блоке 1 150 000, устанивши из сети контракты Canary. Презентация апгрейда транслировалась в Google Hangout.

Обновление Homestead в Ethereum включило несколько значимых улучшений:

• EIP-2: Набор изменений в правилах консенсуса, включающих увеличение стоимости газа, ограничение максимального значения s-value подписи транзакции для лучшей защиты сети от спам-атак, модификации в алгоритме просчета сложности майнинга и исправление багов.
• EIP-7: Внедрение новой операции — DELEGATECALL.
• EIP-8: Улучшение сетевой совместимости для будущих изменений в протоколе.

После Homestead многие новые биржи и сервисы начали поддерживать Ethereum, что способствовало его дальнейшему росту и принятию в сообществе, повышению эффективности Ethereum.

Именно Homestead сделал Ethereum надежным и готовым к использованию в реальных приложениях и на практике.

уникальность

Сообщество Ethereum сталкивается с кризисом идентичности, так как токен ETH отстает от других криптовалют, а конкурирующие сети, такие как Solana, привлекают внимание и таланты из экосистемы Ethereum.

В условиях споров и критики в адрес Ethereum Foundation разработчики надеются, что Pectra поможет стабилизировать сеть и вернуть ей конкурентоспособность.

Ethereum всему голова

Экосистема Ethereum постоянно развивается. Она продолжает лидировать по общему объему заблокированных средств (TVL, доля почти 55% от всего рынка DeFi) и удерживает позицию второй по капитализации криптовалюты.

Предстоящий Pectra обещает сильно улучшить удобство использования сети как для пользователей, так и для разработчиков. Ethereum станет более универсальной, способной удовлетворить разнообразные потребности.

Виталик Бутерин уверен, что ближайшие 5 лет будут "решающими" для Ethereum в плане его массового внедрения и принятия в "реальном мире". Будущие обновления помогут Ethereum справляться с растущим спросом, интегрироваться с другими сетями и внедрять новые функции, удерживая Ethereum на передовой блокчейн-инноваций.

ПРОДОЛЖЕНИЕ В КОММЕНТАРИЯХ

уникальность

 

[Alcest]

ETH добавил 1 блокчейн Solana к своей рыночной капитализации за 3 дня )

UPD:

Обновлен стартовый пост темы

Спойлер: Про Fusaka простыми словами

Во второй половине 2025 года в сети Ethereum ожидается следующее крупное обновление — Fusaka, которое продолжит развитие платформы после успешно реализованного форка Pectra. По словам соисполнительного директора Ethereum Foundation Томаша Станчака, запуск Fusaka планируется на сентябрь или октябрь, однако точная дата хардфорка пока не определена.

Ключевые особенности Fusaka

Главным элементом обновления станет внедрение PeerDAS — технологии, призванной значительно улучшить масштабируемость Ethereum. PeerDAS (Peer-to-Peer Data Availability Sampling) позволит снизить нагрузку на ноды, повысить пропускную способность сети и подготовить инфраструктуру к увеличению объема данных. В частности, речь идёт об увеличении размеров бинарных массивов данных (BLOB) с текущих 6 МБ до 32 МБ.

Разработка PeerDAS вызвала оживленные дискуссии в сообществе. Ещё в 2024 году один из ведущих разработчиков Ethereum, Петер Силадьи, критиковал технологию, заявляя, что она может создать препятствия для домашних валидаторов и тем самым угрожать децентрализации сети. Тем не менее, команда разработчиков решила сделать PeerDAS центральным элементом Fusaka, отложив его внедрение в рамках Pectra.

Исключение Ethereum Object Format (EOF)

Одним из ожидавшихся компонентов Fusaka был Ethereum Object Format (EOF) — предложение по изменению формата байткода EVM с целью оптимизации выполнения смарт-контрактов и снижения стоимости операций. Однако Тим Бейко, ведущий координации core-разработчиков Ethereum, сообщил, что от внедрения EOF в Fusaka решено отказаться. Причина — техническая неопределённость и отсутствие консенсуса в сообществе.

Бейко также подчеркнул, что ситуация с EOF продемонстрировала слабые места в текущем процессе приоритизации предложений для хардфорков. Несмотря на поддержку EOF со стороны многих разработчиков, проект вызвал возражения у ряда участников сообщества, что привело к его исключению из текущей дорожной карты.

Стратегия и временные рамки

На сегодняшний день обновление Fusaka находится на стадии раннего планирования. Параллельно ведётся работа над формированием перечня улучшений (EIP), которые войдут в релиз. В частности, ожидается реализация предложений, направленных на снижение вычислительных узких мест, улучшение пропускной способности и подготовку к дальнейшему увеличению лимитов газа.

Хотя точный график развертывания Fusaka пока не зафиксирован, команда Ethereum придерживается активного и открытого подхода к координации — с регулярными встречами All Core Devs и техническими сессиями (ACDT), на которых формируется структура будущего обновления.

Изменено название темы на

Все о хардфорке Ethereum - FUSAKA 2025-2026 [гайд по EIP / песочницам / Pectra]​

 

[Alcest]

Кто работает над Fusaka и что может пойти не так?

За реализацией видения Fusaka стоят несколько команд из сообщества Ethereum: основные разработчики, команды клиентов, такие как Geth и Prysm, а также группы, работающие над решениями второго уровня (Layer 2).

Все эти команды должны работать слаженно. Однако история показывает, что столь масштабные проекты могут сталкиваться с препятствиями. К примеру, есть опасения по поводу несогласованности состояния сети (когда разные её части не сходятся в понимании текущей ситуации) и ошибок при восстановлении (которые могут привести к потере или искажению данных). Даже изменения в руководстве Ethereum Foundation могут замедлить прогресс, добавляя элемент неопределённости.

На первый взгляд, Fusaka кажется решением проблем масштабируемости Ethereum — быстрой «заплаткой», способной снизить комиссии и ускорить транзакции. Но на деле всё гораздо сложнее. Это тонкий баланс между стремлением к революционным изменениям и необходимостью не нарушить работу сети.

Для обычного пользователя Ethereum эти обновления могут казаться далёкими или слишком техническими. Однако выгоды вполне ощутимы. Более эффективный Ethereum — это более комфортный опыт при покупке NFT, торговле токенами или использовании децентрализованных приложений в повседневной жизни. Меньше задержек и ниже издержки — Fusaka может сделать ежедневные транзакции быстрее и надёжнее.

Будет ли Fusaka готов вовремя — вопрос открытый. Но ясно одно: это поворотный момент, который может определить будущее Ethereum на многие годы вперёд.

уникальность

 

[Alcest]

Разработчики уже начали подготовку к Fusaka, следующему обновлению сети, и на текущий момент согласовали включение предложения об улучшении Ethereum (EIP) под названием PeerDAS, которое должно помочь сети обрабатывать более крупные “blobs” — фрагменты данных, связанных с транзакциями.

Blobs, впервые представленные в обновлении Dencun, — это выделенные области для хранения больших объёмов транзакционных данных. Они сохраняются вне блокчейна, что снижает нагрузку на сеть и уменьшает комиссии (gas fees). Такие данные особенно важны для растущей экосистемы Layer 2-решений на базе Ethereum, таких как Arbitrum, Optimism и Base от Coinbase, которые позволяют обрабатывать транзакции быстрее и дешевле, чем основная сеть.

PeerDAS (Peer Data Availability Sampling — выборочная проверка доступности данных) позволит валидаторам загружать только часть данных blob’ов, а не весь объём, чтобы подтвердить, что данные действительно размещены в сети.

Теоретически PeerDAS сможет ещё больше снизить стоимость транзакций на уровне Layer 2 и принесёт пользу институциональным валидаторам Ethereum.

«PeerDAS — это очень важно, потому что мы хотим помочь масштабировать Layer 2-решения», — сказал инженер DevOps из Ethereum Foundation Паритош Джаянти в сообщении CoinDesk в Telegram. — «Он позволяет нам значительно увеличить лимит на количество blobs».

Запуск Fusaka намечен на конец 2025 года, и в него также войдут другие обновления помимо PeerDAS. Однако разработчики Ethereum известны своей непунктуальностью в реализации обновлений.

Так, Pectra изначально планировалась к запуску в конце 2024 года, но была отложена на первый квартал 2025-го. После ряда неудачных тестов обновление было снова перенесено — на май.

уникальность

 

[Alcest]

В ходе созвона разработчиков All Core Devs (ACDC) №157 обсуждалось успешное внедрение обновления Pectra. Основные темы — стабильность тестовых сетей для Fusaka, предложение изменить формат встреч ACD для лучшего планирования новых обновлений и идеи по привлечению большего числа участников сообщества.

Что нового в Pectra

Все разработники были рады, что обновление Pectra вышло без проблем. Оно успешно заработало на главных клиентах (ПО для работы с Ethereum), таких как Geth, Prysm и Lighthouse. Сеть была стабильной, и благодаря слаженной работе сообщества обновление быстро распространилось по всем элементам экосистемы Ethereum.

Один из разработчиков, Трент Ван Эппс, опубликовал «Pectra Pages» — сборник мыслей и впечатлений ключевых разработчиков, которые они записали перед обновлением.

Другой разработчик, Паритош Джаянти, рассказал, что сейчас они изучают, как увеличение количества больших данных (называемых «блобами») влияет на работу сети. Эти блобы помогают лучше хранить большие объёмы информации, что важно для второго уровня Ethereum (L2).

Что происходит с тестовой сетью Fusaka

Недавно была запущена тестовая сеть PeerDAS Devnet 7, которая сейчас работает стабильно, а команды разработчиков активно её тестируют. Основная задача — добавить поддержку BPO, что улучшит работу уровня консенсуса (части, отвечающей за подтверждение транзакций).

Следующий важный шаг — запуск Fusaka Devnet 0, запланированный на 26 мая. В этой тестовой сети впервые будут одновременно проверять функции и уровня исполнения (выполнение смарт-контрактов), и уровня консенсуса.

• Сторона консенсуса будет основываться на стабильности предыдущей сети PeerDAS Devnet 7.
• Сторона исполнения получит обновление, которое изменит стоимость газа для одной из операций, чтобы сделать её более справедливой.

Также обсуждается новая функция Validator Custody — улучшенный способ управления ключами валидаторов, которые проверяют транзакции и получают за это вознаграждение. Это повысит безопасность, позволит использовать внешние сервисы для хранения ключей и упростит работу для участников сети. Но эта функция сложная, и есть риск, что её введение может задержаться.

Предложение по изменению формата созвонов ACD

Сейчас созвоны All Core Devs делятся на обсуждения двух частей — исполнения и консенсуса — и сосредоточены на ближайшем обновлении. Тим Бейко предложил изменить это так:

• Отделить задачи — часть команды будет заниматься текущими обновлениями и срочными вопросами, а другая часть — планировать следующие обновления, чтобы лучше подготовиться заранее.
• Использовать свободное время после выхода обновлений для обсуждений, сбора идей от сообщества и приоритетов перед началом разработки.

Это поможет сделать процесс более понятным, прозрачным и даст время для долгосрочного планирования.

Однако некоторые разработчики выразили опасения, что слишком раннее переключение на будущие обновления может отвлекать от текущих задач. Также есть разногласия по тому, сколько времени уделять текущим и будущим обновлениям.

Тим пояснил, что это эксперимент, цель которого — сделать работу более эффективной и прозрачной. Если всё получится, такие изменения помогут лучше планировать развитие Ethereum и при этом не потерять скорость работы над текущими обновлениями.

уникальность

 

[Alcest]

Тем временем данная тема уже набрала 15 000 просмотров

 

[Alcest]

Разработчики Ethereum планируют начать тестирование новой функции под названием “истечение истории” с 1 июня 2025 года на тестовой сети Sepolia.

Это важный шаг на пути к обновлению Ethereum, которое сделает сеть легче, быстрее и удобнее для пользователей и разработчиков.

Что такое “истечение истории”?

Сейчас каждый узел Ethereum хранит всю историю данных сети — балансы, транзакции и т. д. Но со временем таких данных становится всё больше, и это занимает много места. Новая функция позволяет удалять устаревшие и уже не нужные данные. Это как очистка памяти на телефоне: вы удаляете старые фото, чтобы освободить место.

Так сеть станет легче, и даже простые устройства смогут подключаться к Ethereum без необходимости скачивать всю историю. Это делает Ethereum более децентрализованным и доступным для большего числа пользователей.

• Некоторые клиенты (программы, которые взаимодействуют с Ethereum), такие как Geth, уже поддерживают эту функцию. Другие (например, Erigon и Nethermind) всё ещё дорабатывают её.
• Первое тестирование пройдёт в специальной сети Sepolia. Там разработчики и команды смогут проверить, как работает удаление старых данных, и нет ли сбоев.
• Будет подготовлена документация, чтобы все участники знали, как использовать и тестировать новую функцию.
• Хотя 1 июня — это не жёсткий дедлайн, разработчики договорились использовать эту дату как ориентир.

Это тест — первый шаг к большой цели Ethereum: перейти к системе, где узлы не будут хранить всю историю, а смогут быстро проверять информацию на основе доказательств. Это сделает Ethereum более масштабируемым и эффективным, особенно для новых решений вроде rollups (технологии, ускоряющей и удешевляющей транзакции).

уникальность

 

[Alcest]

Бутерин предложил пути масштабирования Ethereum без ущерба для персональных нод

Сооснователь Ethereum Виталик Бутерин представил рекомендации по масштабированию сети, которые позволят повысить производительность, сохранив доступность запуска персональных узлов. В новом эссе он обозначил ключевые технические решения, способные облегчить участие пользователей в работе сети.

Среди предложений — внедрение:

• EIP-4444 (ограниченное хранение истории блоков);
• распределенного хранения данных о транзакциях и блоках;
• синхронизации без сохранения полного состояния (stateless verification);
• частично “облегчённых” нод с ограниченным локальным состоянием.

По словам Бутерина, полная реализация EIP-4444 позволит существенно снизить требования к объёму хранимых данных, так как каждая нода будет сохранять только последние 36 дней истории и текущее состояние Merkle-деревьев. Это устранит одно из главных препятствий для пользователей, желающих запустить собственный узел.

В случае распределённого хранения истории предлагается, чтобы каждая нода сохраняла лишь небольшую долю устаревших данных. Для надёжности можно применять стирающий код (erasure coding) — это позволит избежать централизации и снизить нагрузку на операторов узлов, сохранив долгосрочную доступность данных.

Виталик также отметил необходимость пересмотра газовой модели Ethereum: повысить стоимость хранения данных и снизить цену на выполнение операций. Такой подход, по его мнению, создаст стимулы для более эффективного использования ресурсов сети.

В среднесрочной перспективе он видит логичным переход к stateless-синхронизации, при которой ноды смогут обслуживать RPC-запросы без необходимости сохранять полное состояние. Это потенциально уменьшит требования к хранению примерно в два раза.

Дополнительно рассматривается концепция partially stateless nodes — облегчённых нод, способных работать с ограниченным подмножеством состояния. Такие узлы смогут обслуживать запросы, если нужные данные входят в их локальный набор, и будут отклонять остальные. Это открывает возможность работы персональных нод даже при значительном увеличении лимита газа на L1 (в 10–100 раз).

Предложения Бутерина подчеркивают стремление Ethereum сохранить децентрализацию и доступность, несмотря на рост масштабов сети.

 

[Alcest]

Более 11 000 авторизаций смарт-аккаунтов за неделю после обновления Pectra: Ethereum движется к улучшенному UX

С момента активации крупного обновления Pectra, число авторизаций смарт-аккаунтов, реализованных по стандарту EIP-7702, превысило 11 000 — что свидетельствует о значительном интересе со стороны бирж, Web3-кошельков и децентрализованных приложений.

Ключевым нововведением стал EIP-7702, который позволяет обычным адресам (EOA) временно функционировать как смарт-контракты во время проведения транзакции. После выполнения операции адрес возвращается к своему первоначальному виду. Это решение открывает путь к более гибкому и удобному взаимодействию с сетью Ethereum без необходимости полного перехода на контрактные кошельки.

Теперь EOA-адрес может делегировать выполнение операций смарт-контракту с помощью специального флага в транзакции. При необходимости делегацию можно отменить — пользователь сохраняет полный контроль над активами. Это дает возможность реализовать такие функции, как мультиподпись, лимиты трат, автоплатежи, а также оплату газа в других токенах, кроме ETH.

По данным дашборда Dune, подготовленного Entropy Advisors, почти половина всех авторизаций пришлась на биржу WhiteBIT — свыше 5300. Аналитики The Block предполагают, что платформа применяет делегацию для оптимизации пользовательских операций, включая агрегированные транзакции и покрытие комиссий.

Среди кошельков лидирует OKX Wallet, собравший более 3100 авторизаций. MetaMask, несмотря на меньшее число делегаций (около 1300), удерживает больше ETH в смарт-контрактах, что может говорить о более высокой активности или объемах пользователей.

Помимо EIP-7702, в рамках обновления Pectra были внедрены и другие улучшения. Некоторые из них касаются механики работы валидаторов, а также направлены на повышение масштабируемости и общей эффективности сети Ethereum.

Pectra демонстрирует переход Ethereum от инфраструктурных апдейтов к улучшению пользовательского опыта, создавая более интуитивную и функциональную экосистему для всех участников сети.

 

[Alcest]

 

[Alcest]

All Core Developers Execution (ACDE) Call #213​

часть 1

На 213-м созвоне All Core Devs Execution (ACDE) разработчики Ethereum сосредоточились на предстоящем обновлении Fusaka, подготовке ко второму Devnet и ранних обсуждениях ключевых EIP для будущего форка Glamsterdam. Однако в центре внимания оказалась горячая тема — потенциальное увеличение лимита газа до 60 миллионов.

Предложение — поднять потолок газа до 60 млн без хардфорка, что расширит пространство блока и увеличит пропускную способность сети. Тестирование уже идёт на сети Hoodi, но разработчики разошлись во мнениях: одни выступают за резкий скачок, другие — за постепенное повышение.

В чём дилемма?

• Резкое увеличение даёт мгновенные преимущества в масштабируемости, но создаёт риск нестабильности и неожиданных последствий.
• Плавное повышение (например, с 45 до 50, затем до 60 млн) безопаснее, но требует больших координационных затрат и времени.

Кто рискует оказаться за бортом?

Micah Zoltu на созвоне выразил обеспокоенность: в обсуждении доминируют крупные валидаторы и блок-билдеры, в то время как локальные пользователи и RPC-провайдеры остаются без внимания.

По его словам, без компенсирующих изменений (таких как state pruning) рост лимита приведёт к ускоренному накоплению данных. Это угрожает первоначальной идее Ethereum как доступной децентрализованной сети.

Кто как справится с повышением лимита:

• Блок-билдеры — обладают мощной инфраструктурой, для них рисков нет.
• Домашние валидаторы — могут столкнуться с необходимостью апгрейда железа.
• RPC-провайдеры (например, Infura) — способны адаптироваться без проблем.
• Обычные пользователи — главные пострадавшие, их могут вытеснить требования к диску и скорости сети.

Сейчас полноценный узел может работать на ~80 ГБ, но с удвоением лимита газа объём состояния будет расти на 6 ГБ в месяц. Через несколько лет это может превысить 1 ТБ.

Разработчики также обсудили EIP-7870, который вводит ограничения на использование ресурсов узла. Однако он получил критику за недостаточное внимание к потребностям домашних RPC-операторов.

Решение пока не принято. Дискуссия продолжится в Discord-канале #gas-limit-testing. Следующая встреча разработчиков состоится через две недели — ближайшие созвоны отменены из-за очных встреч.

уникальность

 

[Alcest]

стремление Ethereum сохранить децентрализацию и доступность

Вот это мне нравится:

 

[OkMonday]

Вот это мне нравится:

Посмотреть вложение 397670

Что то прям невероятное )

 

[Alcest]

Что то прям невероятное )

В периоды затишья на рынке Эфириум очень доступный для платежей )

 

[Alcest]

Сеть Ethereum готовится к одному из самых важных этапов масштабирования — запуску основной сети Fusaka, который запланирован на 5 ноября 2025 года. Этот шаг стал возможен после тщательных тестов на девсетях, поэтапного внедрения увеличенной пропускной способности и согласования команд разработчиков к готовности и управлению рисками.

Путь к запуску Fusaka Mainnet

Во время встречи All Core Developers Consensus (ACDC) #162 был утверждён поэтапный график подготовки к запуску основной сети в ноябре.

Основные даты:

• 1 сентября 2025 — выпуск клиентов для Holesky и Sepolia
• 8 сентября 2025 — старт программы по поиску багов (bug bounty)
• 15 сентября 2025 — форк Holesky
• 22 сентября 2025 — форк Sepolia
• 1 октября 2025 — выпуск клиента для основной сети и форк Hoodi
• 8 октября 2025 — активация форка Hoodi
• 5 ноября 2025 — запланированный запуск Fusaka mainnet

Разработчики предупреждают, что даже небольшие задержки могут привести к сдвигу сроков на несколько месяцев из-за праздничного периода в конце года.

Тестирование на девсетях и сценарии с отсутствием финализации

Devnet-3 Fusaka показал 100% участие валидаторов во время стресс-тестов, имитировавших:

• Отключение валидаторов (полных узлов и супервузлов)
• Ограничение пропускной способности до 1 Мбит/с для 30% сети
• Разделение и повторное объединение сети с помощью инструмента Tyler’s Chaos Tool

8 августа 2025 года запущен Devnet-4, который имитирует 10% нагрузки основной сети в течение одного дня для проверки пропускной способности и устойчивости клиентов под нагрузкой.

Управление рисками

Разработчики, включая Мэттью Кайла, выразили озабоченность из-за незавершённого слияния кода, неполного тестирования приватного мемпула и отсутствия заморозки спецификаций.

Для снижения рисков предусмотрено:

• Форк Holesky с использованием нестабильных веток, чтобы отделить циклы выпуска клиентов
• Запуск Devnet-5 после Holesky для финального тестирования перед основной сетью
• Параллельное проведение тестов для избежания узких мест

Команды клиентов Prysm, Nimbus и Teku уверены в соблюдении сроков сентябрьских форков и продолжают тестирование.

уникальность

 

[Alcest]

Ethereum закроет публичную тестовую сеть Holešky, переход на Hoodi стартует через две недели

Ethereum готовится к закрытию своей крупнейшей публичной тестовой сети Holešky. Соответствующее объявление команда поддержки протокола Ethereum Foundation сделала 1 сентября, запустив двухнедельный отсчет до окончания работы сети. Этот шаг станет финалом одной из крупнейших сред для публичного тестирования.

Процесс закрытия начнется после завершения обновления Fusaka, после чего клиентские команды будут вынуждены отключить подавляющее большинство нод валидаторов. По завершении двухнедельного периода Holešky полностью перестанет поддерживаться — дальнейшее обслуживание и инфраструктура со стороны основных команд разработки прекращаются.

Тестовая сеть Holešky была создана для работы с большим числом валидаторов, предоставляя поставщикам инфраструктуры и стейкинговым сервисам возможность стресс-тестирования обновлений протокола, таких как Dencun и Pectra, в условиях, максимально приближенных к основной сети. В марте 2025 года была представлена новая среда Hoodi, предназначенная для эффективной обработки операций валидаторов с полной поддержкой всех функций Pectra и обновлений, включая Fusaka.

Ethereum Foundation предоставила четкие рекомендации по миграции для всех проектов, работающих в Holešky. Операторам стейкинга и провайдерам нод рекомендовано перенести тестовые операции в Hoodi. Разработчикам приложений и смарт-контрактов советуется использовать сеть Sepolia, которая остается основной тестовой средой для децентрализованных приложений и инструментов.

 

[Alcest]

All Core Developers Consensus (ACDC) #167

Во время созвона All Core Developers Consensus (ACDC) #167 разработчики Ethereum приняли важное решение: механизм Trustless Payments (доверенные выплаты) будет встроен в обновление Glamsterdam V1 вместе с системой Proposer-Builder Separation (ePBS) — разделением ролей валидаторов и строителей блоков.

Такое объединение создаёт прозрачный механизм взаиморасчётов прямо в блокчейне, снижая зависимость от внешних (off-chain) посредников и улучшая прозрачность процесса формирования блоков.

Что обсуждали

Главная дискуссия на созвоне касалась того, стоит ли внедрять Trustless Payments в составе ePBS или как отдельное обновление Ethereum (EIP). Trustless Payments позволяет передавать вознаграждения между строителями и валидаторами напрямую в блокчейне, без участия централизованных реле (relay-сервисов).

Одни разработчики предлагали вынести механизм отдельно, чтобы упростить реализацию и избежать лишней сложности. Другие настаивали, что разделение на ранней стадии приведёт к фрагментации разработки и затянет тестирование.

В итоге сообщество пришло к компромиссу: в Glamsterdam V1 Trustless Payments останется встроенным в ePBS, чтобы обеспечить цельную реализацию и совместное тестирование. Позже, в версии Glamsterdam V2, возможен переход к более модульной архитектуре.

Влияние на валидаторов, строителей блоков и стейкинг

Интеграция ePBS и Trustless Payments — крупный шаг к децентрализации и прозрачной экономике блоков Ethereum.
Теперь выплаты между участниками будут фиксироваться на самой цепочке (on-chain), что уменьшит зависимость от непрозрачных off-chain схем.

Операторы ликвидного стейкинга, такие как Lido и Rocket Pool, отметили, что появление двойных путей выплат (ончейн и оффчейн) потребует:

• улучшенного мониторинга и аудита;
• обновления систем учёта;
• поддержки fallback-механизмов на случай перегрузки ончейн-платежей.

Что дальше: план внедрения

Интеграция ePBS + Trustless Payments станет основным направлением работы консенсусных команд Ethereum в ближайшие месяцы. Разработчики клиентов уже начали подготовку к полному внедрению V1, которое стартует после успешного завершения обновления Fusaka в основной сети.

Параллельно строителям блоков и операторам реле рекомендовано тестировать ончейн-платежные сценарии в закрытых средах (sandbox), чтобы быть готовыми к Devnet-тестам. Стейкинговые протоколы должны адаптировать свои системы под двойной платёжный поток с прозрачной отчётностью и fallback-логикой.

Почему это важно

Решение сохранить Trustless Payments внутри ePBS демонстрирует подход Ethereum к эволюции сети — надёжные и постепенные обновления вместо поспешных разрывов архитектуры. Glamsterdam станет ключевым этапом, где на Devnet будет проверено, как интегрированная модель выдерживает нагрузку в реальных условиях.

 

[Alcest]

Основные итоги созвона All Core Developers Consensus (ACDC) #167

ЧАСТЬ 1

На недавнем созвоне All Core Developers Consensus (ACDC) #167 разработчики Ethereum обсудили прогресс обновления Fusaka и подготовку к следующему крупному релизу Glamsterdam.

Основные выводы: Devnet-сети работают стабильно, форки Holesky и Sepolia прошли без серьёзных проблем, а конкурс на проверку безопасности завершился без критических уязвимостей.

Fusaka: готовность к декабрьскому запуску

DevNet-3 работает стабильно. Ранее выявленные мелкие баги с базой данных и «потерей» блоков (blob-dropping) уже исправлены. Клиенты Ethereum не показывают серьёзных сбоев, и сеть готовится к переходу на продакшн.

Форки Holesky и Sepolia также прошли успешно, подтвердив, что системы клиентов ведут себя корректно. Безопасность Fusaka проверена, высоких рисков для переноса на mainnet не обнаружено.

Разработчики подчеркнули, что сети Devnet должны использоваться как настоящие тестовые среды, а не для работы в реальном времени. Многие проекты Layer-2 (rollups) используют публичные тестовые сети, что может скрывать последние ошибки перед запуском. Рекомендуется проверять обновления на поздних Devnet-сетях, таких как DevNet-3, чтобы минимизировать риски.

Оптимизация работы сети

Большое внимание уделялось оптимизации передачи больших блоков данных (blobs). Разработчики предложили несколько способов уменьшить нагрузку и затраты:

• Лёгкие суперноды — узлы хранят минимальный набор данных для восстановления блоков.
• Отслеживание на уровне исполнения (EL) — хранение данных только для транзакций конкретного rollup.
• Резервное использование mempool — получение данных из общей очереди транзакций при необходимости.
• Хранение больше доказательств и меньше «тяжёлых» ячеек — экономия до 50% ресурсов.

Эти меры позволят сократить расходы и ускорить работу сети без потери надёжности.

 

[Alcest]

Основные итоги созвона All Core Developers Consensus (ACDC) #167

ЧАСТЬ 2

Glamsterdam: Trustless Payments и ePBS

Следующее крупное обновление, Glamsterdam, обсуждалось особенно подробно. Главный вопрос: оставить Trustless Payments встроенными в ePBS или вынести отдельно.

Trustless Payments — это механизм прямых выплат между строителями блоков и валидаторами внутри блокчейна, без участия сторонних посредников. Это снижает зависимость от внешних реле и повышает прозрачность.

После обсуждений было решено сохранять Trustless Payments внутри ePBS в версии V1, чтобы обеспечить цельную реализацию. Возможность модульного разделения оставят на Glamsterdam V2 после стабилизации сети.

Операторы ликвидного стейкинга, такие как Lido и Rocket Pool, отметили, что с двумя потоками выплат (он- и оффчейн) потребуется усиленный мониторинг и аудит.

Следующие шаги

• Разработчики клиентов начинают полную реализацию ePBS + Trustless Payments V1.
• Тесты на Devnet планируются после стабилизации Fusaka.
• Стейкинговые протоколы должны подготовить системы учёта для двух потоков выплат.
• Летние EIP, например EIP-7688, будут мониториться, но их окончательная интеграция откладывается до стабилизации Fusaka.

Главная цель — надёжные постепенные обновления, без поспешного внедрения новых функций, чтобы избежать ошибок и сбоев в сети.

Ethereum Governance: контроль за обновлениями

Ethereum использует пошаговый процесс обновлений: дизайн функции → тесты в Devnet → публичные тестнеты → mainnet.

Каждый созвон ACDC проверяет готовность сети (temperature check), чтобы все клиенты и сторонние проекты могли синхронизироваться. Такой подход предотвращает внезапные ошибки и позволяет участникам экосистемы заранее готовиться к изменения

Разработчики также договорились лучше документировать все изменения в RPC и API, чтобы пользователи и команды могли понимать, что меняется

В результате Ethereum продвигается к безопасным и прозрачным обновлениям, а Devnet остаются ключевой площадкой для проверки новых функций перед полноценным запуском.

уникальность

 

[Alcest]

Созвон Ethereum All Core Devs #223: тестирование Fusaka и новые подходы к обновлениям сети

23 октября 2025 года состоялся 223-й созвон разработчиков Ethereum (All Core Devs Execution Call, ACDE). Основные темы встречи — ход тестирования предстоящих обновлений сети, управление предложениями (EIP) и стратегия изменения стоимости операций («газовых» комиссий).

Ключевые темы:

• тестирование сетей Fusaka (Sepolia, Hoodi, Holesky);
• новые правила для второстепенных предложений EIP в грядущем обновлении Glamsterdam;
• координация между командами клиентов (программ, которые обеспечивают работу Ethereum);
• пересмотр стоимости транзакций и оптимизация расхода газа;
• обсуждение EIP-8058, направленного на оптимизацию байткода (выполняемого кода смарт-контрактов);
• удаление ряда EIP из списка предложений, планировавшихся к включению в обновление.

Прогресс по тестовой сети Fusaka

Разработчик Барнабаш Буса сообщил, что тестовая сеть Fusaka Devnet 3 работает стабильно — к ней подключено около 99% клиентов (программ, поддерживающих сеть Ethereum). После недавнего обновления Lighthouse удалось устранить старые ошибки.

В сети Sepolia несколько дней назад запустился первый этап тестирования (BPO1) — это важный шаг, позволяющий проверить, как система справляется с повышенной нагрузкой на хранение данных. Второй этап (BPO2) запланирован через четыре дня.

Следующей сетью, где пройдет обновление Fusaka, станет Hoodi — активация ожидается через пять дней. Разработчиков и операторов узлов (валидаторов) предупредили, что им нужно заранее обновить программное обеспечение, иначе их узлы пропустят часть данных и не смогут участвовать в подтверждении блоков.

Отдельно сообщалось, что старая тестовая сеть Holesky прекращает работу — активность в ней упала, и сеть больше не может стабильно обрабатывать блоки. Полное отключение запланировано на следующую пятницу, а всех операторов призвали перейти на Sepolia или Hoodi.

После обзора тестовых сетей Алекс Стокс предложил график активации Fusaka в основной сети Ethereum (mainnet):

• 3 декабря 2025 — запуск Fusaka mainnet,
• 9 декабря — активация первого этапа BPO1,
• 7 января 2026 — второго этапа BPO2.

Первоначально планировалось запустить обновление 17 декабря, но график изменили, чтобы не пересекаться с праздничным периодом.

Хотя обычно точные даты утверждаются после того, как тестовые сети полностью завершат тестирование, Стокс отметил, что предварительное объявление сроков помогает разработчикам клиентов и сообществу лучше подготовиться.

Также обсуждалось новое предложение (на GitHub под номером 1780), которое позволит назначать дату обновления основной сети уже после успешного завершения теста хотя бы на одной сети, а не на всех. Это ускорит процесс координации, но при этом даты всё равно будут оставаться гибкими.

Новый процесс для «неосновных» предложений EIP

Следующий блок обсуждения касался новой схемы работы с EIP — предложениями по улучшению Ethereum. Обычно обновления сети включают несколько «главных» (headliner) предложений, которые меняют ключевые механизмы сети. Теперь вводится отдельный процесс для «второстепенных» (non-headliner) предложений, которые не столь масштабны, но важны для стабильности и улучшения протокола.

Авторы процесса — ansgar.eth и ralexstokes — пояснили, что это экспериментальная система, впервые применяемая на практике. Она позволит лучше организовать работу над менее крупными инициативами и сделать процесс более прозрачным.

Согласно плану, в течение недели после подачи предложения автор должен явно указать, что хочет включить его в список рассматриваемых. А через две недели — завершить все формальности и внести текст EIP в общий репозиторий.

На момент созвона рассматривалось около 31 EIP. После завершения двухнедельного периода разработчики подготовят общий отчет с обратной связью по ним.

В рамках нового подхода достаточно даже короткого комментария о намерении в специальном разделе, чтобы EIP был зафиксирован в системе. Это делает процесс менее бюрократичным и более гибким.

Координация между командами клиентов

Так как обновление Glamsterdam больше затрагивает «исполнительный» уровень Ethereum (Execution Layer), основные задачи ложатся на команды, которые поддерживают эти клиенты (например, Geth, Nethermind, Besu и др.).

Они должны подготовить короткие документы с мнением по ключевым группам предложений — например, по изменениям стоимости газа или структуре данных. Делать детальный анализ каждого EIP не требуется.

Эти документы нужно представить к следующему созвону, 6 ноября, чтобы к концу месяца можно было согласовать позиции и окончательно утвердить состав обновления.

Также призвали всех авторов EIP быть на связи — им могут понадобиться уточнения. Быстрая обратная связь и открытая коммуникация важнее формальностей.

Главная цель — сделать процесс подготовки обновления эффективным, прозрачным и удобным как для занятых команд клиентов, так и для авторов предложений. Это должно обеспечить, чтобы обновление Glamsterdam было сбалансированным — сочетало технические инновации с организационной дисциплиной.

 

[Alcest]

ЧАСТЬ 2 — Ethereum All Core Devs #223

Пересмотр стоимости операций и точность расчёта «газа»

Во время созвона Мария подняла тему изменения цен на операции в Ethereum и точности вычисления комиссий («газа»). Она отметила, что почти треть всех предложений, включённых в план обновления Glamsterdam, связаны именно с пересмотром стоимости выполнения разных операций.

Чтобы не перегружать основные собрания разработчиков (All Core Devs), Мария предложила провести два отдельных совещания, посвящённых только вопросам пересмотра стоимости газа. Это позволит командам клиентов и исследователям более глубоко проработать технические детали, выявить связи между разными предложениями и попытаться выработать единые стандарты, не отвлекаясь на вопросы управления и принятия решений.

Такой формат нужен потому, что многие из 31 предложений касаются перерасчёта стоимости вычислений, хранения данных или доступа к состоянию блокчейна. Один обычный созвон просто не позволит всё обсудить. Отдельные встречи дадут полную картину и помогут избежать ситуаций, когда решения по связанным предложениям принимаются вразнобой.

Ошибки округления и идея «миллигаза»

Далее Мария представила исследование о том, как округление при расчёте газа влияет на итоговую стоимость транзакций. Сейчас все значения в Ethereum выражаются целыми числами. Например, если операция должна стоить 0,8 единицы газа, она округляется до 1. В результате сеть систематически немного «переплачивает».

По оценкам Марии, средняя ошибка округления может достигать примерно 4% на каждый блок — и с ростом детализации расчётов это искажение может стать заметным.

Чтобы решить проблему, она предложила два варианта:

1. Пересчитать систему единиц газа, увеличив масштаб, например, в 1000 раз. Это превратит прежние дробные значения в целые, но потребует изменений в настройках сети и инструментах разработчиков.
2. Ввести внутреннюю дробную единицу учёта — “миллигаз”. В этом случае система будет считать всё с высокой точностью, но пользователи по-прежнему будут видеть привычные целые числа. Однако реализация такого подхода усложнит код клиентов и может повлиять на возврат комиссий.

Разработчики клиентов высказали разные мнения. Команда Erigon считает, что подобная точность — лишь незначительная оптимизация, поскольку реальные затраты сильно зависят от оборудования и условий выполнения кода.
Potuz добавил, что текущие расчёты делаются исходя из скорости выполнения блока примерно в 2 секунды, а в обновлении Glamsterdam длительность блока увеличится до 8 секунд — значит, и методику нужно будет пересмотреть.

Участники сошлись на том, что пока рано фиксировать какие-либо постоянные значения. Сначала нужно собрать больше данных и провести сравнительные тесты.

EIP-8058: Оптимизация при развёртывании контрактов

Разработчик CPerezz19 представил предложение EIP-8058, которое поможет снизить затраты при размещении смарт-контрактов. Сейчас, даже если идентичный код уже есть в блокчейне, новый контракт всё равно оплачивает полную стоимость хранения.

EIP-8058 предлагает механизм, который позволит системе распознавать, что код уже существует, и не взимать повторную плату. Разработчик сможет заранее указать в специальном списке (access list) адрес контракта, где уже хранится такой же код. Если при развертывании хэш совпадёт, сеть пропустит повторное начисление за хранение.

Первый контракт в блоке всегда оплачивает полную сумму, но все последующие с тем же кодом получат скидку. Это особенно важно, так как в Glamsterdam ожидаются другие изменения, которые сделают развёртывание контрактов дороже.

Некоторые участники спросили, будет ли это решение совместимо с будущими изменениями вроде разделения кода на части (code chunking) и перехода к структуре Verkle trees. После обсуждения разработчики решили включить EIP-8058 в официальный список предложений, планируемых к реализации (Proposed for Inclusion).

Удалённые предложения

Из списка активных предложений Glamsterdam удалили два EIP, чтобы сократить нагрузку на команды и сосредоточиться на реально продвигаемых инициативах:

• EIP-7667 — его автор перестал участвовать в работе, а команда, занимавшаяся Zero-Knowledge-технологиями, подтвердила, что это предложение лучше отложить;
• EIP-6873 — зависит от будущих изменений в Verkle trees, поэтому сейчас не имеет смысла.

После созвона оба предложения официально исключат из списка.

Теперь каждая команда, поддерживающая клиентов Ethereum, должна до 6 ноября подготовить краткий документ со своим мнением о текущих темах и предложениях. Это поможет к концу ноября определить, какие из них попадут в финальный состав обновления Glamsterdam.

Если список задач окажется слишком большим, часть обсуждений могут вынести на отдельный технический звонок, посвящённый только исполнению (Execution Layer).