#dusk $DUSK
Estos dos días lo volví a revisar otra vez, el documento de arquitectura de @Dusk , y encontré un problema: en realidad, antes lo simplifiqué demasiado.
Al final, DuskEVM también vuelve a hacer settlement con DuskDS, entonces, ¿por qué conservar por separado DuskVM?
Al principio pensé que era simplemente porque los lenguajes de desarrollo son distintos: uno es Solidity y el otro Rust/WASM.
Pero si sigo leyendo, la diferencia está en la ruta de ejecución.
DuskVM se ejecuta directamente en L1.
DuskEVM no. La transacción primero pasa por el sequencer, se ejecuta a nivel de EVM y luego aún hay batch, commitment del estado, y finalmente se vuelve a conectar con DuskDS.
Así que, aunque al final aterrice en la misma capa de settlement, lo que ocurre en medio es totalmente distinto.
Creo que esta diferencia es bastante importante.
Ya existe un conjunto de productos en Solidity; si quieres hacer pocos cambios y migrar, entonces DuskEVM tiene todo el sentido. Las herramientas y los hábitos de desarrollo ya están bastante familiarizados.
Pero si la aplicación en sí necesita tocar directamente L1, o si quiere usar la capacidad nativa de Dusk y lógica a nivel de protocolo, entonces forzarlo para pasar por esta capa de EVM quizá no sea necesario.
Así que ahora ya no me quiebro la cabeza con cuál de DuskEVM y DuskVM es “más avanzado”.
Me parecen dos caminos.
Uno para facilitar que entren los desarrolladores actuales de EVM.
Y el otro para quienes, desde el principio, querían usar capacidades Dusk-native de manera directa.
Al final, los dos pueden conectar con DuskDS, pero no es lo mismo el execution path.
Esa es también la parte que me hace pensar que la arquitectura de Dusk vale más la pena investigarla que un “L1 compatible con EVM” más.
Estos dos días lo volví a revisar otra vez, el documento de arquitectura de @Dusk , y encontré un problema: en realidad, antes lo simplifiqué demasiado.
Al final, DuskEVM también vuelve a hacer settlement con DuskDS, entonces, ¿por qué conservar por separado DuskVM?
Al principio pensé que era simplemente porque los lenguajes de desarrollo son distintos: uno es Solidity y el otro Rust/WASM.
Pero si sigo leyendo, la diferencia está en la ruta de ejecución.
DuskVM se ejecuta directamente en L1.
DuskEVM no. La transacción primero pasa por el sequencer, se ejecuta a nivel de EVM y luego aún hay batch, commitment del estado, y finalmente se vuelve a conectar con DuskDS.
Así que, aunque al final aterrice en la misma capa de settlement, lo que ocurre en medio es totalmente distinto.
Creo que esta diferencia es bastante importante.
Ya existe un conjunto de productos en Solidity; si quieres hacer pocos cambios y migrar, entonces DuskEVM tiene todo el sentido. Las herramientas y los hábitos de desarrollo ya están bastante familiarizados.
Pero si la aplicación en sí necesita tocar directamente L1, o si quiere usar la capacidad nativa de Dusk y lógica a nivel de protocolo, entonces forzarlo para pasar por esta capa de EVM quizá no sea necesario.
Así que ahora ya no me quiebro la cabeza con cuál de DuskEVM y DuskVM es “más avanzado”.
Me parecen dos caminos.
Uno para facilitar que entren los desarrolladores actuales de EVM.
Y el otro para quienes, desde el principio, querían usar capacidades Dusk-native de manera directa.
Al final, los dos pueden conectar con DuskDS, pero no es lo mismo el execution path.
Esa es también la parte que me hace pensar que la arquitectura de Dusk vale más la pena investigarla que un “L1 compatible con EVM” más.