Una EVM privada es una cadena compatible con Ethereum que no es la red pública de Ethereum: el mismo bytecode, los mismos contratos de Solidity y las mismas herramientas para desarrolladores, pero operada por una institución o un pequeño grupo de ellas, que excluyen al público de su lectura de forma predeterminada. Los bancos la quieren precisamente para poder reutilizar una década de patrones de contratos inteligentes auditados y contratar desarrolladores sin anunciar cada operación a la competencia. Esa parte es sencilla.
Lo que me llevó a investigar fue un dato concreto: Hyperledger Besu, el software en el que se ejecuta el propio Private Network Hub de Rayls, ya incluye una forma integrada de hacer exactamente esto. En cambio, Rayls construye otra cosa. Quería saber por qué.
Besu ya tiene una función de privacidad
Besu lo llama transacciones privadas, y el mecanismo es específico. El nodo del emisor pasa la transacción a un nodo Tessera emparejado, que la cifra y la distribuye punto a punto a los nodos Tessera de todos los demás participantes del acuerdo. En la cadena real solo se incluye una transacción marcadora de privacidad, un hash que apunta a ese intercambio fuera de la cadena. La propia documentación de Besu describe el resultado como dos sistemas paralelos: «la transacción privada distribuida entre los participantes involucrados y la transacción marcadora de privacidad (PMT) incluida en la cadena de bloques pública».
Esto es privacidad por segregación: el contenido simplemente nunca llega a nadie ajeno al acuerdo. Es la misma categoría que los propios materiales de marketing de Rayls usaron para describir productos de la competencia en un artículo anterior sobre esta plataforma.
Aquí es donde la cuestión se vuelve específica y tiene fecha.
La función está en proceso de retirada
La documentación actual de Besu lo afirma con prácticamente las mismas palabras en cinco páginas distintas: «La privacidad basada en Tessera está obsoleta en Besu versión 24.12.0 y posteriores». Es una advertencia permanente, no una nota de la hoja de ruta: se repite en la descripción general de privacidad, la página sobre transacciones privadas, la página de procesamiento, la página de grupos de privacidad y la página de complementos.
Esta obsolescencia se remonta a un anuncio concreto y con nombre propio. Los mantenedores de Besu lo publicaron el 24 de septiembre de 2024, con el título «Retirada de Tessera y simplificación de Besu», y dieron una razón directa: Tessera «no ofrece el rendimiento suficiente para los casos de uso previstos». La misma publicación señaló el camino de reemplazo: soluciones de privacidad en la capa de aplicación, desarrolladas fuera del cliente base de Besu, lo bastante sólidas y eficientes como para que Besu ya no necesitara mantener su propia versión.
Las notas de lanzamiento de Besu registran la eliminación efectiva de la función en la versión 25.6.0, publicada el 4 de junio de 2025, con la línea del registro de cambios «Eliminar la función de privacidad de Tessera». Al contrastarlo con rastreadores de versiones independientes, transcurrieron aproximadamente ocho meses entre el anuncio y la eliminación, y casi exactamente ocho años y ocho meses desde el primer lanzamiento de Quorum, el antecesor conceptual de Tessera. Las versiones actuales de Besu han eliminado por completo la privacidad basada en Tessera: ya no se trata simplemente de desaconsejar su uso.
También conviene conocer otra limitación anterior, porque atañe directamente a la propia historia de Rayls. Desde hace tiempo, la documentación de Besu advierte que no se ejecuten transacciones privadas en producción con mecanismos de consenso en los que se producen bifurcaciones; menciona específicamente la prueba de trabajo y Clique, y ya desde Besu v1.4 calificaba esa combinación como una función de acceso anticipado. El libro mayor Sovereign de Rayls funcionaba precisamente con ese mecanismo de consenso, Clique, antes de migrar a Axyl en 2026. Si Rayls hubiera querido usar la privacidad nativa de Besu en su antigua pila tecnológica, la propia documentación de Besu le habría indicado que no ejecutara esa combinación en producción.
Incluso dejando de lado la obsolescencia y la advertencia sobre Clique, la propia arquitectura no se adapta bien a una red institucional en crecimiento. Los grupos de privacidad de Besu quedan fijados al crearse. Su documentación es tajante: «Una vez creado un grupo de privacidad, no se pueden cambiar sus miembros». Añadir un banco comercial a un grupo existente implica formar uno completamente nuevo y migrar cualquier estado que tuviera el anterior.
Por qué los bancos querían este tipo de producto
La necesidad surgió casi una década antes que Rayls. J.P. Morgan presentó Quorum en octubre de 2016: un cliente de Go Ethereum modificado, diseñado para situarse entre lo totalmente privado y lo totalmente público para derivados y pagos, según informó Fortune en aquel momento. El diseño sustituyó los datos privados por hashes criptográficos en una cadena compartida; un ingeniero de JPMorgan describió entonces el resultado como «una clara separación entre lo privado y lo público». Ese es el mismo problema, expresado en dos palabras, que una EVM privada siempre ha buscado resolver: infraestructura compartida, público excluido.
ConsenSys adquirió Quorum de J.P. Morgan en agosto de 2020 e integró su desarrollo en lo que se convirtió en ConsenSys Quorum, ofrecido a través de dos clientes: GoQuorum y, cada vez más, el propio Besu. La privacidad basada en Tessera es descendiente directa de aquel diseño original de 2016, la primera respuesta ampliamente adoptada por la industria a la pregunta de cómo puede un banco obtener privacidad en una cadena EVM.
Lo que Rayls creó en su lugar
El marco Enygma de Rayls no saca los datos privados de la cadena. Los mantiene en el Hub, cifrados y envueltos en pruebas de conocimiento cero, verificables por cualquiera que pueda leer la cadena, pero sin que esa persona pueda leerlos. Un operador de red privada recupera las claves de visualización de las instituciones, cifradas para él durante el registro, y puede leer todas las transferencias; los participantes tienen claves de gasto independientes que pueden autorizar movimientos de valor, pero nunca se diseñaron para descifrar los datos de otros. Añadir una institución nueva significa registrar una nueva clave de visualización, no reconstruir un grupo.
Revisé la documentación del Hub, la gestión de claves y Enygma de Rayls, en particular las páginas que describen el Hub de red privada basado en Besu, buscando cualquier mención de Tessera, grupos de privacidad o una transacción marcadora de privacidad, el vocabulario del software que ejecuta ese Hub. Ninguna de las páginas revisadas utiliza esos términos. Esa ausencia se observa en documentación donde sería natural mencionarlos si Rayls estuviera superponiendo su privacidad a la función nativa de Besu, en vez de reemplazarla. Esto sugiere que se está construyendo algo distinto, aunque una ausencia como esta no llega a ser una prueba concluyente.
También pude acceder directamente al repositorio público de iniciación para hackatones de Rayls, lo que ofreció otro lugar donde buscar. Allí se documenta la capa independiente de nodos de privacidad basada en Reth, no el Hub basado en Besu, por lo que no confirma ni descarta el uso de Tessera específicamente en el Hub. Es evidencia sobre otra parte de la pila tecnológica.
También hay un costo medido asociado a la función que Rayls parece haber omitido. Una prueba académica independiente de una implementación activa de Besu y Tessera, publicada en arXiv en 2025, registró una latencia media superior a 5 segundos al desplegar contratos privados, con llamadas individuales a funciones privadas que iban de aproximadamente 1 a más de 6 segundos. La prueba atribuyó esos tiempos específicamente al cifrado, la distribución de cargas útiles fuera de la cadena y la coordinación del consenso que Tessera añade al procesamiento ordinario de Besu. Es evidencia independiente y cuantificada de que la privacidad basada en la segregación tiene sus propios costos, aparte de los que pueda añadir un enfoque criptográfico.
La pregunta y lo que realmente respalda la evidencia
Si Besu ya tiene una forma integrada de hacer privadas las transacciones, ¿por qué alguien que utiliza Besu necesitaría una segunda capa de privacidad independiente?
Tres hechos distintos, considerados en conjunto, apuntan en la misma dirección. Los propios mantenedores de Besu anunciaron el retiro de la función en septiembre de 2024 y terminaron de eliminarla en junio de 2025; citaron el rendimiento con sus propias palabras. La documentación de Besu desaconsejaba el único mecanismo de consenso, Clique, que el propio libro mayor de Rayls utilizó durante la mayor parte de su historia. Y los grupos de privacidad estáticos de la función, que solo podían recrearse, no encajaban estructuralmente con una red que, según la propia documentación de Rayls, se construye incorporando una institución nueva cada vez. Cada uno de esos tres puntos constituye una incompatibilidad específica y fechada entre lo que ofrecía la herramienta nativa de Besu y lo que necesita el patrón de crecimiento documentado por Rayls.
Por qué importa esta distinción en la práctica
Una institución que evalúa «¿necesitamos Rayls o basta con ejecutar Besu con Tessera?» en realidad está planteando dos preguntas distintas que casualmente comparten proveedor, y la respuesta a la segunda tiene fecha de caducidad. El modelo de segregación de Besu confiaba en que los operadores de nodos mantuvieran los datos completamente fuera del registro público y no exigía a los desarrolladores nada más exótico que las herramientas habituales de Ethereum: justo lo que Quorum prometió a los bancos en 2016. Pero esa implementación concreta ya no se incluye en las versiones actuales de Besu.
El modelo criptográfico de Rayls confía en las matemáticas, no en la disciplina de los operadores; permite que una red crezca registrando claves individuales en lugar de reconstruir grupos fijos, y funciona con un software cuyos mantenedores completaron la eliminación descrita anteriormente, ocho meses después de anunciarla.
Esta es una respuesta específica y fechada a una pregunta específica. La propia documentación de Besu es lo que explica por qué una cadena que ejecuta Besu necesitaría algo que Besu ya no ofrece por completo.