Инженерия Crypto/Web3: метрики для DeFi и L2
У Solidity-инженера, который деплоит контракт в mainnet, запас на ошибку меньше, чем у инженера запуска SpaceX. После деплоя код immutable, публичен для любого аудитора и часто контролирует больше денег, чем весь treasury работодателя. TVL DeFi-протоколов перешёл $200B в Q1 2026 (данные DefiLlama). Метрики, созданные для web2 SaaS, здесь не работают.
Deployment frequency теряет смысл, когда "деплой" — это апгрейд прокси с 48-часовым timelock-голосованием. Lead time теряет смысл, когда последняя стадия — внешний аудит за $200K. Мы работали с 3 Web3-командами — двумя L2 rollup и одним DeFi — и пересобрали стэк метрик под ограничения, которых в web2 просто нет.
{/* truncate */}
Почему Web3-инженерия устроена иначе
У Web3 три ограничения, которые переписывают плейбук.
Иммутабельность. Задеплоенный smart contract нельзя пропатчить. Upgradeable-прокси существуют, но требуют social consensus — timelock + multisig + часто DAO-голосование. "Move fast and break things" — буквальный вектор атаки.
Адверсариальная среда. Каждый задеплоенный контракт — публичный код с публичным bounty. Исследование Trail of Bits отмечает: 78% DeFi-эксплойтов в 2023 году — это уже известные классы уязвимостей, которые были в хотя бы одном аудит-репорте, который команда видела. Engineering velocity бессмысленна, если отгруженный код эксплойтабелен.
Gas как первоклассная метрика. L2-команда измеряет то же, за что платят пользователи: gas на вызов. Снижение gas на 15% на ключевой функции = снижение цены на 15% для каждого пользователя протокола, навсегда.
Большинство платформ engineering intelligence это игнорирует. Итог: DORA-дашборд рядом с задренёным протоколом.
Метрики, которые действительно важны
Пропустим deployment frequency и MTTR — не бесполезны, но вторичны. Пять метрик имеют значение:
1. Audit cycle time
Определение: время от тэга audit-ready ветки → получение отчёта внешнего аудита → закрытие всех critical/high findings.
DeFi-команды живут и умирают по частоте аудитов. Отчёт OpenZeppelin 2024 по throughput аудитов показывает: медиана длительности — 21 день для "средней сложности" smart contract-сьютов, плюс ещё 12-15 дней на remediation. Команды, у которых каждый major upgrade проходит цикл аудита больше 45 дней, фактически шипают один релиз в квартал.
Отслеживайте:
- Дни от тэга до старта аудита (queue wait — часто бутылочное горлышко)
- Дни от старта до отчёта
- Дни от отчёта до закрытия всех critical
- Findings на kLoC (бенчмарк против прошлых циклов)
| Стадия аудита | Медиана (наши 3 команды) | Best-case L2 |
|---|---|---|
| Queue wait | 14 дней | 3 дня (retainer) |
| Исполнение аудита | 18 дней | 12 дней |
| Remediation | 11 дней | 4 дня |
| Полный цикл | 43 дня | 19 дней |
Модель retainer (предоплаченные слоты аудита) — самый большой рычаг, режет queue wait на порядок.
2. Gas-эффективность на релиз
Определение: для каждой изменённой функции сравнить gas до и после. Отслеживать как процентную дельту.
L2-команды, с которыми мы работаем, бенчмаркают каждый коммит. Невинный рефакторинг, добавляющий SLOAD в цикл, может удвоить gas для горячего пути — платят пользователи. Gas-диффы перед merge в CI — минимум; трекинг per-release aggregate дельты — серьёзный уровень.
Здоровый скользящий 12-недельный тренд: gas/function снижается или flat ±3%. Рост gas по релизам — архитектурный сигнал, не просто perf-проблема.
3. Time-to-timelock-merge
Определение: время от "код готов" → прошёл аудит + governance proposal → исполнен через timelock.
Это Web3-аналог DORA lead time for changes. 4 стадии DORA (commit → PR-open → merge → deploy) не подходят. Стадии Web3:
| Стадия | Плоскость контроля | Типичная длительность |
|---|---|---|
| Commit → PR merged | Инженерия | 2-5 дней |
| Merged → Audit complete | Вендор | 20-40 дней |
| Audit → Governance proposal | Product/Eng | 3-7 дней |
| Proposal → Timelock executed | DAO + чейн | 2-14 дней |
| Итого | 27-66 дней |
Команды, которые путают engineering velocity с protocol velocity, обжигаются — большая часть задержки вне контроля инженерии.
4. Покрытие классов эксплойтов
Определение: процент классов уязвимостей OWASP / SWC / Trail of Bits, покрытых тестами + фаззингом + формальной верификацией.
Цифра Trail of Bits 2023 (78% эксплойтов из известных классов) — это весь pitch. Трекинг покрытия против референс-списка меняет разговор про безопасность с "мы прошли аудит?" на "мы протестировали именно этот класс атаки?".
Частые референсы:
- SWC Registry — 136 классов уязвимостей smart contract
- Trail of Bits "Building Secure Contracts"
- Consensys Diligence checklist
5. Время реакции multisig
Определение: от сигнала "нужен pause" до сбора кворума подписей и исполнения транзакции.
Kill-switch DeFi-протокола работает ровно так быстро, как его подписанты. Несколько команд обнаружили, что время реакции multisig больше block time чейна, который нужно паузить — эксплойт подтверждается быстрее, чем можно отреагировать. Цель: ≤ 60 секунд при 24/7 покрытии. Большинство команд, которых мы меряли, на 8-30 минутах.
Стэк метрик Web3 расходится с web2 DORA на каждом слое — вендоры аудита, on-chain governance, gas-бенчмарки.
Как compliance и адверсариальная среда меняют измерение
Две вещи сдвигают работу за пределы "DORA плюс ещё шаги".
On-chain observability ≠ app-телеметрия. Web3-команда может (и должна) трекать on-chain активность своего же протокола: failed-транзакции, reverts на блок, gas-выбросы. Опрос CNCF 2024: только 14% Web3-команд интегрируют on-chain метрики в инженерный стек observability — остальные держат чейн и код как разные вселенные. В этом разрыве живут эксплойты.
Забюджетированный exploit response. Каждую инженерную неделю надо резервировать часть времени на exploit review. Web2-команды бюджетируют 10-20% на "tech debt" и обычно скипают. Web3-команды, которые считают "мониторить Twitter @samczsun, @banteg и post-mortem каждого конкурента" инженерной работой, ловят паттерны эксплойтов раньше. Неромантично. Снижает вероятность эксплойта сильнее, чем ещё один аудит.
Паттерн: типичная DeFi / L2 команда
Из трёх команд, с которыми мы работали:
| Тип команды | Размер | Главная метрика |
|---|---|---|
| L2 rollup инфра | 14 инж | Gas-per-rollup-batch cost |
| DeFi lending | 9 инж | TVL / eng-week (капитал-эффективность инженерии) |
| Cross-chain bridge | 11 инж | Покрытие exploit-классов % |
Метрика lending-протокола — TVL на инженерную неделю — спорная. Не каждая единица TVL вызвана инженерией. Но 12 недель подряд она показывает, когда рост протокола обгоняет способность инженерии его защищать. Это leading indicator выгорания и эксплойта, который никто больше не смотрит.
Где подходит PanDev Metrics
Наш IDE heartbeat не знает "Solidity vs TypeScript" из первых принципов — видит расширение файла и язык. Для Web3-команд мы трекаем: время в Solidity-файлах vs тестах vs TS/Rust интеграции (полезный ratio — зрелые команды проводят 30-40% Solidity-работы в тестах), связку branch/task для циклов audit remediation, deploy-ивенты из Hardhat/Foundry-пайплайнов.
Правило конвенции Git (fix/AUDIT-204, feature/L2-BATCHING-88) здесь важнее, чем в web2, потому что задачи audit remediation и governance-proposal — разные потоки; без именования веток они сливаются на дашборде.
Наших данных здесь мало. Три команды — не индустрия, это анекдот с общими паттернами. У нас нет сигнала по командам L1-клиентов (Geth, Reth, Erigon), где работа ближе к системному программированию. Если у вас L1-клиент — этот пост плохо обобщается на вас.
Где большинство Web3-дашбордов ломается
Они копируют web2-дашборд. Deploy frequency. PR throughput. Строки кода. Ни одно не коррелирует с тем, что реально нужно протоколу — безопасный код, прошедший длинный пайплайн.
Нормальный Web3-дашборд имеет gas наверху, audit cycle посередине, commit velocity внизу. Инверсия SaaS.
Дополнительное чтение
- Инженерные метрики в Fintech: compliance, скорость и безопасность — соседний домен
- DORA Metrics: полный гайд — фреймворк, который Web3 адаптирует, а не усваивает
- Change Failure Rate: почему 15% — норма, 0% подозрительно — в Web3 целевой 0% для mainnet, что само подозрительно