rayls

$RLS
Rayls Relayer 코드를 다시 보다가 이상한 점 하나를 발견했습니다.
Relayer가 메시지를 전달하는 주체라면 "executeMessage()"에도 RELAYER 권한이 있어야 하는 것 아닌가?
그런데 실제 코드를 따라가 보니 아니었습니다.
오히려 Rayls는 메시지를 전달하는 권한과 실제 실행을 분리해 놓고 있었습니다.
Public Chain에서 Relayer가 처음 들어가는 곳은 "PublicRNEndpoint.receivePayload()"입니다.
여기서 메시지를 직접 실행하지 않고,
messageExecutor.executeMessage(...)
로 Executor에게 넘깁니다.
그래서 "RNMessageExecutorV1.executeMessage()"를 확인했습니다.
여기에는 RELAYER 권한이 없습니다.
"MESSAGE_EXECUTOR"도 아닙니다.
대신 "onlyEndpoint"로 보호되어 있습니다.
if (msg.sender != authorizedEndpoint) {
revert UnauthorizedEndpoint(msg.sender);
}
즉 호출 흐름은
Relayer → Endpoint → Executor
로 나뉩니다.
그리고 Executor가 최종 목적지에
to.call(data)
를 실행합니다.
이때 목적지 컨트랙트가 보는 "msg.sender"는 Relayer가 아니라 RNMessageExecutor입니다.
그래서 목적지의 "MESSAGE_EXECUTOR" 권한과 연결됩니다.
여기까지는 코드를 따라가면 확인할 수 있었습니다.
그런데 여기서 또 하나가 궁금해졌습니다.
그렇다면 같은 메시지가 다시 들어오면 어디에서 막을까?
"RNMessageExecutorV1"에는
mapping(bytes32 => bool) public executed;
가 있습니다.
Executor가 "messageId"를 기억하고 이미 처리한 메시지는 다시 실행하지 않는 구조입니다.
여기까지만 보면 흔한 replay protection처럼 보입니다.
그래서 테스트 코드까지 찾아봤습니다.
그리고 이번 조사에서 가장 중요한 부분을 발견했습니다.
Rayls에는
"ReplayProtection_ExecutorSingleSourceOfTruth.t.sol"
이라는 별도의 보안 테스트가 있습니다.
이 테스트는 단순히 같은 메시지를 두 번 보내는 것만 확인하지 않습니다.
같은 "messageId"로 목적지를 바꿔 재실행하는 경우,
그리고 Endpoint 자체를 교체한 뒤 기존 "messageId"를 다시 실행하는 경우까지 테스트합니다.
Endpoint를 바꿔도 결과는 똑같이 차단됩니다.
왜 이게 중요할까요?
재전송 방지의 상태가 Endpoint에 있는 게 아니라 Executor에 있기 때문입니다.
기존 Endpoint에서 메시지를 한 번 실행한 뒤 새로운 Endpoint를 연결해도,
Executor의
executed[messageId]
에는 이미 실행 기록이 남아 있습니다.
따라서 Endpoint가 바뀌어도
“이 메시지는 이미 실행됐다”
라는 판단은 바뀌지 않습니다.
이 테스트를 보고 제가 확인한 건 단순한 replay protection의 존재가 아니었습니다.
Rayls가 cross-chain 메시지 실행의 신뢰 경계를 Executor에 두고 있다는 것입니다.
Endpoint는 메시지를 전달하는 경로이고,
Executor가 실제 실행과 "messageId"의 실행 상태를 가지고 있습니다.
그래서 Endpoint가 교체되는 상황에서도 과거의 실행 기록이 이어집니다.
코드 흐름을 한 줄로 정리하면:
Relayer
→ "receivePayload()"
→ "executeMessage()"
→ "to.call()"
→ "MESSAGE_EXECUTOR"
→ "executed[messageId]"
처음 가졌던 질문,
“Relayer가 메시지를 실행한다면 왜 "executeMessage()"에는 RELAYER 권한이 없지?”
에 대한 답은 명확했습니다.
Rayls는 전달 경로와 실행 주체, 그리고 replay protection의 기준점을 하나로 묶지 않았습니다.
특히 이번에 확인한 “Endpoint를 교체해도 기존 "messageId"는 다시 실행되지 않는다”는 테스트는,
Rayls의 cross-chain 실행 구조를 이해할 때 꽤 중요한 단서라고 생각합니다.
#Rayls

La cadena de bloques ofrece a las instituciones financieras algo que necesitan con urgencia: liquidaciones verificables sin depender por completo de una base de datos cerrada.
Pero hay un problema evidente.
Los bancos no pueden simplemente publicar todos los detalles de cada transacción en una cadena de bloques pública.
Es posible que los saldos, las contrapartes, los importes de las transacciones y otra información confidencial deban mantenerse privados, mientras que los reguladores, las contrapartes y la red siguen necesitando pruebas suficientes para verificar que algo realmente ocurrió.
Entonces, ¿cómo se puede tener privacidad y verificabilidad al mismo tiempo?

En el post anterior ejecuté el código de prueba que Rayls hizo público y medí que el conjunto anónimo de 6 personas tarda 1,96 segundos por registro. Pero en ese artículo había tres frases que eran inferencias y no mediciones; yo lo tengo claro. Esta semana cambié la máquina por una de 2 núcleos y añadí algunos datos más, así que ahora voy a completar esas tres frases con números.
Primero, aclaremos la relación entre este artículo y el anterior, para que los lectores no crean que es una re-publicación del mismo. El artículo anterior medía el tiempo de la prueba en un entorno de un solo núcleo para los modos de 2 personas y de 6 personas; esos dos números se volvieron a medir esta vez y casi no cambiaron. Todo el contenido nuevo de este artículo son esas tres cosas que en el artículo anterior no se pudieron medir y solo se pudieron inferir.

En la tabla comparativa de proveedores del sitio oficial de Rayls hay nueve filas, y elegí la de «Privacidad». La razón es muy simple: la privacidad es importante y Besu es de código abierto; puedo consultar su documentación y su código.
En la tabla comparativa, Rayls marca las dos filas: «Privacidad aislada» y «Privacidad criptográfica». Besu solo marca la primera. Planeo verificarlo con la documentación de la otra parte, así que consulté la documentación de Besu y, después, descargué su código y lo conté una vez.
La conclusión no es «Besu no sirve». La verdadera diferencia es esta: estas dos compañías ponen la privacidad en niveles distintos, y el momento en que Besu la trasladó fue más temprano que lo que mucha gente cree.

El 19 de septiembre, Rayls publicó un artículo (Privacy has a price). En el título decía honest math, pero todo el texto solo ofrecía un rango numérico: que una prueba requiere desde unos cientos de milisegundos hasta unos segundos. Durante varias semanas seguidas estuve escribiendo sobre la arquitectura de privacidad de Rayls; esta vez comparto contenido nuevo con ustedes. Descargué el código de las pruebas que hizo público, lo ejecuté decenas de veces y les comparto esta conclusión interesante.
Primero, hablemos de qué trató el blog. Su argumento central se puede resumir en dos frases. La primera es dónde está el costo: las transacciones confidenciales son más caras que las transparentes; lo caro está en generar las pruebas de conocimiento cero, mientras que verificar resulta más barato. Una prueba para un traspaso confidencial básico, en hardware comercial común, tarda de cientos de milisegundos a unos segundos. La segunda frase es qué deberíamos preguntar: las instituciones no deberían enfocarse solo en el TPS, sino en cuál es el rendimiento cuando se consideran la privacidad y el nivel de auditoría que realmente necesitan, además de la carga de trabajo de negocio real. El blog sostiene que el volumen de las liquidaciones entre instituciones no es grande y que está completamente dentro de la capacidad de los sistemas de liquidación confidencial.

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”.

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.

Para ser honesto, cuando vi estas tres siglas juntas por primera vez, pensé que eran tres respuestas a la misma pregunta: cuál es más rápido, cuál es más seguro, y ya está. Luego entendí que ponerlas en un ranking, es como preguntar: "¿Qué herramienta es mejor, el martillo, el destornillador o la llave inglesa?" La respuesta depende de si lo que tienes delante es un clavo, un tornillo o un perno.
Cada uno de ellos resuelve en realidad tres problemas que se han mezclado en uno.
El primer problema es: quiero demostrar que algo es verdadero, pero los datos necesarios para demostrarlo son sensibles, y no quiero mostrártelos. El banco quiere explicar al regulador que "esta transacción es legal, está autorizada correctamente y no hay duplicados", pero no quiere desglosar el importe y el pagador/receptor en los libros contables. Esta necesidad de que la prueba sea verdadera, sin revelar los datos, es el terreno de ZK. Su encanto consiste en que la garantía proviene de las matemáticas, no de "te prometo que, aunque no lo veas"; un regulador o auditor que reciba la clave de verificación puede comprobar la conclusión, pero no puede acceder a los datos subyacentes. El costo también es bastante tangible: es excelente demostrando propiedades de los datos, pero no tanto para que varias partes calculen conjuntamente cuando ninguna tiene datos completos, y además consume más potencia de cálculo que el texto en claro.

Cuando veo anuncios de bloqueos, normalmente solo me importa una cosa: si esta promesa puede verificarse. La mayoría de los proyectos que hablan de “bloqueo del equipo” terminan en una sola frase: solo puedes elegir creer o no creer. Esta vez no es igual, así que lo revisé en la cadena.
Primero, aclaremos los hechos. Parfin es el socio tecnológico central detrás de Rayls; se encarga del desarrollo de los nodos de privacidad, la red privada, el marco de privacidad Enygma y la cadena pública Rayls. Como compensación por el trabajo realizado antes del TGE, obtuvo 1,070,493,535 RLS, aproximadamente el 11% de la oferta total inicial de 10 mil millones de unidades.
Estos tokens se mantuvieron anteriormente en una entidad custodio en Ethereum. La razón es bastante práctica: durante el TGE, la cadena pública Rayls aún no estaba en marcha, así que solo podían custodiarse. Ahora que la cadena pública ya está disponible, estos tokens se han migrado a la cadena pública Rayls, se han bloqueado en un contrato inteligente verificable públicamente y, al mismo tiempo, el tiempo de desbloqueo se ha pospuesto de diciembre de 2026 a diciembre de 2027.

Hermanos, llevo mucho tiempo en acecho en la comunidad Rayls. Sé que todos están muy descontentos con el equipo; yo también, pero el equipo sí está haciendo trabajo de verdad, y lleva tiempo esforzándose. Lo único es que el equipo de Rayls sigue una ruta conforme a las normas. Hermanos, no se rindan; todo quedará en manos del tiempo. Creo que el equipo de Rayls finalmente entregará los exámenes que nos dejarán satisfechos. Voy a compartir con ustedes buenas noticias: se trata de que recientemente el equipo de Rayls se conectó a RPC. ¡Esto es algo muy importante!
Resumen rápido
¿Qué es RPC?
Puedes entender RPC como una línea telefónica dedicada entre la aplicación y la blockchain.

En la comunidad cripto se ve cada semana: “algún gran magnate de las finanzas tradicionales se lanza al blockchain”. Ahora, cuando veo este tipo de titulares, básicamente los paso de largo, porque en la gran mayoría de los casos al final se quedan en laboratorios de innovación: publican un comunicado de prensa y no hay más novedades. Para determinar si es verdad o no, hay un criterio bastante sencillo: si un cliente común, desde su propia app, puede abrirlo y usarlo directamente.
XP Inc. Esta vez se ha cumplido con este estándar.
Primero, aclaremos qué tipo de empresa es, porque el tamaño determina la importancia del asunto. XP es una plataforma de inversión brasileña listada en NASDAQ; su ticker es XP. Revisé los datos del primer trimestre de 2026 en su página de relaciones con inversores: el patrimonio de clientes está en el orden de R$1.529 mil millones de reales, es decir, R$1.529 billones; asesores/inversionistas registrados superan los 18.000; y en los últimos doce meses los ingresos totales fueron de R$19.8 mil millones de reales, con una utilidad antes de impuestos de R$5.8 mil millones de reales.

En el artículo sobre XP que escribí la vez pasada, siempre tuve curiosidad por una pregunta: cuando una stablecoin de tipo institucional como USDXP se emite, ¿cómo exactamente participa en una liquidación real transfronteriza? Este texto viene a completar esa duda, y de paso también me hizo entender por primera vez una expresión: “sándwich de stablecoins”.
Primero explica este término: en realidad es muy gráfico. Un pago transfronterizo en una sola traza: en los dos extremos están las monedas locales, y en medio hay una capa de stablecoin pública. El pagador convierte su moneda local en una stablecoin en dólares; la stablecoin realiza la liquidación transfronteriza en la cadena; y el receptor, a su vez, la convierte de nuevo a su moneda local. ¿No es como dos rebanadas de pan con esa capa intermedia en medio? Esa es la forma en que la industria empezó a describir la liquidación transfronteriza con stablecoins.

Empecé a hacer staking desde el lote de compromisos previos de junio, así que ya pasé una vez por este proceso. Esta vez se abrió para todo el mundo. Hay bastante gente a mi alrededor preguntándome cómo operar y qué tener en cuenta, así que lo escribo todo de una vez, claro y completo.
Primero, hablemos de los cambios en sí.
Rayls usa prueba de participación delegada: los validadores ejecutan nodos, producen bloques y garantizan la seguridad de la cadena pública. Los tenedores comunes no necesitan ejecutar sus propios nodos; pueden delegar su RLS a algún validador y compartir una parte de las recompensas del staking.
Este mecanismo se puso en marcha en junio, pero entonces solo estaba disponible para las carteras que participaron en el plan de compromisos previos y en las actividades de semillas de liquidez. Ese grupo ya bloqueó sus monedas antes de la red principal; la parte oficial les dio una bonificación anualizada del 55% durante tres meses, e incluso les envió 1 USDr a cada cartera que cumpliera las condiciones, para que ni siquiera tuvieran que preocuparse por no tener gas.

Yo empecé a hacer staking de RLS desde la fase de precompromiso; normalmente leo el blog oficial, en gran parte para saber si mi posición se verá afectada. Este artículo del 30 de agosto sobre lo cuántico es diferente: a lo largo de todo el texto enseña a las instituciones cómo hacer adquisiciones, y no tiene una relación directa conmigo, un pequeño inversor como soy. Aun así, lo leí completo, porque al principio establecía una regla bastante tajante, y esa regla luego me llevó de vuelta al propio artículo.
La regla es así: una afirmación de “seguridad cuántica”, si no especifica claramente qué algoritmo estandarizado se usa y en qué nivel de parámetro, entonces no es una propuesta; es solo una etiqueta.

En el artículo anterior hablé de la apertura del staking en sí. Pero en el backstage, muchos hermanos me preguntaban lo mismo una y otra vez: ¿cómo se hace exactamente? Así que esta vez recorrí todo el proceso de principio a fin, anoté cada paso y también todos los lugares donde es más fácil quedarse atascado. Solo tienes que seguirlo tal cual.
El enlace del artículo anterior está aquí:质押开放给所有人了,但有几件事最好先知道
Primero, aclaremos para quién está escrita esta guía. Si no has tenido ningún contacto con Rayls, e incluso no te suenan bien palabras como “billetera” y “puente”, entonces este artículo es para ti. Cada vez que aparezca algún término profesional, te lo explicaré rápidamente.

He estado revisando la documentación de Rayls y una cosa que al principio me resultó confusa fue la diferencia entre un Privacy Node, una Private Network y una Public Chain.
Después de ver cómo se conectan, se volvió mucho más fácil entenderlo.
Cada una tiene un rol diferente.
1. Privacy Node: la blockchain propia de la institución
Un Privacy Node de Rayls es una cadena compatible con EVM operada por una sola institución.
Lo que ocurre dentro de la institución se queda dentro de su propio entorno.
Puede emitir tokens, gestionar saldos, ejecutar contratos inteligentes y gestionar su actividad interna allí.

Para ser sincero, cuando se trata de noticias de tipo colaborativo, yo normalmente les echo un vistazo y paso; de diez, nueve solo se anuncian cruzando logos. Pero esta vez me detuve y la leí hasta el final, porque toca el eslabón más básico y también el más caro de los pagos transfronterizos.
Las transferencias internacionales son lentas; mucha gente cree que es por “internet lento”. La verdadera razón es más banal: el dinero no se “envía” realmente, sino que ya estaba “depositado” allí. Para que un banco pague a un país determinado, normalmente tiene que abrir una cuenta en el banco local con antelación y dejar una gran suma; en jerga se llama cuenta nostro. Cada corredor de pago global tiene que “apartar” una cantidad, como si depositaras un manojo de efectivo en casa de cada amigo, por si algún día pasas y lo necesitas. El dinero se queda inmóvil en la cuenta, y las fluctuaciones del tipo de cambio las absorbes tú; una transferencia internacional puede tardar varios días en completarse.

Rayls es un proyecto al que he seguido durante mucho tiempo. Recientemente lanzaron el proyecto de comunidad The Rail, y la forma de jugar no es muy parecida a los típicos "eventos para subir puntos". No premia el spam, sino a las personas que aportan de manera real y constante. ¡Te cuento de forma sencilla cómo funciona! ¡Familia! Si también te parece buena, ven y únete para registrarte en el formulario. ¡A bordo!
https://tally.so/r/dWgdrA
1. ¿Qué es The Rail
The Rail es el programa de embajadores de la comunidad de Rayls. Su objetivo es reconocer contribuciones con significado y convertirlas en identidad, permisos y recompensas. El posicionamiento oficial es: "una comunidad construida sobre contribuciones reales, no un juego de subir puntos". Se describe como: "un pequeño cuarto familiar donde la gente realmente se cuida entre sí". El funcionamiento es: contribuyes → ganas puntos → subes de rango/rol → eres reconocido.

Las noticias regulatorias normalmente las miro de reojo y sigo adelante, porque en su mayoría no tienen mucho que ver con los titulares comunes. Esta vez, con estas normas del Reino Unido, las leí y cambié de opinión, porque tiene un mecanismo que no es muy evidente y que en la práctica influirá en qué cadena elegirán las instituciones en el futuro.
Primero aclaremos la línea temporal, porque eso determina el nivel de urgencia.
El Parlamento del Reino Unido aprobó la normativa correspondiente el 4 de febrero de 2026. La FCA publicó el contenido central de este sistema el 30 de junio, en total cinco documentos de políticas. El canal de autorización se abrirá el 30 de septiembre, y el alcance completo de las actividades reguladas solo entrará en vigor de forma plena hasta el 25 de octubre de 2027.