SLA по задержке — это договорённые целевые уровни времени доставки и исполнения операций, выраженные через процентили: медиану (P50), «тонкие хвосты» (P95) и «экстремальные хвосты» (P99). В контексте интероперабельности Web3 измеряют как минимум два интервала:
- A→B delivery latency — время от фиксации события/сообщения в сети A до приёма валидным получателем в сети B.
- Time-to-executed — время от фиксации в A до статуса «исполнено» в B (включая валидацию, финальность, газ и бизнес-логику).
Процентиль P95 показывает, что 95% операций укладываются в целевое окно; P99 — строгий контроль «хвостов». Для безопасности и UX P95/P99 важнее среднего: именно хвосты ломают ликвидации, дедлайны и пользовательские ожидания.
Связанные страницы: Интероперабельность, Allow-list маршрутов, Идемпотентность, Программируемый перевод, CCT, Каноничный мост, Риски мостов, Chainlink CCIP.
Определения и базовая методика
| Метрика | Определение | Комментарии |
|---|---|---|
| P50 | медиана времени между t(A:confirmed) и t(B:received/executed) | База для «нормального» UX |
| P95 | 95-й процентиль для выборки задержек | Контроль «тонких хвостов» |
| P99 | 99-й процентиль | Контроль экстремальных хвостов/инцидентов |
| Window | окно агрегации (скользящее) | Обычно 30–60 мин для алертов, 24 ч для отчётов |
| Bucketization | гистограммы задержек | Обязательны для стабильных квантилей |
| Route | конкретное A→B направление | Считается per-route из allow-list |
Типы отсчётов:
- Delivery latency: t(B:received) − t(A:confirmed)
- Time-to-executed: t(B:executed) − t(A:confirmed)
- On-chain exec latency (B): t(B:executed) − t(B:received)
Все timestamp’ы берутся из надёжных источников: подтверждённые блоки, проверенные логи, метки приёма у получателя. Для сетей с вероятностной финальностью используйте порог финальности по маршруту из allow-list.
Что именно измерять per-route
| Слой | P50 | P95 | P99 |
|---|---|---|---|
| Transport A→B | базовое окно | окно «тонких хвостов» | окно инцидента |
| Верификация/финальность | порог сети | повышенный порог | аварийный порог |
| Исполнение в B | нормальная очередь | деградация | перегрузка |
| Итог TTE | «ожидаемый UX» | критично для дедлайнов | триггер паузы/лимитов |
Для маршрутов «перевод + действие» (см. Programmatic Transfer) измеряйте все три слоя и итоговую TTE.
Как считать процентили надёжно
- Используйте гистограммы задержек с устойчивыми bucket’ами (логарифмическая сетка).
- Считайте квантильную оценку на скользящем окне (например, 30 мин) и дублируйте на более длинном окне (2–6 ч) для «устойчивости».
- Разделяйте метрики per-route, per-asset и per-action (deposit/repay/mint_to).
- Для сетей L2 учитывайте challenge-окно в финальности по маршруту.
Типовые bucket’ы (мс): 100, 250, 500, 1000, 2000, 5000, 10000, 30000, 60000, 120000, 300000, 600000.
SLO vs SLA и «error budget» для задержки
- SLO — внутренняя цель (например, P95 TTE ≤ 60 c, P99 TTE ≤ 180 c).
- SLA — внешнее обязательство; обычно мягче или с оговорками.
- Latency budget — доля запросов, допускающих превышение целей (аналог error budget). Его «прожиг» измеряют burn-rate.
Пример профиля целей:
| Профиль | Цель P95 TTE | Цель P99 TTE |
|---|---|---|
| Консервативный (RWA/клиринг) | ≤ 120 c | ≤ 300 c |
| Активный DeFi (деривативы) | ≤ 30 c | ≤ 90 c |
| Универсальный омничейн | ≤ 60 c | ≤ 180 c |
Конкретные цели зависят от сетей/нагрузки и фиксируются per-route в allow-list.
Алерты и burn-rate для хвостов
Мультиоконные алерты: короткое окно + длинное окно.
- Короткое (5–15 мин): чувствительность к резким всплескам P99.
- Длинное (1–6 ч): устойчивые тренды P95.
Пример правил:
- P99 TTE > целевого × 1.5 в течение 10 мин → warning.
- P99 TTE > целевого × 2 более 10 мин или P95 TTE > целевого × 1.5 более 30 мин → incident.
- Burn-rate: доля запросов, вышедших за SLO по TTE, превысила порог в двух окнах → эскалация.
Действия при инциденте см. ниже в плейбуке; связка с режимами paused/only-returns описана в allow-list.
Связь метрик задержки с рисками и безопасностью
- Длительные хвосты увеличивают окно атак и ошибки ликвидаций. См. Риски мостов.
- Рост TTE → выше риск double-spend perception и пользовательских ретраев; критична идемпотентность.
- Для ценовых действий сочетайте Streams и он-чейн ленты: Data Streams, Streams vs Feeds, Ценовой оракул.
- При деградации маршрута снижайте лимиты и/или включайте отложенное исполнение крупных сумм.
Таблица SLA-параметров per-route
| Маршрут | P95 TTE цель | P99 TTE цель | Finality (A) | Лимиты per-tx / per-interval | Политика паузы |
|---|---|---|---|---|---|
| ethereum → arbitrum (USDC) | 60 c | 180 c | 18 блоков | 50k / 1m/1h | paused при >2×P99 10 мин |
| solana → base (CCT:XYZ) | 30 c | 90 c | подтверждения 32 | 20k / 200k/1h | only-returns при дисбалансе CCT |
| bsc → polygon (USDT) | 45 c | 120 c | 15 блоков | 30k / 500k/1h | повышаем finality + отложенные «large-tx» |
Эти поля являются частью манифеста в allow-list маршрутов.
Инструментирование и наблюдаемость
- Шлите телеметрию на уровне получателя в B: received, validated, executed, коды статуса.
- Логируйте globalMessageID и ключ маршрута (source/dest/asset).
- Отдельно трекайте retry rate, duplicate hit rate (пойманные повторы), queue length.
- Для «программируемых переводов» — метрики бизнес-шагов (deposit/swap/repay).
- Публикуйте агрегированные дашборды SLA с P50/P95/P99 и причинами отказов.
Плейбук деградации по задержке
- Детект: сработал алерт по P99 TTE или «burn-rate».
- Сужение blast-radius: понижаем лимиты per-tx/per-interval, переводим большие суммы в отложенное исполнение.
- Проверка финальности: повышаем порог подтверждений по маршруту.
- Режимы: paused или only-returns для проблемного маршрута (см. allow-list).
- Коммуникация: статус-страница, ожидаемые окна.
- Ремедиация: анализ очередей/ретраев, перезапуск потребителей, калибровка bucket’ов.
- Пост-мортем: обновление целей, лимитов и процедур.
Практические целевые цифры и анти-паттерны
Ориентиры (от которых отталкиваются при проектировании):
- Платёжные статусы и уведомления: P95 delivery ≤ 15–30 c, P99 ≤ 60–90 c.
- Деривативы/ликвидации: P95 TTE ≤ 20–40 c, P99 ≤ 60–90 c, отдельный SLA для цен.
- Универсальный омничейн: P95 TTE ≤ 60 c, P99 ≤ 180 c.
Анти-паттерны
- Опираться на среднее время вместо P95/P99.
- Считать квантили по «сырым» выборкам без гистограмм — дрейф и шум.
- Сливать все маршруты в одну метрику — теряется диагностика.
- Игнорировать TTL/dedline и возвращать «успех» после дедлайна.
- Запускать паузы «вручную» без автоматических триггеров из SLA.
Чек-листы внедрения
Для протокола/моста
- Определены цели P95/P99 TTE per-route и задокументированы в allow-list.
- Реализованы телеметрия и гистограммы; ведётся журнал globalMessageID.
- Есть алерты по мультиокнам и burn-rate.
- Включены режимы paused/only-returns, удерживаются лимиты.
- Отчёты публикаций: ежедневные P95/P99 и причины хвостов.
Для dApp-интегратора
- Показывается ожидаемое окно доставки/исполнения и статусы.
- Параметры TTL и дедлайнов прокидываются в payload.
- Повторы корректно обрабатываются (см. идемпотентность).
- Для ценовых действий используются Streams + ончейн-якоря.
Пример профиля маршрута в документации
| Поле | Значение |
|---|---|
| Route ID | ethereum:arbitrum:USDC |
| SLO P95 / P99 (TTE) | ≤ 60 c / ≤ 180 c |
| Finality (A) | 18 блоков |
| Limits | 50k per-tx, 1m/1h per-interval |
| Pause policy | >2×P99 10 мин → paused, «крупные» переводы — отложенно |
| Idempotency | журнал globalMessageID → executed/hash |
| Status feed | публичный дашборд SLA |