Los desarrolladores de XRP Ledger<\/strong> han defendido una decisi\u00f3n extraordinaria en materia de seguridad tras implementar una correcci\u00f3n cr\u00edtica<\/strong> del protocolo sin esperar el proceso est\u00e1ndar de aprobaci\u00f3n de validadores, que normalmente dura dos semanas. La actualizaci\u00f3n de emergencia<\/strong>, lanzada el 25 de septiembre, abord\u00f3 una vulnerabilidad de 11 a\u00f1os<\/strong> que podr\u00eda haber permitido a los atacantes crear XRP<\/strong> gastable m\u00e1s all\u00e1 del l\u00edmite de suministro previsto de la criptomoneda. Aunque los investigadores no encontraron evidencia de explotaci\u00f3n, el m\u00e9todo utilizado para eliminar la amenaza ha generado un debate sobre c\u00f3mo las redes descentralizadas deber\u00edan responder a emergencias.<\/p>\n Bajo el marco de gobernanza habitual de XRPL, los cambios que afectan el procesamiento de transacciones deben recibir el apoyo de m\u00e1s del 80%<\/strong> de los validadores de confianza durante dos semanas consecutivas antes de su activaci\u00f3n. Sin embargo, el parche de seguridad de septiembre sigui\u00f3 un procedimiento diferente. Seg\u00fan el informe oficial de vulnerabilidad, la correcci\u00f3n se hizo efectiva inmediatamente en cada servidor tras la actualizaci\u00f3n a xrpld 3.4.1<\/strong>, en lugar de activarse simult\u00e1neamente a trav\u00e9s de una enmienda aprobada. Los desarrolladores argumentaron que la gravedad de la vulnerabilidad del suministro de XRP hac\u00eda que el proceso normal fuera demasiado arriesgado. <\/p>\n \u00abPublicar el parche mientras se dejaba la falla explotable durante un per\u00edodo de votaci\u00f3n prolongado podr\u00eda haber proporcionado a los atacantes suficiente informaci\u00f3n para reproducir la explotaci\u00f3n.\u00bb<\/p><\/blockquote>\n El problema subyacente involucraba un desbordamiento de enteros<\/strong> en el motor de pagos. Transacciones especialmente dise\u00f1adas podr\u00edan haber causado que el sistema acreditara m\u00e1s XRP de lo que el remitente realmente pag\u00f3, potencialmente creando nuevos tokens. Los investigadores rastrearon el c\u00f3digo vulnerable hasta 2015<\/strong>, aunque no encontraron evidencia de que se hubiera explotado en una red p\u00fablica.<\/p>\n La decisi\u00f3n no estuvo exenta de consecuencias t\u00e9cnicas. Normalmente, las enmiendas se activan simult\u00e1neamente en servidores compatibles, asegurando que los validadores apliquen reglas de transacci\u00f3n id\u00e9nticas. La actualizaci\u00f3n de emergencia, en cambio, cre\u00f3 un per\u00edodo temporal en el que los servidores actualizados rechazar\u00edan ciertas transacciones maliciosas, mientras que las versiones m\u00e1s antiguas podr\u00edan seguir acept\u00e1ndolas. Esa discrepancia podr\u00eda, te\u00f3ricamente, haber interrumpido la validaci\u00f3n del libro mayor si los atacantes intentaban explotar la vulnerabilidad antes de que suficientes validadores se actualizaran. Sin embargo, el r\u00e1pido despliegue redujo esa exposici\u00f3n. M\u00e1s del 80%<\/strong> de los operadores en la Lista de Nodos \u00danicos predeterminada hab\u00edan instalado la versi\u00f3n 3.4.1<\/strong> para el 25 de septiembre, seg\u00fan la divulgaci\u00f3n del equipo de desarrollo.<\/p>\n La respuesta a esta situaci\u00f3n difiri\u00f3 de la correcci\u00f3n de seguridad Batch<\/strong>, que sigui\u00f3 el procedimiento normal de enmienda y se activ\u00f3 el 9 de octubre. El incidente ha suscitado preguntas sobre cu\u00e1nta autoridad<\/strong> deben ejercer los desarrolladores y los operadores de validadores durante emergencias severas de la red. Las cr\u00edticas se han centrado, en parte, en la distribuci\u00f3n temporal del software antes de que el c\u00f3digo fuente sensible a la seguridad se publicara p\u00fablicamente. Los partidarios argumentan que la coordinaci\u00f3n inmediata era necesaria para evitar que los atacantes explotaran una debilidad divulgada. La Fundaci\u00f3n XRPL ha rechazado las sugerencias de que los operadores fueron obligados a instalar la actualizaci\u00f3n, enfatizando que los validadores tomaron sus propias decisiones de actualizaci\u00f3n.<\/p>\n El debate tambi\u00e9n surge mientras las pr\u00f3ximas actualizaciones de pr\u00e9stamos de XRPL contin\u00faan avanzando a trav\u00e9s del proceso de votaci\u00f3n ordinario, demostrando que los cambios de protocolo rutinarios a\u00fan requieren un apoyo sostenido de los validadores. Los desarrolladores sostienen que eludir las enmiendas deber\u00eda reservarse para amenazas de seguridad excepcionalmente graves<\/strong>, en lugar de convertirse en una alternativa est\u00e1ndar a la gobernanza de la red. Para los poseedores de XRP, la preocupaci\u00f3n inmediata ha sido abordada: la vulnerabilidad fue corregida y los investigadores informaron que no hubo explotaci\u00f3n conocida. La pregunta a largo plazo es c\u00f3mo XRPL puede mantener la toma de decisiones descentralizada<\/strong> mientras responde lo suficientemente r\u00e1pido a futuras amenazas cr\u00edticas.<\/p>\n","protected":false},"excerpt":{"rendered":" Actualizaci\u00f3n de Seguridad en XRP Ledger Los desarrolladores de XRP Ledger han defendido una decisi\u00f3n extraordinaria en materia de seguridad tras implementar una correcci\u00f3n cr\u00edtica del protocolo sin esperar el proceso est\u00e1ndar de aprobaci\u00f3n de validadores, que normalmente dura dos semanas. La actualizaci\u00f3n de emergencia, lanzada el 25 de septiembre, abord\u00f3 una vulnerabilidad de 11 a\u00f1os que podr\u00eda haber permitido a los atacantes crear XRP gastable m\u00e1s all\u00e1 del l\u00edmite de suministro previsto de la criptomoneda. Aunque los investigadores no encontraron evidencia de explotaci\u00f3n, el m\u00e9todo utilizado para eliminar la amenaza ha generado un debate sobre c\u00f3mo las redes descentralizadas<\/p>\n","protected":false},"author":3,"featured_media":19447,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[64],"tags":[65,8,11117,872,11118],"class_list":["post-19448","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hack","tag-hack","tag-ripple","tag-validators","tag-xrpl","tag-xrpl-foundation"],"yoast_description":"Los desarrolladores de XRP Ledger implementaron un parche de emergencia para solucionar una vulnerabilidad de seguridad de 11 a\u00f1os, eludiendo la votaci\u00f3n habitual de validadores debido a su gravedad.","_links":{"self":[{"href":"https:\/\/satoshibrother.com\/es\/wp-json\/wp\/v2\/posts\/19448","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/satoshibrother.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/satoshibrother.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/satoshibrother.com\/es\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/satoshibrother.com\/es\/wp-json\/wp\/v2\/comments?post=19448"}],"version-history":[{"count":0,"href":"https:\/\/satoshibrother.com\/es\/wp-json\/wp\/v2\/posts\/19448\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/satoshibrother.com\/es\/wp-json\/wp\/v2\/media\/19447"}],"wp:attachment":[{"href":"https:\/\/satoshibrother.com\/es\/wp-json\/wp\/v2\/media?parent=19448"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/satoshibrother.com\/es\/wp-json\/wp\/v2\/categories?post=19448"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/satoshibrother.com\/es\/wp-json\/wp\/v2\/tags?post=19448"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Proceso de Gobernanza y Decisi\u00f3n de Emergencia<\/h2>\n
Detalles de la Vulnerabilidad y Consecuencias T\u00e9cnicas<\/h2>\n
Debate sobre la Autoridad de los Desarrolladores<\/h2>\n
Reflexiones Finales<\/h2>\n