Накануне испытаний крупного апгрейда сети Ethereum команды валидаторских клиентов в спешном порядке развернули исправления программного кода. Речь идёт о тесте Sepolia — контрольной сети Ethereum, где разработчики проверяют значительное увеличение пропускной способности: лимит газа на блок должен вырасти до 200 млн единиц. Для сравнения, текущий стандартный лимит держится на уровне 30 млн газа.
Это не первая попытка расширить блокчейн, но масштаб увеличения на 85% — значительный скачок. Тест нужен, чтобы понять, выдержит ли инфраструктура (валидаторы, ноды, сетевые соединения) такую нагрузку без деградации устойчивости и децентрализации. Спешное обновление на последних часах указывает на нетривиальные технические детали, которые команды разработчиков доработали по ходу подготовки.
Для Ethereum это ещё один шаг в долгосрочной стратегии масштабирования. Параллельно идут работы над EIP-4844 (blobs для расширения Data Availability Layer) и накопление опыта для более существенных изменений архитектуры. Но прямое увеличение лимита газа — более простой и быстрый способ поднять throughput в краткосрочке, хотя и с компромиссами по размеру ноды и требованиям к оборудованию валидаторов.
Для российских разработчиков, запускающих крупные DeFi-приложения или протоколы на Ethereum, такой тест важен: он даст ранний сигнал о том, прибыльно ли будет переводить высоконагруженные операции с других цепей на основной слой Ethereum, или имеет смысл дольше оставаться на L2-решениях (Arbitrum, Optimism, Polygon). Если лимит повысится стабильно, комиссии снизятся, что сделает главную сеть конкурентнее для микротранзакций.
Спешка перед тестом — обычная практика в блокчейн-разработке: найти баг на тестовой сети всё равно лучше, чем на mainnet. Но её наличие говорит и о том, что предварительное тестирование в меньшем масштабе (на внутренних ноды или приватных сетях) выявило проблемы поздновато. Это не катастрофа — тест для того и нужен — но требует внимательного мониторинга.
Результаты Glamsterdam (так назвали этот тест в комьюнити) подскажут, готова ли сеть к постоянному росту лимита или стоит идти иным путём — например, через более агрессивное внедрение blob-пространства для масштабирования L2, что снижает требования к самим блокам L1.