Хардфорк Fusaka в сети Ethereum запланирован на третий или четвертый квартал этого года. Об этом сообщил соисполнительный директор Ethereum Foundation Томаш Каетан Станчак в посте в X от 28 апреля. Точный график внедрения пока не утвержден.

Информация появилась на фоне споров вокруг обновления формата объектов виртуальной машины Ethereum — EVM Object Format (EOF). Станчак отметил, что внедрение EOF станет частью Fusaka.

Источник: Томаш Каетан Станчак

«Важное уточнение по поводу дебатов вокруг EOF.  

Сегодня активно обсуждается тема EOF, но нужно четко прояснить одно важное недопонимание: 

Текущая дискуссия о формате объектов EVM (EOF) НЕ связана с предстоящим обновлением Pectra, запланированным на 7 мая. Обновление Pectra не включает EOF и не предполагает его внедрения. Все, что касается Pectra, идет по плану для релиза 7 мая (eips.ethereum.org/EIPS/eip-7600). 

Текущая дискуссия об EOF относится к следующему сетевому обновлению — Fusaka, дата которого еще не назначена, но мы планируем его примерно на третий–четвертый квартал 2025 года (примерно сентябрь–октябрь) 

(eips.ethereum.org/EIPS/eip-7607)», — написал Томаш Каетан Станчак в X.

Виртуальная машина — программное обеспечение, которое исполняет смарт-контракты в сети Ethereum. EVM Object Format предусматривает внедрение нескольких EIP (предложений по улучшению Ethereum) и вводит контейнерный формат для байткода, поддерживающий расширение и управление версиями.

По теме: Исследователь предложил увеличить лимит газа Ethereum в 100 раз за четыре года

Упакуй, проверь и отправь

Байткод представляет собой компактный набор низкоуровневых инструкций. Прежде чем EVM сможет выполнить смарт-контракт, разработчик должен скомпилировать его в байткод.

Обновление EOF предлагает новый способ организации байткода — упаковку в контейнер с четкой структурой. Она включает:

  • заголовок, который начинается с шестнадцатеричного значения 0xEF00 и содержит номер версии;
  • таблица секций, где указаны типы и размеры всех частей содержимого;
  • минимум одна секция для кода и необходимое количество секций для данных. В будущем этот список будет пополняться.

При развертывании смарт-контракта EVM проверяет структуру контейнера, разделяя код и данные. Такой подход упрощает разработку и анализ смарт-контрактов.

Не прыгай наугад — используй RJUMP!

Одно из предложений в рамках обновления EOF — EIP-4200 — содержит альтернативу инструкциям JUMP и JUMPI, позволяющим переходить на произвольные позиции в байткоде. Такая схема выполнения приводит к трудноуловимым ошибкам (например, неочевидное неправильное значение перехода) и упрощает внедрение вредоносного кода.

Эту практику называют динамическими прыжками. EIP-4750 (на рассмотрении) предполагает запрет JUMP и JUMPI в EOF-контрактах, а затем — отклонение таких контрактов. Текущая версия EIP предлагает использовать вызов и возврат из функций (CALLF и RETF). Ранее развернутые смарт-контракты останутся без изменений.

После обновления EVM будет проверять байткод контрактов с JUMP и JUMPI на этапе развертывания. Прыжки не должны попадать в секции данных или в середину других инструкций. Валидация будет выполняться в соответствии с правилами из EIP-3670 и с помощью таблицы переходов, определенной в EIP-3690.

В качестве альтернативы этим инструкциям EOF предлагает RJUMP и RJUMPI. Они требуют жестко зашитых адресов переходов прямо в байткоде. Однако не все разработчики поддерживают внедрение EOF.

По теме: Участники сообщества Ethereum предложили новую структуру комиссий для уровня приложений

У EOF есть противники

Обновление EOF объединяет двенадцать предложений, меняющих подход к разработке смарт-контрактов. Его сторонники считают, что обновление делает систему эффективнее, придает ей большую элегантность и упрощает будущие обновления.

Однако критики считают, что обновление усложняет и без того непростую систему, коей является Ethereum.

Разработчик Паскаль Каверсаккио в посте на Ethereum Magicians от 13 марта отметил:

«EOF чрезвычайно сложный. Он вводит две новые семантики создания контрактов, удаляет и добавляет больше дюжины опкодов. [...] все преимущества EOF можно внедрить через более постепенные и менее инвазивные изменения EVM. Между тем сложности, связанные с EOF, игнорировать нельзя: старую версию EVM, вероятно, придется поддерживать бесконечно».

По его словам, EOF потребует обновления инструментов разработки, а это увеличит риск новых уязвимостей из-за расширения зоны потенциальных атак. Каверсаккио подчеркнул, что контракты станут значительно сложнее из-за добавления заголовков; сейчас пустой контракт занимает всего 15 байт.

Другой участник обсуждения написал:

«Похоже, в сообществе нет согласия, нужны ли вообще масштабные изменения EVM. Стабильная виртуальная машина, на которую можно полагаться при разработке качественных инструментов и приложений, имеет гораздо большую ценность».

Каверсаккио — не единственный противник обновления. В опросе на платформе ETHPulse 39 пользователей с активами на сумму 17 745 ETH проголосовали против внедрения EOF. Только семь участников с балансом менее 300 ETH поддержали обновление.

Smart Contracts, Developers
Источник: ETHPulse

Журнал: Ethereum обгоняет конкурентов в гонке по токенизации активов.