Factory-контракти з CREATE2: детерміністичний деплой
Ми часто стикаємося із завданням детерміністичного деплою смарт-контрактів. CREATE2 — опкод EVM (EIP-1014), введений у Constantinople hard fork. Адреса контракту, що деплоїться, обчислюється заздалегідь: вона детермінована від deployer address, salt та keccak256(initcode). Зміниш будь-який параметр — отримаєш іншу адресу. Це радикально змінює підхід до архітектури протоколів. Наш досвід показує, що правильна реалізація factory з CREATE2 скорочує час розгортання та виключає помилки при адресації контрактів. Ми гарантуємо безпечне розгортання із захистом від фронтрану.
Чому CREATE2 важливий для детерміністичного деплою?
Counterfactual deployment. Користувач може отримати адресу свого Smart Account до деплою. Передає цю адресу для отримання коштів — а сам контракт деплоїться лише при першій транзакції (разом з нею ж). EIP-4337 account abstraction повністю побудований на цьому патерні: initCode в UserOperation містить виклик factory, який через CREATE2 деплоїть Account контракт на заздалегідь відому адресу.
Uniswap V2/V3 pair addresses. Адреса будь-якого пулу Uniswap V2 обчислюється off-chain через CREATE2 формулу: keccak256(abi.encodePacked(hex'ff', factory, keccak256(abi.encodePacked(token0, token1)), INIT_CODE_PAIR_HASH)). Router не зберігає маппінг пар — він обчислює адресу на льоту. Це економить тисячі операцій SLOAD.
Cross-chain консистентність. Протокол деплоїть контракти на 8 чейнах за однією і тією ж адресою. Користувачі та інтегратори знають адресу заздалегідь, whitelist налаштовується один раз. Досягається через Arachnid's Deterministic Deployment Proxy (0x4e59b44847b379578588920cA78FbF26c0B4956C) — він же Nick's factory, задеплоєний на сотнях чейнів з однаковою адресою.
CREATE vs CREATE2: порівняльна таблиця
| Характеристика | CREATE | CREATE2 |
|---|---|---|
| Обчислення адреси | від nonce деплоєра | від salt + initcode + deployer address |
| Передбачуваність | ні (nonce змінюється) | так (детермінований) |
| Counterfactual deployment | неможливий | повністю підтримується |
| Захист від фронтрану | вбудований (nonce) | потребує salt з msg.sender |
| Газ для деплою | ~60K gas | ~40-50K gas (менше) |
| Повторний деплой на ту ж адресу | можливий після selfdestruct (до Cancun) | тільки після selfdestruct (до Cancun) |
Як захистити salt від фронтрану?
Salt — це bytes32. Необережний salt відкриває фронтран: хтось бачить у mempool вашу транзакцію деплою, бере той же bytecode та salt, деплоїть першим на бажану адресу. Ваша транзакція впаде.
Захист: включати msg.sender у salt:
bytes32 salt = keccak256(abi.encodePacked(msg.sender, userProvidedSalt));
Тепер adversary з іншим msg.sender отримає іншу адресу — ваша адреса йому недоступна.
Для протоколів, де адреса має бути однаковою на всіх чейнах незалежно від деплоєра, використовуємо фіксований salt без msg.sender — але тоді деплой йде через довірений deployer (multisig або deployment script з DEPLOY_KEY).
Реалізація Factory з CREATE2
contract ContractFactory {
event Deployed(address indexed contractAddress, bytes32 indexed salt);
function deploy(bytes memory bytecode, bytes32 salt)
external returns (address contractAddress) {
assembly {
contractAddress := create2(
0, // value (ETH)
add(bytecode, 0x20), // bytecode start (skip length prefix)
mload(bytecode), // bytecode length
salt // salt
)
}
require(contractAddress != address(0), "Deploy failed");
emit Deployed(contractAddress, salt);
}
function computeAddress(bytes memory bytecode, bytes32 salt)
external view returns (address) {
bytes32 hash = keccak256(abi.encodePacked(
bytes1(0xff),
address(this),
salt,
keccak256(bytecode)
));
return address(uint160(uint256(hash)));
}
}
Ініціалізація через constructor vs initializer
При CREATE2 деплої контракт з constructor-параметрами включає параметри в initcode — тоді однакові параметри дадуть одну адресу, різні — різні. Це нормально.
Якщо контракт використовує proxy патерн (деплоїться minimal proxy через CREATE2, а реалізація — окремо), constructor не запускається. Ініціалізація через initialize() функцію обов'язкова, і вона має бути захищена від подвійного виклику (initializer modifier від OpenZeppelin або ручний флаг).
Тонкість: CREATE2 з одним salt можна виконати лише один раз — якщо контракт за цією адресою вже існує, деплой поверне address(0). Якщо контракт був selfdestruct-нут (до Cancun EIP-6780), адреса звільняється і CREATE2 з тим самим salt можна повторити. Після Cancun EIP-6780 selfdestruct прибирає лише ETH, код залишається — адреса не перевикористовується.
Мінімальний проксі (EIP-1167) + CREATE2
Комбінація часто використовується в протоколах з тисячами інстансів (lending positions, yield vaults, game characters). Minimal proxy — 45-байтовий контракт, який делегує всі виклики до implementation. Деплой коштує ~40K gas замість 200K-500K для повного контракту.
function deployProxy(address implementation, bytes32 salt)
external returns (address proxy) {
bytes memory bytecode = abi.encodePacked(
hex"3d602d80600a3d3981f3363d3d373d3d3d363d73",
implementation,
hex"5af43d82803e903d91602b57fd5bf3"
);
assembly {
proxy := create2(0, add(bytecode, 0x20), mload(bytecode), salt)
}
require(proxy != address(0), "Deploy failed");
IInitializable(proxy).initialize(/* params */);
}
OpenZeppelin надає Clones.cloneDeterministic(implementation, salt) — готовий wrapper над цим патерном.
Тестування
Foundry спрощує тестування CREATE2: vm.computeCreate2Address(salt, keccak256(bytecode), deployer) дає передбачувану адресу в тесті. Перевіряємо:
- Задеплоєна адреса збігається з обчисленою
computeAddress() - Повторний деплой з тим самим salt повертає address(0)
- Ініціалізація через
initialize()не викликається двічі - Frontrunning salt захищений (якщо потрібно)
Що входить в роботу
- Документація архітектури factory
- Реалізація factory з CREATE2 (з захистом salt)
- Інтеграція minimal proxy при необхідності
- Набір тестів (Foundry) з покриттям граничних випадків
- Скрипти деплою для одного або декількох чейнів
- Верифікація контрактів в Etherscan (або аналогах)
- Підтримка після деплою протягом 2 тижнів
Ми розробляємо factory-контракти під ключ — від проектування до деплою. Оцінюємо проєкт безкоштовно, зв'яжіться з нами. Понад 5 років досвіду в Solidity та 30+ успішних проєктів — гарантуємо безпеку та надійність вашого коду.
Строки
Базовий factory з CREATE2 та обчисленням адрес: 2-3 дні. Factory з minimal proxy патерном та ініціалізацією: 3-4 дні. Мультичейн deployment infrastructure з Arachnid proxy: 4-5 днів, включаючи скрипти деплою та верифікацію.
Вартість розраховується після уточнення вимог до інфраструктури деплою та кількості цільових чейнів.