Обновление Glamsterdam: решение проблемы масштабируемости L1 Ethereum

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

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

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

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

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

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

Основное предложение первое: ePBS, превращение "аутсорсинговых посредников" в "встроенные правила"

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

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

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

Основное предложение второе: BALs, подготовка "списка покупок" перед отправлением

Теперь давайте обсудим основное предложение для слоя исполнения, список доступа на уровне блока, сокращенно BALs (EIP-7928).

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

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

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

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

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

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

Что касается графика, Glamsterdam в настоящее время находится в довольно деликатной фазе. Официально последняя проверяемая встреча всех основных разработчиков (ACDE) была 241-й, состоявшейся 16 июля, с основным повесткой дня, включая обновления по фазе Glamsterdam Devnet и выбор основных предложений для следующего обновления, 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 не зафиксирует конкретную высоту блока, мы можем не увидеть это обновление до четвертого квартала или даже до конца года.

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