Разработка системы 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 недель.

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