#dusk $DUSK @Dusk fui a averiguar hoy por qué dusk incluso se molesta en ejecutar dos entornos de ejecución separados en lugar de simplemente elegir uno, y sinceramente? 😂 la respuesta resultó ser más de un intercambio real que de un alarde técnico.
así que duskvm es un entorno wasm construido alrededor de wasmtime, y se ejecuta directamente en el propio dusk l1, sin necesidad de salto de liquidación como requiere duskevm a través de duskds, del que escribí hace un tiempo. está pensado para contratos de rust que quieren una integración más estrecha con los propios modelos de transacción de dusk, activos a nivel de protocolo y capacidades específicas de privacidad o zk. duskevm, en cambio, existe puramente para solidity y las herramientas estándar de evm: foundry, hardhat, wallets existentes, todo el ecosistema ethereum que la gente ya conoce. la propia documentación de dusk aporta números reales sobre por qué esta división importa; aparentemente, una integración l1 a medida puede tardar de seis a doce meses y costar alrededor de cincuenta veces más que un despliegue evm comparable, y señalan a exchanges que pasan meses adaptándose a dusk nativo frente a semanas para integraciones evm.
lo que sigo pensando desde que leí esos números es si esa brecha de costos empuja en silencio a casi todo el mundo hacia duskevm por defecto, incluso proyectos que en realidad se beneficiarían más de la integración nativa de privacidad más estrecha de duskvm. si el camino de menor resistencia es mucho más barato y rápido, ¿la opción más difícil pero más enfocada termina quedando subutilizada independientemente de que encaje? no he visto nada que aborde directamente esa tensión.
aun así, ofrecer a los creadores dos caminos reales en lugar de imponer un único modelo de compromiso a todo el mundo es una respuesta legítima a necesidades genuinamente diferentes, no solo complejidad añadida por el gusto.
honestamente no sé si esa brecha de costos termina guiando a la mayoría de los proyectos serios hacia duskevm o si duskvm se mantiene firme para los casos de uso que realmente lo requieren.
🤔
#dusk @Dusk $DUSK
así que duskvm es un entorno wasm construido alrededor de wasmtime, y se ejecuta directamente en el propio dusk l1, sin necesidad de salto de liquidación como requiere duskevm a través de duskds, del que escribí hace un tiempo. está pensado para contratos de rust que quieren una integración más estrecha con los propios modelos de transacción de dusk, activos a nivel de protocolo y capacidades específicas de privacidad o zk. duskevm, en cambio, existe puramente para solidity y las herramientas estándar de evm: foundry, hardhat, wallets existentes, todo el ecosistema ethereum que la gente ya conoce. la propia documentación de dusk aporta números reales sobre por qué esta división importa; aparentemente, una integración l1 a medida puede tardar de seis a doce meses y costar alrededor de cincuenta veces más que un despliegue evm comparable, y señalan a exchanges que pasan meses adaptándose a dusk nativo frente a semanas para integraciones evm.
lo que sigo pensando desde que leí esos números es si esa brecha de costos empuja en silencio a casi todo el mundo hacia duskevm por defecto, incluso proyectos que en realidad se beneficiarían más de la integración nativa de privacidad más estrecha de duskvm. si el camino de menor resistencia es mucho más barato y rápido, ¿la opción más difícil pero más enfocada termina quedando subutilizada independientemente de que encaje? no he visto nada que aborde directamente esa tensión.
aun así, ofrecer a los creadores dos caminos reales en lugar de imponer un único modelo de compromiso a todo el mundo es una respuesta legítima a necesidades genuinamente diferentes, no solo complejidad añadida por el gusto.
honestamente no sé si esa brecha de costos termina guiando a la mayoría de los proyectos serios hacia duskevm o si duskvm se mantiene firme para los casos de uso que realmente lo requieren.
🤔
#dusk @Dusk $DUSK