¿Y si hacer que la infraestructura de blockchain sea más fácil de usar a veces significa darle a los desarrolladores más de una forma de construir sobre ella?
Me di cuenta de esto al explorar DUSK, y su división entre DuskVM y DuskEVM me hizo detenerme. Por lo general, pienso en una blockchain como si tuviera un único entorno principal de ejecución, y todo lo demás como herramientas alrededor de él.
DUSK toma un camino diferente. DuskEVM proporciona la ejecución con Solidity y Vyper usando herramientas familiares de Ethereum, mientras que DuskVM ejecuta contratos de Rust/WASM directamente en el Dusk L1. Las dos rutas se asientan sobre la misma red subyacente, pero atienden a necesidades de desarrollo diferentes.
Al principio, esto parecía una conveniencia técnica. Luego empecé a pensar en el problema que hay debajo.
Los desarrolladores ya tienen hábitos, bibliotecas, carteras y bases de código que entienden. Pedirle a cada aplicación financiera que abandone esas herramientas solo para acceder a un entorno de liquidación distinto crea una fricción innecesaria. Al mismo tiempo, algunas aplicaciones pueden necesitar acceso directo a activos nativos, funciones de privacidad o capacidades de protocolo de nivel más bajo que un entorno EVM no ofrece de forma natural.
Ese equilibrio se siente sorprendentemente relevante para el diseño de infraestructura.
Mientras investigaba DUSK, me encontré preguntándome si a veces la interoperabilidad se discute de manera demasiado estrecha. Tal vez la compatibilidad no solo se trata de conectar cadenas diferentes; también puede significar permitir que coexistan distintos modelos de desarrollo sin obligar a cada aplicación a seguir un único camino técnico.
La pregunta interesante para mí es hasta dónde debe llegar la abstracción. La abstracción insuficiente crea fricción, mientras que demasiada puede ocultar capacidades que los desarrolladores eventualmente necesitarán.
DUSK hace que ese límite valga la pena examinarlo desde la perspectiva de quien construye, no solo desde una perspectiva de mercado.
#dusk $DUSK @Dusk
Me di cuenta de esto al explorar DUSK, y su división entre DuskVM y DuskEVM me hizo detenerme. Por lo general, pienso en una blockchain como si tuviera un único entorno principal de ejecución, y todo lo demás como herramientas alrededor de él.
DUSK toma un camino diferente. DuskEVM proporciona la ejecución con Solidity y Vyper usando herramientas familiares de Ethereum, mientras que DuskVM ejecuta contratos de Rust/WASM directamente en el Dusk L1. Las dos rutas se asientan sobre la misma red subyacente, pero atienden a necesidades de desarrollo diferentes.
Al principio, esto parecía una conveniencia técnica. Luego empecé a pensar en el problema que hay debajo.
Los desarrolladores ya tienen hábitos, bibliotecas, carteras y bases de código que entienden. Pedirle a cada aplicación financiera que abandone esas herramientas solo para acceder a un entorno de liquidación distinto crea una fricción innecesaria. Al mismo tiempo, algunas aplicaciones pueden necesitar acceso directo a activos nativos, funciones de privacidad o capacidades de protocolo de nivel más bajo que un entorno EVM no ofrece de forma natural.
Ese equilibrio se siente sorprendentemente relevante para el diseño de infraestructura.
Mientras investigaba DUSK, me encontré preguntándome si a veces la interoperabilidad se discute de manera demasiado estrecha. Tal vez la compatibilidad no solo se trata de conectar cadenas diferentes; también puede significar permitir que coexistan distintos modelos de desarrollo sin obligar a cada aplicación a seguir un único camino técnico.
La pregunta interesante para mí es hasta dónde debe llegar la abstracción. La abstracción insuficiente crea fricción, mientras que demasiada puede ocultar capacidades que los desarrolladores eventualmente necesitarán.
DUSK hace que ese límite valga la pena examinarlo desde la perspectiva de quien construye, no solo desde una perspectiva de mercado.
#dusk $DUSK @Dusk
