#dusk $DUSK @Dusk Hay un hallazgo de auditoría de Dusk que hace que la idea de «verificar mediante aritmética» sea más interesante de lo que parece.
El argumento es simple: la emisión es fija, las recompensas son proporcionales a la participación (stake), así que cualquiera puede reconstruir lo que obtuvo un validador a partir de números públicos. Sin panel de control. Sin confianza ciega. Solo aritmética.
Pero hay una capa debajo de esa suposición: ¿los números en sí son correctos?
La revisión de Oak Security de la capa de consenso de Dusk y de la biblioteca de nodos de Rusk encontró problemas de lógica de validación en la capa responsable de determinar si las transiciones de estado son válidas.
Se detectaron antes de mainnet y se corrigieron, con todos los problemas críticos/mayores resueltos antes del lanzamiento.
Eso es bueno. Pero resalta una distinción importante:
Transparencia y corrección no son la misma garantía.
Un libro contable puede hacer que sus números sean completamente visibles. Eso no significa automáticamente que la lógica que produce esos números sea impecable.
La propiedad de «verificar mediante aritmética» es valiosa precisamente porque las reglas de consenso subyacentes son correctas. Una auditoría ayuda a establecerlo — pero un hallazgo de auditoría también muestra por qué esa garantía no puede simplemente asumirse.
Entonces, ¿dónde trazarías la línea de confianza?
¿Una segunda auditoría independiente, años de producción impecable, o algo más?
#dusk @Dusk $DUSK
El argumento es simple: la emisión es fija, las recompensas son proporcionales a la participación (stake), así que cualquiera puede reconstruir lo que obtuvo un validador a partir de números públicos. Sin panel de control. Sin confianza ciega. Solo aritmética.
Pero hay una capa debajo de esa suposición: ¿los números en sí son correctos?
La revisión de Oak Security de la capa de consenso de Dusk y de la biblioteca de nodos de Rusk encontró problemas de lógica de validación en la capa responsable de determinar si las transiciones de estado son válidas.
Se detectaron antes de mainnet y se corrigieron, con todos los problemas críticos/mayores resueltos antes del lanzamiento.
Eso es bueno. Pero resalta una distinción importante:
Transparencia y corrección no son la misma garantía.
Un libro contable puede hacer que sus números sean completamente visibles. Eso no significa automáticamente que la lógica que produce esos números sea impecable.
La propiedad de «verificar mediante aritmética» es valiosa precisamente porque las reglas de consenso subyacentes son correctas. Una auditoría ayuda a establecerlo — pero un hallazgo de auditoría también muestra por qué esa garantía no puede simplemente asumirse.
Entonces, ¿dónde trazarías la línea de confianza?
¿Una segunda auditoría independiente, años de producción impecable, o algo más?
#dusk @Dusk $DUSK