DuskEVM es interesante porque no le pide a los desarrolladores de EVM que empiecen desde cero.
Si ya estás construyendo con Solidity, Vyper, Foundry, Hardhat, viem o ethers, la idea es llevar ese flujo de trabajo familiar al stack de Dusk.
Pero lo que me resulta más interesante es lo que ocurre por debajo.
DuskEVM es el entorno de ejecución compatible con Ethereum, mientras que DuskDS se encarga del consenso, el settlement y la disponibilidad de datos. DUSK se utiliza para la ejecución y puede moverse entre Dusk L1 y DuskEVM mediante el bridge.
También vale la pena prestar atención al flujo de transacciones.
Una transacción primero llega al sequencer de DuskEVM y luego se incluye en un bloque L2. El batcher publica los datos de la transacción en DuskDS, mientras que las confirmaciones de estado y las pruebas de fallos conectan el estado resultante con el settlement de DuskDS.
Esa última parte es importante porque la inclusión de una transacción y el settlement no son lo mismo. Solo ver una transacción incluida no significa que debas asumir finality basándote únicamente en el tiempo transcurrido.
También me gusta que Dusk no esté forzando que todas las aplicaciones se metan en el mismo entorno.
Para aplicaciones en Solidity, carteras EVM y herramientas existentes de Ethereum, DuskEVM es la ruta obvia.
Para contratos en Rust/WASM que necesitan funcionar directamente con Dusk L1, DuskVM sigue siendo la opción.
Así que lo interesante no es simplemente "Dusk ahora tiene EVM".
Lo interesante es que Dusk le está dando a los desarrolladores un entorno de ejecución familiar mientras lo mantiene conectado a su propia capa de settlement y disponibilidad de datos.
@Dusk_Foundation
#dusk
$DUSK
Si ya estás construyendo con Solidity, Vyper, Foundry, Hardhat, viem o ethers, la idea es llevar ese flujo de trabajo familiar al stack de Dusk.
Pero lo que me resulta más interesante es lo que ocurre por debajo.
DuskEVM es el entorno de ejecución compatible con Ethereum, mientras que DuskDS se encarga del consenso, el settlement y la disponibilidad de datos. DUSK se utiliza para la ejecución y puede moverse entre Dusk L1 y DuskEVM mediante el bridge.
También vale la pena prestar atención al flujo de transacciones.
Una transacción primero llega al sequencer de DuskEVM y luego se incluye en un bloque L2. El batcher publica los datos de la transacción en DuskDS, mientras que las confirmaciones de estado y las pruebas de fallos conectan el estado resultante con el settlement de DuskDS.
Esa última parte es importante porque la inclusión de una transacción y el settlement no son lo mismo. Solo ver una transacción incluida no significa que debas asumir finality basándote únicamente en el tiempo transcurrido.
También me gusta que Dusk no esté forzando que todas las aplicaciones se metan en el mismo entorno.
Para aplicaciones en Solidity, carteras EVM y herramientas existentes de Ethereum, DuskEVM es la ruta obvia.
Para contratos en Rust/WASM que necesitan funcionar directamente con Dusk L1, DuskVM sigue siendo la opción.
Así que lo interesante no es simplemente "Dusk ahora tiene EVM".
Lo interesante es que Dusk le está dando a los desarrolladores un entorno de ejecución familiar mientras lo mantiene conectado a su propia capa de settlement y disponibilidad de datos.
@Dusk_Foundation
#dusk
$DUSK