Axiom: Protocolo de Comunicación Descentralizado y Resistente a la Censura

🚀 Detalles del Despliegue en Vivo

• Red: Arbitrum One (Mainnet L2)
• ID de Cadena: 42161
• Endpoint RPC: https://arb1.arbitrum.io/rpc (o cualquier endpoint personalizado de Alchemy/Infura)
• Dirección del Contrato Proxy de Axiom: 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).

📖 Cómo Leer Datos (Indexador / Clientes)

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.

✍️ Cómo Publicar Datos (Envío de Transacciones del Cliente)

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.

Alcance del Proyecto

El protocolo establece la base de la plataforma:

• Convención de Nomenclatura Estándar: Una estructura clara que define cómo se envían los datos al contrato inteligente y cómo los clientes los leen.
• Inmutabilidad: La blockchain sirve como una base de datos a prueba de manipulaciones y a prueba de fallos.
• Enfoque en Microblogging: El protocolo no está diseñado para grandes cantidades de datos en cadena, sino que sigue el concepto tradicional de microblogging (publicaciones cortas). Los archivos multimedia no se almacenan de forma nativa en la cadena; en su lugar, se incrustan a través de enlaces externos cuando sea necesario.
• Protección contra Spam: Las tarifas de transacción y una tarifa de entrada única y baja para la primera publicación de una billetera evitan ataques de inflado de estado por parte de botnets.
• Enrutamiento de Seguridad: El protocolo impone la separación OPSEC de mensajes basada en requisitos de seguridad específicos.

---

Niveles de Seguridad del Protocolo

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.

• Nivel 1: Abierto La comunicación ocurre abiertamente en texto plano en la blockchain. Todos los clientes pueden leer y procesar todo el tráfico. La incrustación de enlaces (por ejemplo, para imágenes a través de proveedores externos) está permitida en este nivel. La expectativa es que aquí tenga lugar la comunicación estándar de redes sociales, incluyendo imágenes divertidas de gatos. Esto genera ruido importante dentro de la red. Es menos seguro en cuanto al rastreo de IP puro, pero las publicaciones permanecen completamente no censurables.
• Nivel 2: Cerrado Este nivel está destinado a la seguridad estricta. Solo admite mensajes de texto plano. El protocolo prohíbe enlaces multimedia aquí para descartar técnicamente cualquier fuga de IP cuando los clientes cargan contenido externo. Los usuarios deben asegurarse de forma independiente de adquirir la criptomoneda utilizada para las tarifas de gas de forma anónima.
• Nivel 3: Encriptado Construido para la máxima privacidad. Los mensajes en sí mismos se encriptan con AES-256-GCM antes de ser enviados. Solo los metadatos, el vector de inicialización (IV) y el texto cifrado se almacenan en la blockchain. Solo los clientes de usuarios que poseen la clave criptográfica correcta pueden descifrar y leer estos mensajes.

Seguridad de la Red y Rastreo de IP (Regla Estricta)

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.

---

Estándares Criptográficos (Para el Nivel 3)

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.

1. Algoritmo de Encriptación: AES-256-GCM Todos los datos del Nivel 3 deben ser encriptados simétricamente usando AES en modo GCM con una longitud de clave de 256 bits. El vector de inicialización (IV/Nonce) debe regenerarse aleatoriamente para cada mensaje individual y se escribe en la blockchain como metadatos en texto plano. Esto evita el reconocimiento de patrones por parte de observadores externos.
2. Derivación de Clave: Argon2id Los usuarios introducen contraseñas legibles por humanos en sus clientes. Estas nunca deben usarse directamente como claves AES. Los clientes están estrictamente obligados a usar el algoritmo de hash Argon2id. (Nota: Los desarrolladores deben definir parámetros fijos para iteraciones y uso de memoria dentro del cliente para que todos generen exactamente la misma clave).
3. Intercambio de Claves: Fuera de Banda Axiom no maneja el intercambio de claves en cadena. El protocolo no almacena claves públicas. Intercambiar la contraseña (secreto compartido) para un canal específico es responsabilidad de los usuarios y debe ocurrir fuera de la red (por ejemplo, en persona).
4. Integridad de los Datos AES-GCM genera una Etiqueta de Autenticación. Los clientes deben validar esta etiqueta. Si la validación falla, el cliente debe descartar el mensaje silenciosamente (descartar).

---

Estructura de Datos, Entrega de Datos e Indexación

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:

1. Variables Lógicas: El nivel (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.
2. Datos Opacos: El contenido real del mensaje es construido internamente por el cliente como JSON y comprimido en CBOR (Concise Binary Object Representation). El contrato maneja este paquete CBOR "a ciegas" y lo reenvía directamente al registro de eventos.

Claves de Datos (Estructura CBOR)

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.

Tipos de Acción (Campo t)