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.
Del lado de Besu: de la documentación al código
En la documentación oficial de Besu, las páginas relacionadas con privacidad ahora tienen en la parte superior el mismo banner: las funciones de privacidad basadas en Tessera quedan descontinuadas a partir de la versión 24.12.0.
La eliminación real ocurre en 25.6.0. En las notas de lanzamiento de esta versión, lo listan como cambio destructivo: se elimina la funcionalidad de privacidad de Tessera, con número #8369; en esa misma tanda también se eliminó la gestión de permisos on-chain.
La parte que verifiqué por mi cuenta se hizo así. Primero, con tres números de versión, consulté el mismo archivo: en 25.4.0, tanto PrivateTransaction.java como Enclave.java devuelven 200; en 25.6.0 y 26.2.0 devuelven 404. Luego revisé las interfaces: en el enum RpcMethod de 25.4.0 hay 23 métodos con prefijos priv_, eea_ y privx_; en el mismo archivo de 26.2.0 no hay ninguno. También en la línea de comandos: 25.4.0 tiene 12 parámetros de arranque que comienzan con --privacy; en BesuCommand.java de 26.2.0 ni siquiera se puede encontrar la palabra «privacy». En escala: en 25.4.0, los archivos Java no pertenecientes a tests relacionados con privacidad y enclave son 153, con un total de 17.875 líneas.
Por qué Besu quiere hacer esto
Esta parte tiene que escribirse, si no, parecerá que solo estoy señalando fallos.
En el anuncio del 24 de septiembre de 2024, los mantenedores de Besu dieron las razones: el repositorio se convirtió en un cuchillo suizo obeso; funciones como Tessera no ofrecen suficiente rendimiento en los escenarios que originalmente pretendían resolver, y la capa de aplicación ya cuenta con soluciones maduras y emergentes. En el anuncio también se menciona que un proyecto de privacidad programable de código abierto orientado a EVM se enviará próximamente al Laboratorio LF Decentralized Trust.
Ese proyecto es Paladin: ahora ya pasó de ser un proyecto del laboratorio a convertirse en un proyecto oficial de LF Decentralized Trust, con licencia Apache 2.0. Implementa privacidad de dos maneras: usando pruebas de conocimiento cero o prevalidación por parte del emisor, y corre sobre cualquier cadena EVM.
Así que, con precisión: Besu no abandonó la privacidad; trasladó la privacidad del cliente a la capa de aplicación.
Dos formas de colocarlo, con sus respectivos precios
La manera de Rayls es meter la privacidad dentro del protocolo: Enygma cifra el contenido de las transacciones con AES-256, registra los saldos con compromisos de Pedersen y prueba con Groth16 que esa cuenta es correcta; se sigue la ruta normal de transacciones.
El costo de ese camino se puede cuantificar. En la entrada anterior medí la generación de pruebas: en un entorno mononúcleo, para un grupo anónimo de 6 personas, 1,96 segundos por prueba. Hoy medí otra cosa: la propia prueba tiene solo 164 bytes, y con grupo de 2 personas y de 6 personas tiene el mismo tamaño, porque la prueba de Groth16 es de longitud fija. Pero los datos públicos que se publican junto con la prueba no son de longitud fija: 588 bytes para el grupo de 2 personas y 1.612 bytes para el grupo de 6 personas.
Este número corrige de paso una afirmación común. No es solo «una prueba» lo que sale del entorno privado: también salen la carga cifrada, la prueba y los datos públicos necesarios; el contenido se mantiene oculto, mientras que el sistema aún puede verificar y liquidar.
A propósito, otra cosa de la otra fila de la tabla comparativa. Rayls marca en «privacidad aislada»; se apoya en la estructura de despliegue: el libro mayor Sovereign de cada institución se instala dentro de sus propios límites, y según lo que dice el sitio web, los datos privados no salen de esa instancia; solo el mínimo de carga necesaria para completar una transacción se envía a la red externa. Por eso, para Rayls esas dos filas son dos capas distintas: el aislamiento de despliegue separa a las instituciones, y la liquidación entre instituciones se hace con criptografía. Solo miré el sitio web y la documentación para esto, no lo desplegué realmente.
También hay que dejar la parte de la licencia por escrito. El stack abierto de Rayls es Apache 2.0, pero dos módulos, Enygma y Axyl, son BUSL 1.1: las pruebas son gratis, en producción se requiere autorización. Cada versión publicada después de cuatro años se convierte automáticamente a Apache 2.0. Paladin es Apache 2.0.
¿Qué significa esto para una institución?
Si una institución tiene su red privada ejecutándose sobre Besu y usa las interfaces priv_ o eea_, entonces el paso a 25.6.0 no es una actualización, es una migración. 23 interfaces y 12 parámetros de arranque desaparecen al mismo tiempo; la lógica de privacidad tiene que trasladarse a la capa de aplicación y reescribirse; si no, solo puedes quedarte en la serie 25.4 y, a partir de ahí, todas las mejoras de rendimiento y las correcciones de seguridad no tienen nada que ver contigo.
Si eliges Rayls, privacidad y libro mayor son la misma cosa: versiones, auditoría y soporte forman una sola línea, así que no tienes que ensamblar todo por tu cuenta. El costo es que cada transacción confidencial primero tiene que calcular la prueba; cuanto más grande sea el conjunto anónimo, más datos públicos habrá, y además esa parte de Enygma debe licenciarse bajo BUSL.
Ese «cuanto más»… ¿cuánto más? Puedo estimarlo; aquí está el cálculo que hice. Una transferencia de confidencialidad con un grupo de 6 personas: el total de prueba más datos públicos es de aproximadamente 1.776 bytes. Si lo escalas según el volumen de 210.483 transferencias diarias promedio de CHAPS en Reino Unido para 2025: serían ~374 MB al día, y ~136 GB al año. Para el almacenamiento institucional no es gran cosa, pero es un costo fijo que crece linealmente con el número de notas, y el conjunto anónimo es ajustable: bajándolo a un grupo de 2 personas, cada transferencia tiene solo 752 bytes. Supongo que cada transacción solo genera una prueba y no contabilizo esos otros tipos de circuitos para almacenar, retirar y DvP.
De esa línea solo se pueden extraer tres palabras como problema general: en qué capa. Pregunta en qué capa vive la funcionalidad de privacidad para el proveedor, quién la mantiene, cuál es su ciclo de vida y si el libro mayor está o no atado al mismo. Los cambios en Besu en estos dos años muestran que la respuesta cambiará, y que el cambio es destructivo.
Lo que confirmé y lo que inferí
Parte confirmada: si los archivos existen o no en distintas versiones, el número de interfaces y parámetros de arranque, el contenido de comunicados oficiales y notas de lanzamiento, el número de bytes de las pruebas y de los datos públicos, y el tiempo que tardó la prueba de la entrada anterior. Todo esto se puede volver a ejecutar siguiendo los comandos de las capturas.
Parte inferida: la actualización interrumpe los negocios de privacidad existentes; deduzco esto por la desaparición de las interfaces. No probé realmente actualizando una red privada de 25.4 a 25.6. Tampoco evalué si Paladin puede encajar en el caso concreto de alguna institución.
En alcance, solo miré los circuitos de transferencia y la parte de privacidad. Los usuarios de Besu pueden perfectamente mantener sus propias ramas o escribir plugins; su licencia lo permite. No toqué las otras ocho filas de la tabla comparativa.
Mi opinión
La tabla comparativa es una imagen estática, mientras que la capacidad de los proyectos de código abierto se mueve. En esa línea, en dos años pasó de «integrado en el cliente» a «mantenido por la capa de aplicación», pero la tabla solo puede marcar un visto.
Por eso, prefiero usar este tipo de tablas como punto de partida tipo checklist: revisa cada fila mirando una vez en el repositorio del otro cuál es la versión actual. El tiempo que me llevó esta vez fue menos de una hora; los comandos están en capturas. La próxima vez que Rayls actualice esa tabla, lo que vale la pena mirar es si agrega notas de versión en esa sección de Besu.
Fuente de referencia: la página de producto Sovereign del sitio web de Rayls y la tabla comparativa con el proveedor; el banner de retirada en la sección de privacidad de la documentación oficial de Besu; las notas de lanzamiento de Besu 25.6.0, entrada #8369; el anuncio del 24 de septiembre de 2024 de LF Decentralized Trust (Sunsetting Tessera and Simplifying Besu) y el anuncio del proyecto Paladin; las tres etiquetas en el repositorio hyperledger/besu: 25.4.0, 25.6.0 y 26.2.0 (leído el 24 de septiembre de 2026); el commit 67c4c26 en raylsnetwork/rayls-sovereign-gnark-api (medición en local).