
Разработчики Ethereum анонсировали хардфорк Fusaka с масштабными изменениями в EVM
Ожидается, что обновление, запланированное на третий или четвертый квартал 2025 года, внедрит спорный формат объектов EVM (EOF).

Хардфорк 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 проверяет структуру контейнера, разделяя код и данные. Такой подход упрощает разработку и анализ смарт-контрактов.
Байткод представляет собой компактный набор низкоуровневых инструкций. Прежде чем 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 поддержали обновление.
Обновление EOF объединяет двенадцать предложений, меняющих подход к разработке смарт-контрактов. Его сторонники считают, что обновление делает систему эффективнее, придает ей большую элегантность и упрощает будущие обновления.
Однако критики считают, что обновление усложняет и без того непростую систему, коей является Ethereum.
Разработчик Паскаль Каверсаккио в посте на Ethereum Magicians от 13 марта отметил:
«EOF чрезвычайно сложный. Он вводит две новые семантики создания контрактов, удаляет и добавляет больше дюжины опкодов. [...] все преимущества EOF можно внедрить через более постепенные и менее инвазивные изменения EVM. Между тем сложности, связанные с EOF, игнорировать нельзя: старую версию EVM, вероятно, придется поддерживать бесконечно».
По его словам, EOF потребует обновления инструментов разработки, а это увеличит риск новых уязвимостей из-за расширения зоны потенциальных атак. Каверсаккио подчеркнул, что контракты станут значительно сложнее из-за добавления заголовков; сейчас пустой контракт занимает всего 15 байт.
Другой участник обсуждения написал:
«Похоже, в сообществе нет согласия, нужны ли вообще масштабные изменения EVM. Стабильная виртуальная машина, на которую можно полагаться при разработке качественных инструментов и приложений, имеет гораздо большую ценность».
Каверсаккио — не единственный противник обновления. В опросе на платформе ETHPulse 39 пользователей с активами на сумму 17 745 ETH проголосовали против внедрения EOF. Только семь участников с балансом менее 300 ETH поддержали обновление.

Источник: ETHPulse
Журнал: Ethereum обгоняет конкурентов в гонке по токенизации активов.
Больше по теме

