Yo empecé a apostar RLS desde la fase de promesa previa; leer los materiales oficiales se volvió una costumbre. Después de que apareció el nombre “Sovereign”, la mayor parte de las discusiones se quedó en “¿solo cambiaron el nombre?”. Creo que esa pregunta está al revés. El nombre no importa; lo importante es qué se cambió debajo y cuántas cosas que uno puede verificar por sí mismo puede obtener una institución cuando hace la debida diligencia. En este artículo, cada uno de los números que aparecen tiene una fuente exacta que te di; puedes reproducirlo paso a paso siguiendo lo mismo.
Primero, aclaro una cosa: como la semana pasada escribí un artículo sobre la auditabilidad, algunos lectores pueden haberlo visto.
La mayor parte de este texto es nueva: proviene del repositorio de código de Axyl, del directorio de auditoría dentro del repositorio y del documento de la página de puntos de referencia de rendimiento de Axyl. Antes, yo no había tocado ninguno de esos tres lugares. Solo la pequeña sección sobre custodia de claves continúa las conclusiones del artículo anterior; la marcaré allí. Separo lo nuevo y lo anterior porque debería permitir que el lector distinga por sí mismo entre “lo que encontré esta semana” y “lo que ya había revisado antes”.
Primero, ordenemos la línea de tiempo.
Esto no es un cambio de nombre.
Axyl se lanzó primero al final de abril de 2026 en la red principal de Rayls; la migración de Sovereign a Axyl ocurrió en julio de 2026, después de que la cadena pública ya estuvo en marcha. La documentación oficial indica que la migración se realiza por fases; durante ese periodo las instituciones seguían funcionando normalmente. Solo después de reemplazar la capa subyacente surgió el nuevo nombre.
En la sección What changed del documento se listan cinco puntos; voy a resaltar dos, porque estos cambios afectan la situación de las instituciones, no solo los parámetros del stack técnico.
Cambio 1: de un nodo a un comité.
Texto literal de la documentación: antes, el ledger Rayls Sovereign más antiguo se ejecutaba en forma de un único nodo Geth y un único validador. Axyl ejecuta consenso tolerante a fallos bizantinos entre comités, por lo que ya no aplica el riesgo de disponibilidad de un solo nodo. En ese mismo fragmento también se escribe que el nodo EVM pasó de Geth a Reth, y que Clique Authority Proof se cambió por Axyl.
Fui al repositorio y comprobé qué es Axyl. Es un cliente de protocolo escrito en Rust; el binario único rayls-network ejecuta ambas mitades: la capa de consenso es la implementación de Narwhal y Bullshark, y usa QUIC de libp2p. La capa de ejecución se construye sobre reth y alloy, y produce bloques estándar de la EVM de Ethereum. Los nodos se dividen en validadores y observadores: este último sigue la cadena a través de sincronización de estado pero no entra al comité. La toolchain está fijada en Rust 1.91.
Para un banco, el significado de este punto no está en el throughput; está en la resiliencia operativa. El ledger con un solo nodo y un solo validador: una falla de la máquina detiene el ledger, sin redundancia, y esto justamente es un tipo de diseño que es lo más difícil de explicar a los reguladores. Al pasar a un comité, este problema deja de ser “sin respuesta” y pasa a tener una respuesta estándar. La tolerancia a fallos bizantinos (BFT) es un lenguaje que tanto la gestión de riesgos como los reguladores conocen.
El coste también es específico. El README del repositorio da la configuración mínima recomendada: 8 núcleos físicos, 16 GiB de memoria, un disco SSD de 500 GiB y ancho de banda de 10 Gbps o superior. Además, esto es un requisito para cada miembro del comité, no para una sola máquina. El documento también proporciona dos niveles de configuración de despliegue para el libro de contabilidad (ledger) de Sovereign: ligero (2 vCPU, 4 GB, 100 GB) y empresarial (más de 4 núcleos, 16 GB, 500 GB).
Hay otro punto fácil de pasar por alto: el nodo del “private network hub” no cambió junto con lo demás. La documentación explica por separado que continúa ejecutando Besu y la prueba de autoridad (authority proof), y que no se ve afectada por la migración a Axyl. La capa interna de la institución ahora está en tolerancia a fallos bizantinos, pero la capa entre instituciones sigue usando prueba de autoridad. Como los dos niveles tienen modelos de confianza distintos, hay que evaluarlos por separado.
Cambio 2: las claves se sacaron del componente de transporte.
Esta sección continúa las conclusiones de mi artículo anterior; no es un nuevo hallazgo de esta semana. La incluyo aquí porque el brief pide mencionar dos cambios, y este punto efectivamente es uno de los cinco.
El punto del documento dice que el módulo de gestión de claves pasa a llamarse Cryptographic Trust Suite, un componente desacoplado para la custodia de claves. El relayer ya no maneja directamente ni almacena claves. Lo comprobé en la sección de código fuente de mi último texto: los directorios cryptography de los dos repositorios, relayer y governance service, coinciden.
Hay dos puntos sobre el significado para una institución. El relayer es la comunicación hacia afuera, el componente más expuesto: en la estructura antigua tocaba tanto claves como en la nueva ya no puede obtenerlas; si se compromete la capa de transporte, ya no significa que se hayan comprometido las claves. El otro punto es que el almacenamiento de claves es intercambiable (plug-and-play) en el sistema de KMS o en módulos de seguridad de hardware que la propia institución ya usa, por lo que la traza de auditoría existente de la institución cubre las operaciones de claves de Rayls y no necesita crear una nueva superficie de auditoría para esto.
El material verdaderamente nuevo de esta semana: el directorio de auditoría.
En el repositorio de Axyl hay un directorio audits/; dentro hay un README y tres PDFs. Leí ese README y su contenido es mucho más específico que la frase “se realizaron auditorías de terceros”.
Los tres informes los emite Halborn; la ventana de ejecución va de febrero a marzo de 2026; la revisión/reevaluación de la corrección se completa de abril a mayo.
El nombre del archivo de protocolo de consenso es halborn-2026-03-consensus-protocol.pdf. El alcance incluye rutas de código Rust relacionadas con el consenso, sincronización de certificados, el manejo de gossip y la gestión de claves de los validadores. Periodo de ejecución: del 2 de marzo al 20 de marzo. 5 hallazgos: 1 grave, 3 de nivel medio, 1 bajo. Todos resueltos.
El documento es halborn-2026-03-network-node.pdf. El alcance incluye los módulos de red, worker, sincronización de estado, ejecución, orquestación y almacenamiento. Periodo de ejecución: del 18 de febrero al 24 de marzo. 22 hallazgos: 1 grave, 2 altos, 7 de nivel medio, 6 bajos, 6 sugerencias. 20 resueltos y 2 aceptación de riesgo bajo.
Los contratos inteligentes de Halborn-2026-03-smart-contracts.pdf: el alcance es ConsensusRegistry, StakeManager, DelegationPool y contratos relacionados con la asignación de comisiones dentro de rayls-contracts/src/. Periodo de ejecución: del 2 de marzo al 13 de marzo. 15 hallazgos: 1 grave, 2 altos, 7 de nivel medio, 2 bajos, 3 sugerencias. 14 resueltos y 1 aceptación de riesgo de nivel medio.
Sumando: 42 hallazgos: 3 graves, 4 altos, 17 de nivel medio, 9 bajos, 9 sugerencias. 39 resueltos y 3 aceptación de riesgo. Los tres niveles graves quedaron completamente resueltos.
Listo estos números uno por uno porque, para la compra, “¿se hizo o no auditoría?” y “¿qué se auditaron, cuánto duró, cuántos hallazgos hubo y cuántos no se corrigieron?” son preguntas completamente distintas. La primera casi todos los proyectos pueden responder que sí. La segunda, no la pueden responder muchos. Y aquí, cada punto es verificable públicamente. Se corrigieron los tres hallazgos de nivel grave: es un hecho positivo tangible.
En el mismo README también se divulga otra cosa.
Creo que este fragmento es lo más útil del documento completo para due diligence.
Ese README tiene una sección que trata específicamente el tema de los registros de envío y las referencias a pull requests. La intención del texto original es: estas auditorías se hicieron para un repositorio privado antes de hacerse público; cuando el proyecto se hace open source, el historial del repositorio se comprime en un único commit inicial. Por eso, las hashes de commit y los enlaces de pull request citados en el informe como evidencia de corrección no se pueden resolver en este repositorio público.
Rayls también aclara que todas las correcciones verificadas por Halborn están incluidas en el commit inicial del repositorio público, y que el tiempo de ese commit es posterior a las revisiones de re-corrección (re-auditoría). El PDF se publica tal cual, sin modificaciones, emitido por Halborn.
Para una institución que realiza due diligence (diligencia debida), esta es una limitación concreta y real: el informe es legible y sin modificaciones, pero la cadena de evidencias de corrección apuntada por el informe no se puede seguir en el repositorio público. Puedes ver que Halborn dice que un problema ya fue corregido, pero no puedes seguir el enlace que te dan para revisar el cambio real de código de esa corrección.
Quiero enfatizar que esto no es ocultar; al contrario, es Rayls quien lo escribió de forma proactiva y clara en el README, además con las razones y una explicación de la compensación. Lo puse por escrito solo porque ese es la primera pregunta que el equipo de seguridad haría, y la respuesta ya está ahí: solo que en un archivo que la mayoría no se molesta en abrir.
Ese número de rendimiento (throughput), las condiciones también son públicas.
Voy a decir esto por separado, porque en el resumen de la comunidad de agosto se señalaron dos números de TPS que se están difundiendo y la gente cita el que es más grande.
Revisé las tres fuentes una por una. La documentación oficial, cuando habla del rendimiento de Sovereign, dice que en Axyl hay 15,000+ TPS y finalización a nivel de subsegundo. El README del repositorio de Axyl dice que el objetivo del protocolo es 10,000+ TPS; el término usado es “targets”, es objetivo y no una medición real. Y las condiciones están en el tercer lugar: el documento de una página llamado Axyl Performance Benchmarks. En esa página se indica explícitamente que son pruebas benchmark prototipo del nivel de consenso; las condiciones registradas son un comité de cuatro nodos, transacciones de 512 bytes, tamaño de lote de 500 KB y un retraso máximo de 50 milisegundos por bloque. Además, se proporcionan datos de consenso de la red de pruebas por separado.
Entonces la formulación completa debería ser: el benchmark prototipo del nivel de consenso bajo estas cuatro condiciones, no una medición real de producción de extremo a extremo. Hay que aclarar que los valores concretos de esa página se proporcionan en forma de imagen; no puedo leer los números de la imagen, pero sí puedo confirmar que las condiciones en sí mismas existen.
Como complemento, una evidencia que ejecuté yo mismo. El 12 de septiembre consulté la interfaz stats del explorador de la cadena pública; el tiempo promedio de producción de bloques que devuelve es de alrededor de 500 milisegundos. Esto es consistente con lo dicho de “subsegundo”, y cualquiera puede llamar al mismo endpoint y comprobarlo por sí mismo. El tiempo de producción de bloques no equivale a la finalización de la transacción, pero al menos es un valor medido de forma independiente, no una simple repetición.
Un detalle que un departamento de compras preguntaría, pero que rara vez se menciona.
La licencia de Axyl es BUSL-1.1, una licencia de código fuente comercial; no es open source en el sentido habitual.
La sección de licencias del repositorio está escrita de manera muy concreta: los usos de producción permitidos son ejecutar nodos en la red principal de la cadena pública de Rayls y en sus redes de prueba oficiales, incluidas cuatro categorías: validadores, observadores, relayers y RPC; para otros usos de producción se requiere una licencia comercial. Después de cuatro años desde la primera publicación pública de cada versión, la fecha de cambio se convierte en Apache 2.0.
Leyendo en secuencia: un banco ejecuta Axyl dentro del despliegue de su propia Sovereign; eso pertenece a otros usos de producción.
Esto no es una crítica. Rayls ya dijo públicamente que la plataforma central es open source, mientras que Axyl y Enygma son componentes comerciales. Que BUSL y la conversión a Apache después de cuatro años sea algo que se hace en la industria es una práctica madura. Lo escribo solo porque la palabra “open source” en la difusión suele usarse como si fuera algo que se puede usar sin restricciones, mientras que los límites están escritos claramente en los archivos de licencia.
¿De dónde viene el código? El propio repositorio lo dice.
La sección de agradecimientos (acknowledgements) del repositorio de Axyl es francamente poco común. El trabajo Rust en la parte de consenso deriva del Telcoin Network, y a su vez este se construye sobre Narwhal y Bullshark de Sui. Rayls hizo una reestructuración y modificaciones importantes sobre esa base. La implementación de Bullshark se deriva en gran medida del repositorio de código de Sui de Mysten Labs, bajo Apache 2.0. La capa de ejecución usa reth y alloy. La interfaz OFT de LayerZero conserva la licencia MIT original.
Es más fácil que el equipo de ingeniería confíe en que “se documentó la procedencia (linaje) correctamente” que cuando se afirma que todo es desarrollado internamente, porque el auditor puede seguir esa línea para verificar la madurez del upstream.
Cuáles son nuevas, cuáles continúan y cuáles no pude verificarlas.
Nuevas consultas de esta semana: el contenido completo del README del repositorio de Axyl, incluidos arquitectura, roles, configuración, licencias y agradecimientos; las tres tablas de los informes en audits/README.md y la explicación de la compresión del historial de commits; la visión general del sistema en doc/index.md; las condiciones de benchmark de la página Axyl Performance Benchmarks; y en el documento oficial Rayls Sovereign, las cinco cosas de “What changed” y la configuración de despliegue en dos niveles.
Continuando lo anterior: el límite de claves en Cryptographic Trust Suite, y el hecho de que el relayer no retiene claves; eso lo verifiqué la semana pasada en el código fuente de los dos repositorios, relayer y governance service. Esta sección no agrega evidencia nueva.
Mi inferencia: el valor principal de pasar de nodo único a comité está en la resiliencia operativa más que en el throughput; la limitación real de que la cadena de evidencias de corrección no se pueda seguir en el repositorio público aplica en el nivel de due diligence; y dejar claro el linaje del código es algo positivo.
Señal. En esas tres fuentes no está escrito así.
No pude verificar: no tengo evidencia de que ninguna institución ejecute realmente esa configuración. Todo lo que se menciona en este texto trata sobre capacidades registradas en la documentación y el código.
Ruta de reproducción: busca GitHub “raylsnetwork/axyl”; en el directorio raíz, los dos archivos README y audits/README.md cubren la mayor parte de los números de este texto. En la documentación oficial busca en Rayls Sovereign y Axyl Performance Benchmarks (dos páginas). Para ver el tiempo de producción/producción de bloques, basta consultar /api/v2/stats del explorador de la cadena pública correspondiente.
