Los desarrolladores de XRP Ledger han retirado cinco enmiendas de protocolo de larga duración en la versión 3.3.0 de xrpld, pero la medida no elimina sus funciones ni requiere que los titulares de XRP tomen medidas.
Resumen
- XRPL 3.3.0 retira cinco enmiendas de larga duración, haciendo que su comportamiento posterior a la activación sea permanente dentro del protocolo central.
- Clawback sigue disponible después del retiro porque solo se elimina el código obsoleto anterior a la enmienda del software xrpld.
- La documentación de XRPL permite el retiro de enmiendas después de dos años de activación en Mainnet para reducir la complejidad heredada.
- Seis nuevas enmiendas entraron en la versión 3.3.0, pero cada una aún requiere la aprobación de los validadores antes de la activación en Mainnet.
- Los operadores de nodos deben actualizar a la versión 3.3.0 de inmediato, mientras que los usuarios no tienen que tomar ninguna acción relacionada con el retiro.
La ingeniera de software de RippleX, Mayukha Vadari, explicó en X que el retiro elimina el código antiguo anterior a la enmienda que queda después de que un cambio de protocolo ha operado durante años. El comportamiento enmendado en sí 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 de xrpld 3.3.0 el 6 de agosto, 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 retiro de XRP Ledger hace permanentes las reglas antiguas
El sistema de enmiendas de XRP Ledger permite introducir cambios de protocolo sin forzar inmediatamente cada nueva regla en Mainnet. Los validadores votan sobre 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 activarse. Una vez habilitada, el nuevo comportamiento se aplica permanentemente a menos que otra enmienda lo cambie más tarde.
Durante el período posterior a la activación, xrpld mantiene tanto la lógica actual como algo de código anterior a la enmienda. Ese código heredado puede ayudar a los desarrolladores a reproducir el comportamiento antiguo del libro mayor al depurar o verificar transacciones históricas. Sin embargo, mantener años de ramas obsoletas también añade complejidad al código base.
La documentación oficial de enmiendas dice que una enmienda de Mainnet puede retirarse 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 nuevo al protocolo de manera incondicional.
Vadari describió el proceso como "puramente una limpieza del código base" y dijo que "no afectará a ningún usuario". Agregó que los desarrolladores generalmente esperan dos años porque la implementación anterior aún puede ser útil al depurar transacciones más antiguas. La documentación de pruebas de XRPL también advierte que la reproducción históricamente precisa de transacciones puede requerir ejecutar la versión de xrpld que originalmente procesó la transacción después de que las enmiendas antiguas hayan sido retiradas.
Clawback no se está eliminando de XRPL
Clawback es la más reconocible de las cinco enmiendas retiradas y la más fácil de malinterpretar. La función se activó en Mainnet el 8 de febrero de 2024 y permite a los emisores calificados recuperar tokens emitidos de los titulares cuando la cuenta emisora ha habilitado la configuración de clawback requerida. No permite que un emisor recupere XRP nativo.
Por lo tanto, retirar la enmienda 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 anterior a la enmienda como retirada.
Las otras cuatro jubilaciones siguen el mismo principio. fixDisallowIncomingV1 corrigió un problema de autorización de líneas de confianza. fixInnerObjTemplate abordó errores que involucran objetos AMM internos. fixNFTokenReserve agregó verificaciones de reserva cuando se aceptan ofertas de NFT, mientras que fixUniversalNumber unificó partes de los cálculos de punto flotante decimal de XRPL. Sus reglas posteriores a la enmienda siguen en vigor aunque se eliminen las rutas anteriores.
Este no es un mecanismo de gobernanza nuevo. XRPL ha retirado enmiendas anteriores después de que sus reglas se establecieran suficientemente. La versión 3.2.0, por ejemplo, retiró cambios anteriores que cubrían Cheques, Autorización de Depósito, eliminación de cuentas y otras funciones del protocolo.
La versión 3.3.0 también inicia un nuevo ciclo de enmiendas
Mientras cinco enmiendas antiguas salen del estado condicional, la versión 3.3.0 agrega seis nuevas propuestas a xrpld. 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 Mainnet.
Como informó crypto.news, ConfidentialTransfer apoyaría transferencias de tokens multipropósito que preservan la privacidad, mientras que BatchV1_1 permitiría que una cuenta envíe hasta ocho transacciones internas juntas. Sponsor permitiría que terceros cubran tarifas y requisitos de reserva, mientras que DynamicMPT proporcionaría más flexibilidad sobre propiedades de tokens seleccionadas.
Cada propuesta aún debe superar el proceso de validadores de XRPL de forma independiente. 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 a la espera de la aprobación de la red. Las enmiendas retiradas ya superaron esa etapa hace años, se convirtieron en comportamiento de red establecido y ahora han llegado al punto en que mantener su código anterior ya no se considera necesario.
Qué sigue para los operadores de XRPL
Para los tenedores ordinarios de XRP, no se requiere migración, actualización de billetera 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 al día también es importante porque los servidores necesitan software que contenga el código para las enmiendas que pueden 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 una cobertura relacionada, ese mecanismo se demostró en julio cuando la activación de fixCleanup3_2_0 dejó a los nodos que ejecutaban versiones incompatibles anteriores bloqueados por enmienda.
La atención ahora se desplaza 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 en el futuro. La jubilación marca el final de su período de transición más que el final de su funcionalidad: las reglas enmendadas ahora son simplemente parte del comportamiento central permanente de XRP Ledger.
