Автор|jk
Предстоящий апгрейд Ethereum под названием Glamsterdam, по мнению основных разработчиков, станет крупнейшей переработкой протокола со времен The Merge. Это название образовано из двух частей: часть, относящаяся к апгрейду уровня исполнения, сохранила название "Amsterdam" (в честь Амстердама, места проведения прошлых конференций Devconnect); часть, относящаяся к апгрейду уровня консенсуса, получила название "Gloas" (в честь звезды). Следуя за предыдущим апгрейдом Fusaka, Glamsterdam продвигает масштабирование L1, реструктуризируя способ обработки транзакций и управления растущей базой данных сетью, фундаментально обновляя способ создания и проверки блоков в Ethereum.
Этот апгрейд сосредоточен вокруг трех ключевых целей:
- Ускорение обработки (параллелизация): Реструктуризация способа записи зависимостей данных сетью, позволяющая безопасно обрабатывать большое количество транзакций одновременно, а не медленно последовательно.
- Масштабируемость: Разделение трудоемкой работы по созданию и проверке блоков, предоставление сети больше времени для распространения большего объема данных без замедления.
- Устойчивость: Корректировка сетевых комиссий для точного отражения долгосрочных аппаратных затрат на хранение новых данных, расчистка пути для будущего увеличения лимита Gas, избегая при этом деградации аппаратной производительности.
Две ключевые предложения (Headliner) апгрейда относятся к уровню консенсуса и уровню исполнения соответственно:
Есть два ключевых (Headliner) предложения. Источник: Ethereum
Ключевое предложение первое: ePBS — превращение "аутсорсинговых посредников" во "встроенные правила"
Начнем с ключевого предложения уровня консенсуса: Протокольное разделение предлагающего и сборщика блока, англ. ePBS (EIP-7732).
Каждый раз, когда Ethereum создает блок, процесс состоит из двух этапов: один человек отвечает за "выбор того, какой блок будет предложен" (предлагающий), другой — за "фактическую сборку транзакций в блок" (сборщик). В настоящее время это разделение труда не предусмотрено самим протоколом Ethereum, а осуществляется через ряд оффчейн "посреднических компаний" (на жаргоне называемых реле). Эти оффчейн-отношения также создают критический путь во время проверки блока, вынуждая валидаторов в спешке выполнять верификацию транзакций в течение узкого 2-секундного окна, что ограничивает объем данных, который сеть может обработать. Проводя аналогию, это похоже на то, как в ресторане координация между принятием заказа и его приготовлением зависит от независимого внешнего курьера, и если этот курьер подведет, кухня и зал могут разойтись в данных.
Что делает ePBS — так это вписывает эти правила разделения труда "заказ-приготовление" в собственное руководство по эксплуатации ресторана, избавляясь от зависимости от внешнего курьера. Таким образом, надежный механизм доставки блоков и платежей непосредственно встраивается в сам протокол, устраняя необходимость в сторонних промежуточных решениях, хотя стороны все еще могут выбрать использование внешних посредников, если захотят реализовать сложные функции, еще не предусмотренные протоколом. Одновременно, чтобы избавиться от спешки в "передаче заказов", ePBS также учреждает "группу проверки блюд", раздельно проверяющую "кто сделал заказ" и "было ли блюдо приготовлено и подано вовремя". Окно передачи заказов, ранее составлявшее 2 секунды, расширяется примерно до 9 секунд, позволяя ресторану обрабатывать больше заказов за раз, то есть позволяя Ethereum обрабатывать больше данных для Layer2.
Ключевое предложение второе: BALs — сначала составьте "список покупок" перед походом в магазин
Теперь о ключевом предложении уровня исполнения: Списки доступа на уровне блока, англ. BALs (EIP-7928).
Текущий способ обработки транзакций в Ethereum чем-то похож на человека, который идет в супермаркет с завязанными глазами: он должен сначала нащупать товар, понять, что это такое, прежде чем решить, что делать дальше, поэтому он может брать товары только по одному, выстраиваясь в очередь. Поскольку заранее неизвестно, какие данные будет использовать транзакция (например, какие учетные записи будут затронуты), система должна строго обрабатывать транзакции последовательно, одна за другой. В противном случае две транзакции могут неожиданно попытаться одновременно изменить одни и те же данные (например, баланс одного и того же адреса), что приведет к конфликту и ошибке.
BALs — это все равно что дать этому человеку перед выходом из дома "список покупок", в котором четко указано, "к каким полкам подойти и какие товары взять". Имея такой список, система может заранее определить, какие транзакции совершенно не будут "конфликтовать" друг с другом, и затем может разделить взаимно независимые транзакции на группы и обрабатывать их параллельно, вместо того чтобы ставить их в очередь друг за другом. У этого списка есть дополнительное преимущество: когда новый узел присоединяется к сети, он может напрямую копировать конечный результат, записанный в этом списке, без необходимости пересчитывать все сложные исторические транзакции, что значительно ускорит синхронизацию нового узла. Чтобы этот список действительно мог циркулировать в сети, Glamsterdam также включает в себя сопутствующее обновление транспортного протокола, позволяющее узлам фактически обмениваться этими списками доступа; этот транспортный протокол в настоящее время стал обязательным требованием для всех клиентов уровня исполнения.
Сопутствующие предложения: пересчет стоимости операций, "занимающих место"
Помимо этих двух ключевых предложений, Glamsterdam включает два сопутствующих предложения по переоценке, которые можно понимать как корректировку тарифов на "складские расходы" и "плату за запросы" сети.
- Первое касается операций, таких как создание новых аккаунтов или развертывание контрактов, которые "постоянно занимают место" в сети. Раньше плата за них не совсем соответствовала фактически занимаемому пространству. Теперь расчет будет производиться по принципу "плати за каждый занимаемый объем", с целью сдерживания общего роста данных в сети на безопасном и предсказуемом уровне около 120 ГиБ в год, что гарантирует возможность продолжения работы сети на обычном оборудовании. Одновременно эти складские расходы будут учитываться на отдельном счете, больше не смешиваясь с вычислительными расходами на обработку транзакций. Пока разработчики готовы платить немного больше за складские расходы, они все еще могут развертывать более крупные и сложные приложения, не будучи сразу ограниченными общим лимитом Gas.
- Второе касается операций по запросу или чтению существующих данных в сети. Раньше их цена была занижена и не поспевала за реальными затратами на запросы в условиях возросших объемов данных. На этот раз стоимость таких операционных кодов будет повышена, чтобы цена лучше соответствовала реальной нагрузке на современное оборудование, а также чтобы предотвратить возможность злоупотреблений из-за слишком дешевых запросов, когда кто-то может намеренно заблокировать сеть большим количеством запросов.
Дата запуска в основной сети: пока не определена
Что касается графика, Glamsterdam в настоящее время находится на довольно деликатной стадии. На официальном уровне, последнее задокументированное собрание всех основных разработчиков уровня исполнения (ACDE) было 241-м, 16 июля. Основными пунктами повестки дня были последние новости о стадии Devnet для Glamsterdam и голосование за ключевые предложения для следующего апгрейда Hegota. Ранее широко цитировавшийся в отрасли график показывал, что стадия Devnet прошла восемь итераций с 0 по 7, охватывая период с 28 марта по 8 июля 2026 года, за которым должны были последовать форк тестовой сети Sepolia 3 августа 2026 года и форк тестовой сети Hoodi 17 августа 2026 года, с целевой датой активации в основной сети 16 сентября 2026 года.
Изначальный график предполагал первую половину 2026 года, источник: Ethereum
Однако, судя по последним событиям, этот график, скорее всего, сдвинулся назад. Команда EthPandaOps недавно запустила новую тестовую сеть под названием Plataberget — это первая краткосрочная публичная тестовая сеть, специально разработанная для Glamsterdam. Официальные развертывания на Sepolia и Hoodi, как ожидается, будут отложены до сентября, а целевая дата запуска в основной сети соответственно перенесена на четвертый квартал 2026 года. Это уже второй случай переноса сроков для Glamsterdam после предыдущей отсрочки с первоначально намеченного первого полугодия 2026 года. Основные разработчики неоднократно подчеркивали, что корректность апгрейда имеет приоритет над соблюдением любой конкретной даты. Поэтому до тех пор, пока на официальном собрании ACD не будет зафиксирована конкретная высота блока, возможно, нам придется ждать четвертого квартала или даже конца года, чтобы увидеть этот апгрейд.
