Axiom : Protocole de communication décentralisé et résistant à la censure

🚀 Détails du déploiement en direct

• Réseau : Arbitrum One (L2 principal)
• ID de chaîne : 42161
• Point de terminaison RPC : https://arb1.arbitrum.io/rpc (ou tout point de terminaison personnalisé Alchemy/Infura)
• Adresse du contrat proxy Axiom : 0xc11CFf8111e8b1F055eba095Efb679a38Abe6b63

(Remarque : Axiom utilise une architecture de proxy UUPS (Universal Upgradeable Proxy Standard). Toutes les interactions client doivent toujours être dirigées vers cette adresse de proxy, jamais vers le contrat d'implémentation sous-jacent).

📖 Comment lire les données (Indexeur / Clients)

Les clients ne doivent jamais tenter de lire les publications du protocole directement à partir des variables d'état du contrat intelligent (car préserver le gaz est une priorité, le contenu n'est pas stocké dans l'état). Au lieu de cela, les clients doivent indexer les événements de la blockchain.

✍️ Comment publier des données (Soumission de transaction client)

Pour publier des données sur le protocole, les clients doivent soumettre une transaction on-chain appelant la fonction publishAxiom sur le contrat proxy.

---

L'objectif d'Axiom est de fournir une plateforme de médias sociaux complètement anonyme, décentralisée et résistante à la censure.

Pour rendre cela possible, l'architecture est strictement divisée : la fondation (le protocole) et les clients (le logiciel). Ce référentiel définit cette fondation — un contrat intelligent et une structure de données standardisée sur un réseau Ethereum Layer 2.

Périmètre du projet

Le protocole établit la fondation de la plateforme :

• Convention de nommage standard : Une structure claire définissant comment les charges utiles sont envoyées au contrat intelligent et comment les clients les lisent.
• Immutabilité : La blockchain sert de base de données inviolable et de sécurité.
• Focus microblogging : Le protocole n'est pas conçu pour de grandes quantités de données on-chain, mais suit plutôt le concept traditionnel du microblogging (messages courts). Les fichiers multimédias ne sont pas stockés nativement sur la chaîne ; ils sont intégrés via des liens externes si nécessaire.
• Protection anti-spam : Les frais de transaction et des frais d'entrée uniques et faibles pour le premier message d'un portefeuille empêchent les attaques de gonflement d'état par des botnets.
• Routage de sécurité : Le protocole impose la séparation OPSEC des messages en fonction d'exigences de sécurité spécifiques.

---

Niveaux de sécurité du protocole

Axiom est conçu pour permettre une véritable liberté d'expression aux utilisateurs dans les pays où la communication est restreinte. Le protocole distingue trois niveaux de sécurité. Il suppose que les utilisateurs savent quel niveau de sécurité est approprié pour leur situation spécifique.

• Niveau 1 : Ouvert La communication se fait ouvertement en texte clair sur la blockchain. Tous les clients peuvent lire et traiter l'ensemble du trafic. L'intégration de liens (par exemple, pour les images via des fournisseurs tiers) est autorisée à ce niveau. On s'attend à ce que les communications standard des médias sociaux aient lieu ici — y compris les photos de chats amusantes. Cela génère un bruit important dans le réseau. C'est moins sûr en ce qui concerne le suivi IP pur, mais les messages restent totalement incensurables.
• Niveau 2 : Fermé Ce niveau est destiné à une sécurité stricte. Il ne prend en charge que les messages en texte clair. Le protocole interdit les liens vers des médias ici pour exclure techniquement toute fuite IP lorsque les clients chargent du contenu externe. Les utilisateurs doivent s'assurer indépendamment d'acquérir la cryptomonnaie utilisée pour les frais de gaz de manière anonyme.
• Niveau 3 : Chiffré Conçu pour une confidentialité maximale. Les messages eux-mêmes sont chiffrés avec AES-256-GCM avant d'être envoyés. Seules les métadonnées, le vecteur d'initialisation (IV) et le texte chiffré sont stockés sur la blockchain. Seuls les clients des utilisateurs qui possèdent la bonne clé cryptographique peuvent déchiffrer et lire ces messages.

Sécurité réseau et suivi IP (Règle stricte)

Pour tous les niveaux, le routage Onion (par exemple, Tor) est strictement obligatoire. Communiquer avec des fournisseurs RPC commerciaux (comme Infura ou Alchemy) divulgue l'adresse IP de l'expéditeur en texte clair. Pour fermer les vulnérabilités OPSEC potentiellement mortelles pour les dissidents, les clients sont tenus de router les transactions vers les nœuds RPC exclusivement via le réseau Tor.

---

Normes cryptographiques (Pour le niveau 3)

Pour les messages de niveau 3, tous les clients doivent strictement respecter les normes cryptographiques suivantes pour garantir l'interopérabilité et éviter de compromettre la sécurité.

1. Algorithme de chiffrement : AES-256-GCM Toutes les charges utiles de niveau 3 doivent être chiffrées symétriquement à l'aide d'AES en mode GCM avec une longueur de clé de 256 bits. Le vecteur d'initialisation (IV/Nonce) doit être régénéré aléatoirement pour chaque message et est écrit sur la blockchain en tant que métadonnées en texte clair. Cela empêche la reconnaissance de motifs par des observateurs externes.
2. Dérivation de clé : Argon2id Les utilisateurs saisissent des mots de passe lisibles par l'homme dans leurs clients. Ceux-ci ne doivent jamais être utilisés directement comme clés AES. Les clients sont strictement tenus d'utiliser l'algorithme de hachage Argon2id. (Remarque : Les développeurs doivent définir des paramètres fixes pour les itérations et l'utilisation de la mémoire dans le client afin que tous génèrent exactement la même clé).
3. Échange de clés : Hors bande Axiom ne gère pas les échanges de clés on-chain. Le protocole ne stocke aucune clé publique. L'échange du mot de passe (secret partagé) pour un canal spécifique est de la responsabilité des utilisateurs et doit avoir lieu en dehors du réseau (par exemple, en personne).
4. Intégrité des données AES-GCM génère une étiquette d'authentification (Authentication Tag). Les clients doivent valider cette étiquette. Si la validation échoue, le client doit silencieusement rejeter le message (drop).

---

Structure des données, livraison de la charge utile et indexation

Axiom utilise une livraison de charge utile hybride (ABI Split). Pour éviter que le contrat intelligent n'ait à décompresser des formats de données coûteux, les données sont séparées avant la transmission :

1. Variables logiques : Le niveau (uint8 _level) et le vecteur d'initialisation (bytes _iv) sont passés comme paramètres directs au contrat intelligent, car celui-ci en a besoin pour appliquer ses règles de sécurité.
2. Données opaques : Le contenu réel du message est construit en interne par le client en JSON et compressé en CBOR (Concise Binary Object Representation). Le contrat traite ce paquet CBOR "à l'aveugle" et le transmet directement au journal des événements.

Clés de la charge utile (Structure CBOR)

Axiom utilise des lettres uniques comme clés pour économiser des octets. L'auteur (msg.sender) et l'horodatage (block.timestamp) sont omis, car le contrat intelligent extrait ces valeurs de manière inviolable.

• t (Type) : Entier. Le type d'action.
• c (Contenu) : Chaîne/Octets. Le texte, le nom ou le texte chiffré.
• h (Hashtags/Tags) : Tableau. Optionnel. Utilisé pour la catégorisation (sous-canaux).
• m (Indice de message) : Octets (longueur de 2). Niveau 3 uniquement. Un hachage HMAC de 2 octets utilisé pour le regroupement flou (fuzzy bucketing).
• r (Réponse à) : Octets. Optionnel. Le hachage de transaction d'un message référencé.

Types d'actions (champ t)