Una auditoría de seguridad de Sherlock identificó 96 errores en el código del XRP Ledger antes de que la versión llegara a los usuarios, lo que la convierte en una de las revisiones previas al despliegue más sustanciales reportadas para el software de la red.

Qué encontró la auditoría de Sherlock

La auditoría se realizó a través de la plataforma de revisión competitiva de Sherlock, que alojó el concurso que cubrió la base de código del XRP Ledger. Bajo este modelo, investigadores de seguridad independientes examinan una base de código durante un período de revisión definido, y los problemas se señalan antes de que el código se distribuya. La revisión se dirigió al software central del libro mayor y no a una sola aplicación. Ese núcleo es rippled, la implementación de servidor de código abierto, escrita principalmente en C++, que los validadores y otros servidores ejecutan para operar la red, lo que ubica los problemas detectados más cerca de la base del libro mayor que los errores limitados a una sola aplicación o billetera.

Las revisiones de este tipo basadas en concursos, donde investigadores independientes compiten por pagos según hallazgos verificados, se han convertido en un elemento habitual de la seguridad de contratos inteligentes a través de plataformas como Sherlock y Code4rena. Ejecutar una contra el software de nodos de un libro mayor importante extiende el mismo modelo hacia capas más profundas de la infraestructura, desde los contratos a nivel de aplicación hasta el código que procesa cada transacción.

Según los reportes, el proceso reveló 96 errores antes de que el código llegara a una sola billetera. La cifra se refiere a problemas señalados durante el período de revisión, no a explotaciones confirmadas en producción.

La versión asociada a este ciclo está documentada en el propio registro de cambios de la actualización rippled 3.3.0 de la red, la versión que se encuentra en el centro del trabajo auditado.

Por qué es importante encontrar los errores antes del lanzamiento

Detectar fallas antes del despliegue significa que pueden corregirse mientras el código todavía está en revisión, en lugar de después de que esté funcionando en los validadores y en las billeteras de los usuarios. Ese momento oportuno es el valor central de una auditoría previa al lanzamiento.

Para un libro mayor enfocado en liquidaciones, el descubrimiento previo al lanzamiento reduce el riesgo de que un defecto llegue a producción, donde podrían verse afectados los fondos, el procesamiento de transacciones o el comportamiento del consenso. La auditoría funciona como un filtro entre el desarrollo y el uso en producción. Los riesgos son particulares para la infraestructura de este tipo: el XRP Ledger confirma los pagos mediante un proceso de acuerdo entre su conjunto de validadores en lugar de minería de prueba de trabajo, por lo que los defectos que afectan el manejo de transacciones o el consenso se encuentran en la capa de la que depende cada usuario de la red.

El equipo de operaciones del XRP Ledger dio a conocer la revisión a través de su canal oficial en X, subrayando que la auditoría fue parte del proceso de lanzamiento y no una respuesta a un incidente.

Qué significa esto para la supervisión del XRP Ledger de aquí en adelante

Incorporar una revisión externa de terceros añade una capa de escrutinio más allá de las pruebas internas, y la cantidad de errores reportada muestra que este tipo de revisiones todavía revela un volumen significativo de problemas incluso en infraestructura consolidada.

Las auditorías externas se han convertido en una señal de confianza habitual en el ámbito cripto, de manera similar a cómo las certificaciones de reservas marcaron el debate sobre el respaldo de las stablecoins cuando la auditoría de una firma Big Four a Tether reportó reservas superiores a los pasivos. La revisión de código y la certificación financiera persiguen el mismo objetivo: una garantía verificable para los usuarios.

Esa cuestión de garantía también se extiende a las salvaguardas a nivel de billetera, un área destacada recientemente cuando los usuarios de CyberWallet y Passkey enfrentaron un corte de retiros. La preparación de la versión en la capa de protocolo y la confiabilidad en la capa de billetera determinan en conjunto cuánto pueden depender los usuarios de una red.

Los detalles sobre los niveles de gravedad y la forma en que se resolvió cada problema no quedaron establecidos en los reportes disponibles, por lo que la importancia de este caso radica en la escala de la revisión y su momento previo al lanzamiento, y no en la naturaleza específica de los errores individuales. Las señales a observar de aquí en adelante son si un desglose de gravedad y notas de remediación acompañan la documentación de la versión, y si los concursos de terceros se repiten como parte permanente de los ciclos de lanzamiento de XRPL.

Aviso: Este artículo tiene únicamente fines informativos y no constituye asesoramiento financiero o de inversión. Los mercados de criptomonedas y activos digitales conllevan un riesgo significativo. Siempre investigue por su cuenta antes de tomar decisiones.