Lo que me llamó la atención es que la actualización Boreas de Dusk hizo que la ejecución fallida de contratos fuera más visible, no menos.
Desde el despliegue de Boreas en mainnet del 10 de junio de 2026, en el bloque 4,414,095, los eventos de contratos revertidos aún pueden conservarse en los datos de archivo con un marcador explícito “reverted”. Al mismo tiempo, esos eventos fallidos se eliminan del bloom del bloque canónico, y los eventos de stake revertidos se excluyen de las actualizaciones del estado del provisioner.
Esa distinción importa más de lo que parece a primera vista.
Una llamada revertida no debería cambiar el estado canónico. Pero para aplicaciones financieras, borrar por completo el rastro del evento puede dificultar la depuración, la conciliación y la revisión forense. Dusk está separando “este evento ocurrió durante la ejecución” de “este evento pasó a formar parte de un estado válido”.
Esperaba una cadena enfocada en la privacidad que minimizara el detalle de ejecución retenido. En cambio, DuskFoundation está preservando un rastro de auditoría más claro para la actividad de contratos fallidos, manteniendo al mismo tiempo el indexado canónico limpio.
Mi interpretación: es un detalle pequeño del protocolo con una relevancia inusualmente fuerte para las finanzas onchain reguladas. La auditabilidad no solo trata de ver transferencias exitosas; también se trata de demostrar qué falló y asegurarse de que nunca contaminó el estado.
Lo que estoy observando: si los exploradores y las herramientas institucionales presentarán claramente esta metainformación de eventos revertidos para que los usuarios puedan beneficiarse.
@Dusk $DUSK #dusk
Desde el despliegue de Boreas en mainnet del 10 de junio de 2026, en el bloque 4,414,095, los eventos de contratos revertidos aún pueden conservarse en los datos de archivo con un marcador explícito “reverted”. Al mismo tiempo, esos eventos fallidos se eliminan del bloom del bloque canónico, y los eventos de stake revertidos se excluyen de las actualizaciones del estado del provisioner.
Esa distinción importa más de lo que parece a primera vista.
Una llamada revertida no debería cambiar el estado canónico. Pero para aplicaciones financieras, borrar por completo el rastro del evento puede dificultar la depuración, la conciliación y la revisión forense. Dusk está separando “este evento ocurrió durante la ejecución” de “este evento pasó a formar parte de un estado válido”.
Esperaba una cadena enfocada en la privacidad que minimizara el detalle de ejecución retenido. En cambio, DuskFoundation está preservando un rastro de auditoría más claro para la actividad de contratos fallidos, manteniendo al mismo tiempo el indexado canónico limpio.
Mi interpretación: es un detalle pequeño del protocolo con una relevancia inusualmente fuerte para las finanzas onchain reguladas. La auditabilidad no solo trata de ver transferencias exitosas; también se trata de demostrar qué falló y asegurarse de que nunca contaminó el estado.
Lo que estoy observando: si los exploradores y las herramientas institucionales presentarán claramente esta metainformación de eventos revertidos para que los usuarios puedan beneficiarse.
@Dusk $DUSK #dusk
