RippleX espera la próxima versión del software del servidor principal del XRP Ledger, xrpld 3.3.0, tan pronto como la próxima semana. El lanzamiento reincorporaría las enmiendas de Lote y Delegación de Permisos reescritas al proceso de validador, tras fallos de autorización que llevaron a los operadores a bloquear sus versiones anteriores antes de la activación del mainnet.
El lanzamiento sigue en la etapa de prerelease. xrpld 3.2.1 seguía siendo la versión estable más reciente el 1 de agosto, mientras que las etiquetas oficiales beta y release-candidate para la 3.3.0 estaban disponibles públicamente. Aún no había comenzado el conteo regresivo de mayoría en mainnet para ninguna de las enmiendas de reemplazo.
El jefe del producto RippleX, Jazzi Cooper, listó cinco funciones propuestas para el XRP Ledger 3.3.0: MPT confidencial, Lote, Delegación de permisos, Tarifas y reservas patrocinadas, y MPT dinámico. Cooper dijo que las cinco aún requieren la aprobación de los validadores antes de su activación.
¿Por qué los validadores detuvieron las funciones originales
La enmienda original por lotes contenía una falla de autorización que podría haber permitido a un atacante ejecutar transacciones internas para cuentas de víctimas arbitrarias sin sus claves privadas, incluyendo pagos no autorizados y cambios en el libro mayor.
La divulgación oficial indicó que los investigadores encontraron el problema mientras la enmienda aún estaba en votación. Los validadores bloquearon la activación, y ningún fondo se puso en riesgo. CryptoSlate informó sobre esa intervención en febrero.
La delegación de permisos expuso una ruta diferente a la pérdida. Una transacción firmada fuera de línea inválida aún podía cobrar una tarifa de transacción a una cuenta víctima antes de fallar en la autorización, permitiendo envíos repetidos para agotar XRP a través de tarifas. La divulgación de XRPL indicó que la función nunca se activó en mainnet, y los validadores desactivaron el soporte para la enmienda afectada.
El registro de desarrollo 3.3 ahora marca BatchV1_1 y PermissionDelegationV1_1 como compatibles con votos predeterminados en No. “Compatibles” en ese registro significa que el código del servidor comprende las enmiendas; la aprobación y activación por parte de los validadores siguen siendo pasos separados.
Las enmiendas de XRPL solo pueden activarse después de que se implemente el código compatible y el soporte permanezca por encima del 80% de los validadores de confianza durante dos semanas. Si el soporte cae al 80% o menos antes de la activación, el período se reinicia.
El 1º de agosto, el objeto Amendments validado en el libro mayor 105,997,300 no contenía el campo Majorities ni ninguna sustitución entre las enmiendas habilitadas. El campo registra las enmiendas pendientes que han superado el umbral de mayoría, lo que establece que ningún reloj de dos semanas estaba activo. El objeto del libro mayor solo registra relojes de mayoría activos, dejando sin revelar el apoyo exacto por debajo del umbral.
La activación también impondría una fecha límite operativa. Las reglas de enmienda de XRPL indican que un servidor que no comprenda una enmienda activada puede quedar bloqueado por enmienda, perdiendo la capacidad de determinar la validez del libro mayor, procesar transacciones, unirse al consenso o votar. Si cualquiera de las sustituciones se activa, los operadores necesitarán software compatible independientemente de cómo hayan votado personalmente.
El próximo hito medible de XRPL es una versión estable, seguida de una supermayoría sostenida de validadores para cualquiera de las enmiendas. Hasta entonces, las reescrituras siguen siendo propuestas para funciones detenidas antes de la activación, sin explotación ni pérdida en mainnet de la que recuperarse.
La publicación How XRPL validators quietly killed a silent exploit that could have drained victim accounts through transaction fees alone apareció por primera vez en CryptoSlate.