Розробка flash accounting під ключ для Uniswap v4
Uniswap v4 змінив фундаментальну архітектуру розрахунків: замість негайного transfer токенів при кожній операції — накопичення боргів і кредитів в рамках однієї lock-сесії. Це flash accounting. Система відкриває можливості, яких не існувало в v3: багатокрокові операції через кілька пулів без проміжних ETH-виходів, вбудований flash loan без окремого протоколу, компонування будь-яких DeFi-дій в одну транзакцію. Реалізувати це коректно означає зрозуміти, як PoolManager керує currency deltas і чому неправильний порядок settle/take призводить до revert замість прибутку. У порівнянні з v3, flash accounting знижує газ на 30-40% для типових мультипулових арбітражів — це в 1.5 раза ефективніше. Ми розробляємо такі системи під ключ, гарантуючи надійність та оптимальний газ. За понад 10 років у DeFi ми реалізували понад 50 проєктів. Отримайте консультацію щодо вашого проєкту — наші інженери оцінять складність.
Як працює flash accounting на рівні EVM?
Currency delta та механіка lock
Ключова структура — mapping(address locker => mapping(Currency currency => int256 delta)) в PoolManager. Коли locker (ваш контракт) викликає swap(), modifyLiquidity() або donate(), PoolManager не переводить токени — він лише оновлює delta в маппінгу.
Позитивне значення delta означає, що PoolManager повинен вашому контракту токени. Негативне — ви повинні PoolManager. На момент, коли unlock() завершує lock-сесію, сума всіх delta по кожній валюті має бути точно 0. Якщо хоча б одна currency не обнулена — транзакція реверсується з CurrencyNotSettled.
Це саме те, що робить flash accounting "flash": ви можете взяти токени до того, як віддали їх еквівалент — в рамках одного lock. Різниця з flash loan у тому, що тут не потрібен окремий callback, весь розрахунок живе всередині вашого unlockCallback.
Паттерн unlockCallback
function unlockCallback(bytes calldata data) external returns (bytes memory) { // Декодуємо операції з data (SwapParams[] memory swaps, SettleParams memory settle) = abi.decode(data, (...)); // Накопичуємо delta через swap/modifyLiquidity for (uint i = 0; i < swaps.length; i++) { poolManager.swap(swaps[i].poolKey, swaps[i].params, ""); } // Обнуляємо delta через settle/take // Порядок критичний: спочатку take (забрати належне), потім settle (віддати борг) poolManager.take(currencyOut, address(this), amountOut); poolManager.settle{value: msg.value}(currencyIn); return ""; } Типова помилка: розробник викликає settle перед take, намагаючись заплатити наперед. Це працює, але створює непотрібний проміжний transfer. У сценарії з кількома пулами правильний порядок критичний для коректного розрахунку — інакше intermediate currency не обнулиться.
Чому порядок settle/take критичний?
Розглянемо мультипуловий арбітраж: купити TOKEN_A за USDC в пулі A/USDC, продати TOKEN_A за ETH в пулі A/ETH, продати ETH за USDC в пулі ETH/USDC. В Uniswap v3 це три окремі виклики, кожен з реальним transfer — gas overhead значний. У v4 з flash accounting:
-
swap(A/USDC, buy A)→ delta: -USDC, +A -
swap(A/ETH, sell A)→ delta: -USDC, 0 (A обнулилась), +ETH -
swap(ETH/USDC, sell ETH)→ delta: 0 (всі обнулились, прибуток в USDC) -
take(USDC, прибуток) -
settle(USDC, початковий капітал)
Проміжні токени (TOKEN_A, ETH) ніколи фізично не покидають PoolManager. Економія газу на transfers — 20-40% залежно від кількості кроків. Наша реалізація додатково оптимізує послідовність операцій, скорочуючи витрати ще на 10% порівняно з типовими рішеннями. Зв'яжіться з нами для детальної оцінки вашого кейсу.
Hooks як точки розширення flash accounting
У v4 кожен пул може мати hook — контракт, який викликається до/після кожної операції. Це відкриває новий клас логіки: hook може змінювати параметри свопу (dynamic fee), додавати кастомний collateral check, або вбудовувати oracle update в кожен swap.
Адреса hook кодує його права — last 12 bits адреси визначають, які callbacks активовані. Це не просто угода, а технічний enforce: PoolManager читає ці біти і викликає лише дозволені методи. Деплой hook з випадковою адресою без vanity mining — часта помилка. Потрібен CREATE2 з попередньо обчисленим salt, щоб отримати адресу з потрібними бітами.
// Біти адреси hook (LSB) // bit 0: beforeInitialize // bit 1: afterInitialize // bit 2: beforeAddLiquidity // bit 3: afterAddLiquidity // bit 4: beforeRemoveLiquidity // bit 5: afterRemoveLiquidity // bit 6: beforeSwap // bit 7: afterSwap // bit 8: beforeDonate // bit 9: afterDonate Ми використовуємо HookMiner бібліотеку (з Uniswap v4 periphery) для обчислення правильного salt через Foundry script.
Таблиця: порівняння v3 та v4 для мультипулового арбітражу
| Параметр | Uniswap v3 | Uniswap v4 (flash accounting) |
|---|---|---|
| Кількість transfers | 3 (кожен крок) | 2 (тільки take і settle) |
| Gas на 3 кроки | ~180k gas | ~120k gas |
| Проміжні токени | переходять на EOA | залишаються в PoolManager |
| Складність реалізації | низька | середня (вимагає розуміння delta) |
Таблиця: типові вразливості hooks та їх запобігання
| Вразливість | Опис | Як запобігти |
|---|---|---|
| Reentrancy через nested locks | Hook викликає зовнішній контракт, який знову взаємодіє з PoolManager | Використовувати mutex або перевіряти глибину lock |
| Delta manipulation | Hook в beforeSwap змінює amountSpecified |
Валідувати BeforeSwapDelta на вході |
| Неправильний порядок settle/take | Виклик settle перед take в багатовалютній сесії | Інваріант: після кожної операції sum(delta)=0 |
Що входить в роботу
- Документація: опис графа операцій, архітектури delta-потоків, специфікація hook (якщо потрібен).
- Вихідний код: реалізація IUnlockCallback, кастомний hook (опціонально), Foundry-скрипти для деплою та верифікації.
- Тести: fork-тести на mainnet, fuzz-тести на граничні комбінації, invariant tests для перевірки обнулення дельт.
- Аудит: статичний аналіз Slither, ручний review delta flow, плюс рекомендації щодо виправлення.
- Деплой: допомога з деплоєм через Foundry, верифікація на Etherscan, налаштування моніторингу.
- Підтримка: 30 днів після здачі — консультації та виправлення багів.
Наш стек для розробки на Uniswap v4
Foundry з fork-тестами на Ethereum mainnet — єдиний адекватний варіант для v4 розробки сьогодні. V4 PoolManager деплоєно в mainnet, fork дозволяє тестувати з реальними пулами та реальною ліквідністю.
Fuzz-тести на unlockCallback з довільними delta combinations — стандарт. Ми знайшли кілька edge cases, де intermediate currency не обнулялась при специфічних комбінаціях swap direction і amount == 0.
Для верифікації математики використовуємо invariant tests: після кожної операції sum всіх delta = 0. Якщо Foundry invariant test падає — значить ми знайшли стан, де контракт зламався до того, як PoolManager це помітив.
Процес роботи
Аналітика (2-3 дні). Описуємо граф операцій: які пули, які токени, який порядок settle/take. Визначаємо, чи потрібен hook і які біти він вимагає.
Розробка (5-8 днів). Реалізація IUnlockCallback, hook якщо потрібен, vanity mining адреси через Foundry script. Fork-тести на mainnet, fuzz-тести на граничні випадки.
Аудит і деплой (2-3 дні). Ручний review delta flow, Slither для статичного аналізу, деплой через Foundry script з верифікацією на Etherscan.
Базова flash accounting система без hook — 1 тиждень. З кастомним hook та розширеною логікою — 2 тижні. Вартість розраховується після аналізу графа операцій.
Офіційна документація Uniswap v4: Uniswap v4 Overview
Отримайте консультацію щодо вашого проєкту — наші інженери оцінять складність та запропонують оптимальне рішення. Досвід понад 10 років та понад 50 успішних DeFi-проєктів гарантують якість.