El XRPL Dashboard registró 30 votos a favor entre los 35 validadores confiables que monitorea cuando se consultó a las 04:43 UTC del 26 de septiembre. Ese recuento inicia una nueva ventana de aprobación para la enmienda BatchV1_1; por sí solo, no completa el proceso de activación.

Puntos clave:

• BatchV1_1 recuperó 30 de los 35 votos de validadores.
• El reloj de aprobación de dos semanas anterior se ha reiniciado.
• Ahora deben mantenerse al menos 29 votos.
• El 9 de octubre es una fecha más temprana y condicional.
• La activación en el ledger confirma la actualización.

La fecha se reinició aunque el recuento de votos se recuperó

BatchV1_1 alcanzó 30 validadores de apoyo el 15 de septiembre. Según el calendario original, eso situaba la activación cerca del 29 de septiembre. La mayoría fue retirada el 25 de septiembre y se reconstituyó más tarde ese mismo día, moviendo la estimación unos 10 días más adelante.

El dashboard identifica los flag ledgers en los que se retiró la mayoría anterior y se registró la nueva. No revela por qué ocurrió el cambio temporal ni identifica el razonamiento de algún validador en particular. El hecho confirmado es el reinicio en sí: una enmienda necesita respaldo ininterrumpido durante toda la ventana, incluso cuando su recuento de votos vuelve después al mismo nivel.

Eso hace del 9 de octubre una estimación condicional derivada del registro de mayoría actual del ledger. Puede volver a cambiar antes de la activación.

Treinta votos a favor dejan un voto por encima de la línea

El umbral de XRPL a menudo se abrevia como "80% de apoyo", pero la regla es más estricta: una enmienda necesita más del 80% de respaldo de los validadores confiables. Con 35 validadores en el conjunto monitoreado del dashboard, 28 votos equivalen exactamente al 80%. BatchV1_1 necesita 29 votos a favor para iniciar o preservar su mayoría.

El recuento actual de 30 equivale a aproximadamente el 85.7%. Tiene un voto por encima del requisito de 29 votos. Un movimiento de 30 a 29 dejaría la cuenta regresiva intacta; una caída a 28 activaría otro reinicio en el flag ledger correspondiente.

El proceso de enmiendas de XRPL verifica los votos en torno a los flag ledgers, típicamente cada 15 minutos. Estos flag ledgers actúan como puntos de control recurrentes donde se mide el apoyo, y el reloj de dos semanas solo corre mientras el recuento se mantiene por encima del umbral. Una vez que una enmienda ha mantenido más del 80% de apoyo durante dos semanas, el cambio se aplica permanentemente a las versiones posteriores del ledger.

El código del servidor y las reglas de Mainnet son etapas separadas

Coindoo explicó previamente cómo BatchV1_1 puede coordinar instrucciones de pago conectadas. Esa utilidad no es el problema planteado por el reinicio. La pregunta actual es si la enmienda corregida puede completar el proceso de validadores necesario para que esas reglas de transacción entren en vigor en Mainnet.

La disponibilidad en el software del servidor hace que una enmienda sea elegible para la votación de validadores, mientras que el comportamiento de Mainnet solo cambia después de que la red la habilita. Esta separación es la razón por la que una fecha del dashboard debe leerse como una estimación en vivo del avance de gobernanza y no como un anuncio de lanzamiento de producto.

Por qué importa ahora el retiro de seguridad anterior

BatchV1_1 es el sucesorregido de una enmienda Batch anterior que fue retirada antes de la activación en Mainnet después de que investigadores encontraran una falla de autorización. La versión original nunca se activó y, por lo tanto, el problema no expuso fondos de usuarios de Mainnet.

Según la divulgación de vulnerabilidad de XRPL, el reemplazo incorporó cambios en las verificaciones de firma y autorización y se sometió a una revisión adicional antes de regresar a la votación. El episodio muestra cómo el proceso funciona según lo previsto: el código que se vuelve disponible en el software del servidor aún puede detenerse antes de cambiar las reglas de Mainnet. La nueva ventana de 14 días es la prueba de gobernanza actual para esa implementación revisada.

La confirmación a observar está en el ledger

El 9 de octubre solo importa si la mayoría se mantiene durante toda la ventana. La confirmación vendrá de una pseudo-transacción EnableAmendment registrada por el ledger, después de la cual BatchV1_1 se convierte en una regla activa de Mainnet para los ledgers posteriores.

Hasta que ese evento aparezca, la actualización relevante es la continuidad de la mayoría de validadores. El dashboard ofrece una vista útil de la cuenta regresiva actual, pero el registro de activación del ledger determinará si la enmienda Batch corregida realmente cruzó la línea hacia la infraestructura activa de XRPL.

Este artículo se proporciona únicamente con fines informativos y no constituye asesoramiento financiero ni de inversión. El apoyo de los validadores y el estado de la enmienda pueden cambiar.