Розробка системи flash accounting (Uniswap v4)

Розробка системи 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. Коли ваш контракт викликає 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. У сценарії з кількома пулами правильний порядок критичний для правильного розрахунку — інакше проміжна валюта не обнулиться.

Мультипул flash accounting: де реальна цінність

Допустимо, потрібно провести арбітраж: купити TOKEN_A за USDC в пулі A/USDC, продати TOKEN_A за ETH в пулі A/ETH, продати ETH за USDC в пулі ETH/USDC. У Uniswap v3 це три окремі виклики, кожен з реальним transfer — gas overhead значний. У v4 з flash accounting:

1. swap(A/USDC, buy A) → delta: -USDC, +A
2. swap(A/ETH, sell A) → delta: -USDC, 0 (A обнулилась), +ETH
3. swap(ETH/USDC, sell ETH) → delta: 0 (все обнулилось, прибуток в USDC)
4. take(USDC, прибуток)
5. settle(USDC, початковий капітал)

Проміжні токени (TOKEN_A, ETH) ніколи фізично не покидають PoolManager. Економія газу на transfers — 20-40% залежно від кількості кроків.

Hooks як точки розширення flash accounting

У v4 кожен пул може мати hook — контракт, викликаний до/після кожної операції. Це відкриває новий клас логіки: hook може змінювати параметри свапу (dynamic fee), додавати кастомну collateral перевірку, або вбудовувати oracle update в кожний swap.

Адреса hook кодує його права — останні 12 бітів адреси визначають, які callbacks активовані. Це не просто домовленість, а технічний enforce: PoolManager читає ці біти і викликає тільки дозволені методи. Деплой hook зі випадковою адресою без vanity mining — частої помилка. Потрібен CREATE2 з передбачуваним salt, щоб отримати адресу з потрібними бітами.

// Біти адреси hook (LSB)
// біт 0:  beforeInitialize
// біт 1:  afterInitialize
// біт 2:  beforeAddLiquidity
// біт 3:  afterAddLiquidity
// біт 4:  beforeRemoveLiquidity
// біт 5:  afterRemoveLiquidity
// біт 6:  beforeSwap
// біт 7:  afterSwap
// біт 8:  beforeDonate
// біт 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 комбінаціями — стандарт. Ми знайшли кілька edge cases, де проміжна валюта не обнуляється при специфічних комбінаціях 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 тижні. Вартість розраховується після аналізу графу операцій.