He estado profundizando en @Dusk y en sus dos rutas de ejecución: DuskEVM para contratos en Solidity y DuskVM para contratos nativos en Rust/WASM.

El diseño técnico tiene sentido. Pero lo que realmente me hizo detenerme fue el comportamiento de los desarrolladores que podría generar.

Dejé de mirar solo la documentación y empecé a pensar en lo que los desarrolladores realmente elegirán.

DuskEVM resulta familiar, con el ecosistema de herramientas de EVM que los desarrolladores ya conocen. DuskVM profundiza en el runtime a través de Forge: gestiona el trabajo repetitivo, las exportaciones de WASM y los data drivers, mientras que el estado del contrato vive directamente en la memoria lineal y se serializa con rkyv.

Espera: eso crea una contradicción interesante.

DuskVM puede ofrecer un entorno de ejecución más nativo y potencialmente con menos sobrecarga, pero DuskEVM quizá siga siendo la elección obvia simplemente porque es más fácil de construir.

Ese es el vacío que me parece más interesante que la propia arquitectura de Rust/WASM.

No estoy diciendo que DuskVM sea defectuoso aquí. El modelo de ejecución nativo está haciendo exactamente lo que fue diseñado para hacer.

La pregunta real es si la ventaja técnica es lo bastante fuerte como para cambiar el comportamiento de los desarrolladores.

Me recuerda a elegir entre una herramienta familiar que hace el trabajo y una más especializada que te da un control más profundo, pero que te pide aprender primero un nuevo flujo de trabajo.

Si los desarrolladores siguen eligiendo DuskEVM, ¿DuskVM se convertirá en un entorno de ejecución técnicamente potente pero de nicho?

¿O podría el despliegue nativo llegar a convertirse en una señal significativa de la utilidad de red más profunda de #Dusk ?
$DUSK $KII $AKE
#RedditToJoinSP500 #US30YBondAuctionYieldHighestSince2001 #GlobalStocksNearRecordHighs #ProCapFilesBitcoinTreasuryDiscountETF