Uma medição reproduzível de quantos relays do Nostr na verdade compartilham a infraestrutura de uma única empresa — e o que essa decisão realmente implica para um operador.

— @ifuensan / hacknodeslab

TL;DR

  • A descentralização do Nostr costuma ser contada em relays. O número que importa para a resistência à censura é quanta infraestrutura eles compartilham.
  • Em um snapshot de maio de 2026 do nostr.watch com 1.067 relays ativos em clearnet, 28,2% estão por trás do Cloudflare — e o Cloudflare é praticamente a única CDN em uso (CloudFront 0,2%, Fastly 0%). A centralização no Nostr é, quase inteiramente, uma história sobre o Cloudflare.
  • Isso significa que um único evento ao nível do Cloudflare — uma queda de serviço, um bloqueio regional ou uma ordem judicial contra faixas de IP da CF — atinge ~1 em cada 4 relays ativos de uma só vez, sem que ninguém tenha como alvo o Nostr.
  • Pior ainda: para alguns operadores a CDN não oferece proteção alguma. Usando apenas dados públicos e gratuitos (DNS, transparência de certificados, registros de e-mail) e sem chaves de API, recuperei e validei criptograficamente o IP de origem real de 4 dos 185 relays atrás da CF que publicam uma pubkey. Com ferramentas pagas de reconhecimento, esse número é um piso, não um teto.
  • Tudo aqui é reproduzível com dois pequenos scripts em Python e uma lista pública de relays. Refaça isso no cenário atual em menos de trinta minutos.

Por que isso importa

O Nostr é divulgado como uma rede de gossip resistente à censura. A intuição é simples: se há centenas de relays independentes, nenhum ator isolado pode silenciar a rede. Mas “independentes” carrega muito peso nessa frase. Dois relays com domínios diferentes, operadores diferentes e pubkeys diferentes não são independentes se ambos terminam por trás da mesma borda do Cloudflare. Uma única decisão nessa borda derruba os dois simultaneamente.

Isso não é hipotético. No caso em andamento da LaLiga na Espanha, tribunais comerciais ordenaram que provedores bloqueiem faixas de IP do Cloudflare durante partidas de futebol — na ordem de ~3.000 IPs por rodada, derrubando colateralmente mais de 13.500 sites não relacionados (incluindo, em um caso amplamente noticiado, o serviço público de saúde Madrid Salud). A ordem nunca menciona o Nostr. Não precisa: se ~1 em cada 4 relays ativos responde em um IP do Cloudflare, um usuário espanhol perde um quarto da rede durante a duração de uma partida, como dano colateral.

A contagem de relays diz que a rede é descentralizada. A infraestrutura diz que uma fatia significativa dela tem um ponto único de falha compartilhado e exposto a jurisdições. Este artigo quantifica essa lacuna e nomeia o trade-off com precisão.

Passo 1 — Quantos relays se escondem atrás de uma CDN?

Método. Pegue uma lista de relays, resolva cada hostname para seus registros A/AAAA e verifique cada IP contra as faixas de endereços publicadas das principais CDNs:

  • Cloudflare — https://www.cloudflare.com/ips-v4 + ips-v6
  • CloudFront — https://ip-ranges.amazonaws.com/ip-ranges.json (service=CLOUDFRONT)
  • Fastly — https://api.fastly.com/public-ip-list

Sem sondagem, sem exploração — apenas resolução de DNS e uma verificação de faixa. Os snapshots das faixas das CDNs são armazenados em cache para que um terceiro possa reproduzir exatamente os veredictos. A ferramenta é check_cf.py.

Entrada. Uma exportação xlsx do nostr.watch (nw-relays-all-20260503.xlsx), filtrada para o conjunto de relays ativos (in_rstate=True) e somente clearnet — 1.079 hosts únicos, dos quais 1.067 resolveram. A exportação não filtrada é dominada por relays mortos há muito tempo e infla o denominador; o subconjunto ativo-clearnet é a população honesta.

Resultado (snapshot de maio de 2026):

VeredictoContagem% dos resolvidos
cloudflare30128,2%
cloudfront20,2%
fastly00%
direct76471,6%
dns_error12—

~28% dos relays ativos estão por trás de uma CDN, e essa CDN é o Cloudflare. Adicionar CloudFront e Fastly quase não muda nada. Então, para tudo o que se segue, “atrás do Cloudflare” e “atrás de uma CDN” são efetivamente a mesma pergunta.

Passo 2 — A CDN realmente esconde a origem?

Estar por trás do Cloudflare só é protetor se o seu IP de servidor real permanecer secreto. Se um adversário consegue encontrar a origem, ele pode atacá-la ou bloqueá-la diretamente e a CDN se torna decorativa. Então a segunda pergunta é: para um relay atrás da CF, o IP de origem pode ser recuperado apenas a partir de dados públicos — e comprovado como correto?

Fontes candidatas (gratuitas, sem chaves de API):

  1. DNS direto — o domínio apex e subdomínios irmãos comuns (ssh., mail., direct., origin., …). Os operadores rotineiramente colocam o relay atrás do Cloudflare, mas deixam o apex ou um subdomínio de administração apontando diretamente para a máquina.
  2. Transparência de Certificados (crt.sh) — hostnames irmãos na mesma cadeia de certificados, depois resolvidos.
  3. Tokens ip4: de SPF / TXT — configuração de e-mail que nomeia o IP do servidor.
  4. Hosts MX — o servidor de e-mail muitas vezes roda na mesma máquina que o relay.

As consultas DNS para TXT/MX e nomes de CT passam por DNS-over-HTTPS (a API JSON do 1.1.1.1), de modo que toda a ferramenta permanece apenas com a biblioteca padrão e reproduzível sem qualquer conta. Qualquer IP candidato que caia dentro das faixas publicadas do Cloudflare é descartado — esse é o front, não a origem.

Validação — a parte que torna isto evidência, não um palpite. Cada relay Nostr pode servir um documento NIP-11, e muitos incluem a pubkey do operador. Para cada IP candidato, a ferramenta abre uma conexão TLS para esse IP mantendo o SNI/Host definido para o hostname real do relay (o padrão curl --resolve), busca o documento NIP-11 e compara sua pubkey com a que é servida através do front do Cloudflare. Se as pubkeys coincidem, a origem é confirmada criptograficamente — não inferida a partir de ASN, geografia ou um palpite. Quando um relay não publica uma pubkey, a ferramenta recorre a uma impressão digital estrutural (nome + software + NIPs suportados ordenados + contato) e reporta isso como uma correspondência “provável” mais fraca. A ferramenta é find_origin.py.

Um caso passo a passo (anonimizado: “Relay A”)

Conforme a prática de divulgação responsável, o relay e seu IP de origem são omitidos aqui. O método é totalmente reproduzível contra o seu próprio relay.

O Relay A é um relay khatru servido em relay-a.example e respondendo em um IP do Cloudflare — pela medição do Passo 1, ele está “atrás de uma CDN”.

Executando find_origin.py relay-a.example:

  1. A ferramenta busca o NIP-11 do Relay A através do front do Cloudflare e registra a pubkey de referência (uma chave de 64 caracteres hexadecimais).
  2. Ela reúne IPs candidatos. O domínio apex do Relay A e um subdomínio ssh. resolvem ambos para um único IP em um provedor de nuvem de baixo custo — fora das faixas do Cloudflare. O operador colocou o subdomínio do relay atrás do front, mas deixou o resto da zona apontando para a máquina real.
  3. A ferramenta conecta-se a esse IP candidato com SNI/Host definido para relay-a.example, busca o documento NIP-11 e lê sua pubkey.
  4. A pubkey é idêntica à servida via Cloudflare. Origem confirmada.

Tempo total decorrido: alguns segundos. Sem exploração, sem varredura de portas — apenas DNS público e um único HTTPS GET. Para o Relay A, o front do Cloudflare não protege nada: a origem está a um dig de distância.

Quão difundido é isso?

Entre os 185 relays atrás da CF que publicam uma pubkey ativa (o subconjunto criptograficamente validável dos 301), a varredura de fontes gratuitas confirmou a origem verdadeira de 4 relays em 3 operadores — 2,2%, via dois vetores de vazamento distintos:

  • Vazamento de DNS — o apex / um subdomínio irmão aponta diretamente para a origem (o vetor do Relay A).
  • Vazamento de e-mail — o host MX do relay resolve para a mesma máquina que roda o relay.

2,2% é um piso, e um piso honesto. Conta apenas origens comprováveis a partir de dados gratuitos, apenas em relays que publicam uma pubkey, em um único snapshot. Adicione reconhecimento pago (Censys, Shodan, DNS histórico do ZoomEye) e a fração recuperável aumenta. O ponto não é a porcentagem exata — é que para uma fatia não trivial de operadores de relay, a CDN fornece o custo e a complexidade do Cloudflare sem nenhuma da proteção de origem que isso implica.

O trade-off, nomeado

Colocar um relay atrás do Cloudflare é uma decisão de engenharia real com vantagens reais. Vale a pena ser preciso sobre contra qual adversário isso ajuda e a qual ele silenciosamente entrega mais poder.

Contra o que o Cloudflare protege você:

  • DDoS volumétrico — absorvido na borda antes de chegar à sua máquina.
  • Exposição casual da origem — o IP do seu servidor não está no registro A do relay, então o atacante mais preguiçoso não consegue encontrá-lo (até que DNS/e-mail/CT o vazem — veja acima).
  • Trabalho operacional — TLS, cache e um front anycast global de graça.

A que o Cloudflare expõe você — e esta é a parte que o marketing omite:

  • Bloqueio jurisdicional pelo qual você não optou. Uma ordem judicial contra as faixas do Cloudflare em qualquer jurisdição derruba o seu relay ali, mesmo que a ordem tenha sido voltada para a pirataria de futebol. Você herda toda briga em que o espaço de endereços do Cloudflare está envolvido.
  • Falha correlacionada. Você não é mais um relay independente; você é um de ~300 que compartilham um destino. A matemática de resiliência da rede é construída sobre uma independência que não existe.
  • Um único ponto de estrangulamento de moderação/desplataformização. A decisão de termos de serviço de uma única empresa pode remover um quarto da borda da rede ativa em uma única ação.

E para os operadores que vazam, o pior caso: a desvantagem sem a vantagem. Sua origem é pública, então eles obtêm a exposição jurisdicional e o risco de falha correlacionada de estar atrás do Cloudflare, enquanto um atacante que quer derrubar o relay específico deles simplesmente tem como alvo a origem diretamente.

Isto não é um argumento de que operadores de relay não deveriam usar o Cloudflare. É um argumento de que a escolha é um trade-off contra um modelo de ameaça específico, não uma vitória gratuita — e que uma rede cuja história de resistência à censura depende da contagem de relays deveria saber que ~1 em cada 4 desses relays responde à porta da mesma empresa.

Reproduza você mesmo

Todo o ferramental é código aberto — hacknodeslab/nostr-cf-recon:

python3 -m venv .venv
.venv/bin/pip install rich openpyxl

# 1. A partir de uma exportação xlsx fresca do nostr.watch, extraia os relays ativos em clearnet:
.venv/bin/python extract_relays.py nw-relays-all-YYYYMMDD.xlsx relays.txt --online --clearnet

# 2. Meça a presença de CDN (Passo 1):
.venv/bin/python check_cf.py relays.txt --json out.json

# 3. Tente desmascarar a origem de um relay (Passo 2):
.venv/bin/python find_origin.py <some-cf-fronted-relay-host>

Se uma nova ordem de bloqueio no formato da LaLiga aparecer, refaça o Passo 1 contra a lista atual de relays para quantificar o impacto colateral no mesmo dia sobre o Nostr.

Limites do método e ética

  • Apenas dados públicos. Sem exploração, sem bypass de autenticação, sem varredura de portas, sem sondagem além da resolução de DNS padrão e de um HTTPS GET contra endpoints públicos NIP-11. A validação no estilo --resolve conecta-se a um IP candidato que já está publicado no DNS.
  • Reprodutibilidade é obrigatória. As entradas, os snapshots das faixas das CDNs e os veredictos por host são persistidos para que um terceiro possa reexecutar de ponta a ponta.
  • Sem doxxing de operadores. O resultado do desmascaramento é evidência metodológica, apresentada de forma anonimizada. Os vazamentos de origem confirmados foram divulgados privadamente aos operadores afetados; este artigo não nomeia nenhum mapeamento de relay para IP.
  • Snapshot, não vigilância. Esta é uma medição pontual de uma lista pública de relays, não um monitoramento contínuo de qualquer operador.

Ferramentas: check_cf.py (Passo 1), find_origin.py (Passo 2), extract_relays.py. Inspirado em técnica de reconhecimento anti-Cloudflare do CF-Hero; aqui usado apenas para medir um trade-off de centralização, não para atacar. Código completo: github.com/hacknodeslab/nostr-cf-recon.