Encontré el problema de AEGIS más revelador fuera de la propia prueba de conocimiento cero. Un valor junto a él no estaba completamente controlado.
En la ruta de transacciones Phoenix de Dusk Network, un usuario podía comprometerse con un max_fee legítimo mientras la ejecución seguía consumiendo campos de comisión que no estaban vinculados en la misma historia de seguridad. Parámetros hostiles de gas podían provocar inflación de reembolsos o desbordamientos. Una dirección de reembolso modificable podía redirigir el valor.
La prueba era válida. La semántica de la transacción no estaba completamente conectada con ella.
Una comisión no es metadato inofensivo cuando la ruta de reembolso puede crear o redirigir valor.
Ese es un aviso útil para cualquier protocolo de privacidad. Probar una sola afirmación perfectamente no asegura los campos adyacentes en los que la ejecución confiará más adelante. El sistema debe vincular la prueba, la firma, el cálculo de la comisión, el destino y la ruta de reembolso en una sola invariante.
AEGIS añadió la multiplicación verificada para gas_limit por gas_price y exigió que el resultado fuera igual al max_fee probado. Dusk hizo cumplir esa comprobación dos veces: al admitir en el mempool y de nuevo dentro de la ejecución de la VM. También vinculó la dirección sigilosa de reembolso para que cualquier manipulación invalidara la transacción.
La segunda comprobación es el detalle que me importa. Un proponente malicioso de bloque no tiene por qué respetar las suposiciones de un mempool honesto. Si la invariante existe solo en el borde de la red, el consenso aún puede ejecutar una transacción que evitó ese borde.
Ahora vigilaría el mismo patrón de defensa en Dusk: rechazo barato antes de la admisión, validación autorizada en la ejecución, y pruebas de regresión que muten cada campo alrededor de una prueba.
AEGIS cerró las rutas críticas conocidas. La pregunta más grande es si otros contratos de Dusk contienen valores que se "comprueban" en una capa y se confían simplemente en la siguiente.
La criptografía puede probar exactamente lo que se le pide probar. La seguridad depende de que Dusk solicite la afirmación completa.
#dusk $DUSK @Dusk
En la ruta de transacciones Phoenix de Dusk Network, un usuario podía comprometerse con un max_fee legítimo mientras la ejecución seguía consumiendo campos de comisión que no estaban vinculados en la misma historia de seguridad. Parámetros hostiles de gas podían provocar inflación de reembolsos o desbordamientos. Una dirección de reembolso modificable podía redirigir el valor.
La prueba era válida. La semántica de la transacción no estaba completamente conectada con ella.
Una comisión no es metadato inofensivo cuando la ruta de reembolso puede crear o redirigir valor.
Ese es un aviso útil para cualquier protocolo de privacidad. Probar una sola afirmación perfectamente no asegura los campos adyacentes en los que la ejecución confiará más adelante. El sistema debe vincular la prueba, la firma, el cálculo de la comisión, el destino y la ruta de reembolso en una sola invariante.
AEGIS añadió la multiplicación verificada para gas_limit por gas_price y exigió que el resultado fuera igual al max_fee probado. Dusk hizo cumplir esa comprobación dos veces: al admitir en el mempool y de nuevo dentro de la ejecución de la VM. También vinculó la dirección sigilosa de reembolso para que cualquier manipulación invalidara la transacción.
La segunda comprobación es el detalle que me importa. Un proponente malicioso de bloque no tiene por qué respetar las suposiciones de un mempool honesto. Si la invariante existe solo en el borde de la red, el consenso aún puede ejecutar una transacción que evitó ese borde.
Ahora vigilaría el mismo patrón de defensa en Dusk: rechazo barato antes de la admisión, validación autorizada en la ejecución, y pruebas de regresión que muten cada campo alrededor de una prueba.
AEGIS cerró las rutas críticas conocidas. La pregunta más grande es si otros contratos de Dusk contienen valores que se "comprueban" en una capa y se confían simplemente en la siguiente.
La criptografía puede probar exactamente lo que se le pide probar. La seguridad depende de que Dusk solicite la afirmación completa.
#dusk $DUSK @Dusk
