Allow-list маршрутов — это публичная политика протокола, которая чётко определяет, какие межсетевые направления A→B разрешены, в каких режимах переноса актива и при каких ограничениях (лимиты, окна финальности, паузы). Такой список — основа канона маршрутов и обязательный элемент безопасной интероперабельности: он ограничивает поверхность риска, упрощает аудит и делает поведение протокола предсказуемым для пользователей.
Allow-list маршрутов тесно связан с архитектурами:
- Каноничный мост — «официальный» путь переноса активов между сетями.
- CCT — омничейн-модель токена с единой линией обращения.
- CCIP — транспорт сообщений и «программируемых переводов» между сетями.
- Программируемый перевод — перенос ценности + вызов логики в целевом домене.
- Интероперабельность — системное проектирование сообщений, активов и данных.
Allow-list маршруты
- Allow-list — это явный список разрешённых маршрутов A→B с параметрами безопасности.
- Для каждого маршрута фиксируются: режим (*burn/mint* или *lock/mint*), лимиты, порог финальности, режимы паузы и политика «только возвраты».
- Политика публикуется как версионируемый манифест и используется контрактами/офчейн-сервисами для валидации.
- SRE-управление опирается на метрики SLA (latency P95/P99, success ratio, retry rate) и плейбуки инцидентов.
Зачем нужен allow-list маршрутов
| Проблема | Что даёт allow-list |
|---|---|
| Фрагментация ликвидности (много «диких» мостов) | Единый канон: один «официальный» путь для актива |
| Непредсказуемый риск (разные финальности/цепочки) | Пер-маршрутные пороги финальности и лимиты |
| Эскалация инцидентов (blast radius) | Быстрое отключение маршрута: «пауза/только возвраты» |
| Неочевидные комиссии и задержки | Публичные параметры SLA и окна доставки |
| Юзабилити-хаос | Предсказуемый UX и статусы по каждому направлению |
Что входит в политику allow-list
| Параметр | Назначение | Пример значения |
|---|---|---|
| source_chain / dest_chain | Откуда и куда разрешён маршрут | ethereum → arbitrum, solana → base |
| token / asset class | Какой актив/класс активов разрешён | USDC, WETH, CCT:XYZ |
| mode | Режим переноса ценности | burn/mint или lock/mint |
| max_tx_amount | Лимит на одну операцию | 50,000 USDC |
| max_interval_amount | Лимит на окно времени | 1,000,000 USDC / 1h |
| finality_threshold | Порог финальности в исходной сети | L1=18 блоков, L2=challenge window 7d |
| deadline/TTL | Максимальное время на доставку/исполнение | 30 мин |
| price_requirements | Условия цены/проскакивания для «программируемых переводов» | slippage ≤ 0.5% |
| pause_state | Текущий режим маршрута | active / paused / only-returns |
| allowed_receivers | Белый список контрактов-получателей (опционально) | vault_X, lending_Y |
| version | Версия манифеста и схемы | v1.3.2 |
Дата-модель манифеста allow-list
Манифест публикуется в репозитории/реестре и дублируется ончейн через геттеры. Ключевые поля:
- route_id — стабильный идентификатор маршрута (source:dest:token).
- policy — объект с mode, лимитами, финальностью, TTL, ценовыми требованиями.
- governance — роли, timelock и процедура обновлений.
- status — active / paused / only-returns.
- updated_at и version — для воспроизводимости и отката.
Требование: манифест должен быть машиночитаемым (для ботов/валидаторов) и человеко-читабельным (для пользователей/аудита).
Взаимодействие с контрактами и транспортом сообщений
Получатель в целевой сети обязан:
- сверить source_chain, sender, route_id с allow-list манифестом;
- проверить режим и лимиты (max_tx_amount, max_interval_amount);
- применить финальность: не исполнять до достижения порога в исходной сети;
- соблюдать TTL/deadline и ценовые условия (если payload зависит от цены);
- поддерживать идемпотентность (см. Идемпотентность): один messageID → один эффект;
- уважать pause_state: в paused — отклонять новые, в only-returns — обрабатывать только возвраты.
Режимы переноса: burn/mint и lock/mint
| Режим | Когда выбирать | Комментарии |
|---|---|---|
| Burn/Mint | Быстрая надёжная финальность в исходной сети | Чистый учёт предложения; меньше кастодиальных рисков |
| Lock/Mint | «Длинная» финальность, особые регуляторные/кастодиальные требования | Нужен аудит «замков», учёт хранителя, повышенная стоимость |
Режим задаётся пер-маршрутно и фиксируется в манифесте allow-list, см. Каноничный мост и CCT.
Лимиты и окна
- Per-tx: ограничивает размер одной операции.
- Per-interval: ограничивает суммарный объём в окне (1h/24h).
- Burst-limit: защищает от «гребка» коротких пиков.
- Large-tx policy: крупные операции исполняются отложенно после дополнительных подтверждений.
Лимиты — основной предохранитель на время инцидента и часть SRE-регламента.
Паузы и режим «только возвраты»
- paused — новые межсетевые операции отклоняются; уже «в полёте» — обрабатываются по правилам.
- only-returns — разрешены только возвраты активов/состояний; новые переводы запрещены.
- resume — постепенное включение по канареечным лимитам и мониторингу SLA.
Эти режимы публикуются в манифесте и дублируются в ончейн-геттерах для фронтов/ботов.
SLA и метрики эксплуатации
Связь allow-list и SLA раскрывается в наборе метрик. Базовый профиль см. в SLA: latency P95/P99; здесь — контур именно маршрутов:
- Latency P50/P95/P99 доставки A→B и «время до исполнено» в B.
- Success ratio успешных доставок/исполнений по маршруту.
- Retry rate и duplicate hit rate (эффективность идемпотентности).
- Queue length: глубина очередей по маршруту.
- Rate-limit triggers: частота/длительность срабатываний лимитов.
- Equivalence drift (для CCT): сводки «сожжено/под замком ↔ сочеканено».
Срыв SLA — повод автоматически понизить лимиты или перевести маршрут в paused/only-returns.
Плейбуки инцидентов для маршрутов
- Деградация транспорта: рост latency/ретраев → понижаем лимиты, включаем отложенное исполнение крупных сумм.
- Аномалия финальности: reorg/длинное окно L2 → повышаем подтверждения, задерживаем «большие» переводы.
- Дисбаланс CCT: расхождение эквивалентности → paused + «только возвраты», ручная сверка.
- Сигнал о компрометации домена: срочная пауза маршрута, отзыв доверия, публикация advisory.
После инцидента — пост-мортем: корректируем allow-list, лимиты, финальность и SLA.
Проектирование UX и документации
- Публикуйте таблицу маршрутов на сайте/в репозитории: сети, токены, режимы, лимиты, финальность, статусы.
- Обновления делайте через версионирование манифеста и timelock на критичные изменения.
- В интерфейсе показывайте ожидаемое окно доставки и текущий status маршрута (active/paused/only-returns).
Пример табличного представления
| Маршрут | Режим | Порог финальности | Per-tx | Per-interval | Статус |
|---|---|---|---|---|---|
| ethereum → arbitrum (USDC) | burn/mint | 18 блоков | 50k | 1m/1h | active |
| solana → base (CCT:XYZ) | lock/mint | L1: 32 блока | 20k | 200k/1h | paused |
| bsc → polygon (USDT) | burn/mint | 15 блоков | 30k | 500k/1h | only-returns |
Интеграция с программируемыми переводами
В сценариях программируемого перевода allow-list задаёт не только путь ценности, но и разрешённые получатели/действия:
- белый список контрактов-получателей (vault/AMM/lending);
- допустимые типы операций (deposit, repay, mint_to, redeem);
- параметры цены/дедлайна для предотвращения «плохых» исполнений.
Идемпотентность и allow-list
Для каждого маршрута требуется строгая идемпотентность:
- журнал globalMessageID → исполнено/хэш;
- no-op на повторы, отказ устаревших версий payload;
- геттер статуса для клиентов и офчейн-сервисов.
Анти-паттерны
- «Разрешены все маршруты» — непредсказуемые траектории, отсутствие контроля риска.
- Скрытые изменения лимитов/финальности — пользователи теряют доверие; фиксируйте version и делайте публичные изменения.
- Нет режима only-returns — во время инцидента продолжаете принимать риск.
- Отсутствие мониторинга P95/P99 — «средние» метрики маскируют хвосты и реальные просадки SLA.
- Не валидируете получателей — уязвимость к «чужим» контрактам в целевой сети.
Чек-лист внедрения allow-list
- Определён канон: сети, токены/классы, режимы переноса.
- Заданы лимиты per-tx/per-interval/burst и пороги финальности.
- Реализованы режимы paused и only-returns, описаны триггеры переходов.
- Манифест машинo/человеко-читабелен, с version и route_id.
- Контракты валидируют маршруты и идемпотентны.
- Дашборды SLA и алерты по маршрутам подключены.
- Плейбуки инцидентов протестированы.
FAQ
Чем allow-list отличается от block-list? Block-list запрещает частные случаи, но по умолчанию «всё остальное разрешено». Allow-list наоборот: по умолчанию запрещено всё, кроме явно разрешённых маршрутов с параметрами.
Можно ли иметь несколько разрешённых мостов для одного маршрута? Технически да, но для UX и ликвидности обычно фиксируют канон — один «официальный» путь. Альтернативы возможны как резерв, но с меньшими лимитами.
Как часто обновлять пороги финальности и лимиты? При изменении риска/нагрузки и по итогам пост-мортемов. Изменения делайте через версионирование и timelock, публикуйте diff.
Что показывать пользователю? Цепочки A→B, режим, ожидаемое окно доставки, текущий статус, лимиты по сумме и по окну, коды причин отказа.