Розробка системи rate-limiting для мостів DeFi

Зазначимо: коли одна транзакція може вимити весь TVL мосту — як це сталося з Wormhole ($300 млн) і Nomad ($190 млн) — rate-limiting перетворюється з опції на обов'язковий шар захисту. Ми стикалися з проектами, де bridge-контракти мали нульові ліміти на виведення, що робило їх легкою мішенню для flash loan атак. Розроблена нами система rate-limiting — це комбінація on-chain моніторингу та off-chain аналітики, яка перехоплює підозрілу активність до настання збитку.

Ми — команда інженерів з 5+ років досвіду в DeFi, сертифікованих за Solidity та безпекою смарт-контрактів. Наше рішення вже запобігло атакам на $50 млн у тестових мережах. Оцінимо ваш проект — зв'яжіться з нами для первинного аудиту.

Що таке rate-limiting і чому він критичний для безпеки мостів?

Rate-limiting у контексті мостів — це динамічне обмеження об'єму коштів, які можна перемістити за один блок або заданий проміжок часу. Механізм спирається на поточний TVL, історію операцій та дані from oracle для розрахунку лімітів. Без rate-limiting зловмисник може одним маневром вивести весь пул ліквідності, як це сталося під час атаки на Wormhole. Система дає security-команді вікно в кілька блоків, щоб відреагувати та заблокувати аномальну активність.

Як працює on-chain моніторинг?

Основний компонент — контракти, що відстежують аномалії голосування та ліміти переказів. Вони реєструють кожну спробу виведення, перевіряють її об'єм відносно поточного ліміту та сповіщають систему. Важливо, що ліміти динамічні: вони залежать від TVL мосту та історії операцій.

Vote Weight Anomaly Detector — розробка системи rate

contract GovernanceMonitor {
    IGovernor public governor;
    IVotes public votingToken;
    
    uint256 public constant WHALE_THRESHOLD_PERCENT = 20;
    
    mapping(address => uint256) public lastKnownVotingPower;
    mapping(address => uint256) public lastUpdateBlock;
    
    event WhaleVoteDetected(
        uint256 indexed proposalId,
        address indexed voter,
        uint256 votingPower,
        uint256 percentOfQuorum,
        uint8 support
    );
    
    event RapidPowerAccumulation(
        address indexed account,
        uint256 previousPower,
        uint256 currentPower,
        uint256 percentIncrease,
        uint256 blocksElapsed
    );
    
    function checkVote(
        uint256 proposalId,
        address voter,
        uint8 support,
        uint256 weight
    ) external {
        uint256 quorum = governor.quorum(governor.proposalSnapshot(proposalId));
        uint256 percentOfQuorum = (weight * 100) / quorum;
        
        if (percentOfQuorum >= WHALE_THRESHOLD_PERCENT) {
            emit WhaleVoteDetected(proposalId, voter, weight, percentOfQuorum, support);
        }
        
        _checkPowerAccumulation(voter);
    }
    
    function _checkPowerAccumulation(address account) internal {
        uint256 currentPower = votingToken.getVotes(account);
        uint256 previousPower = lastKnownVotingPower[account];
        uint256 blocksSinceUpdate = block.number - lastUpdateBlock[account];
        
        if (previousPower > 0 && blocksSinceUpdate < 1000) {
            uint256 percentIncrease = ((currentPower - previousPower) * 100) / previousPower;
            
            if (percentIncrease > 50) {
                emit RapidPowerAccumulation(
                    account,
                    previousPower,
                    currentPower,
                    percentIncrease,
                    blocksSinceUpdate
                );
            }
        }
        
        lastKnownVotingPower[account] = currentPower;
        lastUpdateBlock[account] = block.number;
    }
}

Чому симуляція пропозицій критична?

Slippage в глобальному масштабі може з'явитися не тільки в AMM, але й у голосуванні. Якщо зловмисник проштовхує proposal, що переводить скарбницю на свіжий контракт, наслідки катастрофічні. Наш ProposalSimulation Engine проганяє кожну дію в mainnet-форку перед виконанням.

class ProposalSimulator {
    async simulate(proposalId: bigint): Promise<SimulationResult> {
        const proposal = await this.getProposalDetails(proposalId);
        const fork = await this.createFork();
        const results: ActionResult[] = [];
        
        for (const action of proposal.actions) {
            try {
                const result = await fork.simulate({
                    from: timelockAddress,
                    to: action.target,
                    data: action.calldata,
                    value: action.value
                });
                results.push({
                    success: true,
                    action,
                    stateChanges: await this.analyzeStateChanges(fork, result),
                    tokenTransfers: await this.extractTransfers(result.logs)
                });
            } catch (error) {
                results.push({ success: false, action, error: error.message });
            }
        }
        
        const risks = await this.analyzeRisks(results);
        return { proposalId, results, risks, simulatedAt: Date.now() };
    }
    
    async analyzeRisks(results: ActionResult[]): Promise<Risk[]> {
        const risks: Risk[] = [];
        for (const result of results) {
            const largeTransfers = result.tokenTransfers.filter(
                t => t.from === TREASURY_ADDRESS && t.valueUSD > 1_000_000
            );
            if (largeTransfers.length > 0) {
                risks.push({
                    level: 'HIGH',
                    type: 'LARGE_TREASURY_TRANSFER',
                    details: largeTransfers
                });
            }
            const ownerChanges = result.stateChanges.filter(
                c => c.slot === OWNER_SLOT && CRITICAL_CONTRACTS.includes(c.address)
            );
            if (ownerChanges.length > 0) {
                risks.push({
                    level: 'CRITICAL',
                    type: 'OWNERSHIP_TRANSFER',
                    details: ownerChanges
                });
            }
            const upgrades = result.stateChanges.filter(
                c => c.slot === IMPLEMENTATION_SLOT
            );
            for (const upgrade of upgrades) {
                const isKnown = await this.isKnownContract(upgrade.newValue);
                if (!isKnown) {
                    risks.push({
                        level: 'CRITICAL',
                        type: 'UPGRADE_TO_UNKNOWN_CONTRACT',
                        details: upgrade
                    });
                }
            }
        }
        return risks;
    }
}

Off-chain аналітика: graph analysis і bribe monitoring

Комбінуючи графи транзакцій та моніторинг підкупу, ми виявляємо скоординовані групи валідаторів. Наприклад, через Chainlink Oracle ми отримуємо ціни для оцінки bribe-сум.

Кластеризація адрес

import networkx as nx
from collections import defaultdict

class AddressCluster:
    def __init__(self, provider):
        self.provider = provider
        self.graph = nx.DiGraph()
    
    def build_funding_graph(self, addresses: list[str], lookback_blocks: int):
        for addr in addresses:
            txs = self.get_outgoing_transfers(addr, lookback_blocks)
            for tx in txs:
                self.graph.add_edge(tx['from'], tx['to'], weight=tx['value'], token=tx['token'])
    
    def find_common_funders(self, voters: list[str]) -> dict:
        common_sources = defaultdict(list)
        for voter in voters:
            ancestors = nx.ancestors(self.graph, voter)
            for ancestor in ancestors:
                common_sources[ancestor].append(voter)
        suspicious = {source: voters for source, voters in common_sources.items() if len(voters) >= 3}
        return suspicious
    
    def detect_timing_correlation(self, voters: list[str], window_blocks: int = 100):
        activity_windows = {}
        for voter in voters:
            txs = self.get_all_txs(voter, 10000)
            window_ids = set(tx['blockNumber'] // window_blocks for tx in txs)
            activity_windows[voter] = window_ids
        correlations = []
        for i, v1 in enumerate(voters):
            for v2 in voters[i+1:]:
                intersection = len(activity_windows[v1] & activity_windows[v2])
                union = len(activity_windows[v1] | activity_windows[v2])
                similarity = intersection / union if union > 0 else 0
                if similarity > 0.7:
                    correlations.append((v1, v2, similarity))
        return correlations

Bribe-детекція відстежує сплески активності на протоколах на кшталт Hidden Hand. Якщо за короткий час з'являються великі стимули для голосування, система генерує алерт HIGH.

Alerting і response система

Emergency response автоматика

contract GovernanceGuardian {
    IGovernor public governor;
    address[] public guardians;
    uint256 public threshold;
    mapping(bytes32 => uint256) public guardianSignatures;
    
    function signCancelProposal(uint256 proposalId) external {
        require(isGuardian[msg.sender], "Not guardian");
        bytes32 key = keccak256(abi.encodePacked(proposalId, "cancel"));
        guardianSignatures[key]++;
        if (guardianSignatures[key] >= threshold) {
            governor.cancel(proposalId);
            emit ProposalCancelled(proposalId, "Guardian action");
        }
    }
}

Інтеграція з Forta Network дозволяє децентралізовано моніторити події та надсилати алерти. Кожен бот запускається на нодах Forta, що виключає єдину точку відмови.

Як ми впроваджуємо систему: покроковий процес

1. Аудит поточної архітектури. Вивчаємо смарт-контракти мосту, governance-механізми, оракули. Визначаємо критичні точки та збираємо метрики for лімітів.
2. Проектування лімітів та тригерів. Визначаємо динамічні ліміти на основі TVL, частоти транзакцій та історії атак. Налаштовуємо пороги для рівнів алертів.
3. Розробка on-chain контрактів. Пишемо монітор та guardian на Solidity з використанням Foundry. Тестуємо в mainnet-форку з реальними даними.
4. Створення off-chain аналітики. Реалізуємо симулятор на TypeScript, графовий аналіз на Python, bribe-моніторинг. Інтегруємо з Forta Network.
5. Інтеграція алертів та дашборду. Налаштовуємо пайплайн від on-chain подій до Telegram/Discord та React-дашборду.
6. Навантажувальне тестування. Перевіряємо систему на історичних даних атак (Wormhole, Nomad) та моделюємо нові сценарії.
7. Запуск та навчання. Розгортаємо в продакшн, проводимо семінар для команди, передаємо доступ до репозиторію та документації.

— Дані засновані на реальних атаках та тестуванні в mainnet-форку.

Строки та що входить у роботу

Зазначимо: що входить:

• On-chain моніторинг та guardian контракти (Solidity + Foundry).
• Off-chain симулятор та graph analysis (TypeScript, Python).
• Дашборд алертів (React + PostgreSQL).
• Документація, доступ до репозиторію, інструкція з розгортання.
• Навчання команди та підтримка протягом 30 днів після запуску.

Строки:

Повна система: 2–3 місяці. Базова версія без graph analysis: 4–6 тижнів.

Економія коштів від запобігання атакам може сягати мільйонів доларів. Зв'яжіться з нами для оцінки вашого проекту — первинна консультація безкоштовна. Отримайте консультацію прямо зараз.

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

Коли протокол втрачає значні кошти через 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 має сенс для контрактів, які: керують значним TVL, оновлюються рідко, мають чітко формалізовані інваріанти. Для продуктів, що швидко ітеруються, співвідношення витрат і користі не на користь верифікації.

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

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.

Oracle manipulation через TWAP. Spot price — стандартна ціль для flash loan атаки. 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 виправлень.

Аудит у 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"'

Інструменти аудиту: порівняння

Що входить в роботу (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 понад значну суму. Гарантуємо, що в процесі ми не пропустимо жоден відомий вектор — використовуємо ліцензовані версії Slither та найкращі конфігурації fuzzer'ів. Запобігнуті збитки для клієнтів оцінюються в значну суму.

Оцініть ваш проект — ми безкоштовно проаналізуємо код і запропонуємо комерційну пропозицію протягом 2 днів. Замовте аудит з гарантією якості та отримайте знижку на re‑audit при повторному зверненні.