Das Ziel von Axiom ist es, eine vollständig anonyme, dezentrale und zensurresistente Social-Media-Plattform bereitzustellen. Um dies zu ermöglichen, ist die Architektur streng in das Protokoll und die Clients unterteilt. Dieses Repository definiert das Protokoll und den Smart Contract sowie eine standardisierte Datenstruktur auf einem Ethereum Layer 2 Netzwerk.
42161https://arb1.arbitrum.io/rpc (oder ein benutzerdefinierter Alchemy/Infura-Endpunkt)0xc11CFf8111e8b1F055eba095Efb679a38Abe6b63(Hinweis: Axiom verwendet eine UUPS-Upgradeable-Proxy-Architektur. Alle Client-Interaktionen müssen immer an diese Proxy-Adresse gerichtet werden, niemals an den zugrunde liegenden Implementierungsvertrag).
Clients sollten niemals versuchen, Protokollbeiträge direkt aus den Smart-Contract-Statusvariablen zu lesen (da die Einsparung von Gas Priorität hat, werden Inhalte nicht im Status gespeichert). Stattdessen müssen Clients die Blockchain-Events indizieren.
Um Daten im Protokoll zu veröffentlichen, müssen Clients eine On-Chain-Transaktion durchführen, die die Funktion publishAxiom auf dem Proxy-Vertrag aufruft.
Das Ziel von Axiom ist es, eine vollständig anonyme, dezentralisierte und zensurresistente Social-Media-Plattform bereitzustellen.
Um dies zu ermöglichen, ist die Architektur strikt unterteilt: die Grundlage (das Protokoll) und die Clients (die Software). Dieses Repository definiert diese Grundlage – einen Smart Contract und eine standardisierte Datenstruktur auf einem Ethereum Layer-2-Netzwerk.
Das Protokoll legt die Grundlage der Plattform fest:
Axiom wurde entwickelt, um echte Meinungsfreiheit für Nutzer in Ländern zu ermöglichen, in denen Kommunikation eingeschränkt ist. Das Protokoll unterscheidet zwischen drei Sicherheitsstufen. Es wird davon ausgegangen, dass die Nutzer wissen, welche Sicherheitsstufe für ihre spezifische Situation angemessen ist.
Für alle Stufen ist Onion-Routing (z.B. Tor) strikt verpflichtend. Die Kommunikation mit kommerziellen RPC-Anbietern (wie Infura oder Alchemy) gibt die IP-Adresse des Senders im Klartext preis. Um potenziell lebensbedrohliche OPSEC-Schwachstellen für Dissidenten zu schließen, sind Clients verpflichtet, Transaktionen ausschließlich über das Tor-Netzwerk an die RPC-Knoten zu leiten.
Für Nachrichten auf Stufe 3 müssen alle Clients die folgenden kryptografischen Standards strikt einhalten, um Interoperabilität zu gewährleisten und die Sicherheit nicht zu gefährden.
Axiom verwendet eine hybride Payload-Auslieferung (ABI-Split). Um zu verhindern, dass der Smart Contract teure Datenformate entpacken muss, werden die Daten vor der Übertragung getrennt:
uint8 _level) und der Initialisierungsvektor (bytes _iv) werden als direkte Parameter an den Smart Contract übergeben, da dieser sie benötigt, um seine Sicherheitsregeln durchzusetzen.Axiom verwendet einzelne Buchstaben als Schlüssel, um Bytes zu sparen. Der Autor (msg.sender) und der Zeitstempel (block.timestamp) werden weggelassen, da der Smart Contract diese Werte manipulationssicher extrahiert.
t (Typ): Ganzzahl. Der Aktionstyp.c (Inhalt): String/Bytes. Der Text, Name oder Chiffretext.h (Hashtags/Tags): Array. Optional. Wird zur Kategorisierung verwendet (Unterkanäle).m (Nachrichtenhinweis): Bytes (Länge 2). Nur Stufe 3. Ein 2-Byte-HMAC-Hash, der für Fuzzy-Bucketing verwendet wird.r (Antwort auf): Bytes. Optional. Der Transaktionshash eines referenzierten Beitrags.t-Feld)0 = Profilaktualisierung (Verknüpft die Wallet-Adresse mit einem lesbaren Namen im Feld c)1 = Beitrag (Standardnachricht)2 = Antwort (r erfordert den Hash des ursprünglichen Beitrags)3 = Like (r erfordert den Hash des Beitrags)4 = Unlike (Macht Typ 3 rückgängig)5 = Retweet / Repost (r erfordert den Hash des Beitrags)6 = Un-Retweet (Macht Typ 5 rückgängig)h-Feld)