La publicación XRPL corrige un fallo crítico previo a la mainnet, pero las aplicaciones cliente siguen en riesgo apareció en BitcoinEthereumNews.com.
Los validadores de XRP Ledger (XRPL) han situado BatchV1_1 en una ruta condicional para activarse a las 14:06:41 UTC del 29 de septiembre, convirtiendo un casi accidente de seguridad en una prueba en vivo del proceso de enmienda de la red y de su software circundante. El 22 de septiembre, xrpldashboard mostró 30 de 35 validadores de confianza apoyando la enmienda, por encima de su umbral mostrado de 28 votos. La mayoría apareció por primera vez en el ledger el 15 de septiembre. Según las reglas de enmienda de XRPL, el apoyo debe mantenerse por encima del 80% durante dos semanas. Una caída al 80% o menos pone fin al periodo de mayoría, por lo que la fecha de activación sigue siendo condicional. El 29 de septiembre es la primera prueba en producción de si el proceso de validadores de XRPL, la implementación de referencia y el ecosistema de clientes convirtieron un peligroso fallo previo a la mainnet en una infraestructura utilizable de transacciones atómicas. El cortafuegos de los validadores funcionó antes de la mainnet La enmienda Batch original nunca se activó en la mainnet de XRP Ledger. En febrero, los investigadores encontraron un fallo crítico de autorización mientras la enmienda aún estaba en su fase de votación, y se aconsejó a los validadores que votaran en contra. La divulgación oficial de vulnerabilidades de XRPL Labs afirma que no hubo fondos en riesgo. El fallo residía en el bucle que verificaba las cuentas que autorizaban un lote. Si el código encontraba un firmante de una cuenta recién creada cuya clave coincidía con esa cuenta, devolvía éxito inmediatamente en lugar de continuar con los firmantes restantes. Un atacante podía colocar primero ese firmante válido y luego añadir una entrada falsificada que pretendía autorizar una cuenta víctima. Si la enmienda hubiera entrado en vigor, la transacción de la víctima no verificada podría haberse ejecutado sin las claves de la víctima. La respuesta de XRPL llegó en dos etapas. La versión 3.1.1 marcó las enmiendas originales Batch y fixBatchInnerSigs como no compatibles, bloqueando su activación. BatchV1_1 las reemplazó posteriormente con una ruta de autorización reescrita y defensas adicionales. El episodio fue un fallo detectado en la frontera entre la publicación de software y la activación del protocolo. La especificación final XLS-56 de la Fundación XRPL ahora…