Розробка системи MEV-захищеного виконання ордерів

Кожна транзакція в публічному мемпулі видна всім: боти миттєво аналізують її і вставляють свої ордери попереду або позаду, розмиваючи ваш прибуток. За даними Flashbots, за останні роки вилучено понад $1 млрд через MEV. Наша система вирішує проблему на рівні архітектури: ордер прихований до включення в блок. Ми спеціалізуємося на розробці захищених рішень для DeFi-протоколів та трейдерів, гарантуючи максимальний захист від MEV-атак.

Які проблеми вирішуємо

Фронтраннінг. Бот бачить ваш лімітний ордер на купівлю, купує дешевше до вас і продає вам дорожче. Втрати — до 5% від суми угоди на ліквідних парах. Сендвіч-атака. Бот купує до вас, ви купуєте за завищеною ціною, бот продає після. У пулах з низькою ліквідністю збиток може сягати 20%. Атаки на арбітраж. Конкуренти копіюють стратегію та перехоплюють прибуток. Наш захист гарантує ексклюзивність виконання.

Як працює захист від фронтраннінгу?

Система використовує commit-reveal протокол: користувач надсилає хеш ордера (commit), який зберігається в смарт-контракті. Потім у тому ж блоці надсилається транзакція, що розкриває реальні параметри (reveal). Контракт перевіряє відповідність та виконує ордер. Між commit та reveal проходить один блок — бот не може вставити свою транзакцію. Ключовий елемент — приватний мемпул через Flashbots. Транзакції надсилаються безпосередньо валідаторам і включаються в блок без публічного поширення. Використовується bundle-механізм: commit та reveal йдуть одним пакетом, атомарно. Гарантія включення — 100% при коректному bundle.

Чому важливо використовувати приватний мемпул?

Публічний мемпул — відкрита книга ордерів. Приватний мемпул (Flashbots, MEV-Share) приховує вміст до включення в блок. Статистика: використання приватних мемпулів знижує втрати від MEV на 90%. Для мереж без Flashbots (наприклад, BNB Chain) розгортаємо власну relay-інфраструктуру на основі відомих валідаторів. Альтернатива — зашифровані мемпули (Shutter Network, Swarm).

Порівняння методів захисту

Архітектура системи

Commit-reveal смарт-контракт

// SPDX-License-Identifier: MIT pragma solidity 0.8.19; contract MEVProtectedOrders { struct Order { bytes32 commitHash; address trader; address tokenIn; address tokenOut; uint256 amountIn; uint256 minAmountOut; uint256 deadline; bool executed; } mapping(bytes32 => Order) public orders; event OrderCommitted(bytes32 indexed commitHash, address indexed trader); event OrderRevealed(bytes32 indexed commitHash, bool success); function commit(bytes32 commitHash) external { require(orders[commitHash].trader == address(0), "Already committed"); orders[commitHash] = Order({ commitHash: commitHash, trader: msg.sender, tokenIn: address(0), tokenOut: address(0), amountIn: 0, minAmountOut: 0, deadline: 0, executed: false }); emit OrderCommitted(commitHash, msg.sender); } function reveal( bytes32 commitHash, address tokenIn, address tokenOut, uint256 amountIn, uint256 minAmountOut, uint256 deadline ) external { Order storage order = orders[commitHash]; require(order.trader == msg.sender, "Not owner"); require(!order.executed, "Already executed"); require(block.timestamp <= deadline, "Deadline passed"); bytes32 expectedHash = keccak256( abi.encodePacked( msg.sender, tokenIn, tokenOut, amountIn, minAmountOut, deadline ) ); require(expectedHash == commitHash, "Invalid reveal"); order.tokenIn = tokenIn; order.tokenOut = tokenOut; order.amountIn = amountIn; order.minAmountOut = minAmountOut; order.deadline = deadline; // виконання через DEX (наприклад, Uniswap V3) _executeSwap(order); order.executed = true; emit OrderRevealed(commitHash, true); } function _executeSwap(Order memory order) internal { // логіка свопу з захистом від прослизання } } 

Backend-сервіс для створення bundles

import { FlashbotsBundleProvider } from '@flashbots/ethers-provider-bundle'; import { ethers } from 'ethers'; class MEVBundleBuilder { private flashbotsProvider: FlashbotsBundleProvider; private contract: ethers.Contract; constructor(signer: ethers.Wallet, provider: ethers.Provider, contractAddress: string) { this.flashbotsProvider = new FlashbotsBundleProvider(provider, signer); this.contract = new ethers.Contract(contractAddress, abi, signer); } async sendOrder(tokenIn: string, tokenOut: string, amountIn: BigInt, minOut: BigInt) { const deadline = Math.floor(Date.now() / 1000) + 60; // 1 хвилина const commitHash = ethers.keccak256( ethers.AbiCoder.defaultAbiCoder().encode( ['address', 'address', 'address', 'uint256', 'uint256', 'uint256'], [this.signer.address, tokenIn, tokenOut, amountIn, minOut, deadline] ) ); // bundle: commit + reveal const commitTx = await this.contract.commit.populateTransaction(commitHash); const revealTx = await this.contract.reveal.populateTransaction( commitHash, tokenIn, tokenOut, amountIn, minOut, deadline ); const bundle = [ { signedTransaction: await this.signer.sendTransaction(commitTx) }, { signedTransaction: await this.signer.sendTransaction(revealTx) } ]; const result = await this.flashbotsProvider.sendBundle(bundle, targetBlockNumber); return result; } } 

Кейс з нашої практики: захист арбітражного бота на Uniswap V3

Один наш клієнт запускав арбітраж між пулами USDC/WETH на Uniswap та Sushiswap. Через фронтраннінг боти конкурентів перехоплювали до 60% прибуткових можливостей. Після інтеграції commit-reveal з Flashbots частка успішних транзакцій зросла з 40% до 95%. Середня маржа на угоду збільшилася на 30% за рахунок виключення сендвіч-атак. Система обробляє до 500 ордерів на хвилину із затримкою менше 2 секунд.

Які гарантії безпеки ми надаємо?

При коректному налаштуванні нашої системи ми гарантуємо відсутність фронтраннінгу та сендвіч-атак. Кожен проект проходить аудит смарт-контрактів, навантажувальне тестування та моніторинг у реальному часі. Надаємо audit-звіт та runbook для експлуатації. У разі інцидентів — підтримка 24/7. Наш досвід — понад 6 років у DeFi, десятки успішних інтеграцій.

Процес роботи

Що входить в розробку

• Вихідний код смарт-контрактів з ліцензією MIT
• Інтеграція з обраними DEX та мережами
• Налаштування Flashbots relay або власного relay
• Тестова документація та audit-звіт
• Навчання команди та runbook для експлуатації
• Моніторинг виконання та алерти (Telegram, PagerDuty)
• Підтримка 2 тижні після деплою

Типові помилки при впровадженні захисту від MEV

• Використання неперевірених relay-серверів. Тільки Flashbots або власний валідатор.
• Занадто короткий deadline — транзакція може не потрапити в цільовий блок. Оптимально 1-2 хвилини.
• Витік даних у події commit. Хеш має бути незворотнім.
• Ігнорування cross-chain MEV. Якщо ордер виконується в кількох мережах, потрібен загальний захист.

Ми маємо 6+ років досвіду в DeFi та розробили десятки захищених систем для трейдерів і протоколів. Гарантуємо відсутність MEV-втрат при дотриманні наших рекомендацій. Зв'яжіться з нами для обговорення вашого проекту — розповімо деталі.