Lo que descubrí al investigar el consenso, la arquitectura de liquidación y los recibos de transacción de Rayls.
Empecé con una pregunta sencilla:
Si una cadena de bloques promete finalidad en menos de un segundo, ¿significa eso que toda la transacción se completa en menos de un segundo?
Al principio, la respuesta podría parecer obvia. Se confirma una transacción, la red alcanza el consenso y la operación termina.
Pero la infraestructura financiera es más compleja que eso.
Una transacción puede confirmarse en un libro mayor mientras una operación más amplia sigue dependiendo de otro libro mayor, un retransmisor, la verificación de pruebas o la ejecución en el lado de destino.
Mientras investigaba Rayls, descubrí que para entender sus afirmaciones sobre finalidad hay que mirar más allá de las cifras de velocidad destacadas.
La clave es saber qué entorno de Rayls gestiona la transacción, qué evento cuenta como definitivo y si la afirmación abarca todo el flujo de trabajo o solo una etapa.
1. Finalidad y finalización de una transacción no son lo mismo
Pensemos en una transferencia entre dos instituciones financieras.
La institución emisora registra la instrucción. La transacción se procesa. Después, puede que la institución receptora tenga que validar y completar su parte de la operación.
Calificar el proceso de «instantáneo» puede ocultar que intervienen varios pasos.
Los sistemas de cadena de bloques presentan una distinción similar.
- Finalidad del consenso: La red ha acordado la posición de una transacción en su historial confirmado.
- Ejecución: La transacción aplica correctamente sus cambios al estado de la cadena de bloques.
- Finalización de extremo a extremo: La operación prevista ha concluido en todos los sistemas implicados.
Están relacionadas, pero no son intercambiables.
Una transacción puede alcanzar la finalidad en su registro de origen sin que se haya completado todo el flujo de trabajo entre redes.
Eso no significa que la afirmación sobre la finalidad carezca de sentido. Significa que debemos entender exactamente qué mide.
2. Rayls tiene distintas rutas de transacción
Rayls no es simplemente una cadena de bloques con un único mecanismo de liquidación. Su arquitectura incluye varios entornos diseñados para distintos requisitos.
Rayls Sovereign ofrece registros privados para instituciones individuales.
Rayls Private Network conecta registros Sovereign a través de un Private Network Hub compartido.
Rayls Public Chain ofrece un entorno público compatible con la EVM.
Según la «documentación oficial de arquitectura» de Rayls (https://docs.rayls.com/docs/rayls-high-level-architecture), la fuente de verdad depende de la ruta de la transacción.
Ruta de la transacción - Fuente de verdad
Dentro de un registro Sovereign - El registro de la institución
Entre registros Sovereign dentro de una Private Network - Private Network Hub
Entre registros Sovereign a través de Public Chain - Public Chain
Esta es una distinción importante.
Una transacción procesada íntegramente en el registro de una institución no es lo mismo que una transacción que se mueve entre instituciones. Una transacción que implica a Public Chain sigue otra ruta de liquidación.
Así que, en lugar de preguntar solo «¿Qué tan rápido es Rayls?», una pregunta más útil sería:
¿Qué entorno liquida esta transacción y qué es exactamente lo que ha alcanzado la finalidad?
3. ¿Cómo contribuye Axyl a la finalidad?
Rayls utiliza Axyl como mecanismo de consenso para su Public Chain. Su documentación también indica que Rayls Sovereign adoptó Axyl en julio de 2026, en sustitución de la prueba de autoridad Clique.
Sin embargo, por ahora, Private Network Hub sigue utilizando la prueba de autoridad de Hyperledger Besu.
Eso significa que Axyl no debería describirse como el mecanismo de consenso de todos los entornos de Rayls.
Vale la pena entender su diseño porque separa varias responsabilidades.
Narwhal: Garantizar la disponibilidad de los datos
Axyl utiliza Narwhal para organizar lotes de transacciones en un grafo acíclico dirigido, o DAG.
En lugar de tratar los datos de las transacciones como algo que siempre debe generar secuencialmente un solo participante, este diseño permite difundir los datos en paralelo.
El objetivo es que los validadores tengan disponibles los datos pertinentes de la transacción.
Bullshark: Acordar el orden
No basta con que los datos estén disponibles. La red también debe acordar el orden en que se confirman las transacciones.
Bullshark procesa el DAG y establece un orden coherente conforme a las reglas de consenso del protocolo.
El diseño se basa en supuestos de consenso tolerante a fallos bizantinos para ayudar a que los validadores honestos acuerden un historial coherente, aunque algunos participantes se comporten de forma incorrecta o no estén disponibles, siempre dentro de los límites de fallos del protocolo.
Reth: Ejecución de transacciones
Una vez establecido el orden de las transacciones, Reth se encarga de la ejecución de la EVM.
Aquí aparece otra distinción importante.
Una transacción puede enviarse a una red y aun así no ejecutarse correctamente. El consenso y la ejecución cumplen funciones distintas: uno establece el orden acordado y la otra aplica las transacciones válidas al estado de la EVM.
Esta diferencia cobra especial relevancia cuando los desarrolladores consultan los recibos de las transacciones.
Fuentes: «Rayls Axyl overview» (https://docs.rayls.com/docs/meet-axyl-the-consensus-behind-rayls) y «Axyl technical documentation» (https://docs.rayls.com/docs/about-the-axyl-consensus-algorithm).
4. El detalle que llamó mi atención: transacciones sin recibos
Al leer la documentación de Axyl, encontré una salvedad dirigida a los desarrolladores que merece atención.
La documentación explica que las transacciones no válidas pueden omitirse sin generar un recibo.
Algunos ejemplos son las transacciones con una firma incorrecta, saldo insuficiente, nonce no coincidente o una transacción duplicada.
También señala que Public Chain no expone un mempool público.
¿Por qué es importante?
Los desarrolladores suelen esperar que una transacción enviada permanezca pendiente hasta que se confirme o se revierta. Pero si se omite una transacción no válida sin generar un recibo, una aplicación no puede asumir con seguridad que la transacción simplemente está esperando a ser incluida.
Para una aplicación de monedero o de pagos, esto plantea un importante desafío de experiencia de usuario.
¿Qué debería mostrar la interfaz si el usuario envió una transacción, pero no aparece ningún recibo?
¿Debería seguir mostrando «pendiente»? ¿Debería volver a intentarlo? ¿Cómo puede evitar confundir un envío fallido con una transacción que ya se ha completado?
La documentación recomienda hacer un seguimiento de los envíos, conservar los hashes de las transacciones, consultar los recibos y considerar que la ausencia de un recibo tras un tiempo de espera razonable podría indicar que la transacción se ha descartado.
Esta es una lección útil:
La finalidad es una propiedad del consenso, pero gestionar el estado de las transacciones también es responsabilidad del diseño de la aplicación.
Un mecanismo de consenso rápido no elimina la necesidad de una gestión de errores sólida.
5. ¿Qué ocurre cuando una transacción pasa de una institución a otra?
Private Network Hub de Rayls añade otra dimensión al análisis.
Según la «documentación oficial del Hub» (https://docs.rayls.com/docs/private-network-hub), el Hub ayuda a coordinar transacciones entre registros Sovereign y valida las pruebas criptográficas asociadas a esas transacciones.
La documentación describe dos mecanismos relevantes:
- Confirmaciones de estado basadas en el tiempo, que publican periódicamente en el Hub información de las cabeceras de bloque de un registro Sovereign.
- Pruebas de transacción, enviadas por los registros Sovereign participantes y verificadas con respecto a la información de estado pertinente.
El Hub también admite el procesamiento por lotes, lo que permite agrupar miles de transacciones en una sola transacción del Hub.
Rayls afirma que una Private Network puede admitir más de 15 000 transacciones por segundo con una finalidad inferior a un segundo, según la configuración y el tipo de transacción.
Esa salvedad es importante.
Una cifra de rendimiento no nos dice automáticamente con qué rapidez se completa cada pago individual. Del mismo modo, que una transacción confirmada en un entorno alcance la finalidad no demuestra que ya se hayan completado todos los pasos posteriores en otro entorno.
Para una evaluación rigurosa, separaría tres mediciones:
1. Latencia de consenso: ¿Cuánto tarda en confirmarse una transacción?
2. Latencia de ejecución: ¿Cuánto tarda en aplicarse correctamente la transacción?
3. Latencia de extremo a extremo: ¿Cuánto tarda la operación completa en los sistemas implicados?
Estas mediciones responden a preguntas distintas.
6. ¿La finalidad inferior a un segundo demuestra que todas las transacciones terminan en menos de un segundo?
No, por sí solo.
La documentación oficial de Rayls describe Axyl como un mecanismo que ofrece finalidad determinista en menos de un segundo y documenta afirmaciones de rendimiento de más de 15 000 transacciones por segundo.
Estas afirmaciones son un punto de partida útil. Pero entender el diseño y verificar de forma independiente el rendimiento en producción son dos tareas distintas.
Para este artículo, revisé la documentación publicada de Rayls sobre arquitectura, consenso y Private Network Hub. No realicé una evaluación comparativa en producción ni verifiqué de forma independiente las cifras de rendimiento.
Para que una evaluación comparativa sea reproducible, tendría que especificar el entorno, los tipos de transacción, la carga de trabajo, la duración de la prueba y el punto exacto en el que se mide la latencia.
También querría saber:
- ¿La medición va desde el envío hasta la confirmación por consenso o desde el envío hasta la ejecución correcta?
- ¿Mide una transacción local o una operación entre registros?
- ¿El resultado es una cifra en condiciones óptimas, un promedio o una medición de latencia de cola?
- ¿Qué ocurre cuando los validadores dejan de estar disponibles o las transacciones no son válidas?
- En los flujos de trabajo entre redes, ¿la medición termina cuando se alcanza la finalidad en el origen o espera a que se complete el proceso en el destino?
Sin esos detalles, una cifra destacada no puede responder a todas las preguntas operativas.
Esto no significa que las afirmaciones de Rayls sean falsas. Significa que debemos evitar interpretar una garantía de finalidad específica como una promesa universal para todas las rutas de transacción.
7. ¿Qué deberían comprobar los desarrolladores antes de confiar en una afirmación de finalidad?
Si estuviera evaluando una infraestructura de cadena de bloques para aplicaciones financieras, empezaría con cinco preguntas.
1. ¿Qué entorno es la fuente de verdad?
Determina si la operación se liquida en Sovereign, en Private Network Hub o en Public Chain.
2. ¿Qué significa «final» en este contexto?
¿La aplicación necesita una transacción confirmada, una ejecución correcta o la finalización en varios sistemas?
3. ¿Qué ocurre cuando no llega ningún recibo?
Comprende cómo se gestionan las transacciones no válidas, omitidas o descartadas antes de diseñar la interfaz.
4. ¿Cómo gestiona la aplicación la incertidumbre?
Haz un seguimiento de los hashes de las transacciones, usa tiempos de espera razonables y evita reintentar a ciegas operaciones que podrían haberse completado ya.
5. ¿Se puede reproducir de forma independiente la afirmación sobre el rendimiento?
Busca una definición del entorno, la carga de trabajo, el método de medición y las estadísticas de latencia.
Estas preguntas no son exclusivas de Rayls. Son útiles para evaluar cualquier cadena de bloques que prometa una liquidación rápida.
Reflexiones finales
Empecé esta investigación esperando encontrar una respuesta sencilla sobre la velocidad de las transacciones.
En cambio, el hallazgo más útil fue que la finalidad depende de la ruta de la transacción y del entorno en el que se produce la liquidación.
Rayls documenta Axyl para Public Chain y Sovereign, mientras que Private Network Hub utiliza actualmente la prueba de autoridad de Besu. El Hub tiene su propio modelo de validación y agrupación por lotes, y la documentación de Axyl destaca un problema práctico relacionado con las transacciones no válidas que no generan recibos.
La distinción importante está entre que una transacción alcance la finalidad en un registro concreto y que la operación prevista en su totalidad se complete en todos los sistemas implicados.
En la infraestructura financiera, la velocidad importa. Pero la velocidad por sí sola no define la calidad de la liquidación.
Las preguntas que seguiría planteando son sencillas:
¿Dónde se liquidó la transacción? ¿Qué alcanzó exactamente la finalidad? ¿Y qué pruebas confirman que la operación prevista se completó?
Estas preguntas nos dicen mucho más que una cifra de velocidad por sí sola.
Fuentes oficiales
- «Rayls High-Level Architecture» (https://docs.rayls.com/docs/rayls-high-level-architecture)
- «Meet Axyl: The Consensus Behind Rayls» (https://docs.rayls.com/docs/meet-axyl-the-consensus-behind-rayls)
- «Axyl Technical Specifications» (https://docs.rayls.com/docs/about-the-axyl-consensus-algorithm)
- «Rayls Private Network Hub» ( https://docs.rayls.com/docs/private-network-hub )
- «A Warm Introduction to Rayls Sovereign» (https://docs.rayls.com/docs/a-warm-introduction-rayls-sovereign)
- «A Warm Introduction to the Rayls Public Chain» (https://docs.rayls.com/docs/a-warm-intro-do-rayls-public-chain)
Nota de investigación: Este artículo analiza la documentación técnica publicada por Rayls. No es una evaluación comparativa independiente en producción.