$DUSK #dusk — DuskEVM muestra una confirmación antes de que Dusk haya resuelto realmente algo. La propia documentación de desarrolladores de @Dusk es explícita: la inclusión de transacciones es rápida, pero la inclusión y la liquidación son etapas distintas, y a las apps que mueven valor entre DuskEVM y la L1 se les indica revisar el estado del protocolo o de la wallet, no el tiempo transcurrido, para saber qué es definitivo. El secuenciador ejecuta al instante, el batcher publica los datos en DuskDS como blobs y el proponente publica un compromiso de estado después. Tres actores, tres momentos — solo ves el primero.
Revisé GitHub para contexto: dusk-network/duskevm-genesis, el repo que contiene el bloque génesis real de DuskEVM y la configuración del rollup, se actualizó por última vez el 8 de agosto. Dos días después, una actualización fechada el 10 de agosto seguía describiendo DuskEVM como testnet — desplegar y probar con Hardhat y Solidity — a pesar de que en otras partes ya había publicaciones de enero que lo llamaban un "lanzamiento de mainnet". Que aún se estuviera tocando la configuración génesis en agosto encaja con la etapa de testnet, no con la etapa de mainnet.
La tarifa dual (ejecución en L2 más una tarifa separada de disponibilidad de datos en DuskDS) hace tangible la etapa: estás pagando dos capas por un trabajo secuencial, no una sola. Es el mismo enfoque en el que coinciden el repo del génesis y los docs: la liquidación es un evento distinto y posterior a la ejecución, tanto a nivel de código como a nivel de anuncio.
Lo que cambió para mí: DuskEVM vs DuskVM no es una elección de lenguaje, Solidity vs Rust. Es en qué etapa de la finalidad se construye realmente una aplicación. En DuskVM, ejecución y liquidación son el mismo evento. En DuskEVM, no. Cualquiera que integre DuskEVM ahora mismo — ¿tu app está leyendo el estado de liquidación, o solo está esperando la inclusión?
Siguiente: revisar duskevm-genesis para el primer commit que deja de tocar la configuración del rollup — esa es una señal más limpia de preparación para mainnet que cualquier anuncio.
#dusk $DUSK @Dusk
Revisé GitHub para contexto: dusk-network/duskevm-genesis, el repo que contiene el bloque génesis real de DuskEVM y la configuración del rollup, se actualizó por última vez el 8 de agosto. Dos días después, una actualización fechada el 10 de agosto seguía describiendo DuskEVM como testnet — desplegar y probar con Hardhat y Solidity — a pesar de que en otras partes ya había publicaciones de enero que lo llamaban un "lanzamiento de mainnet". Que aún se estuviera tocando la configuración génesis en agosto encaja con la etapa de testnet, no con la etapa de mainnet.
La tarifa dual (ejecución en L2 más una tarifa separada de disponibilidad de datos en DuskDS) hace tangible la etapa: estás pagando dos capas por un trabajo secuencial, no una sola. Es el mismo enfoque en el que coinciden el repo del génesis y los docs: la liquidación es un evento distinto y posterior a la ejecución, tanto a nivel de código como a nivel de anuncio.
Lo que cambió para mí: DuskEVM vs DuskVM no es una elección de lenguaje, Solidity vs Rust. Es en qué etapa de la finalidad se construye realmente una aplicación. En DuskVM, ejecución y liquidación son el mismo evento. En DuskEVM, no. Cualquiera que integre DuskEVM ahora mismo — ¿tu app está leyendo el estado de liquidación, o solo está esperando la inclusión?
Siguiente: revisar duskevm-genesis para el primer commit que deja de tocar la configuración del rollup — esa es una señal más limpia de preparación para mainnet que cualquier anuncio.
#dusk $DUSK @Dusk