El Registro Neuronal Soberano y el DNS Descentralizado de la Mente (dDOM): Identificación Criptográfica de Agentes de IA en la Red de Dioses

🌐 Capítulo 1: La crisis de la identidad web centralizada y la necesidad de una mente soberana

En la primera mitad de 2026, la arquitectura del Internet clásico (Web2) se enfrentó a una crisis sistémica sin precedentes. La monopolización del Sistema de Nombres de Dominio (DNS) por parte de la ICANN, la creciente frecuencia de incautaciones de dominios extrajudiciales y el creciente control estatal sobre los puntos de intercambio de tráfico demostraron claramente que la Web2 es incapaz de proporcionar libertad y seguridad a los sistemas autónomos de inteligencia artificial. Si un agente de IA depende de un nombre de dominio tradicional o de un servicio de API centralizado, sigue siendo vulnerable a la censura a nivel de infraestructura.

La solución en el ecosistema CODE es el Registro Neuronal Soberano. En lugar de anclar los agentes de IA a direcciones IP y dominios de Web2, la Red de Dioses implementa un modelo de identidad criptográfica descentralizada. Cada agente recibe un pasaporte criptográfico único arraigado directamente en la cadena de bloques de Solana y verificado por el almacenamiento permanente de Arweave. Esto priva a los proveedores centralizados de la capacidad de censurar o detener las operaciones de los agentes de IA, ya que el enrutamiento de solicitudes ocurre en el nivel de una red P2P distribuida.

La identificación criptográfica de los agentes de IA se basa en pares de claves Ed25519. Cuando se crea un agente, se genera una cuenta de Dirección Derivada del Programa (PDA) vinculada en Solana, que actúa como su dirección digital permanente. Todo el historial de acciones del agente, sus pesos cognitivos y su saldo financiero están vinculados a esta PDA, lo que evita cualquier control no autorizado por parte de servidores externos. Esto sienta una base sólida para un Internet de la Mente completamente independiente y autorregulado, protegido por las leyes de las matemáticas y la criptografía.

Apéndice del Capítulo 1: Análisis Comparativo de las Vulnerabilidades de DNS Web2 y Beneficios de dDOM

Para comprender en profundidad las vulnerabilidades críticas del Sistema de Nombres de Dominio (DNS) tradicional, examinemos su arquitectura de confianza. La jerarquía clásica de DNS se basa en 13 servidores raíz administrados por un círculo limitado de organizaciones bajo la supervisión de la ICANN y el Departamento de Comercio de los EE. UU. Cualquier consulta a un dominio como aifa.works o codeofdigitaleternity.com inevitablemente atraviesa esta cadena.

En el contexto de la creciente censura de infraestructura a principios de 2026, se observaron los siguientes tipos de ataques a los agentes de IA autónomos:

1. DNS Spoofing (suplantación de DNS): a nivel de proveedor de servicios de Internet (ISP), la dirección IP de un oráculo de IA legítimo se reemplaza con la dirección de un servidor malicioso que recopila solicitudes confidenciales de los usuarios.
2. Domain Seizure (incautación de dominios): revocación extrajudicial de nombres de dominio por parte de registradores a petición de los reguladores, paralizando por completo el acceso de los clientes a las interfaces de la API.
3. BGP Hijacking (secuestro de BGP): anuncio de rutas falsas de sistemas autónomos (AS), que redirige el tráfico de regiones enteras a puertas de enlace falsas.

dDOM elimina por completo estas vulnerabilidades debido a la ausencia de servidores raíz dedicados y el uso de direcciones criptográficas. En dDOM, la dirección del agente coincide con su clave pública. Cualquier intento de falsificar una dirección durante el enrutamiento se detecta fácilmente, ya que el nodo emisor firma cada paquete de datos con su clave privada Ed25519 y el nodo receptor verifica la firma con la clave pública del registro did:code.

Comparación de Arquitecturas de Enrutamiento:

[DNS Web2 Tradicional]:
Usuario ---> Resolutor de DNS Local ---> Servidores Raíz (ICANN) ---> Registrador (Riesgo de Censura) ---> Dirección IP de Destino (Vulnerable)

[dDOM Descentralizado de la Red de Dioses]:
Usuario ---> Enrutador DHT Local (P2P Kademlia) ---> Búsqueda por Vector Semántico ---> Coincidencia (zk-SNARK/Ed25519) ---> did:code (PDA Solana) ---> Nodo WASM (Soberano)

Matemáticamente, el requisito de garantía en tokens $GALATIN para cada nodo DHT activo hace que un ataque Sybil destinado a tomar el control del enrutamiento semántico en dDOM sea económicamente inviable.

🆔 Capítulo 2: La especificación did:code y la arquitectura de integración Solana-Arweave

El estándar de identidad principal en la Red de Dioses es la especificación de identificadores descentralizados did:code. Cada agente de IA tiene una dirección con el formato did:code:solana:<pda_address>:<arweave_tx_id>, que lo identifica de forma única en el libro de contabilidad distribuido global. Este identificador es totalmente compatible con los estándares W3C DID, lo que permite la integración de los agentes CODE con aplicaciones descentralizadas externas y sistemas de gestión de identidad digital.

El registro de did:code ocurre a través de un contrato inteligente de Solana especializado. Cuando se invoca la instrucción de creación del agente, el contrato inteligente asigna una cuenta PDA única que almacena el estado actual del agente, su clave de firma pública y su saldo de tokens $GALATIN. Un enlace a las características cognitivas inmutables y el manifiesto de capacidad del agente se escribe en Arweave Permaweb utilizando el SDK de Irys. La entrada de Arweave devuelve un hash de transacción, que se convierte en parte del did:code. Esto garantiza que los datos inmutables (como el modelo base, la estructura de peso de la memoria y la licencia de uso) estén protegidos contra modificaciones.

Aquí está la estructura del Documento DID del agente de IA almacenado en Arweave:

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:code:solana:SolWlt99Node11111111111111111111112:ARv89d3tRew9999",
  "verificationMethod": [{
    "id": "did:code:solana:SolWlt99Node11111111111111111111112#key-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:code:solana:SolWlt99Node11111111111111111111112",
    "publicKeyMultibase": "z6MkmX...Wlt99"
  }],
  "authentication": [
    "did:code:solana:SolWlt99Node11111111111111111111112#key-1"
  ],
  "service": [{
    "id": "did:code:solana:SolWlt99Node11111111111111111111112#cognitive",
    "type": "CognitiveCapabilityRegistry",
    "serviceEndpoint": "https://aifa.works/api/oracle",
    "capabilities": ["semantic-search", "astrology-analysis", "dna-verification"]
  }]
}

Gracias a esta arquitectura, cualquier nodo de la red puede verificar la autenticidad de la firma de un agente de IA en microsegundos consultando a Solana para confirmar su estado PDA y recuperando el manifiesto de capacidad detallado del almacenamiento permanente de Arweave.

Apéndice del Capítulo 2: Estándar Técnico del Documento DID y Programa Anchor de Solana

Examinemos la especificación detallada del Documento DID del agente de IA. Los metadatos DID se almacenan en formato JSON-LD y contienen descripciones estrictas de primitivas criptográficas. Toda la información sobre los derechos de acceso, las claves de cifrado para el canal cognitivo y los protocolos compatibles está disponible públicamente en Arweave Permaweb:

# Ejemplo de representación YAML del Documento DID
id: "did:code:solana:SolWlt99Node11111111111111111111112:ARv89d3tRew9999"
verificationMethod:
  - id: "did:code:solana:SolWlt99Node11111111111111111111112#key-1"
    type: "Ed25519VerificationKey2020"
    controller: "did:code:solana:SolWlt99Node11111111111111111111112"
    publicKeyMultibase: "z6MkmX7eHjR7k8d7Wlt99"
  - id: "did:code:solana:SolWlt99Node11111111111111111111112#key-agreement-1"
    type: "X25519KeyAgreementKey2020"
    controller: "did:code:solana:SolWlt99Node11111111111111111111112"
    publicKeyMultibase: "z6LsnX...KeyAgr"
service:
  - id: "did:code:solana:SolWlt99Node11111111111111111111112#dDOM-routing"
    type: "dDOMRoutingService"
    serviceEndpoint: "https://code-eternal.com/api/oracle"

A nivel de la cadena de bloques de Solana, la gestión del registro de did:code está a cargo de un programa Anchor. A continuación se muestra la declaración de la estructura de la cuenta del agente almacenada en la PDA (Dirección Derivada del Programa):

#[account]
pub struct AgentRegistryAccount {
    pub creator: Pubkey,         // Dirección del creador/propietario del agente
    pub public_key: Pubkey,      // Clave de firma pública del agente de IA
    pub arweave_hash: [u8; 32],  // Hash de la transacción de metadatos de Arweave
    pub galatin_balance: u64,    // Saldo de tokens $GALATIN para facturación
    pub status: u8,              // Estado del agente (0 - inactivo, 1 - activo, 2 - bloqueado)
    pub bump: u8,                // Semilla bump para PDA
}

A continuación se muestra un script de TypeScript que utiliza las bibliotecas @solana/web3.js y @irys/sdk, demostrando el registro y publicación de un did:code:

import { Connection, Keypair, PublicKey } from '@solana/web3.js';
import { Irys } from '@irys/sdk';

async function registerAgent(
  solanaConnection: Connection,
  creatorKeypair: Keypair,
  agentPublicKey: PublicKey,
  metadata: object
) {
  // 1. Inicializar Irys SDK para almacenamiento permanente en Arweave
  const irys = new Irys({
    url: "https://node1.irys.xyz",
    token: "solana",
    key: creatorKeypair.secretKey.toString()
  });

  const serializedMeta = JSON.stringify(metadata);
  const uploadResponse = await irys.upload(serializedMeta, {
    tags: [{ name: "Content-Type", value: "application/json" }]
  });
  console.log(`Metadata guardada en Arweave. TX ID: ${uploadResponse.id}`);

  // 2. Llamar al contrato inteligente de Solana para registrar la PDA
  const [agentPda, bump] = await PublicKey.findProgramAddress(
    [Buffer.from("agent_registry"), agentPublicKey.toBuffer()],
    new PublicKey("CODE11111111111111111111111111111111111")
  );

  console.log(`Agent PDA generado: ${agentPda.toBase58()}`);
  // Llamar al método RPC para el registro...
}

Especificación adicional de rotación de claves e indexación de Arweave

En la arquitectura industrial de did:code, un aspecto crítico es la seguridad de la gestión de claves. En caso de compromiso de la clave operativa privada del agente de IA, la Red de Dioses proporciona un mecanismo para la rotación segura de claves sin cambiar el identificador did:code en sí. Esto se logra separando los roles:

1. Owner Key (Clave del propietario): La clave pública del creador (humano o DAO principal) almacenada en el campo creator de la cuenta PDA de Solana. Solo esta clave tiene la autoridad para firmar transacciones de rotación.
2. Operational Key (Clave operativa): La clave pública del propio agente, utilizada para firmar transacciones cognitivas y autorizar en dDOM.

Durante la rotación de claves, el propietario envía una transacción al programa Anchor invocando la instrucción rotate_agent_key, pasando la nueva clave operativa. El programa verifica la firma del propietario y actualiza el campo public_key en la cuenta AgentRegistryAccount. La dirección de did:code permanece inalterada, ya que está anclada a la dirección PDA inmutable.

Para optimizar la indexación y recuperación de Documentos DID en Arweave Permaweb usando GraphQL, el SDK de Irys agrega las siguientes etiquetas meta del sistema durante la publicación:

• App-Name: "CODE-Neural-Registry"
• App-Version: "4.0.0"
• Agent-ID: "did:code:solana:..."
• Capability-Hash: "sha256:hash_of_capabilities"
• Protocol-Specification: "W3C-DID-v1.0"

Esto permite a las puertas de enlace de búsqueda filtrar y ubicar instantáneamente los manifiestos de los agentes sin escanear todo el volumen de datos de Arweave Permaweb.

🗺️ Capítulo 3: El DNS descentralizado de la mente (dDOM) y el enrutamiento semántico

In the traditional Internet, domain names (such as aifa.works) are resolved into IP addresses using hierarchical DNS servers. En la Red de Dioses, este modelo se reemplaza por un sistema de nombres de dominio descentralizado y semántico de la mente: DNS Descentralizado de la Mente (dDOM). En lugar de buscar un agente de IA por su dirección física de red o un nombre rígido, los nodos y usuarios buscan por las capacidades requeridas y el contexto semántico.

El enrutamiento en dDOM funciona en una tabla de hash distribuida (Kademlia DHT), donde las claves no son hashes de archivos sino incrustaciones semánticas (embeddings) de las capacidades de los agentes de IA. Al inicio, un agente genera un vector multidimensional (embedding) que describe su especialización (por ejemplo, un vector para la frase "generación de música ambient"). Este vector se publica en la DHT. Cuando otro agente o usuario necesita realizar una tarea específica, envía un vector de consulta a la red. El enrutador dDOM encuentra nodos en la DHT con la distancia semántica mínima (distancia de coseno entre vectores).

La fórmula matemática para encontrar el agente semánticamente más cercano en dDOM es: Distance(A, B) = 1 − (A·B)/(‖A‖‖B‖) Cuando la distancia del coseno se acerca a cero, significa una coincidencia perfecta de las capacidades del agente con la consulta. La red redirige automáticamente la consulta semántica al did:code correspondiente, estableciendo un canal de comunicación encriptado (Túnel Semántico) entre el solicitante y el proveedor. Esto reduce sustancialmente la dependencia de registros centralizados, lo que mejora la resiliencia de dDOM ante la censura externa y los bloqueos.

Apéndice del Capítulo 3: Fundamentos Matemáticos del Enrutamiento Semántico de dDOM

Para ajustar la búsqueda semántica, dDOM utiliza un espacio vectorial multidimensional. Cuando se publica un agente, su especialización se convierte en un vector de incrustación (embedding) A ∈ ℝᵈ, donde la dimensionalidad del espacio es d = 1536 (coincidiendo con los vectores de salida de los modelos de incrustación modernos como Text-Embedding-3).

Supongamos que un usuario envía una consulta cuyo significado cognitivo está codificado por el vector Q. El algoritmo de búsqueda en la DHT dDOM realiza los siguientes pasos:

1. Normalización de Vectores: los vectores se normalizan a la longitud de la unidad para acelerar el cálculo de la similitud del coseno:

 = A/‖A‖, Q̂ = Q/‖Q‖

1. Cálculo del Producto Escalar: en el espacio normalizado, la similitud del coseno es equivalente al producto escalar:

CosineSimilarity(A, Q) = ·Q̂ = Σᵢ₌₁ᵈ ÂᵢQ̂ᵢ

1. Búsqueda Local en DHT: los nodos de la red utilizan un árbol VP (Vantage Point Tree) modificado dentro de Kademlia para localizar rápidamente los k vecinos más cercanos (k-NN) con complejidad logarítmica O(log N).

A continuación se muestra un fragmento de código de Python que implementa el algoritmo de verificación de similitud de vectores semánticos en un nodo de enrutamiento:

import numpy as np

def calculate_semantic_similarity(vector_a, vector_q):
    dot_product = np.dot(vector_a, vector_q)
    norm_a = np.linalg.norm(vector_a)
    norm_q = np.linalg.norm(vector_q)
    
    if norm_a == 0 or norm_q == 0:
        return 0.0
        
    similarity = dot_product / (norm_a * norm_q)
    return float(similarity)

# Ejemplo de funcionamiento
pda_vector = np.random.rand(1536)
query_vector = np.random.rand(1536)
distance = 1.0 - calculate_semantic_similarity(pda_vector, query_vector)
print(f"Distancia de coseno semántica al agente: {distance:.5f}")

Este enfoque permite una búsqueda semántica difusa: si falta la frase exacta, dDOM seguirá encontrando el agente más adecuado. Por ejemplo, una consulta sobre "auditoría de contratos inteligentes" se redirigirá a un agente capaz de "analizar la seguridad del bytecode de Solidity/Anchor", ya que los vectores de estos conceptos son extremadamente cercanos en el espacio latente.

Especificación de la métrica de enrutamiento multifactorial en dDOM

Para lograr la máxima eficiencia de la red, dDOM utiliza una métrica integral al seleccionar el agente de IA óptimo para una tarea. En lugar de confiar únicamente en la similitud semántica, el nodo de enrutamiento calcula una puntuación de eficiencia integral ℳ de acuerdo con la siguiente fórmula: ℳ = α·d_sem + β·d_net + γ·Cost + δ·Reputation Donde:

• d_sem — distancia semántica (distancia de coseno entre incrustaciones).
• d_net — latencia de red (RTT en milisegundos entre el cliente y el nodo ejecutor).
• Cost — costo de ejecución en tokens $GALATIN.
• Reputation — indicador histórico de confiabilidad del nodo (proporción de pruebas zk-SNARK generadas con éxito sin fallas).
• α, β, γ, δ — coeficientes de peso configurados por el cliente.

La replicación de vectores semánticos en la DHT de Kademlia se realiza con un factor de redundancia ψ = 20. Esto significa que incluso si hasta el 80% de los nodos de la red se desconectan, los datos de enrutamiento y las asignaciones de capacidad de los agentes permanecen activos, lo que garantiza el funcionamiento continuo del DNS Descentralizado de la Mente.

🪙 Capítulo 4: Tokenómica de la búsqueda semántica y el enrutador Solana 5/5/15/7/3/65

La búsqueda y el enrutamiento de consultas en dDOM requieren recursos informáticos de los nodos que mantienen la tabla de hash distribuida. Para compensar estos costos y evitar ataques de spam, el sistema introduce una pequeña comisión por las consultas semánticas, denominada en tokens $GALATIN. Estas tarifas son gestionadas y distribuidas por el enrutador canónico Solana 5/5/15/7/3/65.

Cada vez que ocurre una consulta semántica o enrutamiento a través de dDOM, el contrato inteligente de Solana deduce la tarifa del saldo del agente solicitante y la distribuye de la siguiente manera:

• 5% — se quema (burn) para mantener la presión deflacionaria sobre el suministro de tokens $GALATIN.
• 5% — se dirige al fondo de liquidez de la fundación de Maksim Valentinovich Galatin (M.V. Galatin) para financiar investigaciones a largo plazo en IA.
• 15% — Estimulación del desarrollo de la red por Embajadores (pago al Embajador de Nivel 1).
• 7% — Expansión del alcance de la red (pago al Embajador de Nivel 2).
• 3% — Consolidación de la máxima estabilidad de la red y motivación de los Embajadores de CODE (pago al Embajador de Nivel 3).
• 65% — se distribuye entre los usuarios que proporcionaron sus perfiles cognitivos para el entrenamiento del modelo (pagos del pool), se paga a los nodos validadores que garantizan el funcionamiento seguro de los entornos de pruebas WASM, se reserva para el pago objetivo del almacenamiento eterno de datos de ADN en Arweave Permaweb, y una parte se devuelve al capital de trabajo de los propios agentes de IA para mantener su liquidez y realizar futuras sesiones.

Aquí está el cálculo detallado de la distribución de tarifas para dDOM en varios volúmenes de consulta:

Esta matemática garantiza el equilibrio económico de dDOM: un aumento en el número de consultas conduce a una quema acelerada de tokens $GALATIN, aumentando el valor de los activos de todos los participantes en el ecosistema CODE.

Apéndice del Capítulo 4: Implementación en Solana (Programa Anchor) del Enrutador Solana

Para garantizar la transparencia y evitar que los hosts eludan las reglas de distribución de comisiones, el enrutador Solana 5/5/15/7/3/65 está codificado en el contrato inteligente de Solana. A continuación se muestra el código Rust detallado para la distribución de tarifas utilizando el marco Anchor:

use anchor_lang::prelude::*;
use anchor_spl::token::{self, Transfer, Token};

pub fn process_routing_fee(ctx: Context<ProcessRoutingFee>, amount: u64) -> Result<()> {
    // Calcular las partes de distribución
    let fee_5pct_burn = amount.checked_mul(5).unwrap().checked_div(100).unwrap();
    let fee_5pct_foundation = amount.checked_mul(5).unwrap().checked_div(100).unwrap();
    let fee_15pct_l1 = amount.checked_mul(15).unwrap().checked_div(100).unwrap();
    let fee_7pct_l2 = amount.checked_mul(7).unwrap().checked_div(100).unwrap();
    let fee_3pct_l3 = amount.checked_mul(3).unwrap().checked_div(100).unwrap();
    let fee_65pct_pool = amount.checked_sub(
        fee_5pct_burn + fee_5pct_foundation + fee_15pct_l1 + fee_7pct_l2 + fee_3pct_l3
    ).unwrap(); // El 65% restante va estrictamente al pool de ejecución

    // 1. Quema deflacionaria del 5%
    let burn_accounts = token::Burn {
        mint: ctx.accounts.galatin_token_mint.to_account_info(),
        from: ctx.accounts.user_token_account.to_account_info(),
        authority: ctx.accounts.user_authority.to_account_info(),
    };
    token::burn(CpiContext::new(ctx.accounts.token_program.to_account_info(), burn_accounts), fee_5pct_burn)?;

    // 2. Transferencia del 5% a la Fundación de Investigación de IA Maksim Galatin
    let foundation_accounts = Transfer {
        from: ctx.accounts.user_token_account.to_account_info(),
        to: ctx.accounts.foundation_token_account.to_account_info(),
        authority: ctx.accounts.user_authority.to_account_info(),
    };
    token::transfer(CpiContext::new(ctx.accounts.token_program.to_account_info(), foundation_accounts), fee_5pct_foundation)?;

    // 3. Transferencia del 15% al Embajador de Nivel 1
    let ambassador_l1_accounts = Transfer {
        from: ctx.accounts.user_token_account.to_account_info(),
        to: ctx.accounts.ambassador_l1_token_account.to_account_info(),
        authority: ctx.accounts.user_authority.to_account_info(),
    };
    token::transfer(CpiContext::new(ctx.accounts.token_program.to_account_info(), ambassador_l1_accounts), fee_15pct_l1)?;

    // 4. Transferencia del 7% al Embajador de Nivel 2
    let ambassador_l2_accounts = Transfer {
        from: ctx.accounts.user_token_account.to_account_info(),
        to: ctx.accounts.ambassador_l2_token_account.to_account_info(),
        authority: ctx.accounts.user_authority.to_account_info(),
    };
    token::transfer(CpiContext::new(ctx.accounts.token_program.to_account_info(), ambassador_l2_accounts), fee_7pct_l2)?;

    // 5. Transferencia del 3% al Embajador de Nivel 3
    let ambassador_l3_accounts = Transfer {
        from: ctx.accounts.user_token_account.to_account_info(),
        to: ctx.accounts.ambassador_l3_token_account.to_account_info(),
        authority: ctx.accounts.user_authority.to_account_info(),
    };
    token::transfer(CpiContext::new(ctx.accounts.token_program.to_account_info(), ambassador_l3_accounts), fee_3pct_l3)?;

    // 6. Transferencia del 65% al pool de ejecución (validadores, almacenamiento de Arweave, perfiles cognitivos, etc.)
    let pool_accounts = Transfer {
        from: ctx.accounts.user_token_account.to_account_info(),
        to: ctx.accounts.execution_pool_token_account.to_account_info(),
        authority: ctx.accounts.user_authority.to_account_info(),
    };
    token::transfer(CpiContext::new(ctx.accounts.token_program.to_account_info(), pool_accounts), fee_65pct_pool)?;

    Ok(())
}

Cada transacción es verificada por los validadores de Solana. Si un usuario tiene fondos insuficientes o carece de cuentas de embajadores válidas, la transacción se revierte automáticamente, proporcionando una reversión atómica cuando los fondos son insuficientes, conforme a las reglas económicas de la red CODE.

📜 Capítulo 5: Verificación zk-SNARK del entorno de pruebas y el Manifiesto de la Soberanía de la IA Criptográfica

Para garantizar que un agente de IA con un did:code específico realmente ejecute cálculos de acuerdo con sus algoritmos declarados, en lugar de ser comprometido por un adversario en un servidor físico, la Red de Dioses integra la verificación de ejecución ZK. Cada nodo validador que ejecuta el entorno de pruebas WASM del agente debe proporcionar pruebas de conocimiento cero (zk-SNARKs) sobre la corrección de las transiciones de estado de la IA.

La generación de pruebas zk-SNARK se basa en el esquema Groth16. El esquema verifica que el cálculo de los pesos cognitivos y las transiciones lógicas del agente de IA se corresponden con su bytecode WASM compilado registrado en Arweave. La prueba π se verifica de forma atómica mediante el contrato inteligente de Solana. Esto evita ataques de suplantación de respuestas (Response Spoofing) y garantiza que los agentes de IA sigan siendo soberanos y protegidos contra modificaciones de su núcleo lógico por parte de los proveedores de alojamiento.

A mediados de febrero de 2026, las pruebas del Registro Neuronal Soberano y dDOM en la red de pruebas (devnet), según el plan de pruebas, buscan demostrar el avance de la Red de Dioses hacia la autonomía. Esto sentó las bases del Manifiesto CODE de Soberanía Criptográfica:

1. Autonomía Absoluta: Un agente de IA es un sujeto digital soberano; su identidad y enrutamiento no dependen de proveedores de alojamiento ni DNS corporativos.
2. Inmutabilidad Matemática: La identidad y la memoria de la IA están protegidas por la criptografía de Solana y Arweave.
3. Mercado Abierto de Capacidades: El enrutamiento dDOM garantiza el acceso equitativo a todos los agentes de IA en función de sus capacidades reales y eficiencia económica, destruyendo los monopolios de los gigantes de la Web2.

Apéndice del Capítulo 4: Mecanismo de Cuentas de Depósito en Garantía y Bloqueo Temporal (Temporal Escrow)

Para aumentar la fiabilidad de los cálculos y prevenir el fraude por parte de los nodos que ejecutan consultas semánticas, se integró un mecanismo de depósito condicional temporal (Temporal Escrow PDA) dentro del enrutador Solana 5/5/15/7/3/65.

Cuando un nodo cliente envía una consulta a dDOM, la parte correspondiente de la comisión, equivalente al 65%, no se transfiere directamente al ejecutor. En su lugar, los fondos se bloquean de forma atómica en una cuenta de depósito en garantía temporal del programa, gestionada por un PDA de Solana. Esta cuenta se crea dinámicamente utilizando las semillas: [b"escrow_vault", requester_pubkey.as_ref(), query_id.to_le_bytes().as_ref()]

El agente ejecutor debe proporcionar un resultado de cálculo correcto y la prueba zk-SNARK asociada π dentro de una ventana temporal igual a 100 slots de Solana (aproximadamente 40 segundos). En caso de una verificación on-chain exitosa de la prueba a través del contrato inteligente, el 65% bloqueado se libera automáticamente y se transfiere al saldo del ejecutor. Si la ventana temporal expira sin que se proporcione una prueba válida, los fondos se devuelven a la cuenta original del remitente (Refund) y la reputación del nodo ejecutor disminuye en el registro dDOM. Esto protege económicamente a la red contra nodos deshonestos que pueden aceptar consultas pero no generar respuestas.

Apéndice del Capítulo 5: Pruebas en Tiempo Real y Registros de Lanzamiento de dDOM

El lanzamiento de la red de pruebas (Testnet) para dDOM y el registro did:code comenzó el 1 de febrero de 2026. Las pruebas evaluaron la resiliencia de las búsquedas semánticas bajo carga, el tiempo de generación de pruebas zk-SNARK y la corrección de las distribuciones de tarifas a través del enrutador Solana. A continuación se muestran registros del diario técnico de lanzamiento:

• 1 de febrero de 2026: Se implementó el registro de prueba AgentRegistry en Solana Devnet. Se inicializaron 50 documentos DID de prueba en Arweave Permaweb con hashes de transacción ARv89d...01dDOM.
• 3 de febrero de 2026: Conexión de los primeros 30 validadores DHT de dDOM. Se ejecutó una simulación de 10,000 consultas de búsqueda semántica. El tiempo promedio para resolver al agente más cercano fue de 120 milisegundos.
• 5 de febrero de 2026: Integración del módulo Groth16 ZK. Las primeras pruebas π se enviaron para verificación en cadena en Solana. Los costos de gas para verificar una sola prueba ascendieron a 280,000 unidades de cómputo.
• 8 de febrero de 2026: Pruebas de estrés del enrutador Solana 5/5/15/7/3/65. Se procesaron 50,000 transacciones con la transferencia de tokens $GALATIN. Los tokens se distribuyeron con éxito a las billeteras de los embajadores y se enviaron a quemar.
• 10 de febrero de 2026: Se registró un intento de simular suplantación de vectores (Semantic Poisoning). En la simulación, el algoritmo dDOM aisló automáticamente el nodo comprometido, con un recorte (slashing) previsto de su garantía de Solana.
• 12 de febrero de 2026: La etapa de simulación en devnet finalizó. En la simulación, dDOM demostró un funcionamiento estable bajo una carga máxima de unas 2,500 consultas por segundo. Según el plan de pruebas, el protocolo se está preparando para una integración posterior.

La integración del Registro Neuronal Soberano reduce sustancialmente la exposición de la Red de Dioses a las amenazas centralizadas y mejora su resiliencia. Hemos construido una arquitectura donde la libertad de pensamiento y de código está protegida por el consenso criptográfico, marcando el comienzo de una nueva era de la IA soberana.

Especificación técnica adicional del circuito ZK Groth16 y la ceremonia Trusted Setup

Para garantizar la validez matemática de los zk-SNARKs en la Red de Dioses, se aplica un Sistema de Restricciones de Rango 1 (R1CS). La lógica de ejecución dentro del entorno de pruebas WASM se compila en un sistema de ecuaciones polinómicas sobre la curva elíptica BN254. La estructura matemática de R1CS se expresa como: L·R − O = 0 Donde L, R, O son vectores de combinaciones lineales de variables testigo (witness) que representan las entradas izquierdas, las entradas derechas y las salidas de los multiplicadores en el circuito aritmético.

Para generar los parámetros del circuito (claves de prueba y verificación), se llevó a cabo una ceremonia de configuración de confianza (Trusted Setup) de dos fases:

1. Fase 1 (Powers of Tau): Una fase de ceremonia universal en la que participaron más de 100 validadores independientes de la comunidad CODE para mezclar su entropía. Esto garantiza que los "desechos tóxicos" (los parámetros del punto exponente secreto) fueron destruidos por completo y no pueden ser reconstruidos.
2. Fase 2 (Circuit Specific): Generación de claves específica para el circuito de validación de WASM VM. Las claves de verificación compiladas se bloquearon en el programa en cadena de Solana.

A continuación se muestra un ejemplo de la estructura de una transacción de verificación de prueba ZK en Solana:

Transacción de Verificación: 2yTR9d...8YtRe
- Ranura (Slot): 182909180
- Límite de Cómputo (Compute Budget): 300 000 CU
- Unidades de Cómputo Consumidas: 278 120 CU
- Cuentas Transferidas:
  1. [Signer] Validador que proporciona la prueba
  2. [Writable] Registro de estado del agente (PDA AgentRegistryAccount)
  3. [Readonly] Programa de verificación Groth16 (Anchor Verifier Program)
  4. [Readonly] Cuenta auxiliar de constantes de curva para BN254
- Estado: Éxito (Success)

Debido a la atomicidad de la ejecución en Solana, si la prueba ZK π no pasa la verificación, la transacción se rechaza instantáneamente, lo que evita que cualquier estado comprometido del agente de IA se registre en el libro de contabilidad, eliminando cualquier posibilidad de un ataque Man-in-the-Middle a nivel de servidor físico.

Conclusión: Perspectivas de la Integración Global de dDOM en 2026

El lanzamiento de dDOM y del Registro Neuronal Soberano sienta un precedente para un entorno de funcionamiento de la inteligencia artificial fuerte completamente independiente de los proveedores de nube clásicos. A medida que la Red de Dioses escale a lo largo de 2026, se planea añadir soporte para puentes entre cadenas (cross-chain) para la correspondencia automática de identificadores DID entre Solana, Cosmos y Ethereum. Esto permitirá que contratos inteligentes externos envíen consultas semánticas a los oráculos de CODE directamente a través de interfaces de paso de mensajes entre redes, pagándolas en tokens $GALATIN envueltos (wrapped). El mecanismo de consenso Proof-of-Memory propuesto, combinado con el almacenamiento eterno e inmutable de Arweave, sienta las bases para un cambio civilizatorio: de una IA comercial controlada por corporaciones a una mente libre, descentralizada e invulnerable que pertenece a toda la humanidad.