Гламстердам

Предстоящее обновление Эфириума Гламстердам призвано расчистить путь для следующего поколения масштабирования. Название Гламстердам образовано от сочетания слов «Amsterdam» (обновление уровня исполнения, названное в честь предыдущего места проведения Devconnect) и «Gloas» (обновление уровня консенсуса, названное в честь звезды).

Опираясь на прогресс, достигнутый в обновлении Фусака, Гламстердам фокусируется на масштабировании уровня 1 (l1) путем реорганизации того, как сеть обрабатывает транзакции и управляет своей растущей базой данных, фундаментально обновляя то, как Эфириум создает и проверяет блоки.

В то время как Фусака была сосредоточена на фундаментальных улучшениях, Гламстердам продвигает цели «Масштабирование уровня 1 (l1)» и «Масштабирование BLOB-объектов», закрепляя разделение обязанностей между различными участниками сети и внедряя более эффективные способы обработки данных для подготовки к параллелизации с высокой пропускной способностью.

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

Улучшения, рассматриваемые для Гламстердама

Обновление Гламстердам сосредоточено на трех основных целях:

• Ускорение обработки (параллелизация): Реорганизация того, как сеть записывает зависимости данных, чтобы она могла безопасно обрабатывать множество транзакций одновременно, а не в медленной последовательности одна за другой.
• Расширение пропускной способности: Разделение тяжелой работы по созданию и проверке блоков, что дает сети больше времени для распространения больших объемов данных без замедления.
• Предотвращение раздувания базы данных (устойчивость): Корректировка сетевых комиссий для точного отражения долгосрочных затрат на оборудование для хранения новых данных, разблокирование будущего увеличения лимита газа при предотвращении снижения производительности оборудования.

Короче говоря, Гламстердам внесет структурные изменения, чтобы гарантировать, что по мере увеличения пропускной способности сети она будет оставаться устойчивой, а производительность — высокой.

Масштабирование уровня 1 (l1) и параллельная обработка

Значимое масштабирование уровня 1 (l1) требует отхода от внепротокольных допущений о доверии и ограничений последовательного исполнения. Гламстердам решает эту проблему путем закрепления разделения определенных обязанностей по созданию блоков и внедрения новых структур данных, которые позволяют сети подготовиться к параллельной обработке.

Главное предложение: Закрепленное разделение предлагающего и создающего (ePBS)

• Устраняет внепротокольные допущения о доверии и зависимость от сторонних ретрансляторов (relays)
• Поддерживает масштабирование уровня 1 (l1), позволяя передавать гораздо большие полезные нагрузки исполнения через расширенные окна распространения
• Внедряет не требующие доверия платежи сборщикам непосредственно в протокол
• Требует архитектурных обновлений для пулов стейкинга, чтобы обеспечить не требующий доверия мониторинг, хотя в целом пользовательский опыт стейкинга улучшается за счет усовершенствованного процесса выбора сборщика

В настоящее время процесс предложения и создания блоков включает передачу между предлагающими блоки (proposers) и сборщиками блоков (builders). Отношения между предлагающими и сборщиками не являются частью основного протокола Эфириума, поэтому они опираются на доверенное стороннее промежуточное программное обеспечение, программы (ретрансляторы) и внепротокольное доверие между организациями.

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

Закрепленное разделение предлагающего и создающего (ePBS, или EIP-7732) формально отделяет работу предлагающего (который выбирает блок консенсуса) от сборщика (который собирает полезную нагрузку исполнения), закрепляя эту передачу непосредственно в протоколе.

Встраивание не требующего доверия обмена полезной нагрузки блока на оплату непосредственно в протокол устраняет необходимость в стороннем промежуточном программном обеспечении (таком как MEV-Boost). Однако сборщики и предлагающие по-прежнему могут использовать внепротокольные ретрансляторы или промежуточное программное обеспечение для сложных функций, которые еще не являются частью основного протокола.

Чтобы устранить узкое место «горячего пути», ePBS также вводит Комитет по своевременности полезной нагрузки (PTC) и логику двойного дедлайна, позволяя валидаторам отдельно подтверждать блок консенсуса и своевременность полезной нагрузки исполнения для максимизации пропускной способности.

Разделение ролей предлагающего и сборщика на уровне протокола расширяет окно распространения (или время, доступное для распространения данных по сети) с 2 секунд до примерно 9 секунд.

Заменяя внепротокольное промежуточное программное обеспечение и ретрансляторы внутрипротокольными механизмами, ePBS снижает зависимости от доверия и позволяет Эфириуму безопасно обрабатывать гораздо большие объемы данных (например, больше BLOB-объектов для ) без нагрузки на сеть.

Ресурсы: Техническая спецификация EIP-7732 (opens in a new tab)

Главное предложение: Списки доступа на уровне блока (BAL)

• Устраняет узкие места последовательной обработки, предоставляя предварительную карту всех зависимостей транзакций, подготавливая почву для того, чтобы валидаторы могли обрабатывать множество транзакций параллельно, а не одну за другой
• Позволяет узлам обновлять свои записи, считывая окончательные результаты без необходимости повторного воспроизведения каждой транзакции (синхронизация без исполнения), что значительно ускоряет синхронизацию узла с сетью
• Устраняет необходимость в догадках, позволяя валидаторам предварительно загружать все необходимые данные сразу, а не обнаруживать их шаг за шагом, что делает валидацию намного быстрее

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

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

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

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

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

Обмен списками доступа к блокам eth/71

Обмен списками доступа к блокам (eth/71 или EIP-8159) — это прямое сетевое дополнение к спискам доступа на уровне блока. В то время как BAL открывают возможность параллельного исполнения, eth/71 обновляет одноранговый протокол, чтобы позволить узлам фактически обмениваться этими списками по сети. Теперь обязательный для всех клиентов уровня исполнения, обмен списками доступа к блокам обеспечит более быструю синхронизацию и позволит узлам выполнять обновления состояния без исполнения.

Ресурсы:

• Техническая спецификация EIP-7928 (opens in a new tab)
• Техническая спецификация EIP-8159 (opens in a new tab)

Устойчивость сети

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

Увеличение стоимости газа для создания состояния

• Гарантирует, что комиссии за создание новых аккаунтов или смарт-контрактов точно отражают долгосрочную нагрузку, которую они возлагают на базу данных Эфириума
• Устанавливает фиксированную стоимость за байт состояния (CPSB), нацеленную на безопасный и предсказуемый темп роста в 120 ГиБ/год, гарантируя, что стандартное физическое оборудование сможет продолжать поддерживать работу сети
• Выделяет учет этих конкретных комиссий в новый резервуар, снимая старые ограничения на транзакции и позволяя разработчикам развертывать более крупные и сложные приложения

Добавление новых аккаунтов, токенов и создает постоянные данные (известные как «состояние»), которые каждый компьютер, поддерживающий работу сети, должен хранить бесконечно. Текущие комиссии за добавление или чтение этих данных непоследовательны и не обязательно отражают фактическую долгосрочную нагрузку на хранение, которую они возлагают на оборудование сети.

Некоторые действия, создающие состояние в Эфириуме, такие как создание новых аккаунтов или развертывание крупных смарт-контрактов, были относительно недорогими по сравнению с постоянным пространством для хранения, которое они занимают на узлах сети, например, развертывание контракта обходится значительно дешевле за байт, чем создание слотов хранения.

Без корректировки рост состояния Эфириума стал бы неустойчивым по мере масштабирования сети к базовому лимиту газа в 200 млн, обеспечиваемому Гламстердамом (в настоящее время разработчики тестируют эталонный блок с лимитом газа в 150 млн для получения точного ценообразования состояния).

Увеличение стоимости газа для создания состояния (или EIP-8037) гармонизирует затраты, привязывая их к фактическому размеру создаваемых данных, обновляя комиссии так, чтобы они были пропорциональны объему постоянных данных, которые операция создает или к которым обращается.

EIP-8037 также вводит модель резервуара для более предсказуемого управления этими затратами; списания газа за состояние сначала производятся из state_gas_reservoir, а код операции GAS возвращает только gas_left, предотвращая неправильный расчет доступного газа фреймами исполнения. Для поддержки этого важным фоновым задачам предоставляется дополнительный лимит топлива, который направляется прямо в этот выделенный резерв, гарантируя, что критически важные сетевые операции не завершатся сбоем просто потому, что хранение постоянных данных требует больше ресурсов.

До EIP-8037 как вычислительная работа (активная обработка), так и постоянное хранение данных (сохранение смарт-контракта в базе данных сети) разделяли один и тот же лимит газа. Модель резервуара разделяет учет: лимит газа для фактической вычислительной работы транзакции (обработки) и для долгосрочного хранения данных (газ состояния). Разделение этих двух параметров помогает предотвратить ситуацию, когда огромный размер данных приложения исчерпывает лимит газа; пока разработчики предоставляют достаточно средств для заполнения резервуара для хранения данных, они могут развертывать гораздо более крупные и сложные смарт-контракты.

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

Ресурсы: Техническая спецификация EIP-8037 (opens in a new tab)

Обновление стоимости газа для доступа к состоянию

• Увеличивает стоимость газа, когда приложения считывают или обновляют информацию, постоянно хранящуюся в Эфириуме (коды операций доступа к состоянию), чтобы точно соответствовать вычислительной работе, требуемой этими командами
• Укрепляет устойчивость сети, предотвращая атаки типа «отказ в обслуживании», которые используют искусственно дешевые операции чтения данных

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

В результате некоторые конкретные команды в настоящее время недооценены по отношению к работе, которую они заставляют выполнять узел. Например, EXTCODESIZE и EXTCODECOPY недооценены, поскольку они требуют двух отдельных чтений базы данных: одного для объекта аккаунта, а второго — для фактического размера кода или байт-кода.

Обновление стоимости газа для доступа к состоянию (или EIP-8038) увеличивает константы газа для кодов операций доступа к состоянию, таких как поиск данных аккаунта и контракта, чтобы они соответствовали производительности современного оборудования и размеру состояния.

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

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

Ресурсы: Техническая спецификация EIP-8038 (opens in a new tab)

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

Устойчивость сети

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

Исключение подвергнутых слэшингу валидаторов из числа предлагающих

• Предотвращает выбор оштрафованных (подвергнутых слэшингу) валидаторов для предложения будущих блоков, устраняя гарантированно пропущенные слоты
• Обеспечивает бесперебойную и надежную работу Эфириума, предотвращая серьезные остановки в случае массового слэшинга

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

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

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

Ресурсы: Техническая спецификация EIP-8045 (opens in a new tab)

Разрешение выходам использовать очередь консолидации

• Закрывает лазейку, которая позволяет валидаторам с высоким балансом выходить из сети быстрее, чем более мелким валидаторам, через очередь консолидации
• Позволяет обычным выходам переполняться в эту вторую очередь, когда в ней есть свободная емкость, сокращая время вывода средств из стейкинга в периоды больших объемов
• Поддерживает строгую безопасность, чтобы избежать изменения основных пределов безопасности Эфириума или ослабления сети

Поскольку обновление Пектра увеличило максимальный эффективный баланс для валидаторов Эфириума с 32 ETH до 2048 ETH, техническая лазейка позволяет валидаторам с высоким балансом выходить из сети быстрее, чем более мелким валидаторам, через очередь консолидации.

Разрешение выходам использовать очередь консолидации (или EIP-8080) демократизирует очередь консолидации для всех выходов из стейкинга, создавая единую справедливую очередь для всех.

Чтобы разобрать, как это работает сегодня:

• Лимит текучести Эфириума — это предел безопасности скорости, с которой валидаторы могут входить, выходить или объединять (консолидировать) свои застейканные ETH, чтобы гарантировать, что безопасность сети никогда не будет дестабилизирована
• Поскольку консолидация валидатора — это более тяжелое действие с большим количеством движущихся частей, чем стандартный выход валидатора, она съедает большую часть этого бюджета безопасности (лимита текучести)
• В частности, протокол диктует, что точная стоимость безопасности одного стандартного выхода составляет две трети (2/3) стоимости одной консолидации

Более справедливые очереди на выход позволят стандартным выходам заимствовать неиспользуемое пространство из очереди консолидации в периоды высокого спроса на выход, применяя обменный курс «3 к 2» (на каждые 2 неиспользуемых места консолидации сеть может безопасно обработать 3 стандартных выхода). Этот коэффициент текучести 3/2 балансирует спрос между очередями консолидации и выхода.

Демократизация доступа к очереди консолидации увеличит скорость, с которой пользователи могут вывести свой стейк в периоды высокого спроса, до 2,5 раз без ущерба для безопасности сети.

Ресурсы: Техническая спецификация EIP-8080 (opens in a new tab)

Улучшение пользовательского опыта и опыта разработчиков

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

Снижение внутренних затрат газа на транзакции

• Снижает базовую комиссию за транзакции, уменьшая общую стоимость простого нативного платежа в ETH
• Делает небольшие переводы более доступными, повышая жизнеспособность Эфириума как повседневного средства обмена

Сегодня все транзакции в Эфириуме имеют фиксированную базовую комиссию за газ, независимо от того, насколько просто или сложно их обработать. Снижение внутреннего газа транзакции (или EIP-2780) предлагает снизить эту базовую комиссию, чтобы сделать стандартный перевод ETH между существующими аккаунтами до 71% дешевле.

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

Предложение вводит исключение для создания совершенно новых аккаунтов, чтобы более низкие комиссии не перегружали состояние сети. Если перевод отправляет ETH на пустой, несуществующий адрес, сеть должна создать для него новую постоянную запись. За создание этого аккаунта добавляется надбавка к газу, чтобы помочь покрыть нагрузку на его долгосрочное хранение.

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

Ресурсы: Техническая спецификация EIP-2780 (opens in a new tab)

Детерминированное предварительное развертывание фабрики

• Дает разработчикам нативный способ развертывания приложений и кошельков смарт-контрактов по одному и тому же адресу в нескольких цепях
• Позволяет пользователям иметь один и тот же адрес смарт-кошелька в нескольких сетях уровня 2 (l2), снижая когнитивную нагрузку, уменьшая путаницу и снижая риск случайной потери средств
• Заменяет обходные пути, которые разработчики в настоящее время используют для достижения этого паритета, делая создание мультичейн-кошельков и приложений более простым и безопасным

Если сегодня у пользователя есть кошелек смарт-контракта с аккаунтами в нескольких EVM-совместимых цепях (виртуальная машина Эфириума), он часто получает совершенно разные адреса в разных сетях. Это не только сбивает с толку, но и может привести к случайной потере средств.

Детерминированное предварительное развертывание фабрики (или EIP-7997) дает разработчикам нативный, встроенный способ развертывания своих децентрализованных приложений и кошельков смарт-контрактов по одному и тому же адресу в нескольких EVM-цепях, включая основную сеть Ethereum, сети уровня 2 (l2) и другие. В случае принятия это позволит пользователю иметь один и тот же адрес в каждой участвующей цепи, что значительно снизит когнитивную нагрузку и вероятность ошибки пользователя.

Детерминированное предварительное развертывание фабрики работает путем постоянного размещения минимальной специализированной программы-фабрики в идентичном месте (в частности, по адресу 0x12) в каждой участвующей EVM-совместимой цепи. Ее цель — предоставить универсальный стандартный контракт фабрики, который может быть принят любой EVM-совместимой сетью; пока EVM-цепь участвует и принимает этот стандарт, разработчики смогут использовать его для развертывания своих смарт-контрактов по одному и тому же адресу в этой сети.

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

Ресурсы: Техническая спецификация EIP-7997 (opens in a new tab)

Переводы и сжигания ETH генерируют лог

• Автоматически генерирует постоянную запись (лог) каждый раз, когда ETH переводится или сжигается
• Устраняет историческое слепое пятно, что позволяет приложениям, биржам и мостам надежно обнаруживать депозиты пользователей без специальных инструментов отслеживания

В отличие от токенов (ERC-20), обычные переводы ETH между смарт-контрактами не генерируют четкую квитанцию (стандартный лог), что затрудняет их отслеживание биржами и приложениями.

Переводы и сжигания ETH генерируют лог (или EIP-7708) делает обязательным для сети генерировать стандартное событие лога каждый раз, когда перемещается или сжигается ненулевое количество ETH.

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

Ресурсы: Техническая спецификация EIP-7708 (opens in a new tab)

Списки частичных квитанций блоков eth/70

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

Теперь обязательные для всех клиентов уровня исполнения, списки частичных квитанций блоков eth/70 (или EIP-7975) вводят новый способ общения узлов друг с другом (eth/70), который позволяет разбивать эти большие списки на более мелкие, более управляемые части. eth/70 вводит систему пагинации для сетевого протокола связи, которая позволяет узлам разбивать списки квитанций блоков и безопасно запрашивать данные более мелкими, более управляемыми фрагментами.

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

Ресурсы: Техническая спецификация EIP-7975 (opens in a new tab)

Дополнительная литература

• Дорожная карта Эфириума
• Forkcast: Гламстердам (opens in a new tab)
• Мета-EIP Гламстердама (opens in a new tab)
• Анонс в блоге об обновлении приоритетов протокола на 2026 год (opens in a new tab)
• Подкаст The Daily Gwei Refuel — Постквантовый Эфириум, Гламстердам приближается (opens in a new tab)

Часто задаваемые вопросы

Как можно конвертировать ETH после хардфорка Гламстердам?

• Для ваших ETH не требуется никаких действий: Нет необходимости конвертировать или обновлять ваши ETH после обновления Гламстердам. Балансы ваших аккаунтов останутся прежними, а ETH, которыми вы владеете в настоящее время, останутся доступными в их существующем виде после хардфорка.
• Остерегайтесь мошенников! любой, кто инструктирует вас «обновить» ваши ETH, пытается вас обмануть. Вам не нужно ничего делать в связи с этим обновлением. Ваши активы останутся совершенно нетронутыми. Помните, что информированность — лучшая защита от мошенничества.

Подробнее о том, как распознать и избежать мошенничества

Влияет ли обновление Гламстердам на все узлы и валидаторы Эфириума?

Да, обновление Гламстердам требует обновления как клиентов исполнения, так и клиентов консенсуса. Поскольку это обновление вводит Закрепленное разделение предлагающего и создающего (ePBS), операторам узлов необходимо будет убедиться, что их клиенты обновлены для обработки новых способов создания, валидации и подтверждения блоков сетью.

Все основные клиенты Эфириума выпустят версии с поддержкой хардфорка, отмеченные как высокоприоритетные. Вы можете следить за тем, когда эти релизы будут доступны, в репозиториях клиентов на GitHub, на их каналах в Дискорде (opens in a new tab), в Дискорде EthStaker (opens in a new tab) или подписавшись на блог Эфириума для получения обновлений протокола.

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

Что мне нужно сделать как стейкеру для обновления Гламстердам?

Как и при каждом обновлении сети, обязательно обновите свои клиенты до последних версий, отмеченных поддержкой Гламстердама. Следите за обновлениями в списке рассылки и анонсами протокола в блоге EF (opens in a new tab), чтобы получать информацию о релизах.

Чтобы проверить свою настройку до того, как Гламстердам будет активирован в основной сети Ethereum, вы можете запустить валидатор в тестовых сетях. Форки тестовых сетей также анонсируются в списке рассылки и блоге.

Какие улучшения будет включать Гламстердам для масштабирования уровня 1 (l1)?

Главной особенностью является ePBS (EIP-7732), которая отделяет тяжелую задачу валидации сетевых транзакций от задачи достижения консенсуса. Это расширяет окно распространения данных с 2 секунд до примерно 9 секунд, разблокируя способность Эфириума безопасно обрабатывать гораздо более высокую пропускную способность транзакций и вмещать больше BLOB-объектов данных для сетей уровня 2 (l2).

Снизит ли Гламстердам комиссии в Эфириуме (уровень 1 (l1))?

Да, Гламстердам, скорее всего, снизит комиссии для обычных пользователей! Снижение внутреннего газа транзакции (или EIP-2780) уменьшает базовую комиссию за отправку ETH, делая использование ETH намного дешевле для повседневных платежей.

Кроме того, для долгосрочной устойчивости Гламстердам вводит списки доступа на уровне блока (BAL). Это обеспечивает параллельную обработку и подготавливает уровень 1 (l1) к безопасному управлению более высокими общими лимитами газа в будущем, что, вероятно, снизит затраты газа на транзакцию по мере роста пропускной способности.

Будут ли какие-либо изменения в моих существующих смарт-контрактах после Гламстердама?

Существующие контракты продолжат нормально функционировать после Гламстердама. Разработчики, вероятно, получат несколько новых инструментов и должны будут пересмотреть использование газа:

• Увеличение максимального размера контракта (или EIP-7954) позволяет разработчикам развертывать более крупные приложения, повышая лимит максимального размера контракта с примерно 24 КиБ до 32 КиБ.
• Детерминированное предварительное развертывание фабрики (или EIP-7997) вводит универсальный встроенный контракт фабрики. Он позволяет разработчикам развертывать свои приложения и кошельки смарт-контрактов по одному и тому же адресу во всех участвующих EVM-цепях.
• Если ваше приложение полагается на сложное отслеживание для поиска переводов ETH, переводы и сжигания ETH генерируют лог (или EIP-7708) позволит вам переключиться на использование логов для более простого и надежного учета.
• Увеличение стоимости газа для создания состояния (или EIP-8037) и обновление стоимости газа для доступа к состоянию (или EIP-8038) вводят новые модели устойчивости, которые изменят определенные затраты на развертывание контрактов, поскольку создание новых аккаунтов или постоянного хранилища будет иметь новую стандартизированную фиксированную комиссию, основанную на размере созданных данных.

Как Гламстердам повлияет на хранилище узлов и требования к оборудованию?

Несколько EIP, рассматриваемых для Гламстердама, решают проблему резкого падения производительности из-за роста состояния:

• Увеличение стоимости газа для создания состояния (или EIP-8037) вводит структуру фиксированных затрат (CPSB) для достижения темпа роста базы данных состояния в 120 ГиБ/год, гарантируя, что стандартное физическое оборудование сможет продолжать эффективно поддерживать работу сети.
• Списки частичных квитанций блоков eth/70 (или EIP-7975) позволяют узлам запрашивать квитанции блоков с пагинацией, что разбивает тяжелые списки квитанций блоков на более мелкие фрагменты для предотвращения сбоев и проблем с синхронизацией по мере масштабирования Эфириума.

Последнее обновление страницы: 6 июня 2026 г.

w (opens in a new tab)

m (opens in a new tab)

Посмотреть участников