Axiom: Protocolo de Comunicação Descentralizado e Resistente à Censura

🚀 Detalhes da Implantação ao Vivo

• Rede: Arbitrum One (Mainnet L2)
• Chain ID: 42161
• Endpoint RPC: https://arb1.arbitrum.io/rpc (ou qualquer endpoint Alchemy/Infura personalizado)
• Endereço do Contrato Proxy Axiom: 0xc11CFf8111e8b1F055eba095Efb679a38Abe6b63

(Nota: A Axiom usa uma arquitetura de Proxy Atualizável UUPS. Todas as interações dos clientes devem sempre ser direcionadas a este endereço de Proxy, nunca ao contrato de implementação subjacente).

📖 Como Ler Dados (Indexador / Clientes)

Os clientes nunca devem tentar ler as postagens do protocolo diretamente das variáveis de estado do contrato inteligente (como preservar gás é uma prioridade, o conteúdo não é armazenado no estado). Em vez disso, os clientes devem indexar os eventos da blockchain.

✍️ Como Publicar Dados (Submissão de Tx do Cliente)

Para publicar dados no Protocolo, os clientes devem enviar uma transação on-chain chamando a função publishAxiom no contrato Proxy.

---

O objetivo da Axiom é fornecer uma plataforma de mídia social completamente anônima, descentralizada e resistente à censura.

Para tornar isso possível, a arquitetura é estritamente dividida: a base (o protocolo) e os clientes (o software). Este repositório define essa base—um contrato inteligente e uma estrutura de dados padronizada em uma rede Ethereum Layer 2.

Escopo do Projeto

O protocolo estabelece a base da plataforma:

• Convenção de Nomenclatura Padrão: Uma estrutura clara definindo como os payloads são enviados ao contrato inteligente e como os clientes os leem.
• Imutabilidade: A blockchain serve como um banco de dados à prova de falhas e de adulteração.
• Foco em Microblogging: O protocolo não é projetado para grandes quantidades de dados on-chain, mas segue o conceito tradicional de microblogging (postagens curtas). Arquivos de mídia não são armazenados nativamente na chain; em vez disso, são incorporados via links externos quando necessário.
• Proteção Anti-Spam: Taxas de transação e uma taxa de entrada única e baixa para a primeira postagem de uma carteira impedem ataques de inchaço de estado por botnets.
• Roteamento de Segurança: O protocolo impõe a separação OPSEC de mensagens com base em requisitos específicos de segurança.

---

Níveis de Segurança do Protocolo

A Axiom é projetada para permitir a verdadeira liberdade de expressão para usuários em países onde a comunicação é restrita. O protocolo distingue três níveis de segurança. Ele assume que os usuários sabem qual nível de segurança é apropriado para sua situação específica.

• Nível 1: Aberto A comunicação ocorre abertamente em texto puro na blockchain. Todos os clientes podem ler e processar todo o tráfego. Incorporar links (por exemplo, para imagens através de provedores terceiros) é permitido neste nível. A expectativa é que a comunicação padrão de mídia social ocorra aqui—incluindo fotos engraçadas de gatos. Isso gera ruído importante dentro da rede. É menos seguro em relação ao rastreamento IP puro, mas as postagens permanecem totalmente incorruptíveis.
• Nível 2: Fechado Este nível é destinado a segurança estrita. Ele suporta exclusivamente mensagens de texto puro. O protocolo proíbe links de mídia aqui para descartar tecnicamente qualquer vazamento de IP quando os clientes carregam conteúdo externo. Os usuários devem garantir de forma independente que adquiram a criptomoeda usada para taxas de gás anonimamente.
• Nível 3: Criptografado Construído para máxima privacidade. As próprias mensagens são criptografadas com AES-256-GCM antes de serem enviadas. Apenas metadados, o vetor de inicialização (IV) e o texto cifrado são armazenados na blockchain. Apenas clientes de usuários que possuem a chave criptográfica correta podem descriptografar e ler essas mensagens.

Segurança de Rede e Rastreamento IP (Regra Rígida)

Para todos os níveis, o Onion Routing (por exemplo, Tor) é estritamente obrigatório. Comunicar-se com provedores RPC comerciais (como Infura ou Alchemy) vaza o endereço IP do remetente em texto puro. Para fechar vulnerabilidades de OPSEC potencialmente fatais para dissidentes, os clientes são obrigados a rotear transações para os nós RPC exclusivamente através da rede Tor.

---

Padrões de Criptografia (Para Nível 3)

Para mensagens no Nível 3, todos os clientes devem aderir estritamente aos seguintes padrões criptográficos para garantir interoperabilidade e evitar comprometer a segurança.

1. Algoritmo de Criptografia: AES-256-GCM Todos os payloads de Nível 3 devem ser criptografados simetricamente usando AES no modo GCM com um comprimento de chave de 256 bits. O vetor de inicialização (IV/Nonce) deve ser gerado novamente aleatoriamente para cada mensagem individual e é escrito na blockchain como metadados em texto puro. Isso evita o reconhecimento de padrões por observadores externos.
2. Derivação de Chave: Argon2id Os usuários inserem senhas legíveis por humanos em seus clientes. Estas nunca devem ser usadas diretamente como chaves AES. Os clientes são estritamente obrigados a usar o algoritmo de hash Argon2id. (Nota: Os desenvolvedores devem definir parâmetros fixos para iterações e uso de memória dentro do cliente para que todos gerem exatamente a mesma chave).
3. Troca de Chave: Fora de Banda A Axiom não lida com trocas de chave on-chain. O protocolo não armazena chaves públicas. Trocar a senha (segredo compartilhado) para um canal específico é responsabilidade dos usuários e deve ocorrer fora da rede (por exemplo, pessoalmente).
4. Integridade dos Dados AES-GCM gera uma Tag de Autenticação. Os clientes devem validar esta tag. Se a validação falhar, o cliente deve descartar silenciosamente a mensagem (drop).

---

Estrutura de Dados, Entrega de Payload e Indexação

A Axiom utiliza uma entrega de payload híbrida (Divisão ABI). Para evitar que o contrato inteligente tenha que descompactar formatos de dados caros, os dados são separados antes da transmissão:

1. Variáveis Lógicas: O nível (uint8 _level) e o vetor de inicialização (bytes _iv) são passados como parâmetros diretos para o contrato inteligente, pois ele os necessita para aplicar suas regras de segurança.
2. Dados Opacos: O conteúdo real da mensagem é construído internamente pelo cliente como JSON e comprimido em CBOR (Concise Binary Object Representation). O contrato lida com este pacote CBOR "cegamente" e o encaminha diretamente para o registro de eventos.

Chaves do Payload (Estrutura CBOR)

A Axiom usa letras únicas como chaves para economizar bytes. O autor (msg.sender) e o timestamp (block.timestamp) são omitidos, pois o contrato inteligente extrai esses valores de forma à prova de adulteração.

• t (Tipo): Inteiro. O tipo de ação.
• c (Conteúdo): String/Bytes. O texto, nome ou texto cifrado.
• h (Hashtags/Tags): Array. Opcional. Usado para categorização (subcanais).
• m (Dica de Mensagem): Bytes (comprimento de 2). Apenas Nível 3. Um hash HMAC de 2 bytes usado para agrupamento difuso (fuzzy bucketing).
• r (Resposta a): Bytes. Opcional. O hash da transação de uma postagem referenciada.

Tipos de Ação (t Field)

• 0 = Atualização de Perfil (Vincula o endereço da carteira a um nome legível no campo c)
• 1 = Postagem (Mensagem padrão)
• 2 = Resposta (r requer o hash da postagem original)
• 3 = Curtir (r requer o hash da postagem)
• 4 = Descurtir (Reverte o Tipo 3)
• 5 = Retweet / Repostagem (r requer o hash da postagem)
• 6 = Desfazer Retweet (Reverte o Tipo 5)

Subcanais e Roteamento Escuro (h Field)