Quand un fichier de fonctionnalités a fait trébucher l'Internet

Un mauvais artefact de plan de contrôle, un plan de données fragile et des 5xx partout

Ce post explique comment nous réfléchissons aux incidents comme la panne de Cloudflare cette semaine, pourquoi les plans de contrôle basés uniquement sur des Smart Contracts avec timelocks modifient les modes de défaillance, et où les preuves à divulgation nulle de connaissance s'intègrent.

Résumé de la panne de mardi

Le 18 novembre 2025 à 11h20 (UTC), l'infrastructure edge de Cloudflare a commencé à renvoyer des erreurs 5xx pour une grande partie du trafic. La cause première n'était pas une attaque, mais un changement de permissions ClickHouse qui a fait qu'une requête renvoie des lignes en double. Cette requête générait un "fichier de fonctionnalités" de gestion des bots envoyé à chaque serveur edge toutes les quelques minutes.

Les doublons ont doublé la taille du fichier et fait passer le nombre de fonctionnalités au-delà de 200. Le module de bots avait une limite stricte et un unwrap() qui paniquait en cas de dépassement. Comme les nœuds alternaient entre les sorties "anciennes-bonnes" et "nouvelles-mauvaises" toutes les cinq minutes, la flotte oscillait jusqu'à ce que tous les shards soient mis à jour et restent dans un état défectueux.

Cloudflare a arrêté le système de publication à 14h24, a déployé un dernier fichier connu comme fonctionnel à 14h30, et a signalé une récupération complète à 17h06. Les suivis qu'ils ont listés : renforcer l'ingestion de la configuration interne, ajouter des interrupteurs d'arrêt globaux et revoir les modes de défaillance dans tous les modules.

Consultez le post-mortem de Cloudflare pour la chronologie complète et les extraits de code.

Il y a deux problèmes distincts dans cette histoire :

1. Défaillance du plan de contrôle : un générateur a émis un artefact non conforme aux spécifications (doublons, trop de fonctionnalités, trop volumineux).
2. Fragilité du plan de données : le consommateur s'est planté au lieu de se dégrader gracieusement.

Vous corrigez toujours (2) dans les revues de code. Mais (1) est là où les blockchains excellent : comme une barrière programmable et inviolable devant les déploiements.

"Configuration avec preuve" sur une blockchain publique

Si vous compressez l'idée en une phrase : aucune configuration ne devient "actuelle" sans l'accord d'un smart contract, et le contrat ne bascule ce drapeau qu'après un timelock et une preuve que l'artefact respecte les invariants. Cette seule phrase implique une architecture complète.

Il s'avère que les blockchains publiques, en particulier celles construites sur Ethereum, les chaînes EVM exécutant la Machine Virtuelle Ethereum et la couche de consensus, offrent une bonne solution à ce problème.

Un Registre de Configuration on-chain comme porte de promotion

• Un smart contract sur un EVM rapide et crédible (souvent une L2) enregistre chaque artefact candidat et les engagements pour toutes les preuves.
• Les écritures sont contrôlées par un timelock et une multisig ; un interrupteur de pause/arrêt et un pointeur de rollback sont de première classe.
• Seuls les hachages ou même les scripts complets peuvent être mis on-chain. Si off-chain, le blob vit dans un stockage d'objets mais fournira des garanties moindres. Une excellente idée si le stockage entièrement on-chain n'est pas possible en raison de la taille, et lorsque les données sont temporaires, est d'utiliser les blobs EIP-4844. Bien qu'il s'agisse d'un stockage séparé, vous pouvez associer un véritable hash on-chain et un blob avec une rétention de 18 jours, ce qui est idéal pour une fenêtre de rollback continue.

Adaptation de la latence. Ethereum finalise par époques, mais les L2 confirment en secondes (OP Stack vise ~2s ; zkSync ~1s ; de nombreux systèmes exposent une attestation rapide). C'est suffisant pour des cadences de plan de contrôle de cinq minutes, voir par exemple la discussion sur le temps de bloc OP ou les délais d'attestation de Circle).

Preuves obligatoires : rendre la porte intelligente

Attachez une preuve succincte à chaque artefact et vérifiez-la on-chain. C'est exactement ce que nous faisons pour notre protocole Chainwall, bien que pour un type de données différent !

L'objectif principal est de prouver des propriétés de base : row_count <= 200, trié + unique par clé, schéma correspondant aux règles regex et de type, taille de fichier <= N. Vous pouvez soit intégrer toute la logique on-chain, soit vous appuyer sur des circuits Plonk/Groth pour des expressions plus importantes. Par exemple, un invité zk-VM peut analyser CSV/Parquet/JSON et émettre un SNARK. Vous n'avez pas à révéler le contenu, seulement l'engagement. Des systèmes de recherche et de production pour regex en ZK existent (par exemple, Reef et les travaux connexes sur zk-regex), ce qui rend les vérifications de schéma réalistes.

Il y a deux voies pratiques :

• Route zkVM : Exécutez votre vérificateur dans un zkVM et vérifiez les reçus on-chain ; voir les contrats de vérification RISC Zero et l'encapsulation de preuve on-chain SP1 de Succinct.
• Route des circuits : Petits circuits fixes pour les invariants ci-dessus ; pour CSV/JSON + regex, vous pouvez combiner des gadgets d'analyse avec des techniques zk-regex.

Distribution qui n'introduit pas de nouvelle confiance

Les edges interrogent le registre et n'adoptent que les artefacts qui sont validés on-chain. Pour éviter de faire confiance à un RPC tiers, exécutez un client léger dans votre plan de contrôle (par exemple, Helios) ou planifiez pour le Portal Network. De cette façon, les edges vérifient localement les en-têtes et les preuves d'inclusion avant d'accepter tout nouvel état "actuel".

L'interrupteur d'arrêt et le rollback ne sont que des bits dans le contrat, respectés par l'edge. Cloudflare a explicitement souligné la nécessité d'interrupteurs d'arrêt globaux plus robustes ; placer cet interrupteur dans un petit contrat audité vous donne une source unique de vérité sous pression.

Cela aurait-il vraiment changé le problème de CloudFlare ?

• Le fichier gonflé par les doublons dépasse une limite de nombre/taille qui est appliquée par une preuve, et non par un effort optimal. La promotion échoue.
• Même si quelqu'un téléchargeait manuellement le blob dans le stockage, les edges refuseraient de l'adopter sans le drapeau "actuel" on-chain et la vérification de la preuve.
• Vous corrigez toujours la panique dans le proxy, mais vous avez déplacé le bord le plus tranchant du risque vers un domaine où les systèmes de preuve et les timelocks sont très efficaces.

Pourquoi nous insistons sur des plans de contrôle purement on-chain pour les actifs numériques

L'événement CloudFlare n'était pas une attaque, mais ils l'ont initialement pensé et c'était en effet probable ! Comme nous l'avons vu dans la sécurité crypto : les attaquants ne se contentent pas de poursuivre les clés ; ils contraignent le plan de contrôle.

• Falsification du front-end ou de l'interface utilisateur du signataire : Le vol Bybit a montré comment manipuler ce que les signataires voient peut faire passer une approbation catastrophique. Les analyses pointent vers le phishing et la manipulation de l'interface utilisateur du flux d'approbation des transactions, et non vers une exploitation de smart contract. Lisez la note technique du NCC Group et la couverture de Ledger Insights.
• Autorité API tierce : SwissBorg/Kiln n'était pas un bug de solidity ; c'était un chemin API off-chain qui permettait à un attaquant de réorganiser les autorités de staking et de drainer ~193k SOL comme expliqué dans la déclaration conjointe de Kiln.
• Du laptop du développeur aux identifiants cloud à tout : Lazarus/TraderTraitor continue de prouver que les machines de développeurs compromises et les flux de construction piégés vous achètent des points d'appui dans le cloud et le pouvoir de plier ce que l'équipe voit et signe. Voir par exemple l'avis du CISA ou la simulation d'Elastic sur la façon dont les identifiants AWS fuient des machines de développement.

Conclusion

Notre position : le contrôle des actifs numériques doit résider dans des smart contracts protégés par des timelocks et des multisigs, et non dans des identifiants privés, des jetons CI, des ACL cloud ou des tableaux de bord d'administration. Si votre déploiement ou action de "changement de propriétaire" doit traverser le chemin schedule() et execute() d'un contrat, même un rootkit sur un laptop de développeur ne peut pas sauter la file d'attente. Le délai est un disjoncteur sur lequel vous pouvez compter, et la piste d'audit on-chain est objective. Cela ne laisse que la question "et si ce que nous promouvons est mal formé ?", ce à quoi répond exactement la "configuration avec preuve".

Nous croyons également qu'il existe un marché considérable pour les applications à confiance minimisée. Nous ne construisons que les bonnes fondations maintenant pour un premier cas d'utilisation bien défini chez OKcontract Labs.

---

When a Feature File Tripped the Internet a été initialement publié dans Coinmonks sur Medium, où les gens continuent la conversation en mettant en évidence et en répondant à cette histoire.