Glamsterdam обновляется, ответ на масштабирование L1 Ethereum

Оригинал | Odaily Звёздная газета jk

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

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

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

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

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

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

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

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

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

Основное предложение 2: 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 не будет зафиксирована конкретная высота блока, мы, вероятно, не увидим это обновление до четвертого квартала или даже до конца года.