El resultado más peligroso no es necesariamente que los nodos se enfrenten entre sí, sino que todos los nodos llamen al mismo conjunto de código de verificación y, de forma metódica, verifiquen de manera incorrecta.
He comparado el libro blanco histórico de @Dusk con la documentación actual. Los materiales antiguos se referían a este runtime Rust/WASM como Piecrust; la documentación vigente lo llama DuskVM. El nombre ha evolucionado, pero el diseño clave no ha cambiado: los contratos pueden delegar verificaciones criptográficas como PLONK, Groth16, BLS, etc., en el nivel de host mediante un punto de entrada público, sin necesidad de implementarlo cada uno por su cuenta.
Las ventajas son muy concretas. Los desarrolladores escriben menos un juego de código criptográfico propenso a errores, y los nodos no tienen que repetir en el sandbox WASM los cálculos de bajo nivel; las aplicaciones quedan más ligeras y las reglas de verificación se unifican con mayor facilidad.
El costo también se concentra. Si un contrato de aplicación se equivoca, normalmente primero se perjudica a sí mismo; si el validador compartido falla en el análisis de entradas, en la selección de versión o en condiciones de borde, todos los contratos que dependan de él pueden verse afectados. A nivel de toda la red es todo consistente: solo se puede demostrar que todos ejecutaron la misma regla.
En la actualización Aegis de Dusk de marzo de 2026 se habilitaron PLONK V3 y el nuevo comportamiento de BLS; además, la consulta host de BLS usada por los contratos se cambia según la altura del bloque. Los bloques históricos llaman al verificador antiguo, mientras que los nuevos datos usan la versión nueva; si se elige mal la altura, podría llegarse a conclusiones distintas sobre la validez de las transacciones.
Por eso no solo revisaré informes de auditoría: también vigilaré la versión del validador, la altura de la actualización, los vectores de prueba, la invalidez de caché y los ensayos de reversión. $DUSK asume el Gas y la seguridad del consenso, pero además estos puntos de verificación pública sostienen las aplicaciones financieras. La velocidad determina qué tan rápido corre un sistema; el validador determina si los errores también se ejecutarán con la misma rapidez.
#dusk
He comparado el libro blanco histórico de @Dusk con la documentación actual. Los materiales antiguos se referían a este runtime Rust/WASM como Piecrust; la documentación vigente lo llama DuskVM. El nombre ha evolucionado, pero el diseño clave no ha cambiado: los contratos pueden delegar verificaciones criptográficas como PLONK, Groth16, BLS, etc., en el nivel de host mediante un punto de entrada público, sin necesidad de implementarlo cada uno por su cuenta.
Las ventajas son muy concretas. Los desarrolladores escriben menos un juego de código criptográfico propenso a errores, y los nodos no tienen que repetir en el sandbox WASM los cálculos de bajo nivel; las aplicaciones quedan más ligeras y las reglas de verificación se unifican con mayor facilidad.
El costo también se concentra. Si un contrato de aplicación se equivoca, normalmente primero se perjudica a sí mismo; si el validador compartido falla en el análisis de entradas, en la selección de versión o en condiciones de borde, todos los contratos que dependan de él pueden verse afectados. A nivel de toda la red es todo consistente: solo se puede demostrar que todos ejecutaron la misma regla.
En la actualización Aegis de Dusk de marzo de 2026 se habilitaron PLONK V3 y el nuevo comportamiento de BLS; además, la consulta host de BLS usada por los contratos se cambia según la altura del bloque. Los bloques históricos llaman al verificador antiguo, mientras que los nuevos datos usan la versión nueva; si se elige mal la altura, podría llegarse a conclusiones distintas sobre la validez de las transacciones.
Por eso no solo revisaré informes de auditoría: también vigilaré la versión del validador, la altura de la actualización, los vectores de prueba, la invalidez de caché y los ensayos de reversión. $DUSK asume el Gas y la seguridad del consenso, pero además estos puntos de verificación pública sostienen las aplicaciones financieras. La velocidad determina qué tan rápido corre un sistema; el validador determina si los errores también se ejecutarán con la misma rapidez.
#dusk
