Разработка на Эфириуме в 2026 году: что изменилось

комиссии за газ

абстракция учетной записи

обновления протокола

Филип Краузе

EF Builder Growth

7 мая 2026 г.

9 минута прочтения

Если ваше представление об Эфириуме сформировалось в период с 2021 по 2023 год, оно устарело. Три обновления протокола с тех пор — Денкун в марте 2024 года, Пектра в мае 2025 года и Фусака в декабре 2025 года — изменили две вещи, которые волнуют разработчиков: стоимость использования уровня 1 (l1) и возможности обычных кошельков.

Мейннет снова стал дешевым

Режим комиссий 2021–2023 годов больше не является надежным базовым предположением.

По состоянию на 5 мая 2026 года трекер газа Etherscan показывает стандартный газ на уровне около 0.15 Gwei, при этом средние дневные значения в апреле составляли около 0.5 Gwei. Базовый перевод ETH на этом уровне стоит меньше цента, а в типичные последние дни — всего несколько центов. Эта тенденция к снижению наблюдалась после каждого из недавних обновлений, и следующее, Гламстердам, должно снизить комиссии еще больше. Это делает утверждение «Мейннет Эфириума слишком дорог для большинства приложений» устаревшей отправной точкой.

Если вам нужно простое эмпирическое правило, используйте математику газа вместо старых мифов. При 0.5 Gwei (недавнее среднее значение за апрель) и цене ETH примерно в 2350 долларов ориентировочные затраты выглядят следующим образом.

Операция	Использованный газ	Ориентировочная стоимость
Перевод ETH	21,000	$0.025
Перевод ERC-20	~65,000	$0.076
Одобрение ERC-20	~46,000	$0.054
Своп	~180,000	$0.21
Развертывание ERC-20	~1,200,000	$1.41

Это примеры, а не гарантии. Затраты меняются в зависимости от цены ETH, цены газа и сложности контракта. Показатели Gwei могут сильно колебаться в течение обычного месяца, в то время как долларовая стоимость почти не меняется, поскольку роллапы теперь обрабатывают около 95 процентов транзакций Эфириума, а уровень 1 (l1) обычно работает значительно ниже своего целевого показателя для блока. Комиссии в мейннете теперь достаточно низкие, чтобы многие приложения могли разумно работать в основной сети.

Почему снизились затраты

Большую часть работы сделали три обновления.

Денкун (март 2024 года) внедрил EIP-4844 и предоставил роллапам собственную полосу данных через блобы с отдельным рынком комиссий. Роллапы перестали конкурировать с обычным трафиком выполнения за одно и то же пространство в блоке.

Пектра была активирована 7 мая 2025 года. EIP-7691 увеличил пропускную способность блобов с 3 целевых / 6 максимальных блобов на блок до 6 целевых / 9 максимальных, что расширило дешевую полосу данных, используемую роллапами, и снизило комиссии на уровне 2 (l2).

Фусака была активирована 3 декабря 2025 года. Главным изменением пропускной способности стал PeerDAS, который позволяет валидаторам делать выборку данных блобов вместо полного скачивания каждого блоба, и именно эта выборка делает безопасным увеличение количества блобов на сетевом уровне. Параллельно сообщество увеличило лимит газа на уровне 1 (l1) с 30 млн до 60 млн в течение 2025 года, а EIP-7935 в обновлении Фусака стандартизировал 60 млн как новое значение по умолчанию. EIP-7825 ограничивает любую отдельную транзакцию примерно 16.78 млн газа, чего большинство приложений никогда не заметит, но очень крупные развертывания и монолитные мультивызовы теперь должны укладываться в этот лимит. EIP-7951 также добавил нативную верификацию secp256r1 (P-256) в мейннете, что делает проверку подписей ключей доступа и WebAuthn в процессах аккаунта намного дешевле.

В результате мейннет больше не оценивается как постоянно перегруженная цепь.

Как EIP-7702 меняет модель аккаунта

Пектра также включила EIP-7702, который дает обычным кошелькам доступ к функциям смарт-аккаунта, таким как пакетирование, спонсирование газа, сессионные ключи, процессы восстановления и удобный для ключей доступа UX, без необходимости перехода пользователя на новый аккаунт.

Это работает за счет добавления нового типа транзакции (тип 0x04, SetCode), который позволяет EOA установить указатель на уже развернутый код контракта. Пользователь сохраняет тот же адрес, исходный ключ EOA сохраняет полный контроль над аккаунтом, а делегирование позже может быть изменено или сброшено на нулевой адрес.

Для разработчиков приложений практическое изменение заключается в том, чтобы запрашивать у кошелька результат, а не низкоуровневую настройку EIP-7702. Если пользователю нужно одобрить и совершить своп в одном процессе, запросите пакетирование через ERC-5792 wallet_sendCalls. Кошелек сам может решить, использовать ли EIP-7702, ERC-4337 или другую систему аккаунтов.

Делегированный код является границей безопасности. Если кошелек направляет EOA на ошибочный или вредоносный код, этот код может выполнять вызовы от имени пользователя, включая одобрения токенов, переводы и взаимодействия с приложениями. Разработчики должны относиться к целям делегирования как к инфраструктуре кошелька, полагаясь на проверенные кошельком реализации и не прося пользователей легкомысленно делегировать полномочия коду, контролируемому приложением.

Что это меняет в подходе к разработке

Раньше стандартным вопросом разработчика был: «какой уровень 2 (l2) достаточно дешев?». На этот вопрос все еще есть ответы, но он больше не единственный. Поскольку комиссии на уровне 1 (l1) при нормальной нагрузке составляют центы за транзакцию, а EIP-7702 позволяет любому кошельку предоставлять UX смарт-аккаунта без миграции адресов, более полезным базовым вопросом становится то, должно ли приложение жить в мейннете, или же конкретный уровень 2 (l2) дает реальное преимущество в дистрибуции, ликвидности или UX, которое уровень 1 (l1) дать не может.

Предположения об аккаунтах также меняются. Не проектируйте новые приложения так, как если бы каждый аккаунт пользователя был простым EOA на базе ECDSA, который должен содержать ETH, прежде чем сделать что-то полезное. Отдавайте предпочтение интерфейсам пакетирования на уровне кошелька, таким как ERC-5792 wallet_sendCalls, исходите из того, что спонсирование газа и сессионные ключи станут обычными функциями кошелька, и рассматривайте ключи доступа и процессы восстановления как часть UX аккаунта, а не как отдельные хаки для онбординга.

Что дальше

Следующее именное обновление Эфириума — Гламстердам, главными элементами которого являются списки доступа на уровне блока (BAL) и закрепленное разделение предлагающего и создающего (ePBS). Вместе они делают безопасным повышение лимита газа в блоке с нынешних 60 миллионов примерно до 200 миллионов, оставляя разработчикам больше пропускной способности на уровне 1 (l1). Активация ожидается во второй половине 2026 года. Планируется, что за Гламстердамом последует Хегота (opens in a new tab), главной особенностью которого станут списки включения, принудительно применяемые правилом выбора форка (FOCIL).

Для разработчиков стоит отслеживать увеличение пропускной способности уровня 1 (l1) (BAL), более надежное включение транзакций (FOCIL) и путь к нативной абстракции учетной записи. ePBS, еще одно главное нововведение Гламстердама, — это в основном инфраструктурное изменение, которое устраняет зависимость от доверия при включении транзакций на уровне 1 (l1). Прямые изменения на уровне приложений невелики.

BAL направлены на то, чтобы уровень 1 (l1) оставался дешевым по мере роста использования. Проще говоря, блок будет поставляться с картой аккаунтов и хранилища, которые он затрагивает. Клиенты могут использовать эту карту для предварительной выборки данных и параллельного выполнения независимых транзакций, что делает более безопасным повышение лимита газа на уровне 1 (l1) без чрезмерного замедления проверки блоков. Практический эффект для разработчиков заключается в том, что больше активности может вернуться в мейннет без автоматического воссоздания режима газа 2021–2023 годов.

FOCIL направлен на то, чтобы валидные транзакции попадали в блоки, даже если один производитель блоков предпочел бы их исключить. Сегодня, если сторона, создающая блок, игнорирует транзакцию, у остальной части протокола есть ограниченные способы принудительно включить ее. С EIP-7805 несколько валидаторов, по сути, скажут: «мы видели эти валидные транзакции, ожидающие в публичном мемпуле». Следующий блок должен будет включить их, иначе валидаторы могут отказаться поддерживать этот блок. Для разработчиков это имеет значение, когда надежный доступ к уровню 1 (l1) является частью продукта, включая инструменты приватности, регулируемые шлюзы ввода фиата или приложения, обслуживающие пользователей, которые могут фильтроваться некоторыми поставщиками инфраструктуры.

Для разработчиков приложений в обновлении Хегота наиболее пристального внимания заслуживает абстракция учетной записи. EIP-8141 (фреймовые транзакции) добавит тип транзакции, в котором валидация, выполнение и оплата газа разделены на фреймы. На практике это означает, что смарт-аккаунт сможет сам проверять транзакцию, определять собственные правила подписи, одобрять того, кто платит за газ, и выполнять одно или несколько действий без зависимости от EntryPoint ERC-4337, сборщиков (bundlers) или ретрансляторов, управляемых приложением.

Это меняет предположения о продукте. Спонсирование газа становится нативным паттерном аккаунта, а не инфраструктурой, которую каждое приложение должно организовывать отдельно. Альтернативные схемы подписи становится проще поддерживать, включая ключи доступа сегодня и отказ от ECDSA, если потребуется постквантовая миграция. Если EIP-8141 или аналогичный дизайн нативной абстракции учетной записи будет внедрен, модель разработчика сместится с «EOA подписывает транзакцию» на «аккаунт определяет, как он проверяет, оплачивает и выполняет транзакцию».

Это направление, а не обещание. EIP-8141 находится в статусе черновика (Draft), и по состоянию на май 2026 года он только «рассматривается для включения» в Хегота, что означает, что команды клиентов обсуждают его, но не взяли на себя обязательство выпустить его в этом обновлении. Практический путь разработки UX аккаунтов в 2026 году — это по-прежнему EIP-7702 плюс процессы кошельков ERC-4337, но разработчики должны проектировать так, как если бы программируемые аккаунты становились моделью аккаунта по умолчанию.

Что теперь разрабатывать по-другому

Начните с перепроверки старых предположений о комиссиях. Если ваше руководство по развертыванию по-прежнему рассматривает мейннет Эфириума как среду с 10–30 Gwei по умолчанию, оно, вероятно, уводит слишком много работы с уровня 1 (l1). Мейннет стоит рассматривать в первую очередь, когда ваше приложение зависит от общей ликвидности, композируемости с существующими протоколами, нейтральности или ценного состояния, которое должно находиться там, где безопасность и социальный консенсус Эфириума наиболее сильны.

Используйте уровни 2 (l2) по причинам, которые все еще имеют значение, включая дистрибуцию, очень высокий объем транзакций, экосистемы для конкретных приложений или затраты на действие, которые должны быть максимально близки к нулю. Суть не в том, чтобы использовать «мейннет для всего». Суть в том, что «мейннет слишком дорог» больше не должно быть первым фильтром.

Что касается аккаунтов, разрабатывайте с учетом возможностей кошельков, а не простых EOA. Ваш фронтенд должен быть готов к тому, что пакетированные вызовы, спонсируемый газ, сессионные ключи, ключи доступа и процессы восстановления будут поступать через кошельки. EIP-7702 и ERC-4337 — это практические инструменты на сегодняшний день. Нативная абстракция учетной записи — это направление, за которым следует следить дальше.

Перестаньте относиться к мейннету Эфириума как к дорогому уровню финализации расчетов, к которому вы обращаетесь только в самом конце, и перестаньте рассматривать аккаунты пользователей как статические ключи ECDSA, которые должны содержать ETH, прежде чем они смогут что-либо сделать. Эфириум в 2026 году движется к более дешевому выполнению на уровне 1 (l1) и программируемым аккаунтам. Разрабатывайте для этого мира.

Дополнительная литература

Последнее обновление страницы: 28 мая 2026 г.