La mayoría de la gente da por hecho que congelar un token simplemente lo detiene todo. En la práctica, los límites son más específicos. Si se restringe a un participante para que no pueda transferir un activo en particular, ¿eso impide que otras instituciones usen el mismo token? ¿Le impide a la institución restringida transferir otro token? ¿Y qué ocurre con las transferencias habituales entre cuentas en su propio libro mayor?
Lo probé directamente, en lugar de basarme únicamente en la documentación.
Puse en marcha una Rayls Private Network local, implementé dos tokens Enygma con autorizaciones independientes, congelé un token para un participante específico y medí qué se detenía y qué continuaba mediante transacciones reales, comprobaciones del estado de los contratos y recibos de gobernanza recuperados.
Configuración utilizada
Tres cadenas Sovereign más el Private Network Hub:
- Sovereign A (ID de cadena 12345)
- Sovereign B (ID de cadena 12346), el participante que restringí
- Sovereign C (ID de cadena 12347)
- Private Network Hub (ID de cadena 1337)
El Hub es la cadena central Hyperledger Besu que contiene el registro de participantes, el registro de tokens y los contratos de mensajería entre cadenas. Todos los mensajes entre cadenas Sovereign pasan por él. Cada cadena Sovereign sigue siendo un libro mayor EVM privado controlado por su propia institución. Las transferencias internas nunca salen de esa cadena.
Creé dos tokens Enygma distintos:
- W2F: el objetivo de la congelación
- W2C: el token de control que permaneció sin congelar
Ambos siguieron el ciclo de vida habitual: implementación en A, registro y autorización locales, envío al Hub, aprobación del Hub y acuñación. Acuñé 1,000 unidades de cada uno y primero confirmé que ambos podían transferirse entre cadenas.
Saldos iniciales después de las transferencias de referencia:
- W2F: A 810 | B 90 | C 100
- W2C: A 910 | B 90
También registré los distintos ID de recurso mediante lecturas directas de los contratos.
Lo que dice el diseño oficial
Según la documentación de Rayls, el operador de Private Network (o un usuario con el rol COMPLIANCE_OFFICER) puede congelar un token específico para los participantes que elija. La congelación se almacena en el TokenRegistry del Hub y se propaga a todas las cadenas.
Una vez aplicada, está diseñada para bloquear:
- Las transferencias Enygma que involucren al participante congelado (en ambas direcciones)
- Las operaciones DvP relacionadas que utilicen ese token para el participante restringido
No está diseñada para detener las transferencias ERC-20 locales ordinarias en la misma cadena Sovereign, ya que estas nunca salen de la cadena ni pasan por el Hub.
Existe un control aparte. El administrador de una cadena Sovereign puede congelar un token localmente mediante `freezeOnPrivacyNode`. Eso bloquea las operaciones en esa misma cadena. La congelación del Hub y la congelación local son mecanismos distintos.
Quería comprobar si el comportamiento de la implementación coincidía con esta descripción.
Congelación de W2F para Sovereign B
Antes de la operación, todos los indicadores de congelación estaban desactivados. Luego ejecuté la congelación autorizada de W2F, dirigida únicamente al participante 12346.
Recuperé la transacción minada original mediante una inspección histórica del Hub. Los datos de llamada decodificados correspondían a `freezeToken`, con el ID de recurso W2F y el ID de cadena 12346 exactos. Después de la transacción, solo W2F para Sovereign B quedó marcado como congelado. W2F permaneció sin congelar para A y C. W2C siguió estando autorizado en todas partes.
El registro de Sovereign B mostraba que el estado de W2F en el Hub era 4 (congelado), mientras que W2C seguía en 2 (autorizado).
Qué detuvo la congelación
Probé ambas direcciones entre cadenas que involucraban a B:
- El envío de W2F de A a B se revirtió durante la estimación de gas (restricción del participante de destino, selector `0xad22899b`).
- El envío de W2F de B a A también se revirtió (comprobación del estado del Hub en el lado de origen, selector `0xdc2ffb0f`).
Ninguno de los intentos se transmitió. Los saldos no cambiaron. Se bloquearon las rutas entre cadenas probadas para W2F que involucraban a Sovereign B.
Qué siguió funcionando
Mientras W2F seguía congelado para B, otras tres actividades se realizaron correctamente:
1. Una transferencia de W2F de A a C (el mismo token, una ruta distinta). Los saldos se actualizaron exactamente como se esperaba.
2. Una `transfer` ERC-20 ordinaria de W2F entre dos cuentas locales en la propia Sovereign B. La congelación del Hub no impidió el movimiento interno en el libro mayor de B.
3. Ambas direcciones de la transferencia del token independiente W2C entre A y B.
Las mismas dos instituciones que ya no podían transferir W2F entre cadenas todavía podían intercambiar W2C. En los escenarios que probé, la restricción era específica del token y del participante.
Esto coincide con el diseño documentado: una congelación del Hub específica para un participante detiene el movimiento entre cadenas de ese token para el participante restringido, pero no afecta las transferencias locales ni otros tokens.
Límites de gobernanza y recuperación
Una cuenta ordinaria no podía congelar ni descongelar. Ambas llamadas se revirtieron con `RaylsAccessManaged__Unauthorized`. Solo el operador autorizado podía levantar la restricción.
Después de la descongelación autorizada, volví a probar las dos rutas que antes se habían rechazado. Ambas funcionaron. Los saldos cuadraron antes, durante y después de la restricción. Los totales registrados para ambos tokens se mantuvieron en 1,000 unidades.
Qué quedó realmente claro
La transferencia local en Sovereign B fue el resultado que más me hizo reflexionar. W2F estaba congelado para B en el nivel del Hub. La actividad entre cadenas que involucraba a B se detuvo. Sin embargo, una transferencia ordinaria entre dos cuentas de B siguió funcionando, y un token completamente distinto continuó moviéndose en ambas direcciones.
Rayls trata estos controles como mecanismos distintos:
- La congelación de un token en el Hub para un participante específico
- La congelación general de un participante
- La congelación local de un token en el nivel de Sovereign
Para una institución que diseña procedimientos de cumplimiento o respuesta a incidentes, esta distinción es importante. Ejecutar correctamente un comando de gobernanza no equivale a comprender exactamente qué se detuvo y qué siguió disponible.
Limitaciones
Este fue un experimento en un entorno de desarrollo local, no una auditoría de producción. Probé tokens, rutas, cantidades y acciones de gobernanza específicos. No probé todas las rutas posibles, condiciones de tiempo ni escenarios de recuperación. Los resultados se limitan al comportamiento que observé en esta implementación.
La documentación pública permite verificar el diseño previsto de la congelación del Hub específica para un participante y la existencia del control de congelación local independiente. El comportamiento en tiempo de ejecución de cualquier implementación activa sigue dependiendo de la configuración, los roles y la forma en que se opere la red.
Conclusión
Una restricción dirigida debe evaluarse no solo por lo que detiene, sino también por lo que permite que siga funcionando.
En este experimento, congelar W2F para Sovereign B bloqueó las rutas entre cadenas probadas que involucraban a B. Las transferencias locales de W2F en B siguieron funcionando, las transferencias del mismo token entre otras instituciones continuaron y un token completamente distinto siguió moviéndose con normalidad. Tras la descongelación autorizada, se restablecieron las rutas bloqueadas.
Ese límite es el detalle práctico que sigue siendo útil mucho después de ejecutar el comando de gobernanza.
Fuentes
- Congelación de tokens: https://docs.rayls.com/docs/freezing-tokens
- Cómo funciona Enygma: https://docs.rayls.com/docs/how-enygma-works
- Roles de Private Network: https://docs.rayls.com/docs/private-network-roles
- Redes privadas de Rayls: https://docs.rayls.com/docs/rayls-private-networks
- Privacidad en una Private Network: https://docs.rayls.com/docs/evm-privacy