Axiom: Protocollo di Comunicazione Decentralizzato e Resistente alla Censura
🚀 Dettagli del Deployment dal Vivo
- Rete: Arbitrum One (Mainnet L2)
- Chain ID:
42161
- Endpoint RPC:
https://arb1.arbitrum.io/rpc (o qualsiasi endpoint personalizzato Alchemy/Infura)
- Indirizzo del Contratto Proxy Axiom:
0xc11CFf8111e8b1F055eba095Efb679a38Abe6b63
(Nota: Axiom utilizza un'architettura di Proxy UUPS Upgradeable. Tutte le interazioni dei client devono sempre essere dirette verso questo indirizzo Proxy, mai verso il contratto di implementazione sottostante).
📖 Come Leggere i Dati (Indicizzatori / Client)
I client non devono mai tentare di leggere i post del protocollo direttamente dalle variabili di stato del contratto intelligente (poiché preservare il gas è una priorità, il contenuto non è memorizzato nello stato). Invece, i client devono indicizzare gli eventi della blockchain.
✍️ Come Pubblicare Dati (Invio di Transazioni del Client)
Per pubblicare dati nel Protocollo, i client devono inviare una transazione on-chain chiamando la funzione publishAxiom sul contratto Proxy.
L'obiettivo di Axiom è fornire una piattaforma di social media completamente anonima, decentralizzata e resistente alla censura.
Per renderlo possibile, l'architettura è rigorosamente divisa: le fondamenta (il protocollo) e i client (il software). Questo repository definisce quelle fondamenta—un contratto intelligente e una struttura dati standardizzata su una rete Ethereum Layer 2.
Ambito del Progetto
Il protocollo stabilisce le fondamenta della piattaforma:
- Convenzione di Denominazione Standard: Una struttura chiara che definisce come i payload vengono inviati al contratto intelligente e come i client li leggono.
- Immutabilità: La blockchain funge da database a prova di manomissione e fail-safe.
- Focus sul Microblogging: Il protocollo non è progettato per grandi quantità di dati on-chain, ma segue piuttosto il concetto tradizionale di microblogging (post brevi). I file multimediali non sono memorizzati nativamente sulla catena; vengono invece incorporati tramite link esterni quando necessario.
- Protezione dallo Spam: Le commissioni di transazione e una commissione di ingresso bassa e una tantum per il primo post di un wallet prevengono attacchi di rigonfiamento dello stato da parte di botnet.
- Routing di Sicurezza: Il protocollo impone la separazione OPSEC dei messaggi in base a specifici requisiti di sicurezza.
Livelli di Sicurezza del Protocollo
Axiom è progettato per consentire la vera libertà di parola per gli utenti in paesi dove la comunicazione è limitata. Il protocollo distingue tra tre livelli di sicurezza. Presuppone che gli utenti sappiano quale livello di sicurezza è appropriato per la loro situazione specifica.
- Livello 1: Aperto
La comunicazione avviene apertamente in testo semplice sulla blockchain. Tutti i client possono leggere ed elaborare tutto il traffico. L'incorporamento di link (ad esempio per immagini tramite provider terzi) è consentito a questo livello. Ci si aspetta che qui avvenga la comunicazione standard dei social media—incluse foto divertenti di gatti. Questo genera rumore importante all'interno della rete. È meno sicuro per quanto riguarda il puro tracciamento IP, ma i post rimangono completamente non censurabili.
- Livello 2: Chiuso
Questo livello è destinato a una sicurezza rigorosa. Supporta esclusivamente messaggi di testo semplice. Il protocollo vieta i link multimediali qui per escludere tecnicamente qualsiasi fuga di IP quando i client caricano contenuti esterni. Gli utenti devono garantirsi autonomamente di acquisire la criptovaluta utilizzata per le commissioni di gas in modo anonimo.
- Livello 3: Crittografato
Costruito per la massima privacy. I messaggi stessi sono crittografati con AES-256-GCM prima di essere inviati. Solo i metadati, il vettore di inizializzazione (IV) e il testo cifrato sono memorizzati sulla blockchain. Solo i client degli utenti che possiedono la chiave crittografica corretta possono decrittografare e leggere questi messaggi.
Sicurezza della Rete e Tracciamento IP (Regola Ferrea)
Per tutti i livelli, il routing Onion (ad esempio Tor) è rigorosamente obbligatorio. Comunicare con provider RPC commerciali (come Infura o Alchemy) fa trapelare l'indirizzo IP del mittente in testo semplice. Per chiudere potenziali vulnerabilità OPSEC letali per i dissidenti, i client sono tenuti a instradare le transazioni verso i nodi RPC esclusivamente attraverso la rete Tor.
Standard Crittografici (Per il Livello 3)
Per i messaggi di Livello 3, tutti i client devono attenersi rigorosamente ai seguenti standard crittografici per garantire l'interoperabilità ed evitare di compromettere la sicurezza.
- Algoritmo di Crittografia: AES-256-GCM
Tutti i payload di Livello 3 devono essere crittografati simmetricamente utilizzando AES in modalità GCM con una lunghezza della chiave di 256 bit. Il vettore di inizializzazione (IV/Nonce) deve essere rigenerato casualmente per ogni singolo messaggio e viene scritto sulla blockchain come metadati in testo semplice. Questo impedisce il riconoscimento di pattern da parte di osservatori esterni.
- Derivazione della Chiave: Argon2id
Gli utenti inseriscono password leggibili dall'uomo nei loro client. Queste non devono mai essere usate direttamente come chiavi AES. I client sono tenuti rigorosamente a utilizzare l'algoritmo di hashing Argon2id. (Nota: Gli sviluppatori devono definire parametri fissi per iterazioni e utilizzo della memoria all'interno del client in modo che tutti generino esattamente la stessa chiave).
- Scambio di Chiave: Fuori Banda
Axiom non gestisce lo scambio di chiavi on-chain. Il protocollo non memorizza chiavi pubbliche. Lo scambio della password (segreto condiviso) per un canale specifico è responsabilità degli utenti e deve avvenire al di fuori della rete (ad esempio di persona).
- Integrità dei Dati
AES-GCM genera un Tag di Autenticazione. I client devono convalidare questo tag. Se la convalida fallisce, il client deve scartare silenziosamente il messaggio (drop).
Struttura dei Dati, Consegna del Payload e Indicizzazione
Axiom utilizza una consegna ibrida del payload (ABI Split). Per evitare che il contratto intelligente debba decomprimere formati di dati costosi, i dati vengono separati prima della trasmissione:
- Variabili Logiche: Il livello (
uint8 _level) e il vettore di inizializzazione (bytes _iv) vengono passati come parametri diretti al contratto intelligente, poiché esso ne ha bisogno per applicare le sue regole di sicurezza.
- Dati Opachi: Il contenuto effettivo del messaggio viene costruito internamente dal client come JSON e compresso in CBOR (Concise Binary Object Representation). Il contratto gestisce questo pacchetto CBOR "alla cieca" e lo inoltra direttamente al registro degli eventi.
Chiavi del Payload (Struttura CBOR)
Axiom utilizza lettere singole come chiavi per risparmiare byte. L'autore (msg.sender) e il timestamp (block.timestamp) sono omessi, poiché il contratto intelligente estrae questi valori in modo a prova di manomissione.
t (Tipo): Intero. Il tipo di azione.c (Contenuto): Stringa/Bytes. Il testo, il nome o il testo cifrato.h (Hashtag/Tag): Array. Opzionale. Usato per categorizzazione (sottocanali).m (Indizio del Messaggio): Bytes (lunghezza 2). Solo Livello 3. Un hash HMAC di 2 byte utilizzato per il bucketing fuzzy.r (Rispondi-A): Bytes. Opzionale. L'hash della transazione di un post a cui si fa riferimento.
Tipi di Azione (Campo t)
