---
title: "Как проверить адрес контракта CREATE2"
description: "CREATE2 предсказывает адрес по развертывателю, соли и хешу init-кода, но проверка требует доказательств по сети, фабрике, bytecode, развертыванию, proxy и владельцу."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Как проверить адрес контракта CREATE2
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
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.
## Связанные темы
- [Proxy-контракт](/ru/crypto/proxy-contract/)
- [Смарт-контракт](/ru/crypto/smart-contract/)
- [Проверка token-контракта](/ru/crypto/token-contract-verification/)
## Источники
- [EIP-1014: Skinny CREATE2](https://eips.ethereum.org/EIPS/eip-1014) - Ethereum Improvement Proposals (дата обращения: 2026-08-13)
- [EIP-684: Revert creation in case of collision](https://eips.ethereum.org/EIPS/eip-684) - Ethereum Improvement Proposals (дата обращения: 2026-08-13)
- [Salted contract creations / CREATE2](https://docs.soliditylang.org/en/latest/control-structures.html#salted-contract-creations-create2) - Solidity (дата обращения: 2026-08-13)
- [ERC-1167: Minimal Proxy Contract](https://eips.ethereum.org/EIPS/eip-1167) - Ethereum Improvement Proposals (дата обращения: 2026-08-13)
- [ERC-2470: Singleton Factory](https://eips.ethereum.org/EIPS/eip-2470) - Ethereum Improvement Proposals (дата обращения: 2026-08-13)
- [Create2](https://docs.openzeppelin.com/contracts/5.x/api/utils#Create2) - OpenZeppelin (дата обращения: 2026-08-13)
- [EIP-155: Simple replay attack protection](https://eips.ethereum.org/EIPS/eip-155) - Ethereum Improvement Proposals (дата обращения: 2026-08-13)
- [Contract Metadata](https://docs.soliditylang.org/en/latest/metadata.html) - Solidity (дата обращения: 2026-08-13)
Source: https://wiki.fcontext.com/ru/crypto/create2-address-verification/index.mdx