Обновление Glamsterdam: решение Ethereum для масштабирования на уровне L1.

Оригинал | Odaily Planet Daily jk

Предстоящее обновление Glamsterdam для Ethereum считается основными разработчиками крупнейшей реструктуризацией на уровне протокола со времен The Merge. Название образовано из двух частей: обновление исполнительного уровня сохраняет название «Amsterdam», по аналогии с местом проведения предыдущих мероприятий Devconnect; обновление уровня консенсуса называется «Gloas», в честь звезды. После предыдущего обновления Fusaka, Glamsterdam повышает масштабируемость L1 за счет реорганизации обработки транзакций в сети и управления растущей базой данных, коренным образом обновляя способ создания и проверки блоков в Ethereum.

Данное обновление направлено на достижение трех основных целей:

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

Два основных предложения по модернизации сосредоточены на уровне консенсуса и уровне исполнения:

Существует два основных предложения по внедрению Headliner. Источник: Ethereum

Главное предложение №1: ePBS превращает «аутсорсинговых посредников» в «встроенные правила».

Для начала давайте обсудим основное предложение по уровню консенсуса, которое разделяет инициаторов и разработчиков в рамках протокола, сокращенно ePBS (EIP-7732).

Каждый раз, когда Ethereum создает блок, это фактически включает два этапа: один человек отвечает за «выбор блока» (инициатор), а другой — за «фактическую сборку транзакций в блоке» (создатель). В настоящее время это разделение труда не определено самим протоколом Ethereum, а полагается на группу внесетевых «посреднических компаний» (обычно называемых ретрансляторами), которые облегчают этот процесс. Эта внесетевая связь также создает путь во время проверки блока, заставляя валидаторов спешно завершать трансляцию и выполнение транзакций в течение 2-секундного окна, ограничивая объем данных, который может обработать сеть. Например, это похоже на ресторан, где процессы заказа и приготовления зависят от независимого внешнего посредника, координирующего доставку блюд; если этот посредник выйдет из строя, кухня и стойка регистрации могут работать несогласованно.

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

Предложение №2 для хедлайнеров: BALs составляют «список покупок» перед отъездом.

Далее обсудим ключевое предложение для уровня выполнения, которым является список доступа на уровне блоков, сокращенно BAL (EIP-7928).

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

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

В поддержку предложений: Переоценка операций, занимающих космическое пространство

В дополнение к этим двум основным предложениям, Glamsterdam также подготовил два дополнительных предложения по пересмотру цен, которые можно понимать как корректировку прейскуранта для «платы за хранение данных» и «платы за запросы» в сети.

• Первое предложение касается таких операций, как создание новых учетных записей и развертывание контрактов, которые будут «постоянно занимать место» в сети. Ранее взимаемая плата не была пропорциональна фактически занятому пространству; теперь она будет пересчитываться на основе «платы за каждую единицу занятого пространства», что позволит контролировать общий темп роста данных в сети на безопасном и предсказуемом уровне в 120 ГиБ в год, обеспечивая возможность работы сети на обычном оборудовании. Кроме того, эта плата за хранение будет учитываться отдельно и больше не будет смешиваться с вычислительными сборами за обработку транзакций. Пока разработчики готовы платить немного больше за хранение, они смогут развертывать более крупные и сложные приложения, не будучи сразу же ограничены общим лимитом Gas.
• Второе предложение касается таких операций, как запрос и чтение существующих данных в сети, которые ранее стоили недостаточно и не соответствовали фактическим затратам на запросы по мере увеличения объема данных. На этот раз стандарты ценообразования для этих кодов операций будут повышены, чтобы лучше отражать реальные условия нагрузки современного оборудования, а также предотвратить злоупотребление низкими тарифами с целью преднамеренного перегрузки сети чрезмерным количеством запросов.

Дата запуска основной сети: пока не определена.

Что касается сроков, Glamsterdam в настоящее время находится на довольно деликатной стадии. С официальной стороны, последнее подтвержденное собрание всех основных разработчиков исполнительного уровня (ACDE) состоялось 16 июля (241-е по счету), и его основной повесткой дня были обновления по фазе Devnet Glamsterdam и выбор ключевых предложений для следующего обновления, Hegota. Широко распространенный в отрасли график указывает на то, что фаза Devnet прошла восемь итераций от 0 до 7, с 28 марта 2026 года по 8 июля, за которыми последовал форк тестовой сети Sepolia, первоначально запланированный на 3 августа 2026 года, и форк тестовой сети Hoodi, первоначально запланированный на 17 августа 2026 года, а целевая дата активации основной сети установлена на 16 сентября 2026 года.

Первоначально запуск был запланирован на первую половину 2026 года. Источник: Ethereum.

Однако, судя по последним событиям, этот график, вероятно, был отложен. Команда EthPandaOps недавно запустила новую тестовую сеть под названием Plataberget, которая является первой краткосрочной публичной тестовой сетью, специально разработанной для Glamsterdam. Официальное развертывание Sepolia и Hoodi, как ожидается, будет отложено до сентября, а целевая дата запуска основной сети, соответственно, перенесена на четвертый квартал 2026 года. Это уже второй раз, когда сроки запуска Glamsterdam сдвигаются, после предыдущего переноса с первоначально запланированной первой половины 2026 года. Основные разработчики неоднократно подчеркивали, что корректность обновления имеет приоритет над соблюдением какой-либо конкретной даты, поэтому, пока конкретная высота блока не будет зафиксирована на официальном совещании ACD, мы можем не увидеть это обновление до четвертого квартала или даже конца года.