Розробка скриптів деплою смарт-контрактів під ключ

Разовий деплой через `forge create` або `npx hardhat deploy` з хардкодованими параметрами — це технічний борг. Коли потрібно задеплоїти на 5 чейнів, потім відтворити на тестнеті для аудиторів, а потім повторити через 3 місяці для нової версії — з'ясовується, що ніхто не пам'ятає точний порядок викли

Напрямки блокчейн-розробки

Часті запитання

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1453
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1312
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1010
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1272
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    722
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    1015

Разовий деплой через forge create або npx hardhat deploy з хардкодованими параметрами — це технічний борг. Коли потрібно задеплоїти на 5 чейнів, потім відтворити на тестнеті для аудиторів, а потім повторити через 3 місяці для нової версії — з'ясовується, що ніхто не пам'ятає точний порядок викликів, які контракти потрібно ініціалізувати після деплою і на якому блоці була верифікація. Нещодавно до нас звернулася команда протоколу, у якої після звільнення розробника ніхто не міг повторити деплой на мейннет. Ми написали скрипт за день, і тепер деплой займає 5 хвилин. Ми спеціалізуємося на створенні професійних скриптів деплою під ключ: від параметризації до інтеграції з CI/CD. Наш досвід — 5+ років у Web3, понад 50 успішних проектів. Зв'яжіться з нами для консультації або отримайте індивідуальну оцінку вашого проекту.

Які проблеми вирішують скрипти деплою?

Ручний деплой через forge create або Hardhat консоль призводить до кількох типових проблем:

  • Відсутність відтворюваності: повторити точний порядок викликів через місяць — лотерея.
  • Помилки ініціалізації: забули викликати initialize() після проксі — контракт непрацездатний.
  • Втрата адрес: ніхто не записав, де лежить proxy або admin.
  • Довге перемикання мереж: при деплої на 5 мереж вручну — втрата часу на 80%.

Скрипти вирішують ці проблеми: один запуск, повний лог, автоматична верифікація.

Чому Forge Script — стандарт індустрії?

Foundry Script (.s.sol) — Solidity-файл, який виконується як деплой-скрипт. Ключова перевага: одна мова для контрактів і деплою, перевірка типів компілятором, можливість тестувати сам скрипт. У документації Foundry підкреслюється, що це значно знижує кількість помилок порівняно з JS-скриптами.

// SPDX-License-Identifier: MIT pragma solidity ^0.8.24; import {Script, console} from "forge-std/Script.sol"; import {MyProtocol} from "../src/MyProtocol.sol"; import {ProxyAdmin} from "@openzeppelin/contracts/proxy/transparent/ProxyAdmin.sol"; contract DeployMyProtocol is Script { function run() external { uint256 deployerKey = vm.envUint("PRIVATE_KEY"); address deployer = vm.addr(deployerKey); vm.startBroadcast(deployerKey); ProxyAdmin admin = new ProxyAdmin(deployer); MyProtocol implementation = new MyProtocol(); bytes memory initData = abi.encodeCall( MyProtocol.initialize, (vm.envAddress("TREASURY"), vm.envUint("FEE_BPS")) ); TransparentUpgradeableProxy proxy = new TransparentUpgradeableProxy( address(implementation), address(admin), initData ); console.log("ProxyAdmin:", address(admin)); console.log("Implementation:", address(implementation)); console.log("Proxy:", address(proxy)); vm.stopBroadcast(); } } 

Запуск: forge script script/DeployMyProtocol.s.sol --rpc-url $RPC --broadcast --verify. Флаг --verify автоматично верифікує всі задеплоєні контракти через Etherscan API. --slow додає затримку між транзакціями — потрібно для RPC-провайдерів з rate limits.

Як параметризація виключає помилки?

Жодного хардкоду адрес у скрипті. Все через environment variables:

address treasury = vm.envAddress("TREASURY"); uint256 fee = vm.envUint("FEE_BPS"); bool isMainnet = vm.envBool("IS_MAINNET"); 

Для різних оточень: файли .env.sepolia, .env.mainnet, .env.polygon. Скрипт деплою один і той самий. Це економить до 40% часу на підготовку деплою.

Логування адрес задеплоєних контрактів

Після деплою адреси потрібно зафіксувати. Підходи:

JSON файл через foundry's --json флаг. forge script ... --json > deployments/sepolia.json — структурований вивід з адресами, transaction hashes, block numbers.

Кастомне логування у скрипті через vm.writeJson() і vm.writeFile():

string memory json = vm.serializeAddress("deployment", "proxy", address(proxy)); vm.writeJson(json, string.concat("deployments/", vm.toString(block.chainid), ".json")); 

Файли деплою комітимо в репозиторій — вони служать джерелом істини для frontend, аналітики та майбутніх upgrade-скриптів.

Upgrade скрипти та мультичейн деплой

Для UUPS і Transparent Proxy паттернів окремий скрипт для кожного upgrade:

contract UpgradeV2 is Script { function run() external { address proxy = vm.envAddress("PROXY_ADDRESS"); address admin = vm.envAddress("PROXY_ADMIN"); vm.startBroadcast(vm.envUint("PRIVATE_KEY")); MyProtocolV2 newImpl = new MyProtocolV2(); ProxyAdmin(admin).upgradeAndCall( ITransparentUpgradeableProxy(proxy), address(newImpl), "" ); vm.stopBroadcast(); } } 

Кожен upgrade-скрипт має ім'я з версією (UpgradeToV2.s.sol) і зберігається в історії репозиторію. Мультичейн деплой: скрипт запускається послідовно для кожного чейна:

forge script script/Deploy.s.sol --rpc-url $ETHEREUM_RPC --broadcast --verify forge script script/Deploy.s.sol --rpc-url $POLYGON_RPC --broadcast --verify --verifier-url $POLYGONSCAN_API forge script script/Deploy.s.sol --rpc-url $ARBITRUM_RPC --broadcast --verify 

Або через Makefile / shell скрипт з ітерацією по масиву RPC endpoints. Наші скрипти скорочують час деплою на 80% порівняно з ручним підходом.

Що входить у нашу роботу?

  • Розробка базового деплой-скрипта з параметризацією (env).
  • Налаштування автоматичної верифікації через Etherscan API.
  • Логування всіх адрес і артефактів у JSON.
  • Створення upgrade-скриптів для UUPS/Transparent Proxy.
  • Підтримка мультичейн (Ethereum, Polygon, Arbitrum, BNB Chain та ін.).
  • Інтеграція з CI/CD (GitHub Actions, GitLab CI).
  • Документація та навчання вашої команди.
  • Гарантія коректності деплою на тестнеті перед мейннетом.

Терміни та вартість

Написання базового деплой-скрипта з параметризацією та логуванням — 1 день. Повна deployment infrastructure з upgrade скриптами, мультичейн підтримкою та CI інтеграцією — 2-3 дні. Вартість розраховується індивідуально після аналізу вашого проекту. Клієнти економлять до 70% часу на деплої, що в перерахунку на зарплату інженера дає десятки тисяч доларів економії на рік. Оцінимо ваш проект безкоштовно — зв'яжіться з нами.

Порівняння: ручний деплой vs скрипти

Критерій Ручний деплой Скрипти деплою (наші)
Час на 1 чейн 30-60 хв 2-5 хв
Верифікація вручну через Etherscan автоматично
Відтворюваність низька 100%
Помилки ініціалізації часті виключені тестами
Мультичейн дні 1 година

Як ми гарантуємо коректність?

Ми пишемо тести на деплой-скрипти (наприклад, через Foundry), використовуємо симуляцію транзакцій в Tenderly, перевіряємо лог і проводимо code review. Після деплою контракти верифікуються автоматично. Отримайте консультацію інженера — обговоріть ваш проект і ми запропонуємо рішення.