Перейти к содержанию
Financial Context Wiki

Как проверить адрес контракта CREATE2

CREATE2 предсказывает адрес по развертывателю, соли и хешу init-кода, но проверка требует доказательств по сети, фабрике, bytecode, развертыванию, proxy и владельцу.

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Краткий ответ

CREATE2 предсказывает адрес, создаваемый конкретным контрактом-развертывателем, используя 32-byte salt и хеш точного init_code. Формула протокола: address = keccak256(0xff || deployer(20 bytes) || salt(32 bytes) || keccak256(init_code))[12:]: хешируется 85-byte preimage, затем берутся последние 20 bytes. Развертыватель — фабрика, выполняющая CREATE2, а не обязательно кошелек, вызвавший фабрику.

init_code состоит из creation bytecode и ABI-кодированных аргументов конструктора; он выполняется один раз и создает runtime bytecode. Версия компилятора, optimizer, связанная библиотека, metadata, аргумент конструктора или точка входа фабрики могут изменить хеш. Runtime-код — результат, а не вход CREATE2. Один адрес сопоставим только при одинаковых развертывателе, соли, init-коде, правилах EVM и состоянии сети.

Контрфактический адрес может получить средства до появления кода, но его управляющая логика еще не проверена. Предсказание не доказывает развертывание, владение, авторизацию, финальность или безопасность. На нужной сети и блоке проверьте код фабрики и calldata, receipt, events, eth_getCode, nonce, storage, balance, implementation proxy, initializer и owner.

Как это работает

Зафиксируйте сеть или домен, правила fork, RPC и блок, адрес фабрики и runtime hash, необработанную salt, точные init-байты, кодирование конструктора, compiler и linked libraries. Пересчитайте keccak256(init_code) и 85-byte preimage, проверив ABI padding, порядок байтов, checksum и извлечение последних 20 байт.

Декодируйте вызов фабрики и value. Убедитесь, что фабрика, entry point, salt domain, constructor, owner и initializer связаны с ожидаемой конфигурацией. Для minimal proxy хешируйте creation bytecode клона с адресом implementation, а не runtime bytecode implementation. Для proxy отдельно проверьте implementation, admin, storage slots и upgrade policy.

По EIP-684 создание отклоняется, если nonce назначения ненулевой или code непуст. Неудачный constructor также не создает успешный deployment. Семантика SELFDESTRUCT и повторного развертывания зависит от правил fork; не используйте старое предположение, что код всегда можно заменить.

Доказательства deployment идут слоями: включение и status транзакции, events, code и nonce, storage и balances, затем безопасное или финальное состояние сети. Успешный RPC или checksum предсказания не заменяет receipt и state. На разных сетях один адрес может иметь разные code, owners, storage и assets.

Используйте этот процесс:

  1. Зафиксируйте chain, fork, RPC и block; factory или deployer и runtime hash; salt bytes; init code, constructor arguments, compiler и linked libraries.
  2. Вычислите init-code hash и точный CREATE2 preimage, проверив widths, padding, 0xff, последние 20 bytes и checksum.
  3. Декодируйте factory calldata и value; сравните predicted address, owner, initializer, proxy target и permissions.
  4. Проверьте receipt, status, events, eth_getCode, nonce, balance и storage на правильной chain; зафиксируйте not-deployed и collision states.
  5. Проверьте factory, proxy, implementation, admin, initializer, upgrade и singleton-factory assumptions, включая ERC-1167 targets.
  6. Протестируйте constructor failure, nonce/code collision, fork-sensitive redeployment, nested factories и chain-domain или replay assumptions.
  7. До funding или signing сопоставьте человекочитаемые и raw amounts; после deployment отслеживайте code hash, owner, implementation, roles, events и finality.

Примеры

  • Вектор EIP-1014: deployer 0x0000000000000000000000000000000000000000, нулевая salt и init 0x00 дают 0x4D1A2e2bB4F88F0250f26Ffff098B0b30B26BF38.
  • Связь с constructor: при фиксированных deployer и salt изменение одного ABI-кодированного аргумента меняет keccak256(init_code) и predicted address; хеширование runtime bytecode проверяет не тот объект.
  • Collision: если nonce назначения больше 0 или code непуст, CREATE2 должен revert по EIP-684. Профинансированный адрес с нулевыми code и nonce остается лишь контрфактическим и непроверенным.
  • Minimal proxy: адрес ERC-1167-клона хеширует clone creation bytecode с адресом implementation. Хеш runtime bytecode implementation дает несвязанный prediction.

Риски

  • Использована неправильная factory или deployer.
  • Неверны ширина, padding, endian или domain encoding salt.
  • Init code перепутан с runtime bytecode.
  • Constructor arguments пропущены или переставлены.
  • Отличаются factory entry point, value или calldata.
  • Proxy или delegate target не является нужной implementation.
  • Отличаются chain, fork или EVM domain.
  • Существующий nonce вызывает collision.
  • Существующий code вызывает collision.
  • Использовано устаревшее предположение о SELFDESTRUCT и redeployment.
  • Nested CREATE2 меняет фактический deployer.
  • Перепутаны формулы CREATE и CREATE2.
  • Не проверен implementation target ERC-1167.
  • Не проверены адрес и предположения singleton factory.
  • Upgrade или admin implementation меняет поведение.
  • Отличаются compiler, metadata, library или source artifact.
  • Перепутаны receipt, mempool, failure и finality.
  • Checksum или UI скрывают неправильный адрес.
  • У prefunded counterfactual funds нет доказанного владельца.
  • Неверны assumptions EIP-7702, replay, gas, DoS или monitoring.

Распространенные заблуждения

  • «Пустой адрес безопасен или кому-то принадлежит». У него может не быть code или проверенного controller.
  • «Адрес определяет только salt». Deployer и init-code hash столь же обязательны.
  • «CREATE2 хеширует runtime bytecode». Хешируется creation code, включая constructor arguments.
  • «Один адрес в двух сетях означает одинаковые code и control». Состояние и deployment каждой chain нужно проверять отдельно.
  • «Успешное предсказание доказывает deployment и безопасность». Наличие устанавливают только receipt, code, state, permissions и finality.

Связанные темы

Источники

Навигация

Поиск по вики...