El XRP Ledger ya trae las transferencias cifradas para bancos y llevan cero votos, y 18 de los 35 validadores que deciden corren un servidor que no sabe que existen

El servidor de referencia del XRP Ledger publicó la versión 3.3.0 el jueves por la noche y con ella seis enmiendas nuevas, entre las que va la que más titulares se ha llevado: transferencias cifradas para tokens institucionales, con importes y saldos ocultos al público pero verificables por auditores y reguladores. La lectura que ha circulado desde entonces es que la privacidad institucional ya está en la cadena. La cadena dice otra cosa. Consultado el registro de enmiendas la madrugada del sábado, la enmienda ConfidentialTransfer tiene cero votos.

No cero de forma retórica. Cero literal, treinta y dos horas después de que el código estuviera descargable, con el listón puesto en 28 votos sobre los 35 validadores que integran la lista de confianza por defecto. Y hay un detalle que ninguna de las coberturas ha puesto sobre la mesa: 18 de esos 35 validadores siguen corriendo la versión 3.2.1, un servidor que no lleva el código de la enmienda y que, por tanto, no puede votarla ni aunque su operador quiera. El techo aritmético de hoy es 17. El suelo para pasar es 28.

Seis enmiendas, y las cuatro grandes en blanco

El anuncio oficial de xrpl.org lista lo que trae 3.3.0: BatchV1_1 (transacciones atómicas por lotes, XLS-56), ConfidentialTransfer (XLS-0096), DynamicMPT (propiedades mutables en tokens multipropósito, XLS-94), PermissionDelegationV1_1 (delegación granular de permisos entre cuentas), Sponsor (que un tercero pague comisiones y reservas del usuario final, XLS-68) y fixCleanup3_3_0, un paquete de arreglos. Además retira cinco enmiendas veteranas, entre ellas Clawback, que pasan a ser protocolo sin más.

El reparto de votos a día de hoy, leído del registro público de enmiendas, es este:

Cuatro votos son los que se sacan las dos enmiendas que un servidor recién actualizado aprueba por defecto sin que nadie toque un fichero de configuración. Las otras cuatro, incluida la joya criptográfica del lanzamiento, están donde estaban el jueves.

Por qué 18 validadores no pueden decir sí

El mecanismo está documentado y no admite atajos. Cada versión del servidor se compila con una lista cerrada de enmiendas conocidas y con el código que las implementa. Un operador puede configurar su voto para cada una, y si no lo hace se aplica el voto por defecto que trae el código fuente. Lo que no puede hacer es votar una enmienda cuyo código no tiene compilado. Un validador en 3.2.1 no está en contra de las transferencias confidenciales: es que para él no existen.

Contados uno a uno los 35 validadores de la lista de confianza, 17 corren ya 3.3.0 y 18 se han quedado en 3.2.1. Fuera de esa lista, entre los 266 validadores que publica el registro, el reparto es más disperso todavía: 83 en 3.2.1, 63 en 3.3.0, 57 en 3.2.0 y una veintena anclada en un 1.0.4 que tiene años.

El recuento se resuelve en los llamados ledgers bandera, uno cada 256 bloques, aproximadamente cada quince minutos. Desde la publicación del paquete han pasado del orden de 127 de esas rondas sin que la enmienda estrella sume un solo voto. Y el reloj de las dos semanas de apoyo sostenido por encima del 80% no arranca hasta que ese 80% aparece: si el respaldo cae por debajo, el contador vuelve a cero y hay que empezar otra vez.

Dos de las seis son segundos intentos

Hay una lectura del lanzamiento que explica mejor la cautela de los operadores que cualquier teoría sobre el precio de XRP. Dos de las seis enmiendas no son novedades, son reintentos. BatchV1_1, dice el propio anuncio, «arregla y sustituye a la enmienda Batch original deshabilitada en la v3.1.1». PermissionDelegationV1_1 «sustituye a la enmienda PermissionDelegation original, corrigiendo un fallo crítico descubierto en la implementación original de la función».

De ese primer fallo escribimos hace una semana: un error en el bucle que validaba los firmantes de un lote permitía ejecutar transacciones internas sin autorización, lo encontró una herramienta de análisis estático y la función se retiró antes de que la red perdiera un dólar. Que vuelva a la papeleta es exactamente lo que se anunció entonces. Que vuelva acompañada de la pieza criptográficamente más ambiciosa que ha intentado esta cadena, en el mismo paquete y en la misma votación, es otra cosa. Un validador prudente no tiene forma de decir sí a una y no a la otra sin editar su configuración a mano.

El precedente que nadie cita: 192 días esperando

Quien crea que el cero de hoy se corrige en unos días debería mirar lo que llevan pendientes otras enmiendas de esta misma cadena. SingleAssetVault y LendingProtocol, las bóvedas de un solo activo y el protocolo de préstamos, entraron a votación con la versión 3.1.0 el 28 de enero. Llevan 192 días en la papeleta y suman 14 y 13 votos respectivamente. Ninguna ha visto nunca los 28.

Del total de 110 enmiendas registradas, 17 siguen sin activar. Ahí sigue XChainBridge, el puente entre cadenas, con 4 votos desde la versión 2.0.0. Y ahí sigue la vieja Batch, la que está deshabilitada por el fallo, acumulando 12 votos de validadores que no han retirado su respaldo a una función que ya no debería recibirlo, más otros 10 en fixBatchInnerSigs, el parche que la nueva enmienda hace innecesario. El registro no es solo una lista de lo que viene: también es un archivo de lo que se quedó a mitad.

Qué es en realidad lo que se está votando

Merece la pena decir qué hay dentro, porque el contenido técnico sí es notable. La especificación XLS-0096 extiende el estándar de tokens multipropósito con cifrado EC-ElGamal y pruebas de conocimiento cero. Los saldos individuales y los importes transferidos quedan cifrados y no se revelan ni a los validadores ni a observadores externos, mientras la oferta total del token sigue siendo verificable públicamente y las cuentas y el tipo de token siguen a la vista. El emisor, un auditor o un regulador pueden obtener acceso selectivo cuando toca.

Es, en la práctica, la respuesta a la objeción que llevan años poniendo los bancos y las tesorerías corporativas a operar en una cadena pública: que cualquiera pueda calcular el tamaño de sus posiciones y de cada pago. El mismo problema que se ve en cada nuevo vehículo tokenizado, como los 3.467 millones en bonos y acciones que salieron esta semana. Que el código exista ya es material para integrar en redes de prueba. Pero en la red principal, hoy, una transferencia confidencial no se puede firmar.

La otra cara

Nada de esto es un fallo del proceso. Es el proceso. La razón de que las enmiendas necesiten un 80% sostenido durante dos semanas es precisamente que un cambio en el procesamiento de transacciones no se pueda colar por consenso apresurado, y el historial reciente de esta cadena defiende el diseño: los dos fallos críticos de este año se detectaron con la función deshabilitada y sin fondos en juego. Que 17 de 35 validadores hayan actualizado en poco más de un día es, para infraestructura financiera, rápido. El voto por defecto de una enmienda también puede cambiar entre versiones, y RippleX no controla la papeleta: publica el código y los operadores deciden.

La objeción no es que la votación vaya lenta. Es que la cobertura del lanzamiento ha contado una activación que no ha ocurrido, y el mercado la ha leído así. XRP cotiza a 1,033 dólares con una capitalización de 64.660 millones y sube un 1,64% en 24 horas, en línea con un bitcoin en 64.982 dólares (+1,24%) y un ether en 1.917 (+1,13%). No hay reacción de precio a la noticia, y con estos números tampoco debería haberla: lo que se publicó el jueves es una papeleta, no una función.

Qué hay que vigilar

Datos: xrpl.org (anuncio de la versión 3.3.0, documentación de enmiendas y especificación XLS-0096), repositorio XRPLF/rippled en GitHub, registro público de enmiendas y de validadores de XRPScan, nodo público de la red principal (server_info, ledger validado 106.148.056), CoinGecko.