Разработка системы flash accounting (Uniswap v4)
Uniswap v4 изменил фундаментальную архитектуру расчётов: вместо немедленного transfer токенов при каждой операции — накопление «долгов» и «кредитов» в рамках одного lock-сессии. Это flash accounting. Система открывает возможности, которых не существовало в v3: многошаговые операции через несколько пулов без промежуточных ETH-выходов, встроенный flash loan без отдельного протокола, компоновка любых DeFi-действий в одну транзакцию. Но реализовать это корректно — значит понять, как PoolManager управляет currency deltas и почему неправильный порядок settle/take приводит к revert вместо прибыли.
Как работает 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 не обнулится.
Мультипул flash accounting: где реальная ценность
Допустим, нужно провести арбитраж: купить 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% в зависимости от количества шагов.
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.
Уязвимости, специфичные для v4 hooks
Reentrancy через hook callback. Hook вызывается из PoolManager в середине lock-сессии. Если hook делает внешний вызов в контракт, который тоже пытается взаимодействовать с PoolManager — это nested lock. PoolManager v4 поддерживает nested locks, но неаккуратная логика в hook приводит к corrupted delta state.
Delta manipulation. Злонамеренный hook в beforeSwap может изменить amountSpecified через возвращаемый BeforeSwapDelta — это легитимная возможность, но если проверка на входные параметры слабая, hook превращается в вектор ценовой манипуляции в пуле.
Наш стек для разработки на 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 недели. Стоимость рассчитывается после анализа графа операций.