Me doy cuenta de lo a menudo que el riesgo real en estas configuraciones modulares se encuentra en algún lugar que el consenso nunca toca.

He visto suficientes ciclos como para saber que la historia siempre empieza limpia: liquidación determinista, los activos se mueven dentro del EVM, solo un cambio de capa de ejecución. Luego, la arquitectura se divide. DuskDS mantiene el consenso, la disponibilidad de datos y la liquidación. DuskVM ejecuta los contratos nativos. DuskEVM se apoya en OP Stack y devuelve los resultados. El perímetro de seguridad se multiplica.

Algo de esto se siente familiar. El incidente del puente de enero lo volvió concreto. La versión oficial fue clara: no se trató de una vulneración del consenso ni del protocolo central. Solo fue la wallet de firma utilizada por el servicio de puente. Los fondos se movieron, los servicios se pausaron, y no hubo fallo del protocolo. Aun así, la ruta real del usuario seguía llevando la exposición.

AEGIS luego corrigió treinta y nueve problemas, siete de ellos críticos. Alias de sandbox en la VM, deserialización insegura, vinculación de comisiones y reembolsos en Phoenix, problemas con BLS. La lista abarca la ejecución, las transacciones, el consenso y las piezas que los rodean.

Sigo notando el mismo tipo de intercambio. Empujas el perímetro de seguridad hacia afuera y la responsabilidad de cada llamada entre capas se vuelve más difícil de ubicar. El consenso puede mantenerse intacto mientras que la ruta por la que realmente viajan los activos no lo hace. He visto este patrón suficientes veces como para no confiar del todo en la separación limpia que la gente describe. La fricción permanece, incluso cuando las etiquetas se ven ordenadas.
@Dusk_Foundation #dusk $DUSK