- XRPLD 3.2.1 corrige los riesgos de manifestos del validador, mientras que la 3.3.0 amplía las características del protocolo.
- BatchV1_1 restaura las transacciones agrupadas con la validación correcta de firma interna.
- Las transferencias confidenciales y las tasas patrocinadas están en desarrollo y no están activas.
El próximo ciclo de software XRP Ledger es separar una reparación de seguridad enfocada de un conjunto más amplio de cambios de protocolo para validadores, intercambios y desarrolladores de aplicaciones. A fecha de 1 de agosto de 2026, xrpld 3.2.1 seguía siendo la última versión, mientras que el hito 3.3.0 mostraba 122 elementos sin fecha de lanzamiento.
Ese estatus crea una distinción para validadores, intercambios y desarrolladores que preparan un plan de actualización xrpld 2026. Esencialmente, la versión 3.2.1 refuerza la resiliencia de los nodos al abordar problemas de propagación de manifestos de validadores y limitar los riesgos derivados de mensajes entre pares no confiables.
En cambio, XRPL 3.3.0 frente a 3.2.1 ofrece un paquete más amplio que incluye procesamiento por lotes de transacciones, herramientas de privacidad, funciones de patrocinio y salvaguardas operativas.
BatchV1_1 trae transacciones agrupadas más seguras a XRPL 3.3.0
La versión 3.2.1 se lanzó el 31 de julio como respuesta dirigida a los riesgos en el manifiesto del validador. Limitaba la caché de manifiestos no confiables, rechazaba manifiestos validadores sobredimensionados y limitaba el número de manifiestos no confiables que llevaban en mensajes de pares. Estos cambios redujeron la exposición a datos malformados o excesivos sin introducir funciones más amplias del protocolo.
Frente a ese enfoque más restringido en la seguridad, la primera gran diferencia en el hito 3.3.0 es BatchV1_1, que reemplaza la enmienda de lotes retirada. XRPL deshabilitó previamente Batch y fixBatchInnerSigs en la versión 3.1.1 después de que los investigadores encontraran un fallo en la autorización de transacciones internas. Dado que las transacciones internas carecen de firmas independientes, ciertas condiciones podrían haber permitido la ejecución de instrucciones no autorizadas.
Para abordar esa debilidad, el hito de desarrollo de la 3.3.0 incluye la integración de BatchV1_1 la implementación y el código que habilita enmiendas. El diseño mantiene el enfoque XLS-56 de combinar varias transacciones bajo reglas de ejecución definidas. Sin embargo, añade validación de firma corregida en lugar de depender de la obsoleta enmienda fixBatchInnerSigs.
| Área de comparación | XRPLD 3.2.1 | Esperado xrpld 3.3.0 |
| Estado de publicación | Última versión estable de producción | Hito de desarrollo con 122 elementos completados |
| Propósito principal | Corrector de seguridad de manifiestos de validador | Actualización más amplia de protocolo y fiabilidad |
| Transacciones por lotes | El lote retirado sigue inutilizado | BatchV1_1 añade comprobaciones de autorización rediseñadas |
| Transferencias confidenciales | No soportado | El código de desarrollo soporta transferencia confidencial. |
| Cuotas patrocinadas | No activo | El trabajo relacionado con patrocinadores sigue en desarrollo |
Las características de XRPL 3.3.0 aún requieren aprobación de validadores
La segunda diferencia tiene que ver con la activación. El soporte de software no activa automáticamente las enmiendas del Ledger XRP en la Mainnet. Una enmienda debe mantener el apoyo de más del 80% de los validadores de confianza durante dos semanas. Por lo tanto, los operadores deben separar la disponibilidad de código de la activación de red al revisar la corrección de errores de las transacciones por lote de XRPL.
Transferencias confidenciales Añadir herramientas de privacidad a XRPL 3.3.0
La tercera diferencia es ConfidentialTransfer, basado en XLS-96. El trabajo de desarrollo fusionado permite la enmienda dentro de la rama 3.3.0. La propuesta ocultaría los saldos de tokens multipropósito y los importes transferidos mediante criptografía EC-ElGamal y pruebas de conocimiento cero.
Los emisores autorizados, auditores o entidades designadas aún podrían recibir acceso a la divulgación. Esa estructura Confidential MPT XRP Ledger se dirige a activos tokenizados regulados mientras reduce la exposición pública de los detalles de las transacciones. No obstante, la documentación oficial sigue listando ConfidentialTransfer como «En desarrollo», mientras que la versión estable mantiene por defecto el voto «No».
Las tasas patrocinadas podrían eliminar las barreras de incorporación de XRP
La cuarta diferencia se refiere a la enmienda de Honorarios y Reservas Patrocinadas, también llamada Patrocinador o XLS-68. Permitiría a empresas, solicitudes o emisores cubrir las comisiones de transacción de otra cuenta, los requisitos de reservas o ambos. Los usuarios patrocinados seguirían controlando sus cuentas y claves privadas.
Relacionado: La comunidad XRP cambia su enfoque a la utilidad XRPL antes de las grandes actualizaciones
Este enfoque podría reducir las barreras de incorporación, ya que los nuevos usuarios no necesitarían XRP inmediatamente para comisiones o reservas de objetos del libro mayor. Aun así, Patrocinador sigue en desarrollo y no está activo en la versión 3.2.1. Su inclusión en el paquete final 3.3.0 tampoco está confirmada hasta que las notas oficiales de lanzamiento definen el conjunto completo de funciones.
XRPL 3.3.0 amplía la fiabilidad y las salvaguardas del libro mayor
Más allá de estas características propuestas, la quinta diferencia es la gama más amplia de mejoras operativas. El hito 3.3.0 incluye filtrado de transacciones delegadas para account_tx, correcciones de redondeo numérico, invariantes de eliminación de cuentas pseudo-eliminadas, comprobaciones de congelación alineadas y salvaguardas AMM relacionadas con los compartidos de bóveda.
En conjunto, estos cambios amplían la actualización más allá de las modificaciones individuales hacia mejoras más amplias en la fiabilidad y consistencia del libro mayor. En consecuencia, XRPL 3.3.0 frente a 3.2.1 representa un cambio del mantenimiento defensivo a capacidades de protocolo más amplias.
Sin embargo, la versión 3.2.1 sigue siendo el objetivo estable para los operadores. Además, la clave rotatoria de firma de paquetes de Ripple debe ser confiable para las actualizaciones automáticas. Mientras tanto, las pruebas deben permanecer separadas hasta que los paquetes firmados y las notas finales confirmen la versión XRP Ledger 3.3.0.
Disclaimer: The information presented in this article is for informational and educational purposes only. The article does not constitute financial advice or advice of any kind. Coin Edition is not responsible for any losses incurred as a result of the utilization of content, products, or services mentioned. Readers are advised to exercise caution before taking any action related to the company.
