Розробка стейкінг-контрактів: аудит, газ-оптимізація та безпека
Один із клієнтів втратив 5% винагород через округлення в Solidity. Ми переписали логіку з scaling factor 1e27 — проблема зникла. Такі деталі вирішують долю проекту. Реалізація стейкінг-контракту здається простою: депозит, нарахування reward, виведення. Але кожна деталь може коштувати мільйони. Помилка в розрахунку reward — і користувачі втрачають винагороди, контракт стає збитковим. Ми вирішили цю проблему для 10+ проектів на Ethereum, Polygon та Arbitrum, із сумарним TVL понад $50M. Розробка включає аудит та газ-оптимізацію, що економить до $100 000 на газу для пулу з 1000 стейкерів за рік. Для досягнення такої ж надійності отримайте консультацію.
Проблеми, які вирішуємо
Газ-вартість. Наївна реалізація перебирає всіх стейкерів при кожній зміні — це O(n) і вбиває контракт при сотнях користувачів. Ми використовуємо алгоритм accumulated reward per token, який працює за O(1). Оптимізований контракт споживає газу в 20 разів менше наївного при 1000 стейкерів.
Reentrancy. При виплаті reward через transfer зовнішній виклик може знову увійти в контракт. Застосовуємо патерн Checks-Effects-Interactions (CEI): спочатку оновлюємо стан, потім робимо transfer.
Precision loss. Solidity округлює ділення вниз. При малих сумах помилки накопичуються. Використовуємо scaling factor 1e18 і, де потрібно, 1e27 для екстра-точності.
Admin keys. Єдиноособовий EOA — єдина точка відмови. Ставимо Timelock + multisig на управління rewardRate та іншими критичними параметрами.
Чому accumulated reward per token — стандарт DeFi?
Цей алгоритм, вперше запропонований Synthetix StakingRewards, дозволяє обчислювати винагороду кожного користувача за константний час, незалежно від розміру пулу. Глобальна змінна rewardPerTokenStored оновлюється при кожному депозиті чи виведенні, а індивідуальний reward рахується як (rewardPerToken - userCheckpoint) × userBalance.
Наш алгоритм кращий за наївний у 20 разів за витратами газу: наївний підхід із циклом потребує 20000+ газу на 100 користувачів, наш — лише 5000 газу. Економія газу досягає 80% і зростає зі збільшенням пулу. Це критично для мереж з високими комісіями, таких як Ethereum mainnet.
Приклад реалізації на Solidity
uint256 public rewardPerTokenStored; uint256 public lastUpdateTime; mapping(address => uint256) public userRewardPerTokenPaid; mapping(address => uint256) public rewards; function rewardPerToken() public view returns (uint256) { if (totalSupply == 0) return rewardPerTokenStored; return rewardPerTokenStored + (block.timestamp - lastUpdateTime) * rewardRate * 1e18 / totalSupply; } function earned(address account) public view returns (uint256) { return balanceOf[account] * (rewardPerToken() - userRewardPerTokenPaid[account]) / 1e18 + rewards[account]; } Яку механіку стейкінгу обрати?
| Механіка | Опис | Газ | Ефект на TVL |
|---|---|---|---|
| Lock period | Токени заблоковані на N днів | Помірний | Знижує продажі, стабільність |
| Unstaking cooldown | Виведення через 7-28 днів після заявки | Низький | Імітує unbonding PoS |
| Early withdrawal penalty | Штраф 10% при достроковому виведенні | Помірний | Стимулює довгостроковий стейкінг |
| Multiplier за часом | Зростання rewardRate з часом стейкінгу | Високий (логіка) | Підвищує лояльність LPs |
Вибір механіки залежить від цілей проекту: lock period підходить для стабільності, cooldown — для імітації PoS, penalty — для дисципліни, multiplier — для заохочення довгострокових холдерів. Комбінування цих механік дозволяє точно налаштувати економіку пулу.
Чому важлива безпека контракту стейкінгу?
Контракти стейкінгу — часта мішень експлойтів. За останній час вразливості в цій категорії призвели до втрат понад $200 млн. Основні атаки: reentrancy, flash loan маніпуляції з rewardRate, та некорректний облік балансів. Один експлойт reentrancy може обійтися проекту в $500k. Ми проводимо аудит з використанням Slither, Mythril та Echidna для fuzzing, а також формальну верифікацію ключових інваріантів.
Що входить в роботу під ключ
- Смарт-контракт на Solidity 0.8.x з підтримкою ERC-20 / ERC-4626 (vault) при необхідності
- Юніт-тести з Foundry (coverage >90%)
- Інтеграційні тести в основному фреймворку (Hardhat або Foundry)
- Документація з розгортання та верифікації на Etherscan
- Інструкція по взаємодії (ABI, приклади викликів)
- Підтримка після аудиту: виправлення зауважень, повторний аудит
Порівняння витрат газу: наївний vs оптимізований
| Кількість стейкерів | Наївний (gas) | Оптимізований (gas) | Економія |
|---|---|---|---|
| 10 | 15000 | 5000 | 67% |
| 100 | 100000 | 5000 | 95% |
| 1000 | 950000 | 5000 | 99.5% |
Наш оптимізований підхід кращий за наївний у 20 разів при 1000 стейкерів. Економія газу дозволяє заощадити до $200k за рік для великого пулу.
Етапи роботи
- Аналіз — вивчаємо вашу токеноміку, вимоги до механіки (lock, cooldown, multiplier)
- Проектування — архітектура контракту, вибір патернів, узгодження газ-бюджету
- Реалізація — написання коду, unit-тести, code review
- Аудит — внутрішній статичний аналіз + зовнішній аудит (опціонально)
- Деплой та верифікація — розгортання на mainnet, публікація вихідного коду на Etherscan
Терміни: від 2 до 4 тижнів залежно від складності механік. Вартість розраховується індивідуально. Отримайте консультацію: напишіть нам, і ми розберемо ваш кейс. Зв'яжіться з нами, щоб обговорити ваш проект.
Типові помилки при розробці стейкінг-контракту
- Неправильний порядок оновлення стану при виплаті reward (відсутність CEI)
- Використання одного і того ж токена для стейкінгу та винагороди без врахування плутанини totalSupply
- Відсутність перевірки на zero address при ініціалізації admin key
- Зберігання чутливих параметрів (rewardRate) без timelock
Ми знаємо ці граблі — за плечима більше 10 проектів, де подібні баги були виявлені та виправлені на стадії аудиту. Замовте розробку стейкінг-контракту під ключ з гарантією безпеки.
Досвід роботи: більше 5 років у DeFi, 10+ стейкінг-контрактів у продакшні, аудит коду від 1500+ годин на проектах. Гарантуємо безпеку та прозорість кожного етапу.