El objetivo de Axiom es proporcionar una plataforma de redes sociales completamente anónima, descentralizada y resistente a la censura. Para hacer esto posible, la arquitectura está estrictamente dividida entre el protocolo y los clientes. Este repositorio define el protocolo, el contrato inteligente y una estructura de datos estandarizada en una red Ethereum Layer 2.
42161https://arb1.arbitrum.io/rpc (o cualquier endpoint personalizado de Alchemy/Infura)0xc11CFf8111e8b1F055eba095Efb679a38Abe6b63(Nota: Axiom utiliza una arquitectura de Proxy Actualizable UUPS. Todas las interacciones del cliente deben dirigirse siempre a esta dirección del Proxy, nunca al contrato de implementación subyacente).
Los clientes nunca deben intentar leer publicaciones del protocolo directamente desde las variables de estado del contrato inteligente (ya que preservar gas es una prioridad, el contenido no se almacena en el estado). En su lugar, los clientes deben indexar los eventos de la blockchain.
Para publicar datos en el Protocolo, los clientes deben enviar una transacción en cadena llamando a la función publishAxiom en el contrato Proxy.
El objetivo de Axiom es proporcionar una plataforma de redes sociales completamente anónima, descentralizada y resistente a la censura.
Para hacer esto posible, la arquitectura está estrictamente dividida: la base (el protocolo) y los clientes (el software). Este repositorio define esa base: un contrato inteligente y una estructura de datos estandarizada en una red Ethereum de Capa 2.
El protocolo establece la base de la plataforma:
Axiom está diseñado para permitir la verdadera libertad de expresión para usuarios en países donde la comunicación está restringida. El protocolo distingue entre tres niveles de seguridad. Asume que los usuarios saben qué nivel de seguridad es apropiado para su situación específica.
Para todos los niveles, el Enrutamiento Cebolla (por ejemplo, Tor) es estrictamente obligatorio. Comunicarse con proveedores RPC comerciales (como Infura o Alchemy) filtra la dirección IP del remitente en texto plano. Para cerrar vulnerabilidades OPSEC potencialmente mortales para disidentes, se requiere que los clientes enruten las transacciones a los nodos RPC exclusivamente a través de la red Tor.
Para los mensajes en el Nivel 3, todos los clientes deben adherirse estrictamente a los siguientes estándares criptográficos para garantizar la interoperabilidad y evitar comprometer la seguridad.
Axiom utiliza una entrega de datos híbrida (División ABI). Para evitar que el contrato inteligente tenga que desempaquetar formatos de datos costosos, los datos se separan antes de la transmisión:
uint8 _level) y el vector de inicialización (bytes _iv) se pasan como parámetros directos al contrato inteligente, ya que los necesita para hacer cumplir sus reglas de seguridad.Axiom utiliza letras individuales como claves para ahorrar bytes. El autor (msg.sender) y la marca de tiempo (block.timestamp) se omiten, ya que el contrato inteligente extrae estos valores de forma segura contra manipulaciones.
t (Tipo): Entero. El tipo de acción.c (Contenido): Cadena/Bytes. El texto, nombre o texto cifrado.h (Hashtags/Etiquetas): Arreglo. Opcional. Se usa para categorización (subcanales).m (Indicación de Mensaje): Bytes (longitud de 2). Solo Nivel 3. Un hash HMAC de 2 bytes utilizado para agrupación difusa.r (Respuesta a): Bytes. Opcional. El hash de transacción de una publicación referenciada.t)0 = Actualización de Perfil (Vincula la dirección de la billetera a un nombre legible en el campo c)1 = Publicación (Mensaje estándar)2 = Respuesta (r requiere el hash de la publicación original)3 = Me Gusta (r requiere el hash de la publicación)4 = No Me Gusta (Revoca el Tipo 3)5 = Retweet / Repost (r requiere el hash de la publicación)6 = Deshacer Retweet (Revoca el Tipo 5)h)c). Para los observadores externos, las etiquetas son, por lo tanto, completamente invisibles (Enrutamiento Oscuro).m)Debido a que las etiquetas están encriptadas en el Nivel 3, los clientes teóricamente tienen que intentar descifrar cada mensaje individual (Descifrado de Prueba). Para evitar sobrecargas de CPU, Axiom utiliza Indicaciones de Mensaje:
HMAC-SHA256(AES_Key, IV) y coloca los primeros 2 bytes como campo m en los datos CBOR.Axiom maneja la identidad con total transparencia: La dirección de la billetera L2 (msg.sender) es la única identidad social y financiera. El protocolo transfiere la responsabilidad de la OPSEC financiera completamente al usuario (por ejemplo, el uso de mezcladores y puentes para adquirir tokens de gas de forma anónima).
La acción de actualización de perfil (t: 0) se comporta de manera diferente según el nivel de seguridad elegido:
@Disidente99).Axiom se basa en validación en cadena con complejidad O(1). Para mantener los costos de gas al mínimo absoluto, el contrato inteligente solo realiza comprobaciones criptográficas básicas. Todas las validaciones de contenido intensivas en recursos se descargan a los clientes (Capa 2).
El contrato actúa como un portero incorruptible. Si un dato no sigue las reglas estrictas, la transacción se revierte.
// 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=Nuevo, 1=PathA(Nivel1), 2=PathB(Nivel2/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, "Nivel inválido");
uint8 requiredPath = (_level == 1) ? 1 : 2;
uint8 currentPath = walletPath[msg.sender];
if (currentPath == 0) {
require(msg.value >= entryFee, "Anti-Sybil: Tarifa de entrada insuficiente");
walletPath[msg.sender] = requiredPath;
} else {
require(msg.value == 0, "Tarifa ya pagada");
require(currentPath == requiredPath, "Violación de OPSEC: La billetera está contaminada");
}
if (_level == 3) {
require(_iv.length == 12, "El Nivel 3 requiere estrictamente un IV de 12 bytes");
} else {
require(_iv.length == 0, "Los Niveles 1 y 2 requieren un IV estrictamente vacío");
}
emit AxiomPost(msg.sender, _level, _iv, _cbor, block.timestamp);
}
function withdraw() external onlyOwner {
payable(owner()).transfer(address(this).balance);
}
}
Si una publicación viola las reglas del protocolo, el cliente debe descartarla silenciosamente (Descarte Local).
c) de los mensajes del Nivel 2. Si se detectan URL, direcciones IP o etiquetas multimedia típicas, la publicación se bloquea por completo.Axiom está desplegado en una red de Capa 2 (L2) de Ethereum (por ejemplo, Arbitrum Nova).
Para evitar sobrecargar los dispositivos móviles (duración de la batería, limitaciones de almacenamiento, límites de WebAssembly para Argon2id), Axiom impone una arquitectura de cliente de alto rendimiento:
Los clientes no descargan todo el estado de la blockchain. Filtran el evento AxiomPost del contrato inteligente, que contiene todos los datos necesarios en texto plano (Remitente, Nivel, IV, CBOR, Marca de tiempo).
Debido a que los nodos de Ethereum eventualmente descartarán datos históricos (eventos anteriores a 365 días) según EIP-4444, el protocolo recomienda que los Axiom Cores locales sirvan como archivos descentralizados, almacenando las bases de datos de forma permanente.
Para ilustrar cómo funciona la arquitectura en la práctica, aquí hay un recorrido completo del ciclo de vida.
Escenario: Alice quiere publicar el mensaje "Reunión a las 8 PM" en el subcanal "AxiomDev". El grupo acordó previamente fuera de línea la contraseña "Secret123".
El Axiom Core de Alice maneja el trabajo computacional pesado:
0x12ab34cd56ef789012ab34cd).m: "0xa1b2").Dado que el nivel y el IV se pasan directamente al contrato, se excluyen del objeto CBOR.
Representación JSON Interna:
{
"t": 1,
"c": "0x8a4f...",
"h": ["0x9b5e..."],
"m": "0xa1b2"
}
Este JSON se comprime en un arreglo de bytes CBOR sin procesar (0xa3617401...) para ahorrar gas.
Alice activa la función del contrato. Importante: ¡La llamada se enruta estrictamente a través de Tor!
(Ejemplos para L3 y L1:)
// Ejemplo 1: Cliente llamando al Contrato Inteligente para una publicación encriptada de Nivel 3
await axiomContract.publishAxiom(
3, // _level: 3
"0x12ab34cd56ef789012ab34cd", // _iv: cadena hexadecimal de 12 bytes requerida
"0xa3617401616358208a4f..." // _cbor: cadena hexadecimal CBOR empaquetada
);
// Ejemplo 2: Cliente llamando al Contrato Inteligente para una publicación pública de Nivel 1
await axiomContract.publishAxiom(
1, // _level: 1
"0x", // _iv: arreglo de bytes estrictamente vacío
"0xa361740161634c48656c6c6f204178..." // _cbor: cadena hexadecimal CBOR empaquetada
);
El contrato inteligente entonces emite el evento:
Evento: AxiomPost(Remitente: 0xAlice..., Nivel: 3, IV: 0x12ab..., CBOR: 0xa361..., Marca de tiempo: 1710425890)
El Axiom Core de Bob está escuchando la blockchain y recibe el evento.
Nivel 3 y desempaqueta el CBOR para acceder al contenido, las etiquetas y la indicación m.m contra las contraseñas almacenadas de Bob.