Разработка системы защиты от сэндвич-атак в DeFi

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Разработка системы защиты от сэндвич-атак в DeFi
Средний
от 1 дня до 3 дней
Часто задаваемые вопросы

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

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

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1374
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1256
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    965
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1208
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    667
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    954

Разработка системы защиты от сэндвич-атак

Средний убыток пользователя от сэндвич-атаки составляет $100–200, а для крупных свопов может достигать $10 000. Внедрение защиты позволяет экономить до $20 000 в месяц на потерях от MEV. Мы — команда с 5-летним опытом в блокчейн-разработке, реализовали более 50 проектов по защите DeFi-протоколов. Свяжитесь с нами для бесплатной оценки вашего проекта.

Сэндвич-атака — форма MEV, при которой атакующий встраивается перед и после транзакции пользователя в публичном mempool. На Uniswap-подобных AMM это приводит к потере до 5% суммы свопа для обычного пользователя. Мы помогаем проектам устранить эту уязвимость на уровне смарт-контрактов и инфраструктуры. Если ваш проект страдает от MEV, получите консультацию эксперта уже сегодня.

Как работает сэндвич-атака и почему это проблема?

Для понимания защиты разберём механизм атаки. Публичный mempool позволяет MEV-ботам видеть все pending транзакции. Бот анализирует параметры свопа (адрес токена, сумму, slippage tolerance) и вычисляет, сколько нужно купить перед жертвой и продать после, чтобы получить прибыль. Чем выше допустимый slippage у пользователя, тем шире окно для атаки. По данным EigenPhi, крупные sandwich-боты на Ethereum зарабатывали сотни тысяч долларов в неделю за счёт обычных пользователей. Источник: EigenPhi. По данным Wikipedia, сэндвич-атаки составляют до 30% всех MEV-транзакций.

Уязвимость лежит в детерминированности price impact: для AMM с формулой x*y=k атакующий точно рассчитывает, какой объём фронтран-свапа даст максимальную прибыль. Слабые места — high slippage и публичность mempool.

Какие методы защиты мы применяем?

Мы используем три уровня защиты: на уровне транзакций, смарт-контрактов и архитектуры протокола. Ниже сравниваем основные подходы:

Метод Эффективность Сложность внедрения UX
Приватный RPC (Flashbots Protect) Снижает риск на 95% Низкая (1–2 нед.) Без изменений
Commit-reveal контракт Блокирует 99% атак Средняя (2–3 нед.) Два шага (тяжёлый UX)
Batch auction (CoW Protocol) Полностью устраняет Высокая (2–4 мес.) Без изменений
Динамический slippage Снижает на 50–70% Средняя (2–3 нед.) Автоматический

Commit-reveal схема в 2 раза эффективнее динамического slippage при защите от целенаправленных атак с высоким slippage.

Приватные RPC и MEV-protection провайдеры

Самая быстрая защита — отправлять транзакции не в публичный mempool, а напрямую блок-строителям. Flashbots Protect направляет транзакции в Flashbots bundle — атакующий их не видит. MEV Blocker от CoW Protocol конкурентно исполняет своп через нескольких searcher'ов и возвращает часть MEV пользователю. Bloxroute предлагает защищённые каналы за плату. Ниже сравнение провайдеров:

Провайдер Тип Стоимость Дополнительные функции
Flashbots Protect Приватный relay Бесплатно (газ) Поддержка bundle, совместимость с ethers.js
MEV Blocker (CoW) Аукцион searcher'ов 0% комиссии Возврат MEV пользователю
Bloxroute Защищённый канал Платный Низкая задержка, приватный поток
// Использование Flashbots Protect через ethers.js
const { FlashbotsBundleProvider } = require('@flashbots/ethers-provider-bundle');
const { ethers } = require('ethers');

async function protectedSwap(swapParams, wallet, provider) {
    // Подключаемся к Flashbots relay
    const flashbotsProvider = await FlashbotsBundleProvider.create(
        provider,
        wallet,
        'https://relay.flashbots.net'
    );
    
    // Собираем swap транзакцию как обычно
    const swapTx = await buildSwapTransaction(swapParams);
    
    // Отправляем через Flashbots
    const bundleSubmission = await flashbotsProvider.sendPrivateTransaction(
        {
            signer: wallet,
            transaction: swapTx
        },
        { maxBlockNumber: (await provider.getBlockNumber()) + 10 }
    );
    
    const receipt = await bundleSubmission.wait();
    return receipt;
}
Пример реализации commit-reveal контракта
contract CommitRevealSwap {
    mapping(bytes32 => Commitment) public commitments;
    
    struct Commitment {
        address user;
        uint256 blockNumber;
        bool revealed;
    }
    
    uint256 public constant MIN_BLOCKS_BEFORE_REVEAL = 1;
    uint256 public constant MAX_BLOCKS_BEFORE_REVEAL = 10;
    
    function commit(bytes32 commitHash) external {
        commitments[commitHash] = Commitment({
            user: msg.sender,
            blockNumber: block.number,
            revealed: false
        });
    }
    
    function reveal(
        uint256 amountIn,
        uint256 amountOutMin,
        address[] calldata path,
        bytes32 salt
    ) external {
        bytes32 commitHash = keccak256(abi.encodePacked(
            msg.sender, amountIn, amountOutMin, 
            keccak256(abi.encode(path)), salt
        ));
        
        Commitment storage commitment = commitments[commitHash];
        require(commitment.user == msg.sender, "Not your commit");
        require(!commitment.revealed, "Already revealed");
        require(
            block.number >= commitment.blockNumber + MIN_BLOCKS_BEFORE_REVEAL,
            "Too early"
        );
        require(
            block.number <= commitment.blockNumber + MAX_BLOCKS_BEFORE_REVEAL,
            "Expired"
        );
        
        commitment.revealed = true;
        _executeSwap(amountIn, amountOutMin, path, msg.sender);
    }
}

Batch Auctions: архитектурное решение CoW Protocol

CoW Protocol решает проблему на уровне архитектуры. Заявки собираются за период (несколько блоков), off-chain solver находит оптимальное исполнение для всего батча, публикуется единая settlement-транзакция с uniform price. В batch auction нет места для сэндвича: атакующий не может встроиться между заявкой и исполнением, так как они разнесены во времени.

Обычный AMM:
Block N:   frontrun_buy → user_swap → backrun_sell

CoW Batch Auction:
Block N:   submit_order(user1), submit_order(user2), ...
Block N+3: solver publishes settlement_tx с uniform price

Как мы проектируем систему защиты?

Процесс состоит из пяти этапов:

  1. Аналитика — изучаем ваш протокол, смарт-контракты, типичные транзакции пользователей, текущий уровень MEV-активности.
  2. Проектирование — выбираем комбинацию методов защиты под ваши требования (безопасность, UX, бюджет).
  3. Реализация — пишем смарт-контракты (Solidity), интегрируем приватные RPC, настраиваем динамический slippage.
  4. Тестирование — покрываем unit-тестами и fuzzing (Echidna), прогоняем на тестнете, симулируем сэндвич-атаки.
  5. Деплой и мониторинг — разворачиваем на mainnet, подключаем мониторинг MEV-активности (Tenderly, собственные дашборды).

Мы гарантируем прозрачность: каждый этап сопровождается документацией, предоставляем доступ к репозиторию и обучение вашей команды.

Что входит в работу

  • Аудит текущей архитектуры и выявление уязвимостей к сэндвич-атакам.
  • Разработка и внедрение выбранных методов защиты.
  • Исходный код смарт-контрактов (Solidity) с покрытием тестами.
  • Настройка приватных RPC (Flashbots, MEV Blocker) — конфигурация и интеграция.
  • Документация по эксплуатации и инструкция для пользователей.
  • Мониторинговая система с алертами при всплеске MEV-активности.
  • Техническая поддержка в течение 3 месяцев после деплоя.

Сроки и стоимость

Сроки зависят от сложности: интеграция приватного RPC — от 1 недели, commit-reveal контракт — от 2 недель, полная система с мониторингом — от 4 недель. Batch auction протокол — от 2 месяцев. Стоимость рассчитывается индивидуально под ваш проект — пишите, мы оценим задачу в течение 2 рабочих дней.

Мониторинг и детекция атак

Для постоянной защиты мы внедряем компонент мониторинга, который отслеживает активность MEV-ботов, анализирует потери пользователей и отправляет алерты при аномальном всплеске сэндвичей. Экономия от внедрения такой системы может достигать $15 000 в месяц.

async function detectSandwichInBlock(blockNumber, provider, uniswapAddress) {
    const block = await provider.getBlock(blockNumber, true);
    const uniswapTxs = block.transactions.filter(
        tx => tx.to?.toLowerCase() === uniswapAddress.toLowerCase()
    );
    
    const sandwiches = [];
    
    for (let i = 1; i < uniswapTxs.length - 1; i++) {
        const prev = uniswapTxs[i - 1];
        const current = uniswapTxs[i];
        const next = uniswapTxs[i + 1];
        
        if (prev.from === next.from && prev.from !== current.from) {
            const prevDecoded = decodeSwap(prev.data);
            const nextDecoded = decodeSwap(next.data);
            
            if (prevDecoded && nextDecoded && 
                prevDecoded.tokenIn === nextDecoded.tokenOut) {
                sandwiches.push({
                    attacker: prev.from,
                    victim: current.from,
                    frontrunTx: prev.hash,
                    victimTx: current.hash,
                    backrunTx: next.hash,
                    estimatedProfit: calculateSandwichProfit(prevDecoded, nextDecoded)
                });
            }
        }
    }
    
    return sandwiches;
}

Получите консультацию эксперта по защите DeFi уже сегодня. Свяжитесь с нами для бесплатной оценки вашего проекта.

Аудит смарт-контрактов: как находят то, что не видит компилятор

Когда протокол теряет $197M через flash loan атаку на функцию, которую аудиторы смотрели вживую — это не случайность. Это системный пробел в методологии. Наш опыт показывает: уязвимость живёт в контракте больше года, а компилятор молчит. Мы перестроили процесс аудита так, чтобы ловить такие кейсы до деплоя.

Что статический анализ не найдёт

Slither — стандартный первый инструмент. Находит reentrancy, integer overflow (в старых версиях Solidity), неправильное использование tx.origin, shadowing переменных, неинициализированные хранилища. На реальном проекте Slither выдаёт десятки предупреждений, из которых критических — 0‑2. Остальное — информационный шум.

Slither не найдёт логическую уязвимость. Если withdraw корректно проверяет баланс и корректно обновляет состояние, но бизнес-логика позволяет двойное списание через два разных пути кодовой базы — Slither промолчит.

Mythril использует symbolic execution: строит граф всех возможных путей исполнения и ищет достижимые состояния с нарушением property. Работает хорошо на изолированных контрактах. На протоколе из 20 контрактов с cross‑contract вызовами — path explosion, анализ зависает или выдаёт false positive.

Оба инструмента обязательны как первый pass. Но они не заменяют ручной анализ.

Fuzzing: где Echidna и Foundry находят реальные баги

Echidna — property‑based fuzzer от Trail of Bits. Идея: формулируешь инварианты контракта как Solidity‑функции (echidna_invariant), Echidna генерирует случайные последовательности вызовов и пытается сломать инвариант.

Пример инварианта для lending протокола:

function echidna_total_assets_ge_liabilities() public view returns (bool) {
    return totalAssets() >= totalLiabilities();
}

Echidna найдёт последовательность deposit → borrow → liquidate → repay, которая нарушает этот инвариант. Руками такой кейс не построишь — комбинаций слишком много.

Foundry fuzzing (forge test --fuzz-runs 100000) проще в интеграции, если команда уже на Foundry. Поддерживает stateful fuzzing через invariant тесты. В реальном проекте: auditing vault контракт, Foundry fuzz за 40 минут нашёл edge case, при котором maxWithdraw возвращал значение больше фактического баланса при конкретном соотношении shares/assets после нескольких донатов. Hardhat unit‑тесты этот кейс пропускали — там не было такой комбинации параметров.

Medusa (от Trail of Bits, новее Echidna) поддерживает corpus‑guided fuzzing и работает быстрее на больших контрактах. Если объём кодовой базы > 5000 строк Solidity — смотрим на Medusa.

Как инварианты помогают выявить критические уязвимости

Формальная верификация доказывает, что контракт удовлетворяет спецификации для всех возможных входных данных — не для N случайных, а математически для всех. Инструменты: Certora Prover, K Framework, Halmos.

Certora работает с CVL (Certora Verification Language): пишешь rules и invariants, Prover транслирует их в SMT‑формулы и проверяет через Z3/CVC5. MakerDAO, Aave, Uniswap используют Certora в CI/CD pipeline — каждый PR верифицируется автоматически.

Ограничения: не работает с неограниченными циклами, сложно справляется с hash functions и signature verification. Для контрактов с простой математикой (AMM, lending) — отлично. Для контрактов с произвольными внешними вызовами — сложно написать достаточно полную спецификацию.

Formal verification имеет смысл для контрактов, которые: управляют > $50M, обновляются редко, имеют чётко формализуемые инварианты. Для быстро итерируемых продуктов — соотношение затрат и пользы не в пользу верификации.

Векторы атак, которые пропускают джуниор‑аудиторы

Storage collision в proxy паттерне. Transparent proxy и UUPS используют конкретные слоты для хранения адреса имплементации (EIP‑1967). Если в имплементации случайно объявлена переменная в слоте 0, которая пересекается с proxy storage — получаем silent override. Slither это не поймает, если proxy и имплементация в разных файлах.

Read‑only reentrancy. Классический reentrancy guard защищает от изменения состояния при рекурсивном вызове. Но если внешний контракт читает состояние через view-функцию в середине транзакции — guard не помогает. Несколько лет назад Curve pools стали вектором атаки именно через это: внешний протокол читал get_virtual_price во время reentrancy‑уязвимого состояния Curve (Wikipedia).

Oracle manipulation через TWAP. Spot price — стандартная цель для flash loan атаки (Wikipedia). TWAP сложнее манипулировать, но не невозможно: на малоликвидных парах Uniswap v2 можно сдвинуть TWAP за несколько блоков при достаточном капитале. Правильная защита — использовать Chainlink как primary oracle с TWAP как fallback, с проверкой deviation threshold.

Gas griefing на unbounded loop. Функция итерируется по массиву пользователей. Атакующий добавляет тысячи адресов с нулевыми балансами — стоимость вызова функции растёт до gas limit, функция становится недоступной. Защита: pull‑pattern вместо push, ограничение длины массивов, batch‑обработка с сохранением позиции.

Front‑running на MEV. Транзакция видна в mempool до включения в блок. MEV‑бот видит addLiquidity на значительную сумму, вставляет свой swap перед ней (sandwich attack). Для AMM это часть модели. Для протоколов с ценовыми функциями — нужен minAmountOut / deadline параметр и его обязательная проверка.

Структура полного аудита

  1. Scope definition и автоматический анализ (1‑2 дня). Фиксируем commit hash, версию компилятора, список out‑of‑scope. Запускаем Slither, Mythril, Aderyn. Triage: отделяем реальные критические баги от false positive. Составляем карту зависимостей контрактов.

  2. Ручной анализ (5‑15 дней). Каждый контракт построчно. Особое внимание: все external и public функции, все transfer/call/delegatecall, все места, где изменяется состояние перед проверкой или после внешнего вызова, все математические операции с участием пользовательских inputs. В среднем 95% найденных уязвимостей — логические, а не технические.

  3. Fuzzing и тестирование (2‑5 дней). Echidna или Foundry invariant tests для критических инвариантов. Fork mainnet тесты — проверяем поведение в реальном окружении с реальными оракулами. Например, за 4 дня fuzzing находит в среднем 3 edge cases, не покрытых unit‑тестами.

  4. Отчёт и митигация. Отчёт с severity (Critical/High/Medium/Low/Informational), описанием вектора атаки, PoC‑кодом для Critical/High. Разработчики исправляют, аудиторы делают re‑audit исправлений.

Severity Примеры Требует ли re‑audit
Critical Drain funds, unauthorized ownership transfer Всегда
High Manipulation, DoS на ключевые функции Всегда
Medium Некорректное поведение при edge cases Рекомендуется
Low Газ‑неэффективность, опечатки в events По желанию

Аудит в CI/CD

Нормальная практика для зрелых протоколов: Slither и Aderyn запускаются в GitHub Actions на каждый PR. Certora Prover — на merge в main. Это не заменяет полный аудит перед деплоем, но ловит регрессии.

# .github/workflows/audit.yml
- name: Run Slither
  uses: crytic/[email protected]
  with:
    target: 'src/'
    slither-args: '--filter-paths "test|mock|script"'
Чек‑лист обязательных проверок перед деплоем
  • Все external функции имеют проверки доступа (onlyOwner, onlyRole)
  • Использование SafeERC20 для внешних токенов
  • Отсутствие delegatecall на неизвестные адреса
  • Проверка на reentrancy во всех функциях с внешними вызовами
  • Наличие minAmountOut и deadline в AMM‑функциях
  • Использование проверенного оракула (Chainlink) с deviation threshold

Инструменты аудита: сравнение

Инструмент Тип анализа Что находит Ограничения
Slither Статический Reentrancy, integer overflow, access control Пропускает логические уязвимости
Mythril Symbolic execution Достижимые состояния с нарушением property Path explosion на больших базах
Echidna Fuzzing (property‑based) Нарушение инвариантов Требует написания инвариантов
Certora Formal verification Математическое доказательство свойств Не работает с хешами/подписями

Что входит в работу (deliverables)

  • Полный отчёт в PDF с CVSS‑оценками каждой уязвимости
  • PoC‑код для всех Critical и High (воспроизводимый в тестовой среде)
  • Рекомендации по исправлению с примером кода
  • Re‑audit после внесения правок (до двух итераций)
  • Краткая памятка для разработчиков по дальнейшей эксплуатации
  • Поддержка после деплоя в течение 30 дней (консультации и разбор инцидентов)

Сроки

Аудит простого токена или NFT‑контракта — 3‑5 рабочих дней. DeFi протокол с lending/AMM — 2‑4 недели. Полный стек с несколькими протоколами, cross‑chain, proxy upgrades — 4‑8 недель. Re‑audit исправлений — 3‑7 дней отдельно.

Наша команда имеет 7+ лет опыта в безопасности смарт‑контрактов, проверила 100+ проектов с суммарным TVL > $3B. Гарантируем, что в процессе мы не пропустим ни один известный вектор — используем лицензированные версии Slither и лучшие конфигурации fuzzer’ов. Предотвращённые убытки для клиентов оцениваются более чем в $50M.

Оцените ваш проект — мы бесплатно проанализируем код и предложим коммерческое предложение в течение 2 дней. Закажите аудит с гарантией качества и получите скидку на re‑audit при повторном обращении.