Empecé a hacer staking de RLS desde la fase de compromiso previo; leer el blog oficial se ha vuelto una costumbre. El 12 de septiembre, este artículo sobre la auditabilidad: en la segunda mitad enumera seis criterios y dice que, mediante la construcción, se satisfacen completamente. Estoy de acuerdo con esa idea, pero "cumplir mediante la construcción" es una afirmación que se puede verificar, no algo que uno tenga que creer a ciegas. Por eso dediqué una semana: tomé una por una esas seis condiciones, las busqué en el código fuente público, en la documentación técnica y en las interfaces on-chain, para encontrar correspondencias; ahora lo comparto con todos.
Primero, hablemos de su clasificación. Creo que es útil, y va más allá de la mayoría de los debates de "privacidad versus transparencia". Para la auditabilidad, hay tres vías: exigencia matemática, donde se incorpora en la construcción criptográfica; confianza en el hardware, apoyada en la integridad de un entorno de ejecución confiable; y control de acceso por políticas, donde quién puede ver qué lo determina la configuración del operador de la red.
Con base en ello, establece seis criterios de auditabilidad a nivel de institución, y luego dice que la matemática fuerza cumplir todas las seis condiciones mediante una construcción.
Para no seguir diciendo cosas que suenen a teoría, fijemos un escenario: un banco participa en un piloto de moneda digital del banco central, y el auditor del banco central quiere ver las transacciones de ese banco en la red. El caso de Brasil, Drex, es ese escenario: Rayls está haciendo un piloto ahí. Solo hay una pregunta: ¿por qué lo que ve el auditor es confiable?
La primera condición y la segunda: divulgación selectiva y alcance limitado.
El punto de llegada de estas dos condiciones es la misma cosa: las claves de observación.
Rayls tiene GitHub público; en el directorio cryptography del repositorio relayer hay un archivo mlkem.go. Ahí, GenerateSalt usa la clave pública de observación ML-KEM-768 del destinatario para compartir la clave; RecoverSalt usa la clave privada de observación ML-KEM-768 local para desempaquetar; se llaman las funciones estándar del paquete Go NewEncapsulationKey768 y NewDecapsulationKey768. Los nombres de variables están escritos como view public key y view secret key.
Así que la base criptográfica para las claves de observación es ML-KEM-768, y esta afirmación tiene respaldo en fuentes.
Una aclaración más sobre su significado. El 30 de agosto, el artículo de Rayls sobre preparación cuántica enfatizaba específicamente: si una afirmación de seguridad cuántica no se expresa a nivel de parámetros, entonces no es una postura sino una etiqueta, y el ejemplo que dieron justamente no es lo mismo entre ML-KEM-512 y ML-KEM-1024. En ese artículo, al hablar de su actualización, solo se escribió «reemplazado por ML-KEM». En el código se ve que es 768. Esto no es una falla: 768 es un parámetro oficial de NIST, y también el valor recomendado por la industria para despliegues empresariales. Solo que antes era un hecho que había que leer el código para saber; ahora se puede citar directamente.
Ya que los niveles están definidos, el costo de cambiar de nivel se puede calcular. FIPS 203 fija los tamaños: la clave pública de encapsulación de 768 ocupa 1184 bytes; el cifrado ocupa 1088 bytes; y ambos tamaños para 1024 son 1568 bytes.
Lo clave es la frecuencia. Y la documentación de gestión de claves también lo escribe: el encapsulado se hace una vez por cada par de participantes en el despliegue de la red; el cifrado se guarda en el hub de red privada, y después cada mensaje solo lleva una etiqueta pequeña. Por eso no crece con el volumen de transacciones. Una red de 30 instituciones tiene 435 pares; dos niveles de diferencia son de ~215 KB. Incluso con 60 instituciones y 1770 pares, la diferencia es menos de 1 MB, y además es algo de una sola vez.
Este volumen es tan pequeño que no tiene sentido, y ahí está exactamente la conclusión: si algún despliegue necesita un nivel más alto, la resistencia no vendrá del ancho de banda o el almacenamiento; eso es simplemente cambiar código. En la discusión genérica de migración post-cuántica, la elección de parámetros suele ser un intercambio de rendimiento; en esta capa no es así.
Alcance limitado a esta condición; la documentación técnica añadió la otra mitad: la capacidad de observación puede limitarse por ventana de tiempo y por cuenta.
Tercera condición: separación entre visibilidad y permisos.
La documentación técnica lo expresa con más firmeza que el blog: las claves de gasto y de observación son matemáticamente independientes; no se puede derivar una a partir de la otra. En el resumen de la revisión de seguridad, la frase es aún más directa: los permisos de observación y los permisos de gasto se separan por criptografía, no por configuración; por eso un error de configuración no puede convertir permisos de lectura en permisos de escritura.
El documento de gestión de claves también corrigió una suposición mía. Todo el material de claves del lado de la institución lo procesa de manera unificada un componente llamado Cryptographic Trust Suite, que se ejecuta dentro del propio perímetro de la institución. Relayer nunca posee ninguna clave; solo se encarga de realizar cifrado y descifrado por cuenta de otros. La autorización de lectura del auditor proviene de esto: cada institución cifra su propia clave de observación con la clave pública del operador, y junto con un código de autenticación lo guarda en el hub de red privada como parte del registro del participante; el servicio de auditoría recupera esto al iniciar.
Aquí hay un documento secundario que lo saca a la luz: la institución puede ver en el hub qué participantes existen registrados, y así saber qué cosas han sido configuradas como legibles. El hecho de conceder visibilidad en sí mismo es visible.
Por cierto, estas tres clases de tablas de claves de esta página también confirman lo que vi en el código: claves de firma ECDSA sobre secp256k1; claves de observación ML-KEM; y claves de gasto Baby JubJub sobre BN254. El documento y el código fuente coinciden por completo.
Cuarta condición: verificabilidad de corrección.
Este blog se apoya en pruebas de conocimiento cero. Rayls tiene un servicio dedicado gnark-api para generar y verificar pruebas Groth16.
El documento de la transacción Enygma aporta varios parámetros concretos que normalmente nadie cita. El tamaño del conjunto anónimo es 2 o 6; es decir, cada transferencia se empaqueta con otra transferencia o con cinco más, y los observadores no pueden distinguir quién inició. Un crossTransfer, como máximo, apunta a 5 cadenas destino y lleva hasta 5 acciones invocables. La atomicidad de un lote la garantiza el contrato Enygma en el hub de red privada: primero valida las pruebas de todo el lote, y solo entonces se acuña el dinero para cualquier destino.
Además, hay un costo operativo documentado de forma muy directa: la suma de procesamiento por lotes, generación de pruebas y verificación en el hub está en el orden de decenas de segundos, así que hay que planificarlo así, en lugar de hacerlo como la finalidad de nivel sub-segundo de transacciones internas de una institución. Verificabilidad de corrección no es gratis; su precio son esos decenas de segundos.
Pero hay una parte del lenguaje que vale la pena sacar y decir por separado, porque involucra cuatro materiales.
La documentación técnica dice que el compromiso Pedersen «oculta un valor, y al mismo tiempo liga el comprometedor a ese valor, de modo que no se pueda cambiar posteriormente». La conclusividad de la vinculabilidad se trata como una propiedad en la afirmación. El artículo cuántico de agosto marcó esta parte como «no requiere tratamiento», es decir, ya es resistente a lo cuántico. En el código, en enygma_math.go se ve que usa dos generadores independientes sobre la curva BabyJubJub: calcula v·G + r·H; eso es una construcción estándar y correcta de Pedersen. Y los dos artículos académicos de Rayls, IACR 2025/1639 y 2025/1638, describen la palabra que usa todo el diseño como quantum-private, o sea privacidad cuántica; la explicación es que un adversario cuántico no puede inferir el pagador, el receptor y el monto de la transacción. Esta es una afirmación puramente sobre confidencialidad.
Mi lectura es que, de las cuatro fuentes, solo el paper usa términos precisos. BabyJubJub se construye sobre el campo escalar BN254, así que la ocultación es válida para un adversario cuántico; esa es precisamente la parte que el paper sostiene. La vinculabilidad depende del logaritmo discreto, que es justo la parte que el paper no sostiene.
Para una institución que necesita demostrar una postura de cumplimiento capaz de resistir auditorías adversarias, «el oponente cuántico no puede ver mi saldo» y «el oponente cuántico no puede falsificar un saldo falso» son dos cosas distintas; y en el documento y el blog se han escrito como si fuera una sola. El paper no comete esa fusión.
Quinta condición: revocable.
Esta afirmación la busqué durante mucho tiempo: en la documentación de Rayls hay una página en un documento llamado Opciones de diseño de red privada, donde encontré la respuesta. Pero no es lo mismo que lo que dice el blog, y además creo que es más interesante.
El auditor es un rol designado por el operador; en paralelo están el participante y el emisor. Lo clave es que la visibilidad del auditor no es un interruptor, sino un asunto de nivel; este documento lo dibuja con tres ejemplos.
En la capa de red de moneda digital del banco central, el auditor puede descifrar las transacciones entre nodos. En la capa de plataforma de negociación de activos tokenizados, el auditor supervisa verificando las promesas (compromisos) de Pedersen publicadas por cada nodo hacia el hub; el documento indica explícitamente que el auditor no tiene permiso de acceso directo a los datos del payload de transacciones cifradas, solo ve las pruebas, no el contenido. El nivel más extremo es el mercado NFT operado por DAO: el rol de auditor lo asume el verificador de pruebas de la blockchain pública, con acceso cero por defecto; solo se habilita el descifrado de esa transacción cuando la verificación de la prueba muestra fraude.
Las tres capas se presentan juntas; la frase del auditor sobre el navegador, «el nivel de descifrado se puede configurar durante la fase de despliegue», es donde todo aterriza.
Volvamos a lo que dice el blog. El blog afirma que la visibilidad se puede recuperar y que la recuperación está forzada mediante criptografía. El documento ofrece otro diseño: la visibilidad se configura por nivel durante el despliegue de la red, no se revoca después. Ambas cosas limitan al auditor: una es una restricción previa y la otra es una cancelación posterior.
Sí, el nivel de gobernanza tiene mecanismos de revocación: los roles se pueden actualizar; los estados de los miembros pueden estar activos, congelados o deshabilitados; el congelamiento lo ejecuta el operador mediante el contrato de gobernanza ParticipantStorage. Pero no encontré una descripción de cómo revocar la visibilidad que un auditor ya tenía concedida. Hay un detalle que hace este tema muy concreto: el documento dice que el auditor recibe una vez un intercambio de claves Diffie-Hellman cuando se integra un nodo nuevo, y que la capacidad de acceso se entrega en forma de material de claves. Revocar el rol puede impedir futuras concesiones; si además se puede hacer que el material de claves ya entregado deje de ser válido, todavía lo estoy investigando.
Sexta condición: persistencia.
Esta condición es lo contrario de la quinta: el blog se ha minimizado el tema.
Dice que la persistencia pertenece a la gestión de claves, que es un problema resoluble, y al leerlo parece un espacio en blanco. Pero la documentación de gestión de claves ya lo convierte ese «se puede resolver» en un plan concreto. El almacenamiento de claves es enchufable a lo que la institución ya tiene: AWS KMS, Google Cloud KMS, Azure Key Vault, un HSM local; el uso de archivos locales se limita al entorno de desarrollo. El cifrado es por sobre (envelope encryption) y lo que queda persistido es el cifrado, no el material de claves.
Lo más crucial es esta frase. Como cada cifrado y descifrado pasa por el servicio de gestión de claves propio de la institución, esos rastros de auditoría que ya se generan por esas instancias cubren las operaciones de claves de Rayls igual que cubren otras cosas que corre la institución. La conclusión para el área de cumplimiento en el documento es: no hace falta crear una nueva superficie de auditoría para esto. Eso es exactamente lo que busca la persistencia: el rastro de auditoría queda colgado del sistema propio de la institución, no en los registros exclusivos de algún proveedor.
La rotación también está escrita con mucho detalle: cada cadena puede tener varias claves de firma; se rota según el uso; a cada clave se le sigue un nonce individual; y las claves que ya firmaron transacciones pendientes permanecen válidas hasta que esas transacciones se liquiden. Esto resuelve exactamente la brecha más propensa a fallos en un proceso de rotación.
Pero hay un límite: la sección que describe la rotación trata de claves de firma; no vi rotación de claves de observación en estas páginas. Y la persistencia, por cierto, se preocupa de si, muchos años después, aún se podrá leer el rastro de auditoría; eso depende mucho más de la parte de las claves de observación.
La herramienta que en realidad usa el auditor.
Al principio se trata toda la criptografía, pero lo que el auditor realmente usa al sentarse y trabajar es una herramienta. El documento indica que el navegador del auditor de la red privada es accesible solo por el auditor, y que el operador y otros participantes no pueden acceder; además, ofrece una vista retrospectiva descifrada de transacciones entre cadenas.
Alcance limitado: solo cubre transacciones entre cadenas registradas al hub de red privada; las transacciones ocurridas dentro del propio libro soberano de alguna institución no permiten acceso a auditores. Por eso, la visibilidad de auditoría es entre instituciones, no dentro de una institución.
Entonces, ¿existe un ejemplo que pueda verificarse por completo?
Sí, y solo hay uno, porque la propia arquitectura determina que la mayor parte de las cosas no se pueden ver.
El documento oficial explica el motivo: las transacciones Enygma se originan desde el propio Sovereign ledger de cada institución; cada institución despliega su propio navegador para monitorear ese ledger, y la parte entre cadenas cae en el hub de red privada, donde la ve el navegador del auditor. Las actividades de la institución por diseño no están en la blockchain pública, así que no se pueden encontrar transacciones Enygma en el navegador de la blockchain pública. No es una ausencia: es un resultado inevitable de una arquitectura en tres capas.
Pero ese contrato de bloqueo de Parfin está en una blockchain pública, y además es un ejemplo completo de «imposición matemática».
El que empieza con la dirección 0x1463889D, el nombre del contrato RlsTokenLock, tiene el código fuente verificado y no es un contrato proxy. Esto significa que es de pocos objetos que pueden leerse el código y consultarse el estado actual. Puse ambos lados en correspondencia.
El constructor declara totalAmount de 1.070.493.535 RLS. Las RLS que el contrato tiene actualmente en posesión son 1.070.493.535. No falta ni una wei; está completamente cubierto.
La tabla de desbloqueo es aún más digna de mencionar. El constructor tiene 48 timestamps y los decodifiqué todos: primer nivel el 1 de diciembre de 2027; luego un nivel el día 1 de cada mes; último nivel el 1 de noviembre de 2031. El rango es de ~3,92 años y cada nivel es de ~22,3 millones de RLS. Materiales publicados antes enfatizaban el bloqueo hasta diciembre de 2027; eso era el primer nivel, correcto; el panorama completo que da el constructor muestra que después del primer nivel aún hay casi cuatro años de liberación mensual.
Los comentarios propios del contrato expresan la intención de diseño con mucha claridad: no es actualizable; los términos del despliegue son para siempre; sin desbloqueo anticipado, ninguna clave puede moverse a un nivel superior antes de la fecha de vencimiento. Estas dos cosas las comprobé una por una contra el código: el cronograma está escrito en el constructor sin setter, y el contrato realmente no es un proxy.
Así es «imposición matemática» en un ejemplo que puedo verificar por completo: la afirmación coincide con el código, y además el código es más específico que la afirmación. En las seis normas, todo lo que yo solo encontraba rastros en el código fuente y en la documentación, aquí se puede ver de principio a fin.
Además, otras dos referencias externas.
Cuando el blog habla de TEE dice que Intel SGX tuvo vulnerabilidades registradas que rompieron garantías de aislamiento. Esa frase es correcta, pero minimiza su propio argumento. Las de tipo aislamiento incluyen Foreshadow, Plundervolt, EPIC Leak y SmashEx, con números CVE-2018-3615, CVE-2019-11157, CVE-2022-21233, CVE-2021-0186 y CVE-2021-33767, respectivamente. Lo realmente devastador es SGAxe de 2020: usa CVE-2020-0549 para extraer directamente las claves de autenticación desde una enclave de certificación en el entorno de producción de Intel; luego puede emitir declaraciones arbitrarias que el propio servicio de certificación de Intel determina como legítimas.
La argumentación del blog dice que la garantía de TEE la proporcionan pruebas emitidas por hardware, y que SGAxe rompe justamente el eslabón que emite esas pruebas. La falla más grave no fue que robaran datos, sino que se falsificó la garantía en sí. Si lo digo con justicia: todas estas cosas ya se repararon mediante actualizaciones de microcódigo y recuperación de TCB. Hoy el SGX no es el SGX de 2018; una formulación precisa es que el root of trust del hardware tiene una superficie de vulnerabilidades de forma rotativa.
Otra parte es donde dice que el Project Agora de BIS está convergiendo hacia la misma arquitectura. Revisé el informe de prototipo del 27 de mayo de BIS: topológicamente sí se parece, con una estructura de doble capa, un libro compartido y libros independientes por jurisdicción. Pero el límite de Agora está trazado por jurisdicción; el informe no explica cómo se implementa el control de acceso dentro de los libros de la jurisdicción. Por eso, si esa convergencia se extiende hasta el nivel del modelo de confianza, con la información pública existente no se puede ver.
Qué cosas están confirmadas y cuáles son mis inferencias.
Confirmado: ML-KEM-768 se usa para claves de observación; ver relayer/cryptography/mlkem.go; Pedersen para generar dos generadores sobre BabyJubJub; ver enygma_math.go; la clave privada del auditor se cifra y se entrega mediante relayer; ver governance service/cryptography/service.go; la matemática de la clave de gasto y la clave de observación es independiente; el alcance de observación puede limitarse por tiempo y por cuenta; el navegador del auditor cubre solo transacciones entre cadenas y el nivel de descifrado puede configurarse en la fase de despliegue; todo ello se ve en los documentos técnicos oficiales. Cryptographic Trust Suite mantiene las claves de forma unificada y Relayer nunca mantiene claves; el almacenamiento de claves es enchufable a KMS o HSM; el cifrado de sobre; los registros de auditoría de la gestión de claves propia de la institución que actúan como rastro de operaciones criptográficas; las claves de firma se rotan según el uso y las claves que ya firmaron transacciones pendientes permanecen válidas hasta que se liquiden; el encapsulado se completa una vez, de forma puntual, para los participantes en el momento del despliegue de la red; el tamaño del conjunto anónimo es 2 o 6; un crossTransfer apunta como máximo a 5 cadenas objetivo; la finalidad está en el orden de decenas de segundos; congelar participantes se ejecuta mediante el contrato de gobernanza ParticipantStorage por parte del operador; todo ello se ve en los documentos técnicos oficiales. En RlsTokenLock: el estado de verificación, el atributo no-proxy, el cronograma de 48 niveles, y la declaración de montos vs saldos reales, todo se lee a través de la interfaz del navegador público el 12 de septiembre de 2026. Los números de CVE de vulnerabilidades de SGX vienen de los registros de CVE y del paper de SGAxe. La estructura y los datos de Agorá vienen de los materiales públicos de BIS.
Mi inferencia: de los cuatro materiales, solo el artículo usa palabras precisas sobre Pedersen. «Los límites los impone la matemática» describe una ejecución, no una distribución. SGAxe sostiene mejor el argumento del blog que las vulnerabilidades de tipo aislamiento. En estos tres materiales no se escribe así.
No pude verificar: el mecanismo de retirada posterior de la quinta condición. Revisé cinco documentos: gestión de claves, navegador del auditor, base criptográfica de Enygma, congelamiento de participantes, opciones de diseño de red privada y el hub de red privada. Además de dos repositorios de código, relayer y el servicio de gobernanza. Encontré tres niveles de configuración de visibilidad, el mecanismo de concesión, y el congelamiento y deshabilitación de participantes; pero no encontré una implementación que revocara la visibilidad concedida ya, y además forzada mediante criptografía. Tampoco encontré rotación a largo plazo de claves de observación: la sección que describe la rotación habla de claves de firma.
Finalmente, una cosa que no tiene relación con la tecnología.
En la misma semana en que se publicó este artículo, la oficial anunció que el 55% de los niveles de staking se extenderían hasta el 15 de septiembre, y dijo que durante el ajuste del mecanismo de staking permitirían a los primeros patrocinadores seguir recibiendo esa parte de los rendimientos; las actualizaciones posteriores sobre staking y sobre la economía de tokens más amplia, incluida la quema, se publicarían más adelante.
Desde la fase de precompromiso ya estaba haciendo staking y participé plenamente durante tres meses. El nivel original terminaba el 9 de septiembre; esos días, en la interfaz vi que el cupo estaba al tope y que no se podía añadir más, y llegué a pensar que era un problema del frontend. Ahora veo que el mecanismo se está ajustando.
Esta parte es mi opinión personal, no una afirmación fáctica: en la ventana de ajuste del mecanismo, en lugar de cortarlo directamente, se eligió extenderlo y, además, se dejaron fechas explícitas. Creo que eso es una muestra de buena fe. Lo más fácil que ocurre en la etapa de ajuste es quedarse en términos ambiguos; dar una fecha exacta implica que al vencer se cumple o se debe volver a explicar.
Esto es solo un evento concreto y no constituye un juicio sobre ningún acuerdo a largo plazo. No predigo rendimientos ni recomiendo a nadie tomar decisiones con base en esto.
Fuentes de referencia: blog oficial de Rayls Auditability without surveillance: why mathematical enforcement beats trusting the code, 12 de septiembre de 2026; dos páginas del documento técnico oficial de Rayls: base criptográfica de Enygma y navegador del auditor de red privada; repositorios rayls-sovereign-relayer y rayls-sovereign-pnh-governance de la organización GitHub raylsnetwork; el explorer.rayls.com de la blockchain pública de Rayls: interfaces de addresses y smart-contracts, con tiempo de extracción el 12 de septiembre de 2026; NIST FIPS 203; registros CVE 2018-3615, 2019-11157, 2020-0549, 2021-0186, 2021-33767, 2022-21233 y el paper de SGAxe; informe de prototipo BIS Project Agorá othp110; archivos electrónicos de criptografía IACR 2025/1638 y 2025/1639; anuncio del 12 de septiembre de 2026 en la cuenta oficial de X de Rayls.
