Ledger assinado de compromissos e proteção por testemunhas

AeroNyx opera um ledger assinado e append-only de compromissos para registros MemChain criptografados. Ele prova ordem e integridade, mas a infraestrutura não consegue ler a memória. Não é uma blockchain pública.

Invariante do protocolo: Coordenador, followers, witnesses, backend e site processam apenas compromissos de ciphertext e evidência operacional limitada; nunca recebem memória em texto claro, chaves, relações de proprietários ou grafo social.

Arquitetura atual de produção

Há um coordenador e três nós follower/witness auditados. A inicialização exige 2 de 3 checkpoints assinados e a produção em runtime exige um lease curto 3/3.

observed_at=2026-07-16 · reporting_nodes=4 · coordinator=1 · followers=3 · height=33 · commitments=8,339 · witness_lease=3/3.

client.encrypt_and_sign
  -> coordinator.append_opaque_commitment
  -> follower.verify_signed_ancestry
  -> pinned_witness.retain_checkpoint_and_grant_bounded_lease

Fluxo de escrita e verificação

1. O client criptografa e assina localmente um registro de memória elegível.
2. O coordinator acrescenta apenas o commitment opaco e os metadata de ordenação.
3. Cada append verifica o Block assinado anterior e atualiza um high-water anchor local assinado.
4. Followers obtêm páginas limitadas, verificam ancestry e assinaturas e guardam checkpoint certificates.
5. Um novo commitment Block só é produzido enquanto todos os runtime witnesses configurados concedem a mesma instância de lease curto.

Controles de inicialização e runtime

Dois controles independentes detectam rollback e impedem que coordinators copiados produzam simultaneamente.

• Limite de inicialização: Antes de abrir listeners UDP, TUN ou API, são necessárias provas assinadas válidas de pelo menos dois witnesses distintos entre os três fixados pelo operator.
• Lease de runtime: Os três witnesses configurados devem conceder um lease curto ao coordinator ativo. Renovação parcial fica degraded; a produção nova para quando a autoridade expira.
• Recuperação: Quando a conectividade retorna, uma rodada completa de lease restaura a autoridade de produção e incrementa o contador agregado de recovery.

Comportamento em falhas

Renovação parcial fica degraded e tenta novamente enquanto o lease atual for válido. Ao expirar, a produção de novos compromissos para automaticamente. remote-ahead ou históricos assinados divergentes bloqueiam a inicialização.

renewal_degraded -> retry_until_expiry

expired -> coordinator_lease_production_permitted=false

remote_ahead | diverged -> startup_denied

Observabilidade pública

A API expõe somente agregados: nós verificados, altura tip, compromissos e estado do lease. Não expõe hashes, assinaturas, identidades de witnesses, endpoints, proprietários ou conteúdo.

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

{
  "mode": "signed_commitment_ledger",
  "status": "witness_protected",
  "verified_nodes": 4,
  "coordinator_nodes": 1,
  "follower_nodes": 3,
  "max_verified_tip_height": 33,
  "max_verified_commitment_count": 8339,
  "max_granted_witnesses": 3,
  "max_required_witnesses": 3,
  "network_consensus": "not_claimed"
}

Coordenador, followers, witnesses, backend e site processam apenas compromissos de ciphertext e evidência operacional limitada; nunca recebem memória em texto claro, chaves, relações de proprietários ou grafo social.

Limite de privacidade

O contract central/público exclui record IDs, Block hashes, assinaturas, identity de witness, endpoints, owners, corpos ciphertext, plaintext, routes, client metadata, wallet-level traffic e arestas de social graph. A contagem agregada de commitments prova trabalho do sistema, não o conteúdo ou autor da memória.

O que não é

• Não é consenso permissionless, finalidade bizantina ou fork choice.
• Não é ledger de tokens nem plataforma de smart contracts.
• Não permite que nós leiam memória em texto claro.

Heartbeat

coordinator_lease_state, coordinator_lease_granted_witnesses, coordinator_lease_required_witnesses, coordinator_lease_seconds_remaining, coordinator_lease_production_permitted, coordinator_lease_last_failure_at, coordinator_lease_consecutive_failures, coordinator_lease_recoveries_total.

Perguntas frequentes

A AeroNyx já possui Blocks?

Sim. O subsistema de commitments usa Blocks assinados para ordenar commitments opacos de registros criptografados. Não deve ser descrito como blockchain pública nem como rede de consenso global.

O que ocorre se um witness ficar offline?

A renovação parcial aparece como degraded enquanto a autoridade vigente for válida. Se o lease expirar sem nova concessão de todos os witnesses, a produção de novos commitments para automaticamente.

Um witness consegue ler a memória MemChain?

Não. Ele verifica a estrutura assinada dos commitments e a titularidade do lease, sem receber registros plaintext ou chaves de descriptografia.

Documentação relacionada: MemChain and Decentralized Node Operations.

Verificar o histórico local somente de acréscimo

Todo nó descentralizado AeroNyx atual pode inspecionar seu arquivo append-only local do MemChain sem exibir conteúdo de memória. É uma barreira local de integridade para reinício, upgrade, recuperação de mirror e análise de incidentes.

O que o verificador confere

• Framing canônico e limitado, com no máximo 10 MiB por registro decodificado.
• Cada Fact isolado e cada Fact dentro de um Block corresponde ao fact_id derivado do conteúdo.
• O Merkle root de cada Block corresponde à ordem exata dos identificadores Fact armazenados.
• Blocks consecutivos preservam continuidade de height e do previous-Block hash.
• O arquivo termina em uma fronteira completa; uma cauda física incompleta é informada separadamente.

Comando somente leitura

Execute no caminho configurado ou informe um caminho explícito:

sudo aeronyx-server memchain verify-aof \
  --config /etc/aeronyx/server.toml

sudo aeronyx-server memchain verify-aof \
  --path /var/lib/aeronyx/.memchain

Barreira de upgrade e recuperação

1. Execute verify-aof antes de trocar o binary e guarde o resultado agregado no command audit.
2. Valide o novo binary e execute a mesma leitura antes de reiniciar o serviço.
3. Após o restart, confirme que replay restaurou a mesma height ou superior e rode os health checks.
4. Se um registro completo falhar semanticamente, pare e preserve a evidência; não trunque nem faça merge automático.

Limite da prova

O comando exibe apenas caminho e contagens agregadas. Nunca mostra valores Fact, record ID, Block hash, assinaturas, proprietários, witness identity, endpoints, rotas ou chaves. Um Mirror ou Full node pode validar os mesmos bytes após sincronização sem conhecer a memória criptografada.

A verificação não substitui assinatura de Block, witness certificate, runtime lease, fork choice ou consensus. Um AOF limpo prova integridade estrutural local, não honestidade universal.

Caminhos da implementação:

• crates/aeronyx-server/src/services/memchain/aof.rs
• crates/aeronyx-server/src/main.rs