#dusk $DUSK Entré en el análisis de seguridad de la AEGIS de Dusk esperando encontrar una lista de fallos.
En cambio, no dejaba de pensar en lo que ocurre después de que un fallo toca una red en vivo.
AEGIS corrigió 39 hallazgos, incluidos 7 críticos. Algunos no eran meros problemas estéticos: afectaban a la ejecución determinista, la autenticación del consenso, la integridad de las tarifas e incluso la disponibilidad de la cadena.
Eso me hizo ver la seguridad de otra manera.
Una revisión de código puede reducir el riesgo técnico, pero por sí sola no puede lograr que una red se comporte correctamente bajo presión. El modelo de validador de Dusk añade otra capa: la participación fallida puede desencadenar penalizaciones suaves, mientras que un comportamiento de consenso demostrablemente inválido puede llevar a que se queme la participación (stake).
Así que, en realidad, hay tres piezas en movimiento aquí: el código tiene que ejecutarse correctamente, los validadores tienen que comportarse correctamente y la economía tiene que hacer que la mala conducta salga cara.
Ninguna de esas capas sustituye a otra.
Esa es la parte que no había considerado cuando miré por primera vez la AEGIS. Ahora la veo menos como un “certificado de seguridad” y más como un componente de un ciclo de seguridad más amplio.
La pregunta interesante para @Dusk no es si el código puede hacerse más seguro.
Es si el código, los validadores y los incentivos siguen reforzándose entre sí cuando la red está bajo presión real.
Ahí es donde vive la suposición de seguridad más profunda.
#dusk $DUSK @Dusk
En cambio, no dejaba de pensar en lo que ocurre después de que un fallo toca una red en vivo.
AEGIS corrigió 39 hallazgos, incluidos 7 críticos. Algunos no eran meros problemas estéticos: afectaban a la ejecución determinista, la autenticación del consenso, la integridad de las tarifas e incluso la disponibilidad de la cadena.
Eso me hizo ver la seguridad de otra manera.
Una revisión de código puede reducir el riesgo técnico, pero por sí sola no puede lograr que una red se comporte correctamente bajo presión. El modelo de validador de Dusk añade otra capa: la participación fallida puede desencadenar penalizaciones suaves, mientras que un comportamiento de consenso demostrablemente inválido puede llevar a que se queme la participación (stake).
Así que, en realidad, hay tres piezas en movimiento aquí: el código tiene que ejecutarse correctamente, los validadores tienen que comportarse correctamente y la economía tiene que hacer que la mala conducta salga cara.
Ninguna de esas capas sustituye a otra.
Esa es la parte que no había considerado cuando miré por primera vez la AEGIS. Ahora la veo menos como un “certificado de seguridad” y más como un componente de un ciclo de seguridad más amplio.
La pregunta interesante para @Dusk no es si el código puede hacerse más seguro.
Es si el código, los validadores y los incentivos siguen reforzándose entre sí cuando la red está bajo presión real.
Ahí es donde vive la suposición de seguridad más profunda.
#dusk $DUSK @Dusk