Descoberta de nós e relay criptografado de múltiplos saltos

Os nós da AeroNyx se encontram por meio de descritores assinados e com prazo de validade e podem encaminhar payloads com criptografia de ponta a ponta salto a salto, com cada relay removendo apenas a sua própria camada de criptografia. Hoje, o chat real dos usuários passa por padrão pelo relay central da AeroNyx (RelayWS). Rotear o chat por nós é uma configuração opcional no aplicativo.

O que roda hoje

Caminhos centralizados e descentralizados funcionam lado a lado.

Como a descoberta funciona

Cada nó publica um descritor assinado com a sua chave de identidade Ed25519. Um descritor inclui o ID do nó, os horários de emissão e de expiração, um endpoint público opcional, flags de capacidade (como relay intermediário onion ou relay de chat), indicações aproximadas de capacidade e a chave usada para a criptografia onion. Os nós rejeitam descritores expirados ou com assinatura inválida.

• O gossip é limitado. A troca entre pares tem limite de taxa e é controlada por política, e as mensagens têm limites de tamanho.
• Recuperação após reinício. Um nó mantém um cache local de pares e, após um reinício, recorre aos endpoints semente configurados. Os operadores também podem fixar sementes (veja a seção sobre sementes fixadas).
• Seleção de rota. Somente descritores recentes, com um endpoint utilizável e uma chave onion, são considerados candidatos a relay.

Quais endpoints um descritor pode indicar

Uma assinatura comprova quem publicou um descritor, não que é seguro contatar o seu endpoint. Por isso, um nó aceita apenas duas formas de endpoint:

• um endereço IP público via http ou https; faixas de loopback, privadas, link-local, CGNAT, de documentação, multicast e reservadas são rejeitadas;
• uma URL https:// com um nome DNS público. Nomes de rótulo único, localhost e sufixos privados como .local, .internal e .home.arpa são rejeitados.

Os hostnames são resolvidos no momento da conexão por um resolvedor que descarta todo endereço não público, de modo que um nome não pode ser apontado para o próprio nó, para uma rede privada nem para um serviço de metadados de nuvem. Os clientes entre pares também ignoram configurações de proxy e nunca seguem redirecionamentos.

A forma com hostname existe para que nós sem um endereço IP próprio, como um nó TEE atrás de um gateway de nuvem, possam participar.

Sementes fixadas

Um nó que inicia sem um snapshot do operador confia apenas nas identidades que já possui, então pode acabar confiando somente em si mesmo. Para esse caso, um operador pode indicar a identidade esperada em um endereço:

[discovery]
pinned_seeds = ["<64-hex node id>@<public ip>:<port>"]

• Uma identidade fixada só é aceita pela primeira vez após uma troca por TLS vinculado à identidade fixado a essa identidade.
• Todo descritor posterior de uma identidade fixada, de qualquer origem, deve manter o endereço fixado e anunciar TLS vinculado à identidade.
• A confiança não se propaga: os demais descritores na resposta de uma semente continuam sendo candidatos não confiáveis.
• Uma fixação removida não pode voltar de um cache ou de um backup antigo.

A Directory Chain

Cada nó também mantém um histórico assinado e encadeado por hash dos seus próprios eventos de descritor, chamado de sua Directory Chain. Outros nós podem espelhar esse histórico, buscar objetos de descritor e solicitar provas de inclusão para um descritor específico. Pares fixados pelo operador podem assinar checkpoints de observação sobre os históricos que viram.

Não há ledger global nem coordenador único: cada nó assina o seu próprio histórico, e os outros o espelham e o verificam.

TLS vinculado à identidade

Para alcançar um nó por HTTPS normalmente são necessários um nome de domínio e um certificado de uma autoridade certificadora, e a maioria dos nós da AeroNyx só pode ser alcançada por endereço IP. Em vez disso, um nó comprova o seu próprio endpoint HTTPS com a sua identidade Ed25519.

• Como funciona. O nó cria uma chave TLS ECDSA P-256 comum e um certificado autoassinado. Um nome alternativo do assunto carrega um vínculo, aeronyx-tls-binding:v1:<node id>:<expiry>:<signature>, em que a assinatura é feita pela chave de identidade do nó sobre um resumo com separação de domínio da chave pública do próprio certificado, do ID do nó e da expiração. O handshake TLS 1.3 comprova que o nó possui a chave do certificado. A chave de identidade nunca assina um handshake.
• O que um cliente verifica. Um verificador aceita um certificado apenas para o nó que pretendia alcançar: exatamente um vínculo, o ID de nó esperado, não expirado, com no máximo 31 dias de validade restantes e uma assinatura válida sobre a chave deste certificado. Um certificado emitido por uma autoridade certificadora não satisfaz essa verificação.
• A mesma porta. A porta pública da API (8422/TCP) atende a ambos: uma conexão que começa com um handshake TLS recebe TLS, e qualquer outra recebe HTTP simples como antes. Vem ativado por padrão (discovery.public_api_identity_tls).
• Entre nós. Um nó cujo descritor assinado anuncia o recurso de protocolo anpf1-ibt1 atende TLS vinculado à identidade. Um par que vê esse recurso deve alcançar esse nó por TLS fixado à sua identidade e nunca recorre a HTTP simples. O recurso é coberto pela assinatura do descritor, então um atacante de rede não pode removê-lo para forçar um downgrade. Se várias identidades reivindicam o mesmo endpoint, nenhum endereço TLS é produzido e a requisição falha de forma fechada. Nós antigos sem o recurso, e endpoints de gateway com nome DNS, mantêm o comportamento anterior.
• Referência. Código-fonte e vetores de teste congelados: aeronyx-node-tls.

O efeito é que as informações de rota dos saltos onion, o gossip, a sincronização do diretório e o tráfego de testemunhas entre nós deixam de ser legíveis na rede. O suporte do aplicativo para se conectar aos nós dessa forma está em desenvolvimento.

Como o relay de múltiplos saltos funciona

1. O remetente envolve o payload em uma camada de criptografia por salto, usando a chave onion publicada de cada relay.
2. Cada relay verifica a assinatura, o carimbo de data e hora e o estado de replay do salto anterior, remove a sua própria camada e encaminha o blob opaco restante. Ele nunca vê as camadas internas.
3. O nó final (terminal) repassa a mensagem à caixa de entrada do relay do destinatário (por padrão, o relay central) e, somente depois que o relay a aceita, retorna um recibo assinado. O recibo vincula o ID da rota, um compromisso com o payload, a identidade do nó terminal e o horário de entrega. Ele comprova que a mensagem foi aceita sob custódia do relay, não que o destinatário a leu. Um nó com o repasse desativado mantém a mensagem no seu próprio armazenamento e assina o mesmo tipo de recibo, então o recibo por si só não distingue os dois casos.

O que cada parte vê

Nenhum nó sozinho vincula o seu endereço de rede a quem você está escrevendo. O nó terminal e o relay central veem ambos quem escreveu para quem.

O protocolo aceita no máximo três saltos de relay verificados. A rota de privacidade do aplicativo usa dois. Os limites contra abuso nos relays são descritos em Proteção contra abuso no relay cego.

Chat no aplicativo

• Padrão: as mensagens passam pelo serviço central RelayWS. O conteúdo das mensagens tem criptografia de ponta a ponta, mas o serviço processa os metadados de entrega. Consulte Integração de clientes com o relay de chat.
• Rota de privacidade (opcional, desativada por padrão): quando ela está ativada e uma rota está pronta, o aplicativo envia primeiro as mensagens individuais pela rota onion de dois saltos. Se nenhuma rota onion aceitar a mensagem, o aplicativo a retém no dispositivo e não usa o relay padrão, a menos que você aprove isso para essa mensagem.
• Caixa postal anônima (beta): um envio separado que só funciona enquanto há conexão com a rede de privacidade. As conversas comuns não a utilizam.

Tamanhos das respostas de coleta da caixa postal anônima

Antes, o resultado de uma coleta da caixa postal era uma única imagem fixa de 163.130 bytes, qualquer que fosse o item, então uma mensagem curta custava uma resposta de cerca de 160 KiB. A versão 2 da coleta, negociada pelo recurso de protocolo assinado anpf1-ampc1, preenche o item selado até a menor de cinco classes de tamanho (4.204, 16.492, 65.644 ou 131.180 bytes, ou o máximo do codec). Um item de 4.096 bytes agora trafega como 4.518 bytes.

Nó TEE

Um nó de produção roda dentro de um ambiente de execução confiável da Phala Cloud (dstack sobre Intel TDX). Ele atua apenas como caixa postal anônima e relay onion: a sua VPN está desativada, o MemChain está desligado, e a sua chave de identidade vem do serviço de chaves do dstack. Ele só pode ser acessado por meio de um hostname TLS no gateway, e é por isso que os endpoints de hostname foram adicionados. No momento, o aplicativo não verifica a atestação TEE do nó.

Status em tempo real

O status agregado da rede é publicado em:

GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/

Os agregados de relay e de descoberta aparecem sob data.protocol_status, por exemplo peer_store.blind_relay e peer_store.peer_quorum. Observe dois pontos ao lê-los:

• Os agregados por nó contam apenas nós com heartbeat nos últimos 120 segundos, então um nó offline sai de contagens como protocol_status.reported_nodes. network.total_nodes e network.vpn_nodes continuam contando os nós ativos registrados, estejam online ou não.
• Os contadores de sondagens sintéticas (probe_*, two_hop_probe_*) medem a saúde dos caminhos. Eles não são tráfego de usuários.

A resposta pública contém apenas contagens, faixas de status e carimbos de data e hora. Ela nunca inclui IDs de nós, endpoints, IDs de rotas, payloads, destinatários, endereços IP de clientes, dados de DNS nem arestas do grafo social. Consulte Estatísticas da rede e fronteira de privacidade.

Perguntas frequentes

Minhas mensagens de chat da AeroNyx passam por nós descentralizados?

Não por padrão. As mensagens passam pelo serviço central RelayWS. Você pode ativar a rota de privacidade no aplicativo, que envia as mensagens individuais por uma rota onion de dois saltos através de nós quando uma rota está pronta. Se nenhuma rota aceitar uma mensagem, o aplicativo a retém até que uma rota esteja disponível ou até que você aprove o envio dessa mensagem pelo relay padrão.

Um nó de relay consegue ler as mensagens que encaminha?

Não. Um relay remove apenas a sua própria camada de criptografia e encaminha um blob opaco. Além disso, o conteúdo das mensagens tem criptografia de ponta a ponta entre as pessoas na conversa.

O que é a Directory Chain?

A Directory Chain é o histórico próprio de cada nó, assinado e encadeado por hash, dos seus descritores. Outros nós o espelham e podem solicitar provas de inclusão. Ela não tem coordenador global.

Como um nó atrás de um gateway pode entrar na rede?

Ele pode publicar um hostname https:// como o seu endpoint. Os outros nós resolvem esse nome no momento da conexão e usam apenas endereços públicos, então o nome não pode ser redirecionado para destinos privados ou internos.

Por que a página pública de estatísticas mostra mais nós registrados do que nós online?

network.total_nodes e network.vpn_nodes contam os nós ativos registrados estejam eles online ou não. Compare-os com network.online_vpn_nodes. As contagens de protocolo e de encaminhamento incluem apenas nós com heartbeat recente.

Os nós precisam de um nome de domínio ou de uma autoridade certificadora para HTTPS?

Não. Um nó pode comprovar o seu endpoint HTTPS com a sua própria chave de identidade: o seu certificado TLS carrega uma assinatura da identidade do nó sobre a chave do certificado, e um cliente ou par que conhece o ID do nó pode verificá-la. Os nós atrás de um gateway ainda podem usar um hostname https:// no lugar.

O que um recibo de entrega assinado comprova?

Comprova que o nó terminal aceitou a mensagem sob custódia do relay, na prática a caixa de entrada do relay do destinatário. Não comprova que o destinatário viu ou leu a mensagem. Para isso, use os recibos de entrega e de leitura do protocolo de chat.