Детерминированное развертывание (CREATE2)

Что такое детерминированное развертывание (CREATE2)?

Детерминированное развертывание (CREATE2) — это метод Ethereum Virtual Machine, позволяющий разработчикам вычислить адрес смарт-контракта до его развертывания.

Для этого используется опкод EVM

, которому соответствует значение опкода .

Адрес контракта, развернутого с помощью CREATE2, определяется адресом развертывающего контракта, выбранным разработчиком salt и хешем кода инициализации контракта.Это отличается от обычного развертывания контракта, при котором итоговый адрес обычно зависит от адреса развертывающей стороны и ее nonce.Поскольку CREATE2 не использует изменяющийся nonce развертывающей стороны, разработчики могут предсказать тот же адрес, даже если фабрика за это время создала другие контракты.Это свойство полезно для контрфактических смарт-аккаунтов, предсказуемых компонентов протоколов, кроссчейн-инфраструктуры приложений, каналов состояний и контрактов, которые получают криптовалюту до развертывания.

Окончательная спецификация CREATE2 EIP-1014 описывает опкод, формулу адреса, расчет газа, поведение при коллизиях и исходную мотивацию контрфактического развертывания.

CREATE2 не делает контракт безопасным, неизменяемым, децентрализованным или автоматически одинаковым во всех блокчейнах.Этот метод лишь детерминированно вычисляет адрес развертывания на основе заданных входных данных.

Почему CREATE2 называется детерминированным?

Процесс называют детерминированным, если одинаковые входные данные всегда дают одинаковый результат.В случае CREATE2 результатом является адрес смарт-контракта.Входные данные — адрес развертывающей стороны CREATE2, 32-байтовый salt и хеш кода инициализации.Любой, кому известны эти данные, может вычислить будущий адрес, не отправляя транзакцию в блокчейн.Адрес не зависит от времени развертывания, текущего номера блока или количества контрактов, ранее созданных фабрикой.Изменение любого входного значения в формуле приводит к другому предсказанному адресу.Поэтому контракт можно заранее запланировать, указать на него, пополнить его или включить его в подписанные сообщения еще до появления кода в блокчейне.

Формула адреса CREATE2

Адрес CREATE2 вычисляется по следующей формуле.

Значение

— однобайтовый префикс, который отделяет адреса CREATE2 от адресов, созданных обычным опкодом CREATE.

— 20-байтовый адрес контракта, который непосредственно выполняет опкод CREATE2.

— 32-байтовое значение, передаваемое операции CREATE2.

— код инициализации, выполняемый при создании контракта.

Перед включением в итоговые 85 байт входных данных хеша CREATE2 код инициализации хешируется.Последние 20 байт итогового хеша Keccak-256 становятся адресом контракта.Формулу можно вычислить локально без оплаты сетевой комиссии, поскольку для предсказания результата не требуется менять состояние блокчейна.

Что такое развертывающий контракт CREATE2?

Развертывающий контракт CREATE2 — это смарт-контракт, который непосредственно вызывает опкод CREATE2.Его часто называют фабрикой, контрактом-развертывателем, прокси для детерминированного развертывания или singleton-фабрикой.Внешний аккаунт, отправивший транзакцию фабрике, не обязательно является адресом, используемым в формуле CREATE2.Обычно нужным адресом развертывающей стороны является адрес фабрики, поскольку именно она выполняет опкод.Использование другой фабрики приводит к другому предсказанному адресу контракта, даже если salt и код инициализации одинаковы.Поэтому разработчикам важно проверить точный адрес фабрики, а не вычислять результат по адресу кошелька, который отправляет транзакцию.Фабрика может разрешать любому пользователю развертывать произвольный код инициализации либо ограничивать развертывание одобренными аккаунтами и шаблонами контрактов.Права доступа и реализация фабрики могут повлиять на возможность развернуть контракт по предсказанному адресу.

Что такое salt CREATE2?

Salt CREATE2 — произвольное 32-байтовое значение, участвующее в детерминированном вычислении адреса.Salt позволяет фабрике развернуть несколько контрактов с одним и тем же кодом инициализации, присвоив каждому отдельный адрес.Salt можно получить из идентификатора пользователя, адреса кошелька, номера аккаунта, идентификатора токена, версии приложения, случайного значения или сочетания нескольких полей.Salt не обязательно хранить в секрете.Любой, кому известны фабрика, salt и код инициализации, может вычислить тот же адрес.Разработчикам следует определить понятный способ кодирования salt, поскольку несовпадение форматов может привести к неожиданным адресам.

Например, число

, текстовая строка и 32-байтовое значение, заканчивающееся на , могут интерпретироваться по-разному.

Чтобы избежать неоднозначности, проект может хешировать структурированные данные и получать salt фиксированной длины — 32 байта.

Что такое код инициализации?

Код инициализации, часто сокращенно называемый init code, — это временный код EVM, выполняемый при создании смарт-контракта.Он выполняет логику конструктора и возвращает исполняемый байт-код, который останется по новому адресу.Сам код инициализации обычно не сохраняется как постоянный код контракта.Формула CREATE2 учитывает хеш этого кода.В развертываниях Solidity полный код инициализации обычно включает байт-код создания контракта и аргументы конструктора, закодированные по ABI.

Текущая документация Solidity по созданию контрактов с salt подтверждает, что адрес зависит от байт-кода создания и аргументов конструктора.

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

Код инициализации и исполняемый байт-код

Код инициализации и исполняемый байт-код связаны, но это не одно и то же.Код инициализации запускается один раз при развертывании.Исполняемый байт-код — это код, который после завершения развертывания хранится по адресу контракта.Формула адреса CREATE2 напрямую учитывает хеш кода инициализации, а не хеш итогового исполняемого кода.Это различие важно для безопасности.Конструктор может считывать внешнее состояние блокчейна и использовать эту информацию, чтобы выбрать исполняемый код или начальные значения хранилища.Поэтому один и тот же код инициализации при выполнении в разных внешних условиях может привести к разному поведению развернутого контракта.Разработчикам, которым необходимо надежно зафиксировать поведение, следует избегать конструкторов, зависящих от окружения, либо после развертывания проверять итоговый исполняемый код и хранилище.

Аргументы конструктора и CREATE2

В развертываниях Solidity аргументы конструктора входят в код инициализации.

Адрес CREATE2 контракта, созданного с адресом владельца

, обычно будет отличаться от адреса того же контракта, созданного с адресом владельца .

То же правило действует для названий токенов, значений предложения, адресов реализаций, списков валидаторов, настроек комиссий и других входных данных конструктора.Разработчики должны кодировать аргументы конструктора в том же порядке и формате, который предусмотрен ABI контракта.Предсказатель адресов, не учитывающий аргументы конструктора, выдаст неверный результат.Функции инициализации, вызываемые после развертывания, не влияют на формулу CREATE2, если сам вызов инициализации не включен в конструктор или процесс фабрики.Разделение развертывания и инициализации может создать риск перехвата, если другой аккаунт способен первым вызвать незащищенную функцию инициализации.

CREATE и CREATE2: сравнение

CREATE и CREATE2 — операции EVM для создания смарт-контрактов.При обычном CREATE новый адрес в основном вычисляется по адресу создающего аккаунта и его nonce развертывания.Nonce увеличивается по мере создания новых контрактов.Чтобы предсказать адрес CREATE, разработчику необходимо знать правильную последовательность развертываний.CREATE2 заменяет формулу с nonce на формулу, основанную на адресе фабрики, salt и хеше кода инициализации.CREATE2 не меняет принцип выполнения кода конструктора или хранения возвращенного исполняемого байт-кода.Он меняет способ вычисления адреса назначения и добавляет затраты газа на хеширование кода инициализации.Обе операции завершаются ошибкой, если целевой адрес не соответствует правилам EVM о коллизиях при создании контрактов.

Когда появился CREATE2?

CREATE2 был описан в EIP-1014 в 2018 году.Он вошел в обновление сети Ethereum Constantinople.

В спецификации обновления Constantinople EIP-1014 указан среди изменений протокола, вошедших в обновление.

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

CREATE2 в Solidity

В Solidity предусмотрен высокоуровневый синтаксис для развертывания контрактов через CREATE2.

Фабрика может использовать синтаксис

.

Компилятор Solidity подготавливает байт-код создания, кодирует аргументы конструктора и формирует операцию CREATE2.

При развертывании конструктор с модификатором payable также может получить нативную валюту блокчейна через параметр

.

Фабрике следует проверять, что развертывание вернуло ожидаемый ненулевой адрес.Разработчики также могут вызывать CREATE2 через встроенный ассемблер, если им необходим прямой контроль над памятью и длиной кода инициализации, salt и передаваемым значением.Встроенный ассемблер увеличивает риск ошибок реализации и требует тщательного тестирования.

Упрощенный пример CREATE2 в Solidity

В этом примере предсказанный адрес дочернего контракта зависит от адреса фабрики, salt, байт-кода создания Child и закодированного аргумента

.

Изменение внешнего вызывающего аккаунта без изменения этих входных данных не обязательно изменит адрес.

Изменение

меняет адрес, поскольку аргумент конструктора входит в код инициализации.

Как предсказать адрес CREATE2

Разработчик может вычислить адрес CREATE2 в смарт-контракте, скрипте развертывания, кошельке или локальном приложении.При расчете необходимо использовать точный адрес фабрики, которая будет выполнять CREATE2.Также нужно использовать salt в его итоговом 32-байтовом представлении.Хеш кода инициализации должен учитывать точный байт-код создания и закодированные аргументы конструктора.После развертывания результат следует сравнить с адресом, возвращенным фабрикой.Инструменты развертывания должны останавливать процесс, если предсказанный и фактический адреса отличаются.Чаще всего ошибочный результат получается из-за использования исполняемого байт-кода вместо байт-кода создания, пропуска аргументов конструктора, выбора неверной фабрики или неправильного кодирования salt.

Что такое контрфактическое развертывание?

Контрфактическое развертывание — это использование будущего адреса смарт-контракта до размещения по нему кода.Участники могут заранее вычислить адрес и договориться об ожидаемом коде инициализации контракта.Они могут отправить активы на этот адрес, указать его в другом контракте или создать связанные с ним подписанные разрешения.Контракт развертывают только тогда, когда он становится необходим.Это позволяет отложить немедленную транзакцию развертывания и сократить первоначальные расходы на подключение.В первоначальном описании EIP-1014 особое внимание уделялось контрфактическому взаимодействию в каналах состояний: контракт мог понадобиться только в случае спора между участниками.Сегодня контрфактическое развертывание также важно для кошельков на основе смарт-контрактов и абстракции аккаунтов.

Контрфактические аккаунты на основе смарт-контрактов

Предсказанный адрес смарт-аккаунта можно определить до развертывания его контракта с помощью CREATE2.Пользователь может сообщить этот адрес и получать на него криптовалюту или токены.Затем первая операция аккаунта может развернуть кошелек и выполнить действие в рамках одного общего процесса.Благодаря этому пользователю не требуется выполнять отдельную транзакцию для создания кошелька до получения активов.

Спецификация абстракции аккаунтов ERC-4337 поддерживает создание смарт-аккаунта отправителя по данным инициализации фабрики, если аккаунт еще не существует.

Фабрики аккаунтов часто используют CREATE2, чтобы вычислить адрес отправителя до развертывания.Не все варианты абстракции аккаунтов обязаны использовать CREATE2: в новых моделях авторизации и аккаунтов могут применяться другие механизмы.

Отправка криптовалюты на неразвернутый адрес

Неразвернутый адрес CREATE2 может получать нативную криптовалюту блокчейна: для хранения баланса адресу не нужен исполняемый код.На предсказанный адрес также можно переводить взаимозаменяемые токены и NFT, если их контракты поддерживают обычные переводы на адреса.Активы остаются привязанными к адресу, хотя кода контракта там еще нет.Ими можно будет пользоваться после успешного развертывания предполагаемого контракта.Такой подход может упростить подключение кошельков и разработку контрфактических приложений.Но он создает серьезный риск: активы могут стать недоступными, если неверно указаны фабрика, salt или код инициализации.Перед отправкой значительной суммы на контрфактический адрес следует убедиться, что развертывание действительно возможно.

Может ли пустой адрес CREATE2 хранить средства?

Да. Адрес без кода может иметь баланс нативной криптовалюты и токенов.Положительный баланс сам по себе не препятствует развертыванию CREATE2 по этому адресу.Правило EVM о коллизиях учитывает ненулевой nonce или непустой код целевого адреса.Это необходимо для контрфактических аккаунтов, получающих средства до развертывания.После развертывания код контракта и правила авторизации определяют, как можно использовать эти активы.

Правила CREATE2 при коллизиях

Развертывание CREATE2 завершается ошибкой, если по целевому адресу уже есть непустой код или ненулевой nonce.Это не позволяет фабрике перезаписать уже существующий контракт по тому же адресу.Правило действует, даже если новый код инициализации в противном случае правильно вычислил бы этот адрес.Развертывание также завершится ошибкой, если код инициализации откатит выполнение, исчерпает газ, вернет недопустимый код или нарушит другое правило создания контрактов.Фабрикам следует обрабатывать нулевой результат опкода CREATE2 и по возможности возвращать понятную ошибку.Коллизия не означает, что криптографическая стойкость хеш-функции Keccak нарушена.Обычно это означает, что детерминированный адрес уже занят согласно правилам аккаунтов EVM.

Могут ли два разных развертывания привести к одному адресу CREATE2?

Два развертывания вычислят одинаковый адрес, если используют один адрес фабрики, один salt и один хеш кода инициализации.Теоретически у разного кода инициализации может быть одинаковый хеш, но практический поиск коллизии Keccak-256 при текущих предположениях о безопасности считается вычислительно невыполнимым.Поскольку в адрес входят только последние 20 байт, случайные коллизии адресов теоретически возможны, как и для других адресов Ethereum.Создание выбранной коллизии при нынешних вычислительных возможностях остается практически невыполнимым.Разработчикам все равно не следует считать визуально похожий адрес доказательством корректности входных данных развертывания.

Повторное использование salt

Фабрика может повторно использовать salt, если код инициализации отличается: хеш такого кода приведет к другому адресу.Одна фабрика не сможет успешно дважды развернуть один и тот же код инициализации с одним salt, пока исходный адрес остается занятым.На уровне приложения проект может запретить повторное использование salt, чтобы упростить отслеживание намерений при развертывании.Публичная фабрика может разрешать использовать уже применявшийся salt, поскольку в полной формуле также учитывается хеш кода инициализации.Уникальность salt сама по себе не является полной гарантией безопасности.Следует проверять всю комбинацию: фабрику, salt и код инициализации.

Опережающий запуск развертывания CREATE2

Ожидающую включения в блок транзакцию CREATE2 могут увидеть заранее.Другой пользователь может скопировать вызов фабрики и попытаться развернуть контракт первым.Если фабрика не ограничивает доступ и использует одинаковые salt и код инициализации, скопированное развертывание должно создать тот же код по тому же предсказанному адресу.В этом случае исходная транзакция может завершиться ошибкой, поскольку целевой адрес уже занят.Это все равно может нарушить сроки, привести к напрасным расходам газа или сбоям в работе приложения.Риск серьезнее, если поведение конструктора зависит от меняющихся данных среды: информации о блоке, отправителе транзакции, состояния внешнего контракта или параметров фабрики, зависящих от вызывающего аккаунта.

В текущем предложении о детерминированной фабрике рекомендуется использовать известные фабрики для полностью детерминированных контрактов, а не применять развертывание, результат которого зависит от среды выполнения.

Риск опережающего запуска конструктора

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

Риск незащищенной функции инициализации

В прокси-контрактах и минимальных клонах часто используют функции инициализации вместо конструкторов.Функция инициализации задает владельца, права доступа, параметры реализации и другие важные состояния после развертывания.Предсказуемость адреса CREATE2 сама по себе не защищает такую функцию.Если развертывание и инициализация выполняются в разных транзакциях, злоумышленник может вызвать функцию инициализации первым.Фабрике следует атомарно инициализировать контракт в той же транзакции, в которой он развертывается, либо обеспечить строгую авторизацию.Детерминированный адрес не компенсирует небезопасную схему инициализации.

Фабрики CREATE2

Фабрика CREATE2 — это многоразовый смарт-контракт, который принимает salt и код инициализации и выполняет опкод CREATE2.Фабрика позволяет внешним аккаунтам и другим смарт-контрактам использовать детерминированное развертывание через единый интерфейс.Минимальная фабрика может принимать произвольный код без проверки разрешений.Специализированная фабрика может развертывать только одобренные реализации аккаунтов или модули приложений.Разработчикам следует проверять исполняемый байт-код фабрики, историю развертываний, права доступа, обработку ошибок и поведение при передаче средств.Вредоносная фабрика может изменить входные данные, ограничить развертывание, удержать средства или запустить неожиданный код.

Singleton-фабрики

Singleton-фабрика — это детерминированная фабрика, которую планируют развернуть по одному и тому же адресу в нескольких сетях EVM.Единый адрес фабрики позволяет разработчикам вычислять одинаковый адрес дочернего контракта в каждой поддерживаемой сети.

В ERC-2470 предложена разрешенная для всех singleton-фабрика CREATE2 для детерминированного развертывания.

В предложении использовался метод развертывания без ключа, чтобы создавать фабрику по известному адресу в совместимых сетях.По состоянию на июль 2026 года в репозитории EIP у ERC-2470 указан статус Stagnant, хотя концепция детерминированных фабрик по-прежнему широко актуальна.Статус предложения в репозитории и факт развертывания контракта в реальной сети — разные вопросы.

Детерминированное развертывание в нескольких сетях

CREATE2 может помочь развернуть контракт по одному и тому же адресу в нескольких сетях EVM.Для этого в каждой сети должны совпадать адрес фабрики CREATE2, salt и хеш кода инициализации.Недостаточно использовать один и тот же кошелек развертывания, если он вызывает фабрики с разными адресами.Метаданные компилятора, привязка библиотек, аргументы конструктора и изменения исходного кода контракта могут изменить хеш кода инициализации.Идентификатор сети напрямую не входит в базовую формулу CREATE2.Однако конструктор или инструмент развертывания может учитывать данные конкретной сети, меняя код инициализации или развернутое состояние.Даже если адреса совпадают, разработчикам следует отдельно проверять код, развернутый в каждой сети.

Зачем нужен одинаковый адрес в нескольких сетях?

Совпадающие адреса контрактов сокращают число адресов, которые необходимо хранить в кошельках, интерфейсах, библиотеках ПО и других контрактах.Разработчик может использовать одну константу адреса в нескольких поддерживаемых сетях.Пользователям проще избежать ошибки при копировании адреса контракта не из той сети.Смарт-аккаунты также могут иметь единый адрес в разных сетях.Это повышает удобство, но может создать ложное чувство уверенности, если в одной из сетей по тому же адресу находится другой код или другая конфигурация.Адрес всегда следует проверять вместе с идентификатором сети и подтвержденным байт-кодом.

Текущие предложения о детерминированных фабриках

Инфраструктура детерминированных фабрик продолжает развиваться по мере появления новых сетей EVM и роллапов.

По состоянию на июль 2026 года EIP-7997 находится на рассмотрении (Review). В предложении предлагается формально требовать размещение широко используемой детерминированной фабрики по заданному адресу в сетях EVM.

Предложение еще не окончательное и не должно рассматриваться как универсальная гарантия для каждой сети.

ERC-7955 остается проектом предложения (Draft) о запуске универсальной фабрики CREATE2 без разрешений с помощью возможностей EIP-7702.

Эти предложения решают проблему, которую не устраняет сам CREATE2: размещение исходной фабрики по одному и тому же адресу во всех сетях.Перед использованием универсальной фабрики разработчикам следует проверять текущий статус предложения и фактическое состояние сети.

CREATE2 и абстракция аккаунтов

Абстракция аккаунтов позволяет смарт-аккаунтам использовать программируемые правила проверки и выполнения операций.Кошелек может поддерживать несколько подписантов, ключи Passkey, доверенных лиц для восстановления, лимиты расходов, пакетные операции и оплату комиссий спонсором.CREATE2 позволяет фабрике кошельков вычислить адрес аккаунта до развертывания контракта кошелька.Пользователь может получить средства на этот адрес и развернуть аккаунт при обработке первой операции.ERC-4337 позволяет включить данные фабрики, чтобы создать аккаунт, которого еще нет.Контрфактический адрес аккаунта должен совпадать с адресом, полученным в результате вызова фабрики.Если фабрика развернет код по другому адресу, операция аккаунта завершится ошибкой при стандартной процедуре проверки.

CREATE2 и подписи до развертывания

Контрактный аккаунт может подписать сообщение для аутентификации еще до развертывания.Стандартная проверка подписей контрактов не может вызвать такой аккаунт, поскольку по его адресу еще нет исполняемого кода.

ERC-6492 определяет формат обертки для проверки подписей от имени контрактных аккаунтов, еще не развернутых в блокчейне.

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

CREATE2 и аккаунты, привязанные к токенам

Аккаунт, привязанный к токену, — это смарт-аккаунт, связанный с невзаимозаменяемым токеном.Такой аккаунт может хранить криптовалюту, токены, NFT и другие ончейн-активы.

ERC-6551 использует CREATE2, чтобы адреса аккаунтов, привязанных к токенам, могли существовать в контрфактическом виде до развертывания.

Это позволяет отправлять активы на аккаунт токена до оплаты развертывания его контракта.Согласно правилам стандарта, адрес аккаунта зависит от реестра, реализации, salt, идентификатора блокчейна, контракта токена и идентификатора токена.Обычно право выполнять действия через аккаунт, привязанный к токену, определяется владением управляющим NFT.

CREATE2 и каналы состояний

Каналы состояний позволяют участникам многократно взаимодействовать вне блокчейна, используя контракт блокчейна для обеспечения итогового результата или разрешения спора.Участники могут заранее согласовать код и адрес контракта для разрешения споров.CREATE2 позволяет вычислить такой адрес, не развертывая контракт немедленно.Участники могут ссылаться на контрфактический контракт в ходе взаимодействия вне блокчейна.Развертывать контракт нужно только тогда, когда требуется принудительное исполнение.Это было одним из исходных сценариев использования, описанных в EIP-1014.

CREATE2 и минимальные прокси-контракты

Минимальный прокси — небольшой контракт, который делегирует вызовы контракту-реализации.Фабрика может сочетать минимальные прокси с CREATE2, чтобы создавать аккаунты или компоненты приложений по предсказуемым адресам.Адрес реализации может входить в код инициализации прокси.В этом случае изменение адреса реализации может изменить и предсказанный адрес прокси.Некоторые фабрики задают параметры инициализации в хранилище развернутого прокси в рамках той же транзакции.Разработчикам необходимо проверить, охватывает ли детерминированная фиксация реализацию, данные инициализации или только типовой каркас прокси.

CREATE2 и обновляемые контракты

Сам по себе CREATE2 не является механизмом обновления.Контракт, развернутый с помощью CREATE2, может поддерживать обновления, если он использует прокси или другую явно заданную архитектуру обновления.В такой схеме прокси остается по детерминированному адресу, а ссылка на реализацию может меняться.Безопасность обновлений зависит от прав администратора прокси, правил управления, задержки и проверки реализации.Детерминированный адрес прокси не гарантирует неизменность его поведения.Пользователям следует проверять права на обновление, а не предполагать, что предсказуемый адрес означает постоянство кода.

CREATE2, SELFDESTRUCT и повторное развертывание

В ранних схемах CREATE2 иногда использовали

, чтобы удалить контракт, а затем развернуть по тому же адресу код с другим поведением.

Такие схемы часто называли метаморфными контрактами.

Действующие правила EIP-6780 для SELFDESTRUCT в Ethereum в целом не позволяют удалять код и хранилище давно развернутого контракта.

Если SELFDESTRUCT вызывает контракт, созданный не в той же транзакции, баланс переводится, но код, хранилище и аккаунт не удаляются.Поэтому обычные схемы обновления, в которых развернутый контракт уничтожали и создавали заново по тому же адресу CREATE2, больше не работают.В EIP-6780 прямо рекомендуется использовать проверенные схемы обновления на основе прокси, а не повторное развертывание CREATE2.SELFDESTRUCT остается устаревающим механизмом, и новые системы не должны полагаться на то, что его поведение всегда будет неизменным.

Риски метаморфных контрактов

Метаморфный контракт предназначен для изменения кода, работающего по постоянному адресу, путем уничтожения и повторного развертывания.До введения действующих ограничений на SELFDESTRUCT этот подход создавал особые риски для доверия, основанного на адресе.Пользователь мог проверить одну версию кода, а позднее взаимодействовать по тому же адресу с другой версией.Действующие правила Ethereum нарушили общую схему повторного развертывания давно существующих контрактов, однако в старых сетях или других средах EVM правила SELFDESTRUCT могут отличаться.Инструментам безопасности следует учитывать правила конкретного блокчейна и периода блока, который анализируется.Исторические транзакции нужно оценивать с учетом правил протокола, действовавших в момент их выполнения.

Затраты газа CREATE2

Расчет газа для CREATE2 похож на обычный CREATE, но включает дополнительную стоимость хеширования кода инициализации.В EIP-1014 эта дополнительная стоимость определяется количеством 32-байтовых слов в коде инициализации.Поэтому для более крупного кода инициализации требуется больше газа на вычисление адреса, а также на работу с памятью и выполнение конструктора.При развертывании также оплачиваются хранение итогового исполняемого байт-кода и операции конструктора.Расценки на газ в сети могут меняться после обновлений протокола, поэтому фиксированные оценки не следует считать постоянными.Для последующего развертывания заранее пополненного контрфактического аккаунта все равно может понадобиться достаточно нативной криптовалюты или спонсор комиссии.

Ограничения на размер кода инициализации

Протокол Ethereum ограничивает размер кода инициализации и вводит за него плату.

EIP-3860 ввел дополнительный расчет газа для кода инициализации и ограничение его максимального размера.

Эти правила применяются как к CREATE, так и к CREATE2.Разработчикам крупных фабрик не следует считать, что можно успешно передать конструктор произвольного размера.Инструменты разработки должны проверять итоговый скомпилированный код инициализации на соответствие действующим ограничениям сети.

Визуально узнаваемые адреса контрактов

Разработчики могут перебирать значения salt, пока предсказанный адрес CREATE2 не будет содержать нужный префикс или шаблон.Этот процесс называют поиском визуально узнаваемого адреса контракта.Короткий узнаваемый префикс может упростить визуальное распознавание адреса.Он не повышает безопасность контракта и не дает дополнительных полномочий.Следует проверять адрес полностью: мошенники могут создавать адреса с похожими префиксами и суффиксами.Визуально узнаваемый адрес не заменяет проверку байт-кода и достоверных данных о развертывании.

CREATE2 и подмена адреса

При подмене адреса злоумышленник пытается сделать так, чтобы обманный адрес появился в истории транзакций пользователя или в интерфейсе кошелька.Злоумышленник может создать адрес, отдельные символы которого похожи на символы доверенного адреса.CREATE2 позволяет искать адреса контрактов с заданным визуальным шаблоном, меняя salt.Для этой атаки не нужно взламывать CREATE2 или Keccak-256.Она рассчитана на то, что пользователи проверяют только начало или конец адреса.Перед отправкой криптовалюты следует проверить весь адрес или воспользоваться надежной адресной книгой.

Путаница с адресами в разных сетях

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

Риски доверия к фабрике

Расчет детерминированного адреса предполагает, что выбранная фабрика работает ожидаемым образом.Фабрика может изменить salt или код инициализации, ограничить доступ, взимать комиссию или неожиданным образом переводить средства за развертывание.Обновляемая фабрика может измениться после первоначальной проверки разработчиком.Если фабрикой управляет один приватный ключ, она может стать недоступной или вредоносной, если ключ утерян или скомпрометирован.Фабрики без разрешений снижают некоторые риски контроля, но могут создавать риски опережающего развертывания и спама.Перед использованием предсказанных адресов разработчикам следует проверять исполняемый код фабрики и способ ее развертывания.

Риски компилятора и метаданных

Разные версии компилятора Solidity могут выдавать разный байт-код создания для одного и того же исходного кода.Настройки компилятора — например количество циклов оптимизации, параметры метаданных, подключенные библиотеки и целевая версия EVM — также могут изменить байт-код.Даже небольшое отличие байт-кода меняет хеш кода инициализации и адрес CREATE2.Разработчикам следует зафиксировать версию компилятора и конфигурацию сборки для детерминированного развертывания.Воспроизводимая сборка помогает независимым пользователям подтвердить, что опубликованный исходный код создает развернутый байт-код.Чтобы воспроизвести предсказанный адрес, может быть недостаточно скопировать только исходный код Solidity без настроек сборки.

Подключение библиотек

В контракте Solidity могут быть незаполненные места, которые необходимо заменить адресами развернутых библиотек до создания контракта.Подключенный байт-код создания входит в код инициализации CREATE2.Изменение адреса библиотеки меняет предсказанный адрес контракта.Поэтому при кроссчейн-развертывании адреса могут отличаться, если связанные библиотеки находятся по разным адресам.Чтобы добиться одинаковых адресов в нескольких сетях, проекту может понадобиться сначала детерминированно развернуть библиотеки, а затем зависимые от них контракты.

Проверка CREATE2: контрольный список

Перед вычислением предполагаемого адреса проверьте блокчейн и адрес фабрики.Убедитесь, что salt закодирован именно в нужном 32-байтовом формате.Используйте байт-код создания, а не исполняемый байт-код.Включите в код инициализации аргументы конструктора, закодированные по ABI.Зафиксируйте версию компилятора, настройки оптимизации, подключенные библиотеки и конфигурацию метаданных.Проверьте, нет ли по предсказанному адресу кода или ненулевого nonce.Смоделируйте вызов фабрики и изучите, зависит ли конструктор от внешнего состояния.После развертывания сравните фактический адрес, исполняемый байт-код, конфигурацию хранилища, владельца, реализацию и сгенерированные события с ожидаемым результатом.

Преимущества CREATE2

С помощью CREATE2 можно узнать адрес контракта до его развертывания.Этот метод поддерживает контрфактические кошельки и контракты, которые могут получать активы до появления кода.Адрес не зависит от изменяющегося nonce фабрики.Если все необходимые входные данные совпадают, CREATE2 позволяет создавать одинаковые адреса приложений в совместимых сетях EVM.Метод поддерживает эффективные схемы каналов состояний и контрактов для разрешения споров.Он упрощает управление адресами в кошельках, библиотеках ПО, смарт-контрактах и мультичейн-интерфейсах.CREATE2 также позволяет создавать воспроизводимые системы развертывания, в которых пользователи могут самостоятельно проверить ожидаемый адрес.

Ограничения CREATE2

CREATE2 не гарантирует, что контракт действительно будет развернут.Он не гарантирует надежность фабрики или ее доступность в каждой сети.Он не гарантирует, что в разных сетях по одинаковым адресам будут находиться одинаковый исполняемый код или состояние.Он не защищает неинициализированный прокси, небезопасный конструктор, скомпрометированного администратора или уязвимый смарт-контракт.Если по целевому адресу уже есть код или ненулевой nonce, CREATE2 не позволяет перезаписать существующий контракт.Действующие правила SELFDESTRUCT не позволяют использовать общие схемы обновления с уничтожением и повторным развертыванием давно существующих контрактов.Кроме того, возникает операционный риск, если пользователи отправляют средства на предсказанный адрес, не проверив все входные данные развертывания.

Часто задаваемые вопросы

Что такое CREATE2 простыми словами?

CREATE2 — инструкция EVM, позволяющая разработчикам вычислить адрес смарт-контракта до его развертывания.

Что означает детерминированное развертывание?

Это означает, что одни и те же заданные входные данные развертывания дают один и тот же вычисленный адрес контракта.

В каком EIP появился CREATE2?

CREATE2 был введен в EIP-1014.

Что такое опкод CREATE2?

Опкоду CREATE2 соответствует значение

.

Какие данные определяют адрес CREATE2?

Адрес зависит от адреса фабрики CREATE2, 32-байтового salt и хеша кода инициализации.

Использует ли CREATE2 nonce?

В формуле адреса CREATE2 не используется изменяющийся nonce фабрики для создания контрактов.

Входит ли отправитель транзакции в формулу CREATE2?

В формулу входит контракт, который непосредственно выполняет CREATE2. Обычно это фабрика, а не внешний кошелек, вызывающий ее.

Что такое salt CREATE2?

Salt — 32-байтовое значение, которое позволяет различать детерминированные развертывания и создавать разные адреса.

Нужно ли хранить salt CREATE2 в секрете?

Нет, обычно salt не нужно держать в секрете.

Что такое init code?

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

Хеширует ли CREATE2 исполняемый байт-код?

Формула адреса хеширует код инициализации, а не только итоговый исполняемый байт-код.

Меняют ли аргументы конструктора адрес CREATE2?

Да. В Solidity аргументы конструктора входят в код инициализации и обычно меняют предсказанный адрес.

Можно ли вычислить адрес CREATE2 вне блокчейна?

Да, адрес можно вычислить локально, не отправляя транзакцию в блокчейн.

Может ли неразвернутый адрес CREATE2 получать криптовалюту?

Да, предсказанный адрес может получать нативную криптовалюту и совместимые токены до развертывания контракта.

Безопасно ли отправлять средства на неразвернутый адрес?

Это рискованно, если не проверены фабрика, salt, код инициализации, возможность развертывания и будущие правила авторизации.

Можно ли развернуть контракт CREATE2 поверх существующего?

Нет. Развертывание завершается ошибкой, если по целевому адресу уже есть непустой код или ненулевой nonce.

Можно ли дважды развернуть один и тот же контракт с CREATE2?

Пока исходный адрес занят, одинаковая комбинация фабрики, salt и кода инициализации не позволит успешно развернуть контракт повторно.

Можно ли повторно использовать один и тот же salt?

Да. Если фабрика или хеш кода инициализации различаются, тот же salt может привести к разным адресам.

Можно ли опередить развертывание CREATE2?

Другой пользователь может скопировать публичный вызов фабрики и развернуть контракт первым. Это может нарушить сроки и быть опасным, если поведение конструктора зависит от меняющихся внешних данных.

Гарантирует ли CREATE2 одинаковый код в разных сетях?

Нет. Для одинаковых адресов должны совпадать входные данные, но среда выполнения конструктора, инициализация, конфигурация и состояние сети все еще могут привести к существенным различиям.

Как с помощью CREATE2 создать один адрес в нескольких сетях?

В каждой совместимой сети должны использоваться одинаковые адрес фабрики, salt и хеш кода инициализации.

Входит ли идентификатор сети в формулу CREATE2?

В базовую формулу идентификатор сети напрямую не входит, хотя код развертывания или аргументы конструктора могут учитывать данные конкретной сети.

Что такое фабрика CREATE2?

Фабрика CREATE2 — смарт-контракт, который выполняет детерминированное развертывание для пользователей или других контрактов.

Что такое singleton-фабрика?

Это фабрика CREATE2, которую планируют развернуть по одному известному адресу в нескольких сетях.

Что такое контрфактическое развертывание?

Это использование предсказуемого адреса контракта до его развертывания.

Как CREATE2 помогает кошелькам на основе смарт-контрактов?

С его помощью можно вычислить адрес кошелька и пополнить его до создания контракта кошелька.

Как CREATE2 связан с ERC-4337?

Фабрики аккаунтов ERC-4337 часто используют CREATE2 для вычисления и развертывания предсказуемых адресов смарт-аккаунтов.

Может ли неразвернутый контракт подписывать сообщения?

ERC-6492 предлагает метод проверки подписей, связанных с некоторыми контрфактическими контрактными аккаунтами, до их развертывания.

Является ли CREATE2 механизмом обновления?

Нет. Для обновления требуется отдельная схема с прокси или механизмом управления.

Может ли SELFDESTRUCT очистить контракт для повторного развертывания через CREATE2?

Действующие правила Ethereum обычно сохраняют код и хранилище уже развернутых контрактов, поэтому схемы обновления с уничтожением и повторным развертыванием давно существующих контрактов больше не работают.

Что такое метаморфный контракт?

Это устаревшая схема, предназначенная для изменения кода по одному адресу путем уничтожения контракта и его детерминированного повторного развертывания.

CREATE2 требует больше газа, чем CREATE?

Да. Помимо обычных затрат на создание, память, выполнение конструктора и хранение кода, CREATE2 требует дополнительного газа на хеширование кода инициализации.

Можно ли создать визуально узнаваемый адрес CREATE2?

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

Повышает ли узнаваемый адрес CREATE2 безопасность?

Нет. Узнаваемый префикс или суффикс не подтверждает безопасность кода, право собственности или подлинность.

Почему предсказанный адрес CREATE2 не совпал с адресом после развертывания?

Частые причины — неверная фабрика, кодирование salt, выходные данные компилятора, подключенная библиотека или аргументы конструктора, а также путаница между байт-кодом создания и исполняемым байт-кодом.

Как проверить развертывание CREATE2?

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

Заключение

Детерминированное развертывание с помощью CREATE2 позволяет вычислить адрес совместимого с Ethereum смарт-контракта до появления кода в блокчейне.Адрес определяется фиксированным префиксом, адресом фабрики CREATE2, 32-байтовым salt и хешем кода инициализации.Аргументы конструктора, выходные данные компилятора, подключенные библиотеки и настройки сборки могут изменить код инициализации, а значит, и адрес.CREATE2 поддерживает контрфактические смарт-аккаунты, каналы состояний, аккаунты, привязанные к токенам, предсказуемые компоненты приложений и развертывание в нескольких сетях по одному адресу.На предсказанный адрес можно отправить криптовалюту до развертывания, но средства могут стать недоступными, если предполагаемый контракт невозможно создать.Для совпадения адресов в разных сетях необходимы одинаковые фабрика, salt и хеш кода инициализации. Это автоматически не гарантирует одинаковый код, состояние или безопасность.Разработчикам также необходимо защитить функции инициализации, избегать конструкторов, зависящих от среды выполнения, проверять поведение фабрики и учитывать риск опережающего развертывания.Действующие правила SELFDESTRUCT в Ethereum не позволяют использовать общие схемы обновления, основанные на уничтожении давно существующего контракта и его повторном создании по тому же адресу.Поэтому CREATE2 следует рассматривать как инструмент вычисления адресов и развертывания, а не как автоматическое решение для безопасности или обновления.При тщательной проверке входных данных, фабрики, байт-кода и процесса инициализации CREATE2 становится мощной основой для предсказуемых и удобных криптовалютных приложений.