#dusk $DUSK
Estos días estoy revisando la documentación de DuskEVM de @Dusk y hay un detalle que antes de verdad pasé por alto:
En DuskEVM, el empaquetado de la transacción no significa que esa transacción ya haya terminado.
Con esta arquitectura actual, Dusk no se encarga de la misma cosa con DuskEVM y DuskDS.
Los contratos Solidity se ejecutan primero en DuskEVM; luego la transacción entra en el sequencer y se incluye en un bloque de L2. Después, el batcher todavía debe enviar los datos de la transacción a DuskDS, y el estado continúa confirmándose mediante mecanismos como el commitment y las fault proof.
Al final, quien se encarga del settlement y la disponibilidad de datos es DuskDS.
Así que, a partir de lo que entiendo ahora, cuando veo DuskEVM, no lo interpreto simplemente como “Dusk le añadió un EVM”.
Con más precisión, sería:
DuskEVM ejecuta; DuskDS determina si el resultado finalmente es válido.
Esto también explica por qué la documentación oficial distingue explícitamente entre transaction inclusion y settlement.
Incluso el flujo de withdrawal en el testnet actual deja ver esta idea de diseño: primero se inicia en DuskEVM, luego se demuestra en Dusk L1 y, al final, se finaliza; no es que en el lado de L2, cuando aparece como exitosa, todo se termine por completo.
Esta diferencia quizá no sea tan “sexy” para una transferencia normal, pero en un escenario financiero creo que es más bien importante.
Si valores, fondos, etc. de verdad se van a tokenizar y subir a la cadena, lo que al final le importa a la gente no es solo si “las transacciones van rápidas”, sino un problema más práctico:
¿En qué capa se alcanza finalmente la finalidad de ese estado?
Por eso, a continuación voy a mirar DuskEVM mainnet: además del rendimiento y la compatibilidad con Solidity, lo que más quiero ver es cómo se comporta realmente esta cadena de principio a fin desde execution hasta el settlement en DuskDS.
Al menos, con la división de responsabilidades a nivel de arquitectura, creo que ya la entiendo claramente.
Estos días estoy revisando la documentación de DuskEVM de @Dusk y hay un detalle que antes de verdad pasé por alto:
En DuskEVM, el empaquetado de la transacción no significa que esa transacción ya haya terminado.
Con esta arquitectura actual, Dusk no se encarga de la misma cosa con DuskEVM y DuskDS.
Los contratos Solidity se ejecutan primero en DuskEVM; luego la transacción entra en el sequencer y se incluye en un bloque de L2. Después, el batcher todavía debe enviar los datos de la transacción a DuskDS, y el estado continúa confirmándose mediante mecanismos como el commitment y las fault proof.
Al final, quien se encarga del settlement y la disponibilidad de datos es DuskDS.
Así que, a partir de lo que entiendo ahora, cuando veo DuskEVM, no lo interpreto simplemente como “Dusk le añadió un EVM”.
Con más precisión, sería:
DuskEVM ejecuta; DuskDS determina si el resultado finalmente es válido.
Esto también explica por qué la documentación oficial distingue explícitamente entre transaction inclusion y settlement.
Incluso el flujo de withdrawal en el testnet actual deja ver esta idea de diseño: primero se inicia en DuskEVM, luego se demuestra en Dusk L1 y, al final, se finaliza; no es que en el lado de L2, cuando aparece como exitosa, todo se termine por completo.
Esta diferencia quizá no sea tan “sexy” para una transferencia normal, pero en un escenario financiero creo que es más bien importante.
Si valores, fondos, etc. de verdad se van a tokenizar y subir a la cadena, lo que al final le importa a la gente no es solo si “las transacciones van rápidas”, sino un problema más práctico:
¿En qué capa se alcanza finalmente la finalidad de ese estado?
Por eso, a continuación voy a mirar DuskEVM mainnet: además del rendimiento y la compatibilidad con Solidity, lo que más quiero ver es cómo se comporta realmente esta cadena de principio a fin desde execution hasta el settlement en DuskDS.
Al menos, con la división de responsabilidades a nivel de arquitectura, creo que ya la entiendo claramente.