Pasé esta mañana revisando cómo en realidad una transacción de duskevm se mueve a través del sistema y, sinceramente? 😂 Asumí que, una vez que aparecía en un bloque, ya estaba. Resulta que no es del todo así.
Entonces, duskevm es la capa compatible con EVM en dusk: significa que escribes en Solidity, usas wallets EVM normales y herramientas estándar como foundry o hardhat, y pagas el gas en dusk. Pero la transacción no vive y muere en duskevm por sí sola. Pasa por un ciclo de vida estilo rollup. Primero se envía al sequencer de duskevm, luego se incluye en un bloque de L2 relativamente rápido. Después, un batcher publica los datos de la transacción en duskds, que es la capa real de liquidación y disponibilidad de datos de Dusk. Las confirmaciones de estado y las pruebas de fallos son lo que conectan ese estado resultante de vuelta a duskds, así que en realidad queda liquidado, no solo “sentado” en algún bloque de L2 esperando.
Lo que no paro de tener en la cabeza es una línea de la documentación que marca la inclusión y la liquidación como etapas genuinamente diferentes, y que las apps que mueven valor entre duskevm y el dusk L1 deberían comprobar el estado del protocolo o de la wallet en lugar de asumir que algo es final solo porque ha pasado el tiempo. Esa es una distinción real, no una simple formalidad. No he encontrado en ningún sitio que explique cuánto suele durar ese intervalo en la práctica: la inclusión rápida claramente no significa liquidación instantánea, pero no sé la ventana real que alguien debería esperar.
Aun así, la decisión de diseño tiene sentido para mí. En vez de construir una cadena EVM totalmente separada flotando por su cuenta, duskevm se mantiene anclado a duskds para la liquidación y la disponibilidad de datos. Así obtienes todo el tooling de Solidity sin perder las garantías base sobre la finalidad.
Honestamente, no sé si esa brecha de inclusión a liquidación es lo bastante pequeña como para ignorarla en el día a día, o si los builders necesitan tenerla en cuenta activamente?
🤔
#dusk @Dusk $DUSK
Entonces, duskevm es la capa compatible con EVM en dusk: significa que escribes en Solidity, usas wallets EVM normales y herramientas estándar como foundry o hardhat, y pagas el gas en dusk. Pero la transacción no vive y muere en duskevm por sí sola. Pasa por un ciclo de vida estilo rollup. Primero se envía al sequencer de duskevm, luego se incluye en un bloque de L2 relativamente rápido. Después, un batcher publica los datos de la transacción en duskds, que es la capa real de liquidación y disponibilidad de datos de Dusk. Las confirmaciones de estado y las pruebas de fallos son lo que conectan ese estado resultante de vuelta a duskds, así que en realidad queda liquidado, no solo “sentado” en algún bloque de L2 esperando.
Lo que no paro de tener en la cabeza es una línea de la documentación que marca la inclusión y la liquidación como etapas genuinamente diferentes, y que las apps que mueven valor entre duskevm y el dusk L1 deberían comprobar el estado del protocolo o de la wallet en lugar de asumir que algo es final solo porque ha pasado el tiempo. Esa es una distinción real, no una simple formalidad. No he encontrado en ningún sitio que explique cuánto suele durar ese intervalo en la práctica: la inclusión rápida claramente no significa liquidación instantánea, pero no sé la ventana real que alguien debería esperar.
Aun así, la decisión de diseño tiene sentido para mí. En vez de construir una cadena EVM totalmente separada flotando por su cuenta, duskevm se mantiene anclado a duskds para la liquidación y la disponibilidad de datos. Así obtienes todo el tooling de Solidity sin perder las garantías base sobre la finalidad.
Honestamente, no sé si esa brecha de inclusión a liquidación es lo bastante pequeña como para ignorarla en el día a día, o si los builders necesitan tenerla en cuenta activamente?
🤔
#dusk @Dusk $DUSK