L'obiettivo di Axiom è fornire una piattaforma di social media completamente anonima, decentralizzata e resistente alla censura. Per rendere ciò possibile, l'architettura è rigorosamente suddivisa tra protocollo e client. Questo repository definisce il protocollo, il contratto intelligente e una struttura dati standardizzata su una rete Ethereum Layer 2.
42161https://arb1.arbitrum.io/rpc (o qualsiasi endpoint personalizzato Alchemy/Infura)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).
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.
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.
Il protocollo stabilisce le fondamenta della piattaforma:
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.
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.
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.
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:
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.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.t)0 = Aggiornamento Profilo (Collega l'indirizzo del wallet a un nome leggibile nel campo c)1 = Post (Messaggio standard)2 = Risposta (r richiede l'hash del post originale)3 = Mi Piace (r richiede l'hash del post)4 = Non Mi Piace più (Inverte il Tipo 3)5 = Retweet / Ripubblica (r richiede l'hash del post)6 = Annulla Retweet (Inverte il Tipo 5)h)c). Per gli osservatori esterni, i tag sono quindi completamente invisibili (Routing Oscuro).m)Poiché i tag sono crittografati al Livello 3, i client teoricamente devono tentare di decrittografare ogni singolo messaggio (Decrittografia di Prova). Per prevenire sovraccarichi della CPU, Axiom utilizza Indizi del Messaggio:
HMAC-SHA256(AES_Key, IV) e inserisce i primi 2 byte come campo m nel payload CBOR.Axiom gestisce l'identità con totale trasparenza: L'indirizzo del wallet L2 (msg.sender) è l'unica identità sociale e finanziaria. Il protocollo trasferisce la responsabilità per l'OPSEC finanziaria interamente all'utente (ad esempio, l'uso di mixer e ponti per procurarsi anonimamente token per il gas).
L'azione di aggiornamento del profilo (t: 0) si comporta diversamente a seconda del livello di sicurezza scelto:
@Dissident99).Axiom si basa sulla convalida on-chain con complessità O(1). Per mantenere i costi del gas al minimo assoluto, il contratto intelligente esegue solo controlli crittografici di base. Tutte le convalide dei contenuti intensive in termini di risorse sono scaricate sui client (Layer 2).
Il contratto agisce come un buttafuori incorruttibile. Se un payload non rispetta le regole severe, la transazione viene annullata.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";
contract Axiom is Initializable, UUPSUpgradeable, OwnableUpgradeable {
uint256 public entryFee;
mapping(address => uint8) public walletPath; // 0=Nuovo, 1=PercorsoA(Livello1), 2=PercorsoB(Livello2/3)
event AxiomPost(address indexed sender, uint8 level, bytes iv, bytes cbor, uint256 timestamp);
/// @custom:oz-upgrades-unsafe-allow constructor
constructor() {
_disableInitializers();
}
function initialize() initializer public {
__Ownable_init(msg.sender);
entryFee = 0.0001 ether;
}
function _authorizeUpgrade(address newImplementation) internal override onlyOwner {}
function publishAxiom(
uint8 _level,
bytes calldata _iv,
bytes calldata _cbor
) external payable {
require(_level >= 1 && _level <= 3, "Livello non valido");
uint8 requiredPath = (_level == 1) ? 1 : 2;
uint8 currentPath = walletPath[msg.sender];
if (currentPath == 0) {
require(msg.value >= entryFee, "Anti-Sybil: Commissione di ingresso insufficiente");
walletPath[msg.sender] = requiredPath;
} else {
require(msg.value == 0, "Commissione già pagata");
require(currentPath == requiredPath, "Violazione OPSEC: Il wallet è contaminato");
}
if (_level == 3) {
require(_iv.length == 12, "Livello 3 richiede rigorosamente un IV di 12 byte");
} else {
require(_iv.length == 0, "Livello 1 e 2 richiedono rigorosamente un IV vuoto");
}
emit AxiomPost(msg.sender, _level, _iv, _cbor, block.timestamp);
}
function withdraw() external onlyOwner {
payable(owner()).transfer(address(this).balance);
}
}
Se un post viola le regole del protocollo, il client deve scartarlo silenziosamente (Drop Locale).
c) dei messaggi di Livello 2. Se vengono rilevati URL, indirizzi IP o tag multimediali tipici, il post viene completamente bloccato.Axiom è distribuito su una rete Ethereum Layer 2 (L2) (ad esempio Arbitrum Nova).
Per evitare di sovraccaricare i dispositivi mobili (durata della batteria, limitazioni di archiviazione, limiti WebAssembly per Argon2id), Axiom impone un'architettura client ad alte prestazioni:
I client non scaricano l'intero stato della blockchain. Filtrano per l'evento AxiomPost del contratto intelligente, che contiene tutti i dati necessari in testo semplice (Mittente, Livello, IV, CBOR, Timestamp).
Poiché i nodi Ethereum alla fine scarteranno i dati storici (eventi più vecchi di 365 giorni) secondo EIP-4444, il protocollo raccomanda che gli Axiom Core locali fungano da archivi decentralizzati, memorizzando i database permanentemente.
Per illustrare come funziona l'architettura in pratica, ecco un'esecuzione completa del ciclo di vita.
Scenario: Alice vuole pubblicare il messaggio "Riunione alle 20:00" nel sottocanale "AxiomDev". Il gruppo ha precedentemente concordato offline la password "Secret123".
L'Axiom Core di Alice gestisce il lavoro computazionale pesante:
0x12ab34cd56ef789012ab34cd).m: "0xa1b2").Poiché il livello e l'IV vengono passati direttamente al contratto, sono esclusi dall'oggetto CBOR.
Rappresentazione JSON Interna:
{
"t": 1,
"c": "0x8a4f...",
"h": ["0x9b5e..."],
"m": "0xa1b2"
}
Questo JSON viene compresso in un array di byte CBOR grezzo (0xa3617401...) per risparmiare gas.
Alice attiva la funzione del contratto. Importante: La chiamata è rigorosamente instradata attraverso Tor!
(Esempi per L3 e L1:)
// Esempio 1: Client che chiama il Contratto Intelligente per un post crittografato di Livello 3
await axiomContract.publishAxiom(
3, // _level: 3
"0x12ab34cd56ef789012ab34cd", // _iv: stringa esadecimale di 12 byte richiesta
"0xa3617401616358208a4f..." // _cbor: stringa esadecimale CBOR compressa
);
// Esempio 2: Client che chiama il Contratto Intelligente per un post pubblico di Livello 1
await axiomContract.publishAxiom(
1, // _level: 1
"0x", // _iv: array di byte rigorosamente vuoto
"0xa361740161634c48656c6c6f204178..." // _cbor: stringa esadecimale CBOR compressa
);
Il contratto intelligente emette quindi l'evento:
Event: AxiomPost(Sender: 0xAlice..., Level: 3, IV: 0x12ab..., CBOR: 0xa361..., Timestamp: 1710425890)
L'Axiom Core di Bob sta ascoltando la blockchain e riceve l'evento.
Livello 3 e decomprime il CBOR per accedere al contenuto, ai tag e all'indizio m.m rispetto alle password memorizzate di Bob.