Quando um ficheiro de funcionalidades derrubou a Internet

Este post explica como pensamos sobre incidentes como a falha da Cloudflare desta semana, por que planos de controlo de contratos inteligentes puros com timelocks mudam os modos de falha, e onde as provas de conhecimento zero se encaixam.

Resumo da falha de terça-feira

Em 18 de novembro de 2025 às 11:20 UTC, a borda da Cloudflare começou a retornar erros 5xx para uma grande parte do tráfego. O gatilho principal não foi um atacante; foi uma alteração de permissões do ClickHouse que fez uma consulta retornar linhas duplicadas. Essa consulta gerou um "arquivo de recursos" de Gestão de Bots enviado para cada servidor de borda a cada poucos minutos.

As duplicatas dobraram o tamanho do arquivo e elevaram a contagem de recursos para mais de 200. O módulo de bot tinha um limite rígido e um unwrap() que entrava em pânico em caso de overflow. À medida que os nós alternavam entre saídas "antigas-boas" e "novas-ruins" a cada cinco minutos, a frota oscilou até que todos os fragmentos fossem atualizados e permanecessem ruins.

A Cloudflare interrompeu o publicador às 14:24, enviou um arquivo do último estado bom conhecido às 14:30, e relatou recuperação completa às 17:06. Os acompanhamentos listados: fortalecer a ingestão de configuração interna, adicionar interruptores globais de emergência e revisar modos de falha em todos os módulos.

Veja o post-mortem da própria Cloudflare para a linha do tempo completa e trechos de código.

Existem dois problemas separados nessa história:

1. Falha do plano de controlo: um gerador emitiu um artefato fora de especificação (duplicatas, muitos recursos, muito grande).
2. Fragilidade do plano de dados: o consumidor travou em vez de degradar graciosamente.

Você ainda corrige o (2) em revisões de código. Mas o (1) é onde as blockchains brilham: como um portão programável e à prova de adulteração na frente das implementações.

"Configuração com prova" numa blockchain pública

Se você comprimir a ideia em uma frase: nenhuma configuração se torna "atual" a menos que um contrato inteligente diga que sim, e o contrato só muda essa flag após um timelock e uma prova de que o artefato obedece a invariantes. Essa única frase implica uma arquitetura completa.

Acontece que blockchains públicas, especialmente construídas sobre Ethereum, as chains EVM executando a Máquina Virtual Ethereum e camada de consenso, oferecem uma boa solução para esse problema.

Um Registro de Configuração on-chain como portão de promoção

• Um contrato inteligente em um EVM rápido e credível (frequentemente um L2) registra cada artefato candidato e compromissos com quaisquer provas.
• As escritas são controladas por um timelock e um multisig; um interruptor de pausa/emergência e um ponteiro de rollback são de primeira classe.
• Apenas hashes ou até mesmo os scripts completos podem ir para a chain. Se off-chain, o blob vive em um armazenamento de objetos, mas fornecerá garantias menores. Uma ótima ideia, se totalmente on-chain não for possível devido ao tamanho, e quando os dados são temporários, é usar blobs EIP-4844. Embora seja um armazenamento separado, você pode combinar um hash verdadeiramente on-chain e um blob com retenção de 18 dias, o que é ótimo para uma janela de rollback contínua.

Ajuste de latência. Ethereum finaliza em épocas, mas L2s confirmam em segundos (OP Stack tem como alvo ~2s; zkSync ~1s; muitos sistemas expõem atestação rápida). É bom o suficiente para cadências de plano de controlo de cinco minutos, veja por exemplo a discussão sobre tempo de bloco OP ou os tempos de atestação do Circle).

Provas obrigatórias: torne o portão inteligente

Anexe uma prova sucinta a cada artefato e verifique-a na chain. É exatamente o que fazemos para nosso protocolo Chainwall, embora para um tipo diferente de dados!

O objetivo principal é provar propriedades básicas: row_count <= 200, ordenado + único por chave, esquema corresponde a regex e regras de tipo, tamanho de arquivo <= N. Você pode ajustar toda a lógica on-chain, ou confiar em circuitos Plonk/Groth para expressões maiores. Por exemplo, um convidado zk-VM pode analisar CSV/Parquet/JSON e emitir um SNARK. Você não precisa revelar o conteúdo, apenas o compromisso. Existem sistemas de pesquisa e produção para regex em ZK (por exemplo, Reef e trabalho relacionado de zk-regex), o que torna as verificações de esquema realistas.

Existem dois caminhos práticos:

• Rota zkVM: Execute seu verificador dentro de um zkVM e verifique recibos na chain; veja contratos verificadores RISC Zero e o encapsulamento de prova on-chain SP1 da Succinct.
• Rota de circuito: Pequenos circuitos fixos para os invariantes acima; para CSV/JSON + regex, você pode combinar gadgets de análise com técnicas zk-regex.

Distribuição que não introduz nova confiança

As bordas consultam o registro e adotam apenas artefatos que estão aprovados na chain. Para evitar confiar em um RPC de terceiros, execute um cliente leve em seu plano de controlo (por exemplo, Helios) ou planeje para a Rede Portal. Dessa forma, as bordas verificam cabeçalhos e provas de inclusão localmente antes de aceitarem qualquer estado "novo atual".

Interruptor de emergência e rollback são apenas bits no contrato, respeitados pela borda. A Cloudflare explicitamente mencionou a necessidade de interruptores globais de emergência mais fortes; colocar esse interruptor em um contrato pequeno e auditado fornece uma única fonte de verdade sob estresse.

Isso realmente teria mudado a falha da CloudFlare?

• O arquivo inflado por duplicatas ultrapassa um limite de contagem/tamanho que é aplicado por uma prova, não por melhor esforço. A promoção falha.
• Mesmo se alguém carregasse manualmente o blob para o armazenamento, as bordas se recusariam a adotá-lo sem a flag "atual" on-chain e verificação de prova.
• Você ainda corrige o pânico no proxy, mas moveu a borda mais afiada do risco para um domínio onde sistemas de prova e timelocks são muito bons.

Por que insistimos em planos de controlo puramente on-chain para ativos digitais

O evento da CloudFlare não foi um ataque, mas inicialmente eles pensaram que sim e isso era de fato provável! Como vimos na segurança de criptomoedas: os atacantes não perseguem apenas chaves; eles coagem o plano de controlo.

• Adulteração de front-end ou UI de assinante: O roubo da Bybit mostrou como manipular o que os assinantes veem pode forçar uma aprovação catastrófica. Análises apontam para phishing e manipulação de UI do fluxo de aprovação de transação, não uma exploração de contrato inteligente. Leia a nota técnica do Grupo NCC e a cobertura do Ledger Insights.
• Autoridade de API de terceiros: SwissBorg/Kiln não foi um bug de solidity; foi um caminho API off-chain que permitiu a um atacante reorganizar autoridades de staking e drenar ~193k SOL como explicado na declaração conjunta da Kiln.
• Do laptop do desenvolvedor às credenciais na nuvem até tudo: Lazarus/TraderTraitor continua provando que máquinas de desenvolvedores comprometidas e fluxos de compilação enganados compram pontos de apoio na nuvem e o poder de dobrar o que a equipe vê e assina. Veja, por exemplo, o aviso da CISA ou a simulação da Elastic sobre como credenciais AWS vazam de máquinas de desenvolvimento.

Conclusão

Nossa posição: o controlo de ativos digitais deve residir em contratos inteligentes protegidos por timelocks e multisigs, não em credenciais privadas, tokens CI, ACLs de nuvem ou painéis de administração. Se sua implantação ou ação de "mudança de proprietário" deve atravessar o caminho schedule() e execute() de um contrato, mesmo um rootkit em um laptop de desenvolvedor não pode furar a fila. O atraso de tempo é um disjuntor com o qual você pode contar, e a trilha de auditoria on-chain é objetiva. Isso deixa apenas a questão "e se a coisa que estamos promovendo estiver malformada?", que é exatamente o que a "configuração com prova" responde.

Também acreditamos que existe um mercado considerável para aplicações com confiança minimizada. Estamos apenas construindo as bases certas agora para um primeiro caso de uso bem definido na OKcontract Labs.

When a Feature File Tripped the Internet foi originalmente publicado em Coinmonks no Medium, onde as pessoas estão continuando a conversa destacando e respondendo a esta história.