Налаштування MEV-захисту транзакцій

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1306 послуг
Налаштування MEV-захисту транзакцій
Середній
від 1 дня до 3 днів
Часті запитання

Напрямки блокчейн-розробки

Етапи блокчейн-розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1306
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1218
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    920
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1147
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    610
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    885

Розробка системи захисту від фронтраннингу

Фронтраннинг в блокчейні — використання публічності mempool для витягування прибутку за рахунок інших транзакцій. MEV (Maximal Extractable Value) — ширше поняття: уся вартість, яку можуть витягти валідатори/searcher-и включенням/виключенням/переупорядкуванням транзакцій в блоці. Sandwich атаки, арбітраж, liquidation MEV — всё це MEV. Користувачі щодня втрачають мільйони на sandwich атаках тільки на Ethereum.

Захист будується на кількох рівнях: transaction privacy, commit-reveal schemes, спеціалізовані RPC, on-chain slippage controls.

Як працює sandwich атака

Атакуючий моніторить mempool, бачить великий swap (наприклад, 50 ETH в USDC через Uniswap). Перед цією транзакцією вставляє свою — купити ETH (підняти ціну). Після жертви — продати ETH за піднятою ціною. Жертва отримує USDC за гіршою ціною, атакуючий витягує різницю.

Ключові умови: достатньо високий slippage tolerance у жертви (щоб транзакція не reverted), достатній розмір свопу для покриття газу атакуючого.

Блок N:
  tx[0]: Attacker купує ETH (frontrun) — газ вищий ніж у жертви
  tx[1]: Victim своп 50 ETH → USDC (за завищеною ціною)
  tx[2]: Attacker продає ETH (backrun) — газ нижчий ніж у жертви

Захист 1: Private RPC / MEV-blocker

Найпростіший та найефективніший для користувачів: відправляти транзакції через private mempool, мінуючи публічний mempool Ethereum.

Flashbots Protect RPC (https://rpc.flashbots.net) — безплатний endpoint. Транзакції йдуть напрямо у Flashbots bundle builders, мінуючи публічний mempool. Не підходять для швидких арбітражних транзакцій, але відмінно для звичайних користувацьких swap-ів.

MEV Blocker (https://rpc.mevblocker.io) — від CoW Protocol та команди Gnosis. Відправляє транзакції кільком builders одночасно, перший включивший отримує екскладний доступ до backrun (без frontrun). Backrun прибуток повертається користувачу як kickback.

Інтеграція в dApp: додати альтернативний RPC endpoint як опцію у wallet connection:

const mevProtectedProvider = new ethers.JsonRpcProvider(
  'https://rpc.mevblocker.io',
  { chainId: 1, name: 'mainnet' }
)

// Або через wagmi config
const config = createConfig({
  chains: [mainnet],
  transports: {
    [mainnet.id]: http('https://rpc.mevblocker.io'),
  },
})

Захист 2: Commit-Reveal схема

Для протоколів де важлива конфіденційність параметрів до виконання (аукціони, лотереї, деякі AMM). Двофазний процес:

Commit: користувач відправляє hash(action + secret) — приховане намірення. Reveal: після deadline всі учасники розкривають секрети, дії виконуються.

contract CommitRevealAuction {
    mapping(address => bytes32) public commitments;
    mapping(address => bool) public revealed;
    
    uint256 public commitDeadline;
    uint256 public revealDeadline;
    
    // Фаза 1: commit
    function commit(bytes32 commitment) external {
        require(block.timestamp < commitDeadline, "Commit phase over");
        commitments[msg.sender] = commitment;
    }
    
    // Фаза 2: reveal
    function reveal(uint256 bidAmount, bytes32 secret) external {
        require(block.timestamp >= commitDeadline, "Still in commit phase");
        require(block.timestamp < revealDeadline, "Reveal phase over");
        require(!revealed[msg.sender], "Already revealed");
        
        bytes32 expectedCommitment = keccak256(abi.encodePacked(bidAmount, secret, msg.sender));
        require(commitments[msg.sender] == expectedCommitment, "Invalid reveal");
        
        revealed[msg.sender] = true;
        _processBid(msg.sender, bidAmount);
    }
}

Уразливість commit-reveal: якщо reveal транзакції видні у mempool — атакуючий може frontrun останній reveal, бачачи успішні ставки інших. Захист: encrypted reveal через threshold encryption (SUAVE, Shutter Network).

Захист 3: On-chain slippage controls

Жорсткі on-chain обмеження slippage не захищають від sandwich (атака підстроюється під tolerance), але обмежують потенційний ущерб.

Uniswap v3 sqrtPriceLimitX96 — жорсткий лімітна ціну виконання. Якщо ціна виходить за лімітом — swap припиняється (partial fill), не повністю reverted. Краще ніж повний откат всієї транзакції при мінімальному slippage.

Для AMM з кастомною ціновою механікою — додати minAmountOut перевірку:

function swap(
    address tokenIn,
    address tokenOut,
    uint256 amountIn,
    uint256 minAmountOut  // slippage protection
) external returns (uint256 amountOut) {
    amountOut = _executeSwap(tokenIn, tokenOut, amountIn);
    require(amountOut >= minAmountOut, "Slippage exceeded");
    return amountOut;
}

minAmountOut повинен розраховуватися frontend з реальним slippage (зазвичай 0.1-1%). Рекомендувати користувачам максимальний slippage 0.5% — знижує ефективність sandwich атак.

Захист 4: TWAP для on-chain pricing

Протоколи, використовуючи AMM spot price для розрахунків (liquidation price, collateral valuation) — уразливі до flash loan маніпуляції. TWAP (time-weighted average price) з Uniswap v3 стійкий до one-block маніпуляції.

// Отримати TWAP за останніх 30 хвилин з Uniswap v3
function getTWAP(address pool, uint32 twapInterval) internal view returns (uint256 price) {
    uint32[] memory secondsAgos = new uint32[](2);
    secondsAgos[0] = twapInterval; // 1800 секунд = 30 хвилин
    secondsAgos[1] = 0;
    
    (int56[] memory tickCumulatives,) = IUniswapV3Pool(pool).observe(secondsAgos);
    
    int56 tickCumulativesDelta = tickCumulatives[1] - tickCumulatives[0];
    int24 timeWeightedAverageTick = int24(tickCumulativesDelta / int32(twapInterval));
    
    price = TickMath.getSqrtRatioAtTick(timeWeightedAverageTick);
    // Конвертувати sqrtPriceX96 в читаєму ціну
}

30-хвилинний TWAP означає, що атакуючому потрібно утримувати спотворену ціну 30 хвилин — дорого та економічно недоцільно.

Захист 5: EIP-3074 та EIP-7702 (майбутнє)

EIP-7702 (активний у Pectra upgrade 2025) дозволяє EOA тимчасово делегувати виконання контракту. Це відкриває шлях до transaction bundles на рівні гаманця — кілька транзакцій атомарно, що робить sandwich неможливим (неможливо вставити транзакцію всередину атомарного bundle).

Для нових протоколів, орієнтованих на Pectra-сумісні гаманці — це перспективна архітектура захисту.

Порівняння підходів

Метод Захист від sandwich Складність Вплив на UX
Private RPC Висока Мінімальна Мінімальний
Commit-Reveal Висока Висока Високий (2 tx)
Slippage controls Частіткова Низька Нема
TWAP oracle Flash loan захист Середня Нема
MEV Blocker Висока + rebate Мінімальна Мінімальний

Практична рекомендація: для dApp — інтегрувати MEV Blocker або Flashbots Protect RPC як default транспорт + жорсткі рекомендації по slippage (max 0.5% для стейблкоїнів, max 1% для волатильних активів). Це закриває 90% sandwich векторів без архітектурних змін.

Розробка кастомної системи захисту (commit-reveal для аукціону, TWAP інтеграція) — 2-4 тижні залежно від механіки.