Разработка 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-проектов гарантируют качество.