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)c) verschlüsselt werden. Für externe Beobachter sind die Tags daher vollständig unsichtbar (Dark Routing).m-Feld)Da Tags auf Stufe 3 verschlüsselt sind, müssten Clients theoretisch versuchen, jede einzelne Nachricht zu entschlüsseln (Trial Decryption). Um CPU-Überlastungen zu vermeiden, verwendet Axiom Nachrichtenhinweise:
HMAC-SHA256(AES_Key, IV) und platziert die ersten 2 Bytes als Feld m in der CBOR-Payload.Axiom behandelt Identität mit völliger Transparenz: Die L2-Wallet-Adresse (msg.sender) ist die einzige soziale und finanzielle Identität. Das Protokoll überträgt die Verantwortung für die finanzielle OPSEC vollständig auf den Benutzer (z.B. die Verwendung von Mixern und Brücken, um anonym Gas-Token zu beschaffen).
Die Profilaktualisierungsaktion (t: 0) verhält sich je nach gewählter Sicherheitsstufe unterschiedlich:
@Dissident99).Axiom verlässt sich auf On-Chain-Validierung mit O(1)-Komplexität. Um die Gaskosten auf einem absoluten Minimum zu halten, führt der Smart Contract nur grundlegende kryptografische Prüfungen durch. Alle ressourcenintensiven Inhaltsvalidierungen werden auf die Clients (Layer-2) ausgelagert.
Der Vertrag fungiert als unbestechlicher Türsteher. Wenn eine Payload nicht den strengen Regeln entspricht, wird die Transaktion zurückgesetzt.
// 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=New, 1=PathA(Level1), 2=PathB(Level2/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, "Invalid level");
uint8 requiredPath = (_level == 1) ? 1 : 2;
uint8 currentPath = walletPath[msg.sender];
if (currentPath == 0) {
require(msg.value >= entryFee, "Anti-Sybil: Insufficient entry fee");
walletPath[msg.sender] = requiredPath;
} else {
require(msg.value == 0, "Fee already paid");
require(currentPath == requiredPath, "OPSEC Violation: Wallet is tainted");
}
if (_level == 3) {
require(_iv.length == 12, "Level 3 strictly requires a 12-byte IV");
} else {
require(_iv.length == 0, "Level 1 and 2 require strictly empty IV");
}
emit AxiomPost(msg.sender, _level, _iv, _cbor, block.timestamp);
}
function withdraw() external onlyOwner {
payable(owner()).transfer(address(this).balance);
}
}
Wenn ein Beitrag gegen die Protokollregeln verstößt, muss der Client ihn stillschweigend verwerfen (Local Drop).
c) von Stufe-2-Nachrichten. Wenn URLs, IP-Adressen oder typische Medien-Tags erkannt werden, wird der Beitrag vollständig blockiert.Axiom ist auf einem Ethereum Layer-2 (L2)-Netzwerk (z.B. Arbitrum Nova) bereitgestellt.
Um eine Überlastung mobiler Geräte zu vermeiden (Akku-Laufzeit, Speicherbeschränkungen, WebAssembly-Limits für Argon2id), erzwingt Axiom eine hochperformante Client-Architektur:
Clients laden nicht den gesamten Blockchain-Status herunter. Sie filtern nach dem AxiomPost-Event des Smart Contracts, das alle notwendigen Daten im Klartext enthält (Sender, Stufe, IV, CBOR, Zeitstempel).
Da Ethereum-Knoten gemäß EIP-4444 historische Daten (Ereignisse älter als 365 Tage) irgendwann verwerfen werden, empfiehlt das Protokoll, dass lokale Axiom Cores als dezentrale Archive dienen und die Datenbanken dauerhaft speichern.
Um zu veranschaulichen, wie die Architektur in der Praxis funktioniert, hier ein vollständiger Lebenszyklus-Durchlauf.
Szenario: Alice möchte die Nachricht "Meeting at 8 PM" im Unterkanal "AxiomDev" posten. Die Gruppe hat zuvor offline das Passwort "Secret123" vereinbart.
Alices Axiom Core übernimmt die rechenintensive Arbeit:
0x12ab34cd56ef789012ab34cd).m: "0xa1b2").Da die Stufe und der IV direkt an den Vertrag übergeben werden, werden sie aus dem CBOR-Objekt ausgeschlossen.
Interne JSON-Darstellung:
{
"t": 1,
"c": "0x8a4f...",
"h": ["0x9b5e..."],
"m": "0xa1b2"
}
Dieses JSON wird zur Gaseinsparung in ein rohes CBOR-Byte-Array (0xa3617401...) komprimiert.
Alice löst die Vertragsfunktion aus. Wichtig: Der Aufruf erfolgt strikt über Tor!
(Beispiele für Stufe 3 und Stufe 1:)
// Beispiel 1: Client ruft den Smart Contract für einen verschlüsselten Stufe-3-Beitrag auf
await axiomContract.publishAxiom(
3, // _level: 3
"0x12ab34cd56ef789012ab34cd", // _iv: 12-Byte-Hex-String erforderlich
"0xa3617401616358208a4f..." // _cbor: gepackter CBOR-Hex-String
);
// Beispiel 2: Client ruft den Smart Contract für einen öffentlichen Stufe-1-Beitrag auf
await axiomContract.publishAxiom(
1, // _level: 1
"0x", // _iv: strikt leeres Byte-Array
"0xa361740161634c48656c6c6f204178..." // _cbor: gepackter CBOR-Hex-String
);
Der Smart Contract gibt dann das Ereignis aus:
Event: AxiomPost(Sender: 0xAlice..., Level: 3, IV: 0x12ab..., CBOR: 0xa361..., Timestamp: 1710425890)
Bobs Axiom Core hört die Blockchain ab und empfängt das Ereignis.
Level 3 und entpackt die CBOR, um auf den Inhalt, die Tags und den Hinweis m zuzugreifen.m gegen Bobs gespeicherte Passwörter.