#XRPLedgerPatchesXRPCreationBug 🚨 ¿Y si un solo pago hubiera podido crear XRP que nunca debió existir?
El XRP Ledger acaba de revelar una falla de seguridad que podría haber puesto en entredicho una de sus reglas más importantes: su oferta fija de 100 mil millones de XRP.
Esto es lo que hace que esta historia sea seria.
Un error oculto de desbordamiento de enteros en el motor de pagos podría haber permitido que ofertas de intercambio cuidadosamente elaboradas generaran XRP gastable sin pagar el monto completo adeudado.
Según los informes, la falla se remontaba aproximadamente a 2015.
Pero aquí está el detalle crucial: 🧵
→ Los investigadores informaron del problema en septiembre.
→ La versión de emergencia "xrpld 3.4.1" de XRPL incluyó la corrección el 25 de septiembre.
→ La corrección correspondiente se activó en la red principal el 9 de octubre.
→ Los desarrolladores informaron que no había evidencia de explotación en redes públicas.
Esto no fue un robo confirmado de XRP. Fue una vulnerabilidad que podría haber socavado las garantías de suministro del libro mayor si se hubiera explotado.
Y esa es la lección más grande: la seguridad de una blockchain no consiste solo en impedir que los hackers roben activos existentes. También se trata de asegurar que el sistema nunca cree activos que no deberían existir.
Pero aquí está la pregunta difícil: si una falla crítica puede sobrevivir durante más de una década, ¿qué debería importar más al evaluar una blockchain: su historial de seguridad o qué tan eficazmente descubre, divulga y corrige las vulnerabilidades?
El XRP Ledger acaba de revelar una falla de seguridad que podría haber puesto en entredicho una de sus reglas más importantes: su oferta fija de 100 mil millones de XRP.
Esto es lo que hace que esta historia sea seria.
Un error oculto de desbordamiento de enteros en el motor de pagos podría haber permitido que ofertas de intercambio cuidadosamente elaboradas generaran XRP gastable sin pagar el monto completo adeudado.
Según los informes, la falla se remontaba aproximadamente a 2015.
Pero aquí está el detalle crucial: 🧵
→ Los investigadores informaron del problema en septiembre.
→ La versión de emergencia "xrpld 3.4.1" de XRPL incluyó la corrección el 25 de septiembre.
→ La corrección correspondiente se activó en la red principal el 9 de octubre.
→ Los desarrolladores informaron que no había evidencia de explotación en redes públicas.
Esto no fue un robo confirmado de XRP. Fue una vulnerabilidad que podría haber socavado las garantías de suministro del libro mayor si se hubiera explotado.
Y esa es la lección más grande: la seguridad de una blockchain no consiste solo en impedir que los hackers roben activos existentes. También se trata de asegurar que el sistema nunca cree activos que no deberían existir.
Pero aquí está la pregunta difícil: si una falla crítica puede sobrevivir durante más de una década, ¿qué debería importar más al evaluar una blockchain: su historial de seguridad o qué tan eficazmente descubre, divulga y corrige las vulnerabilidades?