Когда файл функций обрушил интернет

Плохой артефакт плоскости управления, хрупкая плоскость данных и ошибки 5xx повсюду

В этой статье рассматривается наш подход к инцидентам, подобным сбою Cloudflare на этой неделе, почему чистые плоскости управления на смарт-контрактах с таймлоками меняют режимы отказа, и где применяются доказательства с нулевым разглашением.

Краткое описание сбоя во вторник

В 18 ноября 2025 года в 11:20 UTC, граничные серверы Cloudflare начали возвращать ошибки 5xx для большой части трафика. Первопричиной был не злоумышленник, а изменение разрешений ClickHouse, из-за которого запрос возвращал дублирующиеся строки. Этот запрос генерировал "файл функций" управления ботами, который отправлялся на каждый граничный сервер каждые несколько минут.

Дубликаты удвоили размер файла и увеличили количество функций более 200. Модуль ботов имел жесткое ограничение и функцию unwrap(), которая аварийно завершалась при переполнении. Поскольку узлы чередовались между выводами "старый-хороший" и "новый-плохой" каждые пять минут, флот колебался, пока все шарды не были обновлены и не остались в плохом состоянии.

Cloudflare остановил издателя в 14:24, отправил последний известный рабочий файл в 14:30 и сообщил о полном восстановлении в 17:06. Перечисленные ими последующие действия: укрепить прием внутренней конфигурации, добавить глобальные выключатели и пересмотреть режимы отказа во всех модулях.

Смотрите собственный посмертный анализ Cloudflare для полной хронологии и фрагментов кода.

В этой истории есть две отдельные проблемы:

1. Сбой плоскости управления: генератор выдал артефакт, не соответствующий спецификации (дубликаты, слишком много функций, слишком большой размер).
2. Хрупкость плоскости данных: потребитель аварийно завершил работу вместо того, чтобы плавно деградировать.

Вы все еще исправляете (2) при проверке кода. Но (1) - это то, где блокчейны блистают: как защищенный от подделки, программируемый шлюз перед развертыванием.

"Конфигурация с доказательствами" на публичном блокчейне

Если сжать идею до одного предложения: никакая конфигурация не становится "текущей", если смарт-контракт не говорит об этом, и контракт переключает этот флаг только после таймлока и доказательства того, что артефакт соблюдает инварианты. Это одно предложение подразумевает полную архитектуру.

Оказывается, публичные блокчейны, особенно построенные на Ethereum, цепочки EVM, работающие на виртуальной машине Ethereum и уровне консенсуса, предлагают хорошее решение этой проблемы.

Реестр конфигурации в цепочке как шлюз продвижения

• Смарт контракт на быстром, надежном EVM (часто L2) записывает каждый кандидатский артефакт и обязательства по любым доказательствам.
• Записи контролируются таймлоком и мультиподписью; пауза/выключатель и указатель отката являются первоклассными.
• Только хэши или даже полные скрипты могут быть размещены в цепочке. Если вне цепочки, блоб живет в хранилище объектов, но предоставляет меньшие гарантии. Отличная идея, если полное размещение в цепочке невозможно из-за размера, и когда данные временные, использовать блобы EIP-4844. Хотя это отдельное хранилище, вы можете объединить действительно онцепочечный хэш и блоб с 18-дневным сроком хранения, что отлично подходит для окна отката.

Соответствие задержки. Ethereum финализирует в эпохах, но L2 подтверждают за секунды (OP Stack нацелен на ~2с; zkSync ~1с; многие системы предоставляют быстрое подтверждение). Этого достаточно для пятиминутных циклов плоскости управления, см., например, обсуждение времени блока OP или сроки подтверждения Circle).

Обязательные доказательства: сделайте шлюз умным

Прикрепите краткое доказательство к каждому артефакту и проверяйте его в цепочке. Именно это мы делаем для нашего протокола Chainwall, хотя для другого типа данных!

Основная цель - доказать базовые свойства: row_count <= 200, отсортировано + уникально по ключу, схема соответствует регулярным выражениям и правилам типов, размер файла <= N. Вы можете либо разместить всю логику в цепочке, либо положиться на схемы Plonk/Groth для более крупных выражений. Например, гость zk-VM может анализировать CSV/Parquet/JSON и выдавать SNARK. Вам не нужно раскрывать содержимое, только обязательство. Существуют как исследовательские, так и производственные системы для регулярных выражений в ZK (например, Reef и связанная работа zk-regex), что делает проверки схемы реалистичными.

Есть два практических пути:

• Путь zkVM: Запустите свой проверочный механизм внутри zkVM и проверяйте квитанции в цепочке; см. контракты верификатора RISC Zero и обертку доказательств SP1 от Succinct в цепочке.
• Путь схемы: Небольшие фиксированные схемы для инвариантов выше; для CSV/JSON + regex вы можете комбинировать гаджеты анализа с техниками zk-regex.

Распределение, которое не вводит новое доверие

Края опрашивают реестр и принимают только артефакты, которые одобрены в цепочке. Чтобы избежать доверия к стороннему RPC, запустите легкий клиент в своей плоскости управления (например, Helios) или планируйте для сети Portal. Таким образом, края проверяют заголовки и доказательства включения локально, прежде чем принять любое "новое текущее" состояние.

Выключатель и откат - это просто биты в контракте, которые соблюдаются на краю. Cloudflare явно указал на необходимость более сильных глобальных выключателей; размещение этого переключателя в небольшом, проверенном контракте дает вам единый источник истины в условиях стресса.

Действительно ли это изменило бы сбой CloudFlare?

• Файл, раздутый дубликатами, превышает ограничение по количеству/размеру, которое обеспечивается доказательством, а не лучшими усилиями. Продвижение не удается.
• Даже если кто-то вручную загрузил блоб в хранилище, края отказались бы принять его без флага "текущий" в цепочке и проверки доказательства.
• Вы все еще исправляете панику в прокси, но вы переместили самый острый край риска в область, где системы доказательств и таймлоки очень хороши.

Почему мы настаиваем на чистых плоскостях управления в цепочке для цифровых активов

Событие CloudFlare не было атакой, но они изначально так думали, и это действительно было вероятно! Как мы видели в безопасности криптовалют: злоумышленники не просто гоняются за ключами; они принуждают плоскость управления.

• Подделка фронтенда или пользовательского интерфейса подписи: Кража Bybit показала, как манипулирование тем, что видят подписывающие, может привести к катастрофическому одобрению. Анализы указывают на фишинг и манипуляцию пользовательским интерфейсом потока одобрения транзакций, а не на эксплуатацию смарт-контракта. Прочитайте техническую заметку NCC Group и освещение от Ledger Insights.
• Авторитет стороннего API: SwissBorg/Kiln не был ошибкой solidity; это был путь API вне цепочки, который позволил злоумышленнику перетасовать органы стейкинга и слить ~193k SOL, как объяснено в совместном заявлении Kiln.
• От ноутбука разработчика до облачных учетных данных и всего остального: Lazarus/TraderTraitor продолжает доказывать, что скомпрометированные машины разработчиков и обманутые потоки сборки покупают вам облачные опоры и возможность изменять то, что команда видит и подписывает. См., например, рекомендации CISA или симуляцию Elastic о том, как учетные данные AWS утекают из коробок разработчиков.

Заключение

Наша позиция: контроль цифровых активов должен находиться в смарт-контрактах, защищенных таймлоками и мультиподписями, а не в частных учетных данных, токенах CI, облачных ACL или административных панелях. Если ваше развертывание или действие "изменить владельца" должно пройти через путь schedule() и execute() контракта, даже руткит на ноутбуке разработчика не может обойти очередь. Временная задержка - это автоматический выключатель, на который вы можете рассчитывать, а аудиторский след в цепочке объективен. Остается только вопрос "что, если продвигаемая вещь искажена?", на который как раз отвечает "конфигурация с доказательствами".

Мы также считаем, что существует значительный рынок для приложений с минимальным доверием. Мы только строим правильные основы сейчас для первого, хорошо определенного случая использования в OKcontract Labs.

---

Когда файл функций споткнул интернет был первоначально опубликован в Coinmonks на Medium, где люди продолжают разговор, выделяя и отвечая на эту историю.