Cuanto más miro DuskEVM, más pienso que la parte interesante no es simplemente que Dusk ahora sea compatible con EVM.
Es que los desarrolladores no tienen que desechar el flujo de trabajo que ya conocen.
Si estás construyendo con Solidity, Foundry, Hardhat, viem, ethers o con carteras EVM familiares, DuskEVM está diseñado para llevar esa experiencia al ecosistema de Dusk.
Pero la arquitectura subyacente es lo que llamó mi atención.
DuskEVM se encarga de la ejecución compatible con Ethereum, mientras que DuskDS proporciona la capa subyacente de consenso, liquidación y disponibilidad de datos.
DUSK se usa para la ejecución, y puede moverse entre Dusk L1 y DuskEVM mediante el puente.
También vale la pena entender la ruta de la transacción.
Una transacción llega al secuenciador de DuskEVM, se incluye en un bloque L2 y el batcher publica los datos de la transacción en DuskDS. Luego, las confirmaciones de estado y las pruebas de fallos conectan el estado resultante de vuelta a DuskDS para la liquidación.
Esa distinción importa.
La inclusión de una transacción no es automáticamente lo mismo que la liquidación final.
También me gusta que Dusk no esté obligando a cada desarrollador a entrar en un solo entorno.
Los desarrolladores de EVM pueden usar DuskEVM y sus herramientas existentes, mientras que quienes construyen contratos en Rust/WASM directamente para Dusk L1 pueden seguir usando DuskVM.
Así que mi conclusión es bastante simple:
DuskEVM no es interesante solo porque brinda compatibilidad con EVM a Dusk.
Es interesante porque ofrece a los desarrolladores un entorno de ejecución familiar, al tiempo que conecta ese entorno con la propia arquitectura de liquidación y disponibilidad de datos de Dusk.
Eso se siente como una historia mucho más grande que simplemente decir: “Dusk ya tiene un EVM”.
@Dusk_Foundation
#dusk $DUSK
$EDEN $AKE
Es que los desarrolladores no tienen que desechar el flujo de trabajo que ya conocen.
Si estás construyendo con Solidity, Foundry, Hardhat, viem, ethers o con carteras EVM familiares, DuskEVM está diseñado para llevar esa experiencia al ecosistema de Dusk.
Pero la arquitectura subyacente es lo que llamó mi atención.
DuskEVM se encarga de la ejecución compatible con Ethereum, mientras que DuskDS proporciona la capa subyacente de consenso, liquidación y disponibilidad de datos.
DUSK se usa para la ejecución, y puede moverse entre Dusk L1 y DuskEVM mediante el puente.
También vale la pena entender la ruta de la transacción.
Una transacción llega al secuenciador de DuskEVM, se incluye en un bloque L2 y el batcher publica los datos de la transacción en DuskDS. Luego, las confirmaciones de estado y las pruebas de fallos conectan el estado resultante de vuelta a DuskDS para la liquidación.
Esa distinción importa.
La inclusión de una transacción no es automáticamente lo mismo que la liquidación final.
También me gusta que Dusk no esté obligando a cada desarrollador a entrar en un solo entorno.
Los desarrolladores de EVM pueden usar DuskEVM y sus herramientas existentes, mientras que quienes construyen contratos en Rust/WASM directamente para Dusk L1 pueden seguir usando DuskVM.
Así que mi conclusión es bastante simple:
DuskEVM no es interesante solo porque brinda compatibilidad con EVM a Dusk.
Es interesante porque ofrece a los desarrolladores un entorno de ejecución familiar, al tiempo que conecta ese entorno con la propia arquitectura de liquidación y disponibilidad de datos de Dusk.
Eso se siente como una historia mucho más grande que simplemente decir: “Dusk ya tiene un EVM”.
@Dusk_Foundation
#dusk $DUSK
$EDEN $AKE