Los desarrolladores de XRP Ledger han retirado cinco enmiendas de protocolo activas desde hace tiempo en la versión 3.3.0 de xrpld, pero la medida no elimina sus características ni requiere que los holders de XRP tomen ninguna medida.
La ingeniera de software de RippleX, Mayukha Vadari, explicó en X que el retiro elimina el código antiguo previo a la enmienda que queda después de que un cambio de protocolo ha operado durante años. El comportamiento enmendado en sí mismo permanece. La documentación oficial de XRPL confirma que las enmiendas retiradas se convierten en partes incondicionales del protocolo central.
La distinción se volvió importante después del lanzamiento del 6 de agosto de xrpld 3.3.0, que retiró Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve y fixUniversalNumber. En otras palabras, "retirar Clawback" no significa que los emisores de XRP Ledger pierdan la funcionalidad de clawback. La red está eliminando la ruta de código más antigua que describía cómo se comportaban las transacciones antes de que la enmienda se activara.
El sistema de enmiendas de XRP Ledger permite introducir cambios de protocolo sin forzar inmediatamente cada nueva regla en la Mainnet. Los validadores votan las enmiendas, y una propuesta debe mantener el apoyo de más del 80% de los validadores de confianza durante dos semanas continuas antes de que se active. Una vez habilitado, el nuevo comportamiento se aplica permanentemente a menos que otra enmienda lo cambie posteriormente.
Durante el período posterior a la activación, xrpld mantiene tanto la lógica actual como parte del código previo a la enmienda. Ese código heredado puede ayudar a los desarrolladores a reproducir el comportamiento antiguo del ledger al depurar o verificar transacciones históricas. Sin embargo, mantener años de ramas obsoletas también añade complejidad a la base de código.
La documentación oficial de enmiendas establece que una enmienda de Mainnet puede ser retirada una vez que ha estado habilitada durante dos años. El retiro elimina su ruta de código antigua, deja de tratar el cambio como una enmienda condicional e incorpora el comportamiento más reciente en el protocolo de forma incondicional.
Vadari describió el proceso como "puramente una limpieza del código" y dijo que "no afectará a ningún usuario". Añadió que los desarrolladores generalmente esperan dos años porque la implementación anterior aún puede ser útil al depurar transacciones antiguas. La propia documentación de pruebas de XRPL advierte de manera similar que la reproducción históricamente precisa de transacciones puede requerir ejecutar la versión de xrpld que procesó originalmente la transacción después de que las enmiendas antiguas hayan sido retiradas.
Clawback es la más reconocible de las cinco enmiendas retiradas y la más fácil de malinterpretar. La característica se activó en la Mainnet el 8 de febrero de 2024 y permite a los emisores que cumplen los requisitos recuperar los tokens emitidos de los holders cuando la cuenta emisora ha habilitado la configuración de clawback requerida. No permite a un emisor recuperar el XRP nativo.
Retirar la enmienda, por lo tanto, significa que la red ya no necesita código para una versión de XRPL donde Clawback no existía. El comportamiento actual de Clawback sigue siendo parte del protocolo. La página de enmiendas conocidas de XRPL ahora marca explícitamente su funcionalidad previa a la enmienda como retirada.
Las otras cuatro retiradas siguen el mismo principio. fixDisallowIncomingV1 corrigió un problema de autorización de trust line. fixInnerObjTemplate abordó errores relacionados con objetos AMM internos. fixNFTokenReserve añadió comprobaciones de reserva cuando se aceptan ofertas de NFT, mientras que fixUniversalNumber unificó partes de los cálculos de coma flotante decimal de XRPL. Sus reglas posteriores a la enmienda permanecen en vigor a pesar de que las rutas antiguas están siendo eliminadas.
Este no es un nuevo mecanismo de gobernanza. XRPL ha retirado enmiendas anteriores después de que sus reglas se establecieron suficientemente. La versión 3.2.0, por ejemplo, retiró cambios más antiguos que cubrían Cheques, Autorización de Depósito, eliminación de cuentas y otras funciones de protocolo.
Mientras cinco enmiendas antiguas están dejando su estado condicional, la versión 3.3.0 añade seis nuevas propuestas a xrpld. Estas son BatchV1_1, ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1, Sponsor y fixCleanup3_3_0. Su inclusión en el software no significa que esas capacidades ya estén activas en la Mainnet.
Como informó crypto.news, ConfidentialTransfer apoyaría las transferencias de tokens multipropósito con privacidad, mientras que BatchV1_1 permitiría a una cuenta enviar hasta ocho transacciones internas juntas. Sponsor permitiría a terceros cubrir tarifas y requisitos de reserva, mientras que DynamicMPT proporcionaría más flexibilidad sobre las propiedades de los tokens seleccionados.
Cada propuesta aún debe superar de forma independiente el proceso de validación de XRPL. Más del 80% de apoyo debe persistir durante dos semanas antes de que una enmienda se active, y el apoyo puede caer por debajo del umbral y reiniciar el temporizador.
La diferencia entre estas nuevas enmiendas y las cinco retiradas es, por lo tanto, sustancial. Las nuevas propuestas están esperando la aprobación de la red. Las enmiendas retiradas ya pasaron esa etapa hace años, se convirtieron en un comportamiento establecido de la red y ahora han llegado al punto en que ya no se considera necesario mantener su código antiguo.
Para los holders de XRP comunes, no se requiere ninguna migración, actualización de wallet o transacción específicamente porque las cinco enmiendas fueron retiradas. Clawback y los otros comportamientos de protocolo afectados continúan operando bajo las reglas establecidas.
Los operadores de servidores tienen una consideración diferente. El aviso de lanzamiento de XRPL 3.3.0 indica a los operadores que actualicen a la versión 3.3.0 lo antes posible para mantener la continuidad del servicio. Mantenerse actualizado también es importante porque los servidores necesitan software que contenga el código para las enmiendas que puedan activarse más adelante. Un servidor que carezca de una enmienda activada puede quedar bloqueado por enmienda y dejar de participar normalmente en la red.
En noticias relacionadas, ese mecanismo se demostró en julio cuando la activación de fixCleanup3_2_0 dejó a los nodos que ejecutaban versiones más antiguas incompatibles bloqueados por enmienda.
La atención ahora se traslada de las enmiendas retiradas a las decisiones de los validadores en torno a las seis adiciones en la versión 3.3.0. Como se informó anteriormente, ConfidentialTransfer se encuentra entre las propuestas destinadas a expandir las herramientas de XRPL para activos tokenizados institucionales, pero su uso aún depende de la aprobación de los validadores.
Para las cinco enmiendas retiradas, sin embargo, no hay una votación comparable por delante. El retiro marca el final de su período de transición en lugar del final de su funcionalidad: las reglas enmendadas ahora son simplemente parte del comportamiento central permanente de XRP Ledger.
