Reordené las 12 líneas del índice oficial de auditoría de Dusk: primero las clasifiqué por componentes y luego pegué las fechas al lado. Después de completar la tabla, la frase que antes sonaba tan fluida, “Dusk ya ha sido auditado”, dejó de poder escribirse tal cual: cada informe tiene su propio objeto y su propio tiempo; ninguna línea se llama “certificado total de toda la pila de código actual”.
Las dos últimas entradas son las evaluaciones de seguridad de ERC20 y BEP20 de abril de 2026. Los reportes sobre el protocolo central, el consenso, los nodos, Phoenix, etc., se concentran principalmente en 2023–2024. No se trata de que lo nuevo sea más importante que lo viejo, sino de que los informes solo pueden hablar de los componentes que realmente revisaron. Los módulos añadidos después y las versiones con cambios significativos no pueden heredar, solo por compartir nombre de proyecto, las conclusiones de los informes antiguos.
Esta tabla realmente cambió mi forma de verificar. A partir de ahora, cuando vea propaganda de seguridad, no voy a discutir primero “¿sirve la auditoría?”, sino pedir cuatro cosas: el nombre del informe, el componente auditado, la fecha de auditoría y la versión correspondiente. Solo cuando las cuatro coinciden, sigo leyendo los hallazgos y los recibos de corrección; si solo dan el logo del proyecto o el logo de la entidad auditora, la información se queda en la capa de promoción.
Para $DUSK , esta limitación no es una intención de llevar la contraria. Que el repositorio de auditoría sea público y que los informes se puedan rastrear es, en sí mismo, algo bueno. Pero definir bien el alcance permite ver qué parte ya tiene evidencia y qué parte, por cambios de versión, necesita pruebas adicionales. Los informes antiguos tampoco deberían declararse sin más como inválidos: solo que no pueden garantizar automáticamente objetos que no cubrieron.
Hay otras dos cosas que no se pueden deducir de estas 12 líneas. En esta ocasión no juzgué la calidad de cada informe, ni verifiqué punto por punto si todos los problemas fueron completamente corregidos; que un índice público no liste un material no puede demostrar que en otro lugar no exista. El índice proporcionado por @Dusk sirve como punto de entrada, no como el final de la conclusión.
Una frase como “auditado” ahorra muchas palabras, pero también ahorra el límite más importante. Al desplegar estas 12 líneas, por fin la evaluación de seguridad tiene sujeto rastreable, tiempo y versión. La próxima vez que alguien use un criterio de “todo el proyecto” para sacar conclusiones, le pediré que primero señale exactamente qué línea es la que corresponde. #dusk
Las dos últimas entradas son las evaluaciones de seguridad de ERC20 y BEP20 de abril de 2026. Los reportes sobre el protocolo central, el consenso, los nodos, Phoenix, etc., se concentran principalmente en 2023–2024. No se trata de que lo nuevo sea más importante que lo viejo, sino de que los informes solo pueden hablar de los componentes que realmente revisaron. Los módulos añadidos después y las versiones con cambios significativos no pueden heredar, solo por compartir nombre de proyecto, las conclusiones de los informes antiguos.
Esta tabla realmente cambió mi forma de verificar. A partir de ahora, cuando vea propaganda de seguridad, no voy a discutir primero “¿sirve la auditoría?”, sino pedir cuatro cosas: el nombre del informe, el componente auditado, la fecha de auditoría y la versión correspondiente. Solo cuando las cuatro coinciden, sigo leyendo los hallazgos y los recibos de corrección; si solo dan el logo del proyecto o el logo de la entidad auditora, la información se queda en la capa de promoción.
Para $DUSK , esta limitación no es una intención de llevar la contraria. Que el repositorio de auditoría sea público y que los informes se puedan rastrear es, en sí mismo, algo bueno. Pero definir bien el alcance permite ver qué parte ya tiene evidencia y qué parte, por cambios de versión, necesita pruebas adicionales. Los informes antiguos tampoco deberían declararse sin más como inválidos: solo que no pueden garantizar automáticamente objetos que no cubrieron.
Hay otras dos cosas que no se pueden deducir de estas 12 líneas. En esta ocasión no juzgué la calidad de cada informe, ni verifiqué punto por punto si todos los problemas fueron completamente corregidos; que un índice público no liste un material no puede demostrar que en otro lugar no exista. El índice proporcionado por @Dusk sirve como punto de entrada, no como el final de la conclusión.
Una frase como “auditado” ahorra muchas palabras, pero también ahorra el límite más importante. Al desplegar estas 12 líneas, por fin la evaluación de seguridad tiene sujeto rastreable, tiempo y versión. La próxima vez que alguien use un criterio de “todo el proyecto” para sacar conclusiones, le pediré que primero señale exactamente qué línea es la que corresponde. #dusk