Enterrado en la documentación de DuskEVM hay un detalle que cambia la forma en que pienso la pregunta de “para qué se construye cada capa”: actualmente DuskEVM funciona sin mempool público: solo el secuenciador.
Esa es una elección arquitectónica real, no un simple ajuste. En la mayoría de cadenas EVM, las transacciones pendientes están en un mempool visible antes de su inclusión, que es exactamente la superficie que explotan los bots MEV y los front-runners. DuskEVM se lo salta por completo: ejecuta mediante un único secuenciador y luego publica los datos por lotes de vuelta en DuskDS para la liquidación y disponibilidad. DuskVM, en cambio, ejecuta directamente los contratos nativos en Rust/WASM de Dusk contra los modelos de transacciones de Phoenix/Moonlight: no hay herramientas EVM, pero la privacidad es nativa, no algo añadido.
Lo que me hizo profundizar: el incidente del puente del 16 de agosto. Una wallet gestionada por el equipo y usada para operaciones del puente fue marcada, se deshabilitaron direcciones y se pausaron los servicios de puente; es el mismo puente que mueve DUSK entre DuskDS y DuskEVM para el gas. Es un recordatorio de que la capa de conexión entre estas dos VMs sigue siendo una dependencia operativa, no un traspaso totalmente impuesto por el protocolo.
Lo que no puedo confirmar: el número real de transacciones de testnet de DuskEVM o el volumen de despliegue de contratos esta semana: las estadísticas de Blockscout no devolvieron datos sin una sesión renderizada en JS, así que me baso en la arquitectura documentada, no en el rendimiento en vivo.
¿Qué capa están eligiendo los builders ahora mismo, y por qué?
@Dusk_Foundation $DUSK #dusk
Esa es una elección arquitectónica real, no un simple ajuste. En la mayoría de cadenas EVM, las transacciones pendientes están en un mempool visible antes de su inclusión, que es exactamente la superficie que explotan los bots MEV y los front-runners. DuskEVM se lo salta por completo: ejecuta mediante un único secuenciador y luego publica los datos por lotes de vuelta en DuskDS para la liquidación y disponibilidad. DuskVM, en cambio, ejecuta directamente los contratos nativos en Rust/WASM de Dusk contra los modelos de transacciones de Phoenix/Moonlight: no hay herramientas EVM, pero la privacidad es nativa, no algo añadido.
Lo que me hizo profundizar: el incidente del puente del 16 de agosto. Una wallet gestionada por el equipo y usada para operaciones del puente fue marcada, se deshabilitaron direcciones y se pausaron los servicios de puente; es el mismo puente que mueve DUSK entre DuskDS y DuskEVM para el gas. Es un recordatorio de que la capa de conexión entre estas dos VMs sigue siendo una dependencia operativa, no un traspaso totalmente impuesto por el protocolo.
Lo que no puedo confirmar: el número real de transacciones de testnet de DuskEVM o el volumen de despliegue de contratos esta semana: las estadísticas de Blockscout no devolvieron datos sin una sesión renderizada en JS, así que me baso en la arquitectura documentada, no en el rendimiento en vivo.
¿Qué capa están eligiendo los builders ahora mismo, y por qué?
@Dusk_Foundation $DUSK #dusk