visão geral do protocolo

Este documento descreve o Protocolo Aevia em nível de visão geral. Define a tese, a arquitetura em camadas, e o conjunto de RFCs normativos que juntos constituem a especificação. Clientes e provider nodes que pretendem ser conformes MUST implementar os RFCs listados em §5 conforme aplicável ao seu papel.

As palavras-chave MUST, SHOULD e MAY são interpretadas conforme RFC 2119.

A tese do protocolo é: persistência não implica distribuição. O protocolo separa duas camadas historicamente colapsadas em plataformas comerciais: (i) a permanência dos bytes (persistência), e (ii) a decisão editorial de recomendar os bytes a uma audiência (distribuição). Esta separação é arquitetural e irreversível em nível de protocolo.

O protocolo é organizado em seis camadas. Uma implementação conforme MUST respeitar a ordem de responsabilidades abaixo:

1. endereçamento (RFC-2) — todo conteúdo é referenciado por CID. URLs opacas não constituem referência canônica.
2. identidade (RFC-3) — toda autoria é provada por assinatura EIP-712 sobre o hash canônico do manifesto.
3. persistência — Content Registry em Base L2 ancora manifestos; provider nodes replicam os bytes referenciados e provam replicação em intervalos de challenge-response.
4. rede — libp2p + DHT Kademlia para discovery; Circuit Relay v2 para peers atrás de NAT; WebTransport para viewers em browser.
5. distribuição (RFC-6) — Risk Score governa feed, ranking e subsídio. A decisão de distribuição é sempre secundária à persistência.
6. governança (RFC-7) — Conselho Ecumênico de 12 assentos detém veto sobre parâmetros. Deliberações são ancoradas no Trust Ledger.

O protocolo preserva os seguintes invariantes. Implementações conformes MUST:

• imutabilidade de CID — nenhum fluxo legítimo do protocolo altera os bytes associados a um CID. Toda revisão de conteúdo gera um novo manifesto com novos CIDs.
• append-only do Registry — manifestos registrados não são deletáveis. Revisões superpõem, não sobrescrevem.
• separação persistência/distribuição — nenhuma decisão editorial (Risk Score, feed, subsídio) altera a disponibilidade dos bytes. Um CID com R(c) alto permanece recuperável via DHT; apenas perde subsídio e ranking.
• verificabilidade offline — manifestos DEVEM ser verificáveis sem network round-trip adicional dado apenas o manifesto, seu CID declarado e o domain separator do protocolo.
• denominação em stablecoin — compensações de provider nodes SÃO denominadas em stablecoin atrelada ao dólar (cUSDC em Base). O protocolo não emite token nativo especulativo.

Ameaças estruturais ao protocolo são tratadas em §10 do whitepaper. Implementações MUST considerar ao menos:

• coerção legal contra Aevia LLC não remove conteúdo on-chain; implementações alternativas continuam a servir mesmo que a cliente canônica seja ordenada a desindexar.
• provider desonesto é derrotado pelo desafio de byte-range dentro de janela apertada (RFC-5 §4).
• Sybil é neutralizado pelo pagamento ser proporcional a byte-horas replicadas, não a número de nós.
• eclipse na DHT é mitigado por refresh de buckets com probing aleatório.
• captura econômica do pool dispara revisão do Conselho (RFC-7).